Archive for January, 2011

On WebM again: freedom, quality, patents

I have already presented my views on the relative patent risk of WebM, based on my preliminary analysis of the source code and some of the comment of Jason Garett-Glaser (Dark Shikari), author of the famous (and probably, unparalleled from the quality point of view) x264 encoder. The recent Google announcement, related to the intention to drop the patented H264 video support from Chrome and Chromium (with the implication that it will be probably dropped from other Google properties as well) raised substantial noise, starting with an Ars Technica analysis that claims that the decision is a step back for openness. There is an abundance of comments from many other observers, that mostly revolve around five separate ideas: that WebM is inferior, and thus it should not be promoted as an alternative, that WebM is a patent risk given the many H264 patents that may be infringed by it, that WebM is not open enough, that H264 is not so encumbered as not to be usable with free software (or not so costly for end users) and that Google provides no protection against other potential infringing patents. I will try, as much as possible, to provide some objective points to at least provide a more consistent baseline for discussion. This is not intended to say that WebM is sufficient for the success of HTML5 video tag – I believe that Christian Kaiser, VP of technology at Netflix, wrote eloquently about the subject here.

Quality: quality seems to be one the main criticism of WebM, and my previous post has been used several times to demonstrate that it does employ sub-par techniques (while my intention was to demonstrate that some design decisions were made to avoid existing patents, go figure). The relative roughness of most encoders, the limited time on the markete of the open source implementation led many to believe that WebM is more in the league with Theora (that is, not very good) and not in that of H264. The reality is that encoders are as important as the standard itself for evaluating quality, and this of course means that comparing WebM with the very best encoder in the market (x264) would probably not give much an indication on WebM itself. In fact, a very good comparison by the Moscow state university’s Graphics and media lab performed a very thorough evaluation of several encoders, and an interesting result is this:

conclusion_overall

(source: http://compression.graphicon.ru/video/codec_comparison/h264_2010/#Video_Codecs) where it is evident that there are major variations even among same-technology encoders, like Elecard, MainConcept and x264. And WebM? Our russian friends extended their analysis to it as well:

vp8_rd_ice

What this graph shows is the relative quality, measured using a sensible measure (not PSNR, that values blurriness more than data…) of various encoding done with different presets, with x264, WebM (here called VP8) and Xvid. It shows that WebM is slightly inferior to x264, that is it requires longer encoding times to reach the “normal” settings of x264; and it shows that it already beats by a wide margin xvid, one of the most widely used codecs. Considering that most H264 players are limited to the “baseline” H264 profile, the end result is that – especially with the maturing of command line tools (and the emergence of third party encoders, like Sorenson) we can safely say that WebM is or can be on the same quality level of H264.

WebM is a patent risk: I already wrote in my past article that it is clear that most design decisions in the original On2 encoder and decoder were made to avoid preexisting patents; curiously, most commenters used this to demonstrate that WebM is technically inferior, while highlighting the potential risk anyway. By going through the H264 “essential patent list”, however, I found that in the US (that has the highest number of covered patents) there are 164 non-expired patents, of which 31 specific to H264 advanced deblocking (not used in WebM), 34 related to CABAC/CAVAC not used in WebM, 16 on the specific bytecode stream syntax (substituted with Matroska), 45 specific to AVC. The remaining ones are (to a cursory reading) not overlapping with WebM specific technologies, at least as they are implemented in the libvpx library as released by Google (there is no guarantee that patented technologies are not added to external, third party implementations). Of course there may be patent claims on Matroska, or any other part of the encoding/decoding pair, but probably not from MPEG-LA.

WebM is not open enough: Dark Shikari commented, with some humor, of the poor state of the WebM standard: basically, the source code itself. This is not so unusual in the video coding world, with many pre-standards basically described through their code implementations. If you follow the history of ISO MPEG standards for video coding you will find many submissions based on a few peer-reviewed articles, source code and a short word document describing what it does; this is then replaced by well written (well, most of the time) documents detailing every and all the nooks and crannies of the standard itself. No such thing is available for WebM, and this is certainly a difficulty; on the other hand (and having been part, for a few years, of the italian ISO JTC1 committee) I can certainly say that it is not such a big hurdle; many technical standards are implemented even before ratification and “structuring”, and if the discussion forum is open there is certainly enough space for finding any contradictions or problems. On the other hand, the evolution of WebM is strictly in the hand of Google, and in this sense it is true that the standard is not “open” in the sense that there is a third party entity that manages its evolution.

H264 is not so encumbered-and is free anyway: Ah, the beauty of people reading only the parts that they like from licensing arrangements. H264 playback is free only for non-commercial use (whatever it is) of video that is web-distributed and freely accessible. Period. It is true that the licensing fees are not so high, but they are incompatible with free software, because the license is not transferable, because it depends on field of use, and in general cannot be sensibly applied to most licenses. The fact that x264 is GPL licenses does not mean much: the author has simply decided to ignore any patent claim, and implement whatever he likes (with incredibly good results, by the way). This does not means that suddenly you can start using H264 without thinking about patents.

Google provides no protection against other potential infringing patents: that’s true. Terrible, isn’t it? But, if you go looking at the uber-powerful MPEG-LA that gives you a license for the essential H264 patents, you will find the following text: “Q: Are all AVC essential patents included? A: No assurance is or can be made that the License includes every essential patent. The purpose of the License is to offer a convenient licensing alternative to everyone on the same terms and to include as much essential intellectual property as possible for their convenience. Participation in the License is voluntary on the part of essential patent holders, however.” So, if someone claims that you infringe on its patent, claiming that you licensed it from MPEG-LA is not a defense. And, just to provide an example, in the Microsoft vs. Alcatel/Lucent case, MS had to fight quite a long time to have the claim dismissed (after an initial 1.52B$ damages decision). In a previous effort for creating an open video codec by Sun Microsystem, Sun similarly did not introduce a patent indemnification clause in it – in fact, in one of the OMV presentations this text was included: “While we are encouraged by our findings so far, the investigation continues and Sun and OMC cannot make any representations regarding encumbrances or the validity or invalidity of any patent claims or other intellectual property rights claims a third party may assert in connection with any OMC project or work product.”

So, after all this text, I think that there may be some more complexity behind Google’s decision to drop H264 than “we want to kill Apple”, as some commenters seem to think – and the final line is: software patents are adding a degree of complexity to the ICT world that is becoming, in my humble opinion, damaging in too many ways – not only in terms of uncertainty, but adding a great friction in the capability of companies and researchers to bring innovation to the market. Something that, curiously, patent promoters describe as their first motivation.

40 Comments