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?
> 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
Really? The BBC needs to stay up to date with technology in order to do the best job possible under its mandate. So that means that they are going to start out doing radio, spend money making television work the way they like it, then start promoting teletext (in the form of Ceefax), brand their own computer, and now they want to do the Internet their way (through an open codec).
It's worth reading their own history
for a perspective on just how much technical work the BBC has done since 1920. See also here.
John.
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
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.
> 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.