| |||||||||||||
"Hardware support""Hardware support"Posted Jun 11, 2009 16:01 UTC (Thu) by gmaxwell (subscriber, #30048)In reply to: The LGPL and video codecs by masuel Parent article: The LGPL and video codecs
"The other part where H264 is clearly superior is hardware support. For my usage this point alone is a show stopper for the other contenders."
This is an often invoked spurious argument.
Direct implementation of decoders in asics largely stopped in the late 90s. Today codecs are implemented in 'hardware' by simply writing highly optimized code for more-or-less general purpose processors. (Either SIMD instruction sets like ARM's NEON, or side-car DSPs like the TMS320c64x included with the OMAP chips).
The remaining 'hardware' support for video includes things like hardware colorspace conversion which work equally well for all formats.
The reasons for this is that codecs are simply too volatile for the long development timelines of ASIC design... and that the enormous flexibility of modern codecs (like the variable block sizes in H.264) both greatly increases the gate count for dedicated hardware and reduces the performance gap between an optimized software implementation and a dedicated hardware one.
The Theora reference implementation doesn't currently include optimized assembly for neon or the various widely used DSPs like it does for x86 and x86_64. It makes a large performance difference, and hides the fact that Theora has lower computational complexity than H.264. But this is a *software* problem that can be solved at any point by any party. Not a hardware problem.
But just in case you do have a need for hardware support. There is a synthesizable VHDL implementation of the back half of Theora available. There is also a verilog implementation of dirac. (although perhaps only the dirac-pro subset?)
(Log in to post comments)
"Hardware support" Posted Jun 12, 2009 1:03 UTC (Fri) by ras (subscriber, #33059) [Link]
mod +1. Little gems like this make reading the comments so worthwhile.
"Hardware support" Posted Jun 12, 2009 1:07 UTC (Fri) by masuel (guest, #28661) [Link]
This is correct, Technically correct the best kind!
However often (always?!) the decoder related microcode is on a separate cpu to the main application one and the interface treats it as a hardware decoder. If you pay for the chip you get the current capabilities of the chip/microcode and any changes have to be negotiated. Adding a new codec can and has been done (eg vc1) but I don't know of any manufacture that provides enough access for a 3rd party to add it themselves.
The argument may be over simplification but for all practical purposes it still stands. Have you tried requesting access or feature changes to these devices? If you know of any solution that allows a relevant level of access then please let me know!
"Hardware support" Posted Jun 12, 2009 3:37 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]
That applies the set of devices using things marketed as "H.264 decoder" chips. They usually are some oddball semi-proprietary thing that comes with magic microcode blobs. It's still software, but not something the general world knows how to program. So my "anyone can fix it" doesn't apply. You have a good point there.
The WDTV, a kind of media playing set top box, is an example of a device using a blobby playback engine that could almost certainly play Theora if the maker of the chip cooperated. Some folks are trying to convince them— but I suspect that they'll need to improve their Chinese skills and order a few million chips before they get a return email.
Though, in many devices that people care about and can expect to get firmware upgrades for (i.e all(?!) current generation mobile devices) the decoding is done on a fairly conventional chips simply because the device is used for many purposes and thus needs a fast generally programmable CPU/DSP anyways which makes the parts count for a dedicated decoder unjustified. We can program these. It's just a question of someone sitting down and doing it.
"Hardware support" Posted Jun 12, 2009 4:47 UTC (Fri) by masuel (guest, #28661) [Link]
WDTV seems to use the Sigma Designs SMP8635LF (took some googling to find that)
So you would have to contact them I suspect. I don't think Western Digital have the kind of access we are talking about. The good news is if you speak American then the should be able to communicate fine. The bad news is that I don't think you will get anywhere without a large potential order to discuss.
I happen to have the SMP86** linux SDK and its a long way from the kind of access you would need to add a new codec.
WDTV, Sigma Designs and GPL source code for Linux Posted Jun 14, 2009 1:32 UTC (Sun) by jlokier (guest, #52227) [Link]
Thanks for mentioning the WDTV.
I've been looking for a long time for a legitimate download site for the sources of Sigma Designs' modified Linux kernel for SMP8634 chips.
I did find one very dubious-looking FTP URL in a forum, supposedly from a device manufacturer in Korea, but that leads to a lot of kernel source files which say "proprietary and confidential" on them and no indication that they are distributed under the GPL.
Western Digital's WDTV support site does provide the modified kernel source, which is a refreshing change!, although the copyright notices on many individual kernel files seem inconsistent with the GPL. Still, looks like GPL compliance is slowly improving with these Sigma Designs vendors, and Western Digital are to be commended for being better than average.
|
|||||||||||||