LWN.net Logo

The LGPL and video codecs

The LGPL and video codecs

Posted Jun 11, 2009 8:43 UTC (Thu) by masuel (guest, #28661)
In reply to: The LGPL and video codecs by tzafrir
Parent article: The LGPL and video codecs

(Disclosure: I work for one of the patent holders in the mpeg-la pool)

The current licence is 0$ for "internet broadcast" that in iteslf free to the end user. This will expire at the end of 2010...

If anyone wants more details look here:

http://www.mpegla.com/avc/avc-agreement.cfm

However this is I realise beside the point. It may help to explain why people are happy to agree to this, Google btw is already listed as being a "Licensees in good standing".

The current situation seems to be very much on a don't ask / don't tell basis in both directions (MPEG-LA and FFMPEG) ... But will that change? I don't think so. The MPEG-LA group want to increase adoption and taking action against people who are making no money makes no scene. On the other hand would ffmpeg (and associated projects) like to publicise the fact that there work is (possibly) unusable?

Personally I would like to see increased adoption of Durac and Theora but I don't think mpeg-la will deliberately take any action that will/could make this a priority for many people.

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.

Youtube and the like also want there place in the living room and that nearly always means hardware decoders.


(Log in to post comments)

The LGPL and video codecs

Posted Jun 11, 2009 9:32 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

What about after 2010? Their actions must encourage open alternatives then

The LGPL and video codecs

Posted Jun 11, 2009 10:27 UTC (Thu) by masuel (guest, #28661) [Link]

Hopefully :)

But they try and make it easy to comply with terms like

"100,000 or fewer subscribers during the year = no royalty;"

(with equivalent terms for players).

Then just get money out of the big players and hope not to let anyone else get momentum to be a viable alternative... This seems to be the strategy to me.

The exact terms for 2011 onwards are not yet available (will be discussed this December?)...

I would hope that motivation for open alternatives is already there, but the existing solutions are in a very strong position and not yet being too provocative.

The LGPL and video codecs

Posted Jun 11, 2009 15:50 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]

Also exciting is the annual cap for big organizations.

Here is how it really works:

If you're too small to be a good source of income, but your usage can help cement adoption through network effect… You can use it at no cost.

If you're big enough that you could easily cause adoption of an alternative all on your own, you benefit from an annual cap that lessens the pain and gives you a competitive advantage over medium sized players (who pay a higher effective per-download fee than you do, so they can't be as competitive)

For everyone else: The pricing depends on the viability of alternatives. MP3 pricing went to a small fraction of their prior rates right after Vorbis hit 1.0.

Since viability depends on adoption and adoption decisions happen individually it's possible to charge much higher than the frictionless free market fair-price. The cost of getting a new format adopted is low from an overall perspective, but if you believe that you have to carry most of the burden yourself it can be rather high unless you are a very large org.

This market inefficiency goes away if people collaborate and share the cost of driving the adoption of an alternative. H.264 patent holders (Nokia and Apple) were able to obstruct one obvious attempt at cooperation, the HTML5 baseline recommendation, but they can't block them all. There are also a few large players, like Wikimedia and Mozilla, which are somewhat immune to the cap incentive because they don't compete like normal commercial players do.

(Correcting the article: As of right now Firefox has no support for plugins to add formats. Including such an option at this time would be damaging to their goal of getting a baseline format supported.)

There are some interesting consequences of all this: If you're not one of the few companies receiving royalties its in your interest to ensure that Ogg/Theora is widely and robustly supported— even if you never intend on using it, because only if the alternatives are viable can they exert downward price pressure.

The LGPL and video codecs

Posted Jun 11, 2009 18:17 UTC (Thu) by foom (subscriber, #14868) [Link]

(Correcting the article: As of right now Firefox has no support for plugins to add formats. Including such an option at this time would be damaging to their goal of getting a baseline format supported.)
Firefox certainly supports plugins as in Flash and Quicktime, which, btw, already support H.264 video. Since flash already has nearly 100% deployment, I'm don't really see what possible use it is to cripple the <video> element.

The LGPL and video codecs

Posted Jun 19, 2009 8:30 UTC (Fri) by jwalden (guest, #41159) [Link]

I understood the reference to be to plugins for video formats usable by the built-in <video> element. What you speak of goes through the plugin model and is entirely orthogonal to implementing HTML5 video support for a video format.

"Hardware support"

Posted Jun 11, 2009 16:01 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]

"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?)

"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.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds