The 2010 Google I/O Developer Conference Roundup

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.

Talk of a TV connected box from Google had been making rounds on the net for a few months. Google made the news official by introducing the Google TV platform at the 2010 Google I/O Developer Conference. Based on Android, with the Chrome browser built in, it is yet another avenue for Google to bring in ad-views from your television. In the crowded set-top box market, does Google TV stand a chance? Are people ready to get more of the web on their TVs?


Over the past few years, we have seen many connected televisions with fancy widgets. However, they haven't exactly caught the fancy of the public. This may partly be due to the fact that these widgets were somewhat obtrusive ways of bringing web content on TVs. On the other hand, by bringing Android to TVs, Google is trying to deliver a HTPC experience to the consumer. In our opinion, for technophiles looking to get the web on a TV, a HTPC is a much better option, particularly considering the flexibility that it brings along. However, as HTPC enthusiasts well know, such systems are maintenance heavy. For the average Joe, a restricted experience such as Google TV might be a much better option. As a software platform, Google TV is brimming with possibilities.

Currently, only Sony's TVs and Blu-Ray players to be introduced in Fall 2010 are slated to support Google TV. It is not obvious whether firmware updates would enable Google TV on present day models. No other TV manufacturer has been announced as a Google TV partner. It is not clear when or whether some other company would be able to integrate Google TV in their models. Dish Network's subscribers can get it on their DVRs, but if the consumer's TV experience doesn't involve either of these two companies, he is forced to invest in a Logitech box or some other dedicated hardware to get Google TV. Unfortunately, such boxes probably do not make much sense in the current setup for many people. The average home is already brimming with STBs, DVRs, PVRs, Blu-Ray players and media streamers. Yet another box in the living room is unlikely to enamor consumers.

Dwelling more on the technical side, Google has joined hands with Intel to port the Google TV platform to the Intel CE4100. Promising products based on the CE3100 such as Conceptronic's Yuixx are yet to land in the hands of the consumers. It has also been reported that Intel's CE3100 powers the widgets on some of the sets from Toshiba and Samsung. We all know how those have turned out. One can only hope that Intel has more luck with the CE4100 compared to what it had with the CE3100. Android on CE4100 has the capability to upstage the HTPC as the TV-connected computer of choice, and Google knows perfectly well that the stock Android distribution would find it difficult to make the cut as a proper OS for this platform. A fork, in the form of Google TV, is the best bet, and we will hopefully see this initiative move forward to give a good experience to consumers.

The 2010 Google I/O Developer Conference saw Google's moves in the consumer space, away from its Internet search stronghold.

Android had always been gaining momentum, and the good reception that was accorded to Froyo was always on the cards. We will cover Froyo in a separate article after evaluating it when it is pushed to our Nexus Ones.

With its VP8 open sourcing, Google has managed to open up a can of worms. It is a great thing for consumers in the short run. In the longer term, we feel it wouldn't be of any benefit to consumers to have both VP8 and H264 codecs for different applications.

Google TV, as a software platform, is a laudable initiative. We hope it will get open sourced soon, as an Android port on the x86 platform has innumerable possibilities. On the hardware side, as a dedicated set-top box, things don't look that rosy. Fortunately, Google doesn't have much to lose in that perspective, as long as Google TV manages to reach the television in some form or the other. In this scenario, the open sourcing would create ports for the HTPC. Google would also do well to tie up with other TV manufacturers and TV programming providers (such as Comcast / DirecTV) to bring Google TV on their sets and STBs.