Slashdot Mirror
BBC Wants Help With Dirac Codec
Number Ten Ox writes "According to The Register the BBC wants help to develop their open source video codec Dirac. '[Lead developer Dr. Thomas] Davies said the codec could live on anything from mobile phones to high-definition TVs but not before a lot of further work is completed. For one thing, Dirac doesn't currently work in real-time. Davies also reckons that the compression offered by the technology could be further optimised. The BBC is working on integrating the technology with its other systems, but the corporation would welcome more help in developing Dirac.' Sounds like something worth helping with."
If they want to make an open source video codec, why don't they just support and help further develop the ogg video codec? Would the two codecs be so different that they are both needed?
Have there been any comparisons? Do we really need two fully scalable open-source video codecs?
Also - the BBC is funded by the British government. When did they get a mandate to spend money developing video codecs. I don't have a problem with government-funded "arts" but this seems a bit beyond the normal scope of things
What the major difference with this codec is. Why is the BBC developing their own codec instead of, for instance, throwing a few bucks towards OGM or XVid, or $YOUR_FAVORITE_OSS_CODEC?
I don't need no instructions to know how to rock!!!!
BLING BLING. Meet the architecture that's changing everything.
Can you please list all of the Open and non patent encumbered codecs? I can only think of Theora. Of all the codecs out there just about every one is enbumbered by a patent or license fee or DRM which hinders thier usage for distribution of public content such as documentaries.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
Wrong. Theora is nearly there, whereas Dirac isn't even working in realtime (RTFS). And, it lets them stay with one paradigm (I can't believe I just used that word) because Theora has an audio analogue (ogg) whereas Dirac doesn't.
And that's ignoring the benefit of being involved with an OSS project that, while rough around the edges, has a large development community already (both Theora devs and the potential pool of Ogg devs who could be enticed to work on Theora), rather than starting a new OSS project.
I'm wary of the fact that this "call for help" comes just days after over 1400 BBC technology staff were out sourced to Siemens
1) It's pounds, not dollars. UK, remember? We have GBP over here.
2) The Government doesn't run it. It's state-sponsored, but has it's own independant board of governers.
3) They have no share-holders: therefore no profit motive. Any money they might make goes back into making new programs etc.
4) They aren't trying to become self-sufficient: they're quite happy being given the license fee and maybe making some money by selling program formats (as somebody pointed out to me earlier)
5) It doesn't accept advertising money. They are banned from doing so. A while ago there was trouble because they happened to mention that Coca-Cola sponsors the UK music charts on the BBC's Top of the Pops (the chart show).
It is _trivial_ to develop a system that attempts to eveolve various mechanisms to encode data, but to iterate each generation you need some sort of way to determine the winners and the losers.
:-)
I am not so naive as to be suggesting human evaluation here, give me some credit willya?
First off, as a side point, for lossless encoding evaluation is trivial.
Secondly, there has indeed been much work towards automated performance evaluation of lossy codecs. Not too much on video yet, but a lot on audio, right down to the level of modeling the resulting neural impulses generated by a waveform in the human ear. By using existing research which involved human viewing and listening surveys (Other people's PHd's), developing fitness tests is not as hard as you make it out to be.
Finally, while evolving a whole CODEC is probably not practical with today's CPU power, there are a lot of subsystems which could be optimized through GA/GP to improve their efficiency. Many times in an algorithm you have a subsystem who's functionality is well defined, but who's optimal implementation or parameters are not known.
For example, many algorithms use lookup tables, and I'm sure a clever mathemetician could come up with a family of symmetrical transform functions that vary across a set of coefficients. Those are probably the cases which GA should tackle first, because the search space is much smaller and represents a constant, a "coefficient" to use the term very loosly, of an algorithm rather than a whole algorithm.
The general idea here is not to magically create the best looking/sounding CODEC ever out of thin air. It is to take the goals which we suspect will result in good CODECs and find new algorithms to acheive them. Once we find optimal solutions to those, we either dissect them for insight, which improves our base of theory, or at that point we submit them for side-by-side human comparison with existing CODECs.
Someone had to do it.
How does dirac compare to MPEG-4 when it comes to compression? And how about performance?
I'd think that the argument someone made in an early post about the BBC not being a software development company applies. It only makes sense for the BBC to be involved in media distribution development to a very limited extent. Hiring a single person (or a few people) to coordinate the CODEC development makes sense. Hiring a full blown programming team wouldn't. They will need a continual progression of work over a long-term. They will also not be licensing the technology or getting a revenue for it. So why would they hire anybody to develop it?
I would be surprised to find any BBC worker who was laid off from a BBC 'software CODEC programming job' because of OS development. If anything, it will boost the productivity of employees working on the CODEC, by allowing them to develop the CODEC more quickly and robustly. This is a matter of asking the community to help develop a tool that it would like to use, without footing the full bill.
Besides that, why shouldn't I be allowed to give my own time? I can volunteer in a hospital, a shelter or as a tutor, why shouldn't I be able to volunteer my high-tech skills for a cause I believe to be worthwhile. Isn't it worthwhile to reduce the cost of disseminating the 'free press'?
"BEGIN TROLL FILTER" The US & britain are bombing other countries in the hopes of bringing them freedom. Why not support a better dissemination of information to them, to help distribute a picture of what is going on in the rest of the world. Change can be voluntary instead. "END TROLL FILTER"
Should a large portion of the BBC IT staff be paid to develop CODECs? I believe not, it's not the BBC's task to develop distribution media. However, you are raising a completely extraneous point, since I'm in no way replacing in-house IT staff. But if I felt that I could volunteer time for replacing IT staff, why should I feel bad about it?
I'm not quite sure what upsets you about this whole issue, but please feel free to explain to me how developing a useful, novel open-source CODEC puts IT staff out of work.
By contrast, the government is all too happy to jump onto Corporate America's IP bandwagon, with its Super-DMCA laws*, support for software patents and other such nonsense.
K
* In fact the Copyright and Regulated Relations Act 2002 passed in the UK makes it illegal to do anything that bypasses copy protection, not just traffic in "devices" as in the US. I guess marking a CD with a magic marker is now a criminal offense in the UK.
> The fact that it is currently unable to decode video in a meaning manner at normal speed concerns me greatly. This suggests that it's already 10-100x times slower than current generation video codecs.
Until recent optimisations, I haven't been able to decode broadcast resolution video realtime with any theora players. The issue is C/C++ vs vector assembler (ie, SSE/3dNOW) for the main transform.
The DCT has many fast implementations, the Mallet transform doesn't - lifting is one part of that, but the wavelet filters (along with the lifting algorithm) need implementing in assembler.
I work for another Establishment organisation and we and others are working on improving the situation. Having the BBC as a shining light really does help.