The recently concluded 2010 Google I/O Developer Conference saw three important developments from a consumer perspective, namely, the introduction of Android 2.2 (Froyo), announcement of the WebM initiative and finally, Google TV. First off, we will discuss the controversial WebM / VP8 project, and then talk about Google TV.

One of the most talked about announcements made during the 2010 Google I/O Developer Conference was the open sourcing of the VP8 codec, and the adoption of a Matroska based container termed as WebM. Much has been written online about how VP8 would save the world from the clutches of MPEG-LA. However, there have been rebuttals too, where people analyzed the licensing terms for VP8 and realized that Google offers no patent indemnification for potential users. Coupled with the talk from the MPEG-LA CEO about the creation of a patent pool for VP8, things seem pretty murky with a lot of FUD being spread around. Moving on to the technical side of things, one of x264's (the open source H264 encoder) main developers, Jason Garrett-Glaser, has an in-depth analysis of VP8. In his post, he points out the various shortcomings of the codec, as compared to H264. Detractors have pointed to his role as a developer for x264 as a source for bias in his views, but fail to realize that, as an open source developer, he is free to work on any technically sound spec that he wants. In the rest of this section, we will provide our perspective on the developments surrounding VP8 and WebM

VP8 - The Good

By open sourcing VP8, Google has fired a shot against the MPEG-LA, indicating that they wouldn't remain unchallenged. When one analyzes the reasons as to why VP8 was open sourced, it is easy to see that MPEG-LA's draconian licensing policy was to blame. While indicating that H264 would be free for web use till 2016, it made no forward looking statements regarding the eventual licensing situation after that. This basically meant that open source based organizations such as Mozilla and Wikimedia (which intend to stay free of patent encumbrances in all countries) were hesitant to implement H264 technology in their products. Open source enthusiasts clamored for technology which could stand up to the mighty H264 in terms of technical prowess, particularly considering the fact that Theora compared very poorly with it.

It would be for the good of H264 and its patent holders (not just in monetary terms) if it were to be made more popular by getting used in web videos all over. The sooner MPEG-LA realizes this, the better it is for all concerned. There needed to be a shift in the status quo for MPEG-LA to rethink its stance, and Google just caused that shift by open sourcing its $124 million purchase. How MPEG-LA responds to this remains to be seen.

How can the MPEG-LA satisfy the open source community, while also protecting the financial interests of its members? One avenue could be the introduction of licensing terms by which software based H264 decoders are exempt from any licensing fees. There are many open source H264 decoders already available (though they might not be completely legal in some countries right now), and this would mean that products such as Firefox need not have any reservations about including it in their browser bundle. Right now, MPEG-LA doesn't earn any money from the usage of H264 for web video. In order to get some financial returns, they could start charging websites which encode videos in H264, but also specify a revenue threshold below which these websites are not liable at all. A sample scenario would be a threshold of $5mn and the licensing charge for encoding the video in H264 could be .1% of any revenue above $5mn which was generated based on the usage of H264 video on that website. Of course, these are just ideas which MPEG-LA could think of implementing, which would ensure that low traffic and hobby websites aren't affected at all in any way.

In a perfect world, we would have no software patents and everyone would be capable of using the best technology available. However, for now, we will have to put up with these types of laws and patents. The best that could happen in the present scenario is one where MPEG-LA announces that the situation currently existing (till 2016) would be extended in perpetuity.

VP8 - The Bad

As Jason's article shows, the VP8 specifications are quite lacking in technical prowess. The workarounds to circumvent the H264 patents seem obvious. There would also have been reasons why the original H264 people didn't use the workarounds themselves or patent them. Also glaring is the absence of any technical rebuttals to Jason's analysis (at least that we are aware of) from any Google engineers or other proponents of VP8. [ Update: User EmmetBrown has brought this recent official WebM blogpost to our attention. ] The introduction of VP8 may also lead to a demand from consumers that their camcorders and PVRs record video in this format. While companies are unlikely to yield in to this (and Google itself wants to use this for Internet videos only), there is a small likelihood of of a drawn out format war like Blu-Ray / HD-DVD or VHS / Betamax. In these situations, it is the consumer who becomes the ultimate loser.

Google presented a host of hardware companies who purportedly support hardware acceleration for VP8. They appear to be playing around loosely with the term 'hardware acceleration' here. It is inconceivable that a specification which Google got its hands on late last year could be made available to the multiple partners mentioned in time for them to perform hardware design, verify it and tapeout the chip as a compliant decoder. What we would be seeing in the near future from chips supposedly capable of VP8 decode is software based decode on the ARM NEON engines or proprietary DSPs. Software based decode is always going to be less power efficient than full fledged hardware decode as available for H264 streams. In effect, expect battery life to be a little worse for playing back VP8 streams of the same bit rate as compared to a H264 stream. It is likely that it will take at least another 6 - 8 months for a full fledged VP8 hardware decode engine to become available in the hands of the consumer (Thankfully, this will probably be accelerated by the large number of similarities between VP8 and H264 which could allow reuse of blocks already designed for accelerating H264 decode).

VP8 - The Ugly

Google is a software company, and its inexperience with codec development shows, where they have rushed to market with a spec which has much scope for improvement. On top of that, they are not open to changing the core specifications. Unlike beta software, where bugs can be fixed with a simple and sometimes, transparent, updates, issues with codec specifications may result in huge loss of performance and/or quality if they need to be fixed. This problem will become much more apparent when there is an already existing installed user base of hardware acceleration platforms for this codec.

The MPEG-LA consortium has a number of companies working together to contribute know-how and improve future specifications of H264 in a professional manner. It is hard to imagine an army of open source developers working together to develop specifications, while also avoiding patent issues. Future specifications will always have to skirt around the tried and tested (but patented) H264 algorithms. Even when one considers a big backer like Google behind them, it would become difficult for the project to stay away from legal scrutiny of some sort. Another thing to note is that consumer electronics is probably never going to use VP8 or WebM. Even Google claims that VP8 is suited only for web video. Camcorders (professional or consumer) are unlikely to move away from H264 because quality and performance is of paramount importance in that space.

Do we really need two different codecs in the consumer / web space? Do companies want to make life confusing for the average consumer? This is a question for MPEG-LA to ponder. In our opinion, Google has done the right thing in forcing MPEG-LA to act, but, eventually, we hope MPEG-LA realizes the follies in its licensing terms. If VP8 is successful in the long run, it will have to co-exist with H264, and this is not a good situation for the consumer. Instead of creating a patent pool for VP8, MPEG-LA should work towards making the usage licenses for H264 more friendly for companies and consumers alike.

The contrast is that MPEG-LA will endeavour to bring the AVC patent in question into the patent pool (Otherwise, the holding company might be in trouble while utilizing the other patents in their H264 implementation). Google is not proposing to create a patent pool, and even if it were to, it is unlikely that other patent holders would like to give away their tech for free.

Also, while MPEG-LA doesn't offer patent indemnification, H264 tech has been around for quite some time now, and there are no patents that I am aware of for H264, which is outside the MPEG-LA patent pool. Reply

Note that many speculated that H.264 may infringe some VP8 patents (VP8 was derived from previous On2 codecs, the VP8 source code also include comments dating from 2004, before H.264 was finalized) that Google could use to counter attack eventual litigation from MPEG-LA.Reply

Very much possible! That is why MPEG-LA wants to create a patent pool for VP8, and hasn't talked about suing Google yet.

The lawyers are going to have a field day with this, definitely.

As I said in the post, all is well if MPEG-LA is forced to change its licensing terms. The important thing is for Google to not continue to harp on VP8 if H264's licensing terms are fixed to the satisfaction of the open source community.Reply

"if H264's licensing terms are fixed to the satisfaction of the open source community. "

This never going to happen until Steve Ballmer is CEO of MS. MS is holding the most of the patents for H.264. Open source software is threatening the core of MS business model and MS will do what ever possible to stop open source advances.

Also even if MPEG-LA allow unlicensed decoding of H.264, it does not change nothing in regards of the future of the Internet. Internet needs both encoder and decoder free of restrictions of any kind. We are not going to see the real potentials of the Web Video until somebody has control on video production.

So until we abolish software patents or MPEG-LA releases the H.264 to the public domain we need VP8 and it doesn't really count if doesn't provide better quality as long it is good enough. Remember in 1997 the web was looking horrible compared to AOL. Never the less the open web is here and AOL network is gone.Reply

I remember reading that YouTube uses a variant of x264. The key here is scope for future improvements at the same bitrate. If YouTube were to update its variant to the current x264 version, the quality could be much better. I agree that there has been a lot of FUD around open source codecs, but we have to remember that open source codec development always has to be careful about treading on patents, and inevitably, in the bigger picture, the quality suffers.

Remember that it is not only YouTube which will adopt WebM / VP8 if Google has its way. If websites like Vimeo also go the same route, the quality of HD video on the net is likely to be worse than what it would be if H264 were to be the standard.Reply

> The introduction of VP8 may also lead to a demand from> consumers that their camcorders and PVRs record video in this> format. While companies are unlikely to yield in to this (and> Google itself wants to use this for Internet videos only)

I don't think any of the listed hardware companies do consumer cameras or camcorders.

The Google Group link also suggests decode only.

Cameras and Camcorders do 'encoding', which is converting raw sensor data into video using some codec. Why would a company risk delivering not so good looking video on the HDTV with VP8, when they could create better looking videos at the same bit rate with H264 (for which so much silicon is already available and tried and tested)?

As I have mentioned in the article, even Google agrees that this codec is meant for web use only.Reply