New MacBook Pros are here! Get the lowest prices anywhere: Apple Price Guides updated Sept 18th (exclusive coupons)
 


Saturday, January 15, 2011, 01:00 am PT (04:00 am ET)

Google reaffirms intent to derail HTML5 H.264 video with WebM browser plugins


Not motivated by open innovation

Google is insisting that its move to thwart H.264 adoption by removing support from Chrome is simply an effort to push the web to technologies that any company can afford to use, while noting that "it is clear that there will not be agreement to specify H.264 as the baseline codec in the HTML video standard due to its licensing requirements."

However, while this may be true, the only hold outs in supporting H.264 are Opera, which has negligible share among web browsers, and Mozilla, which is almost entirely financially supported by Google. This is a problem Google could solve by covering Firefox's licensing fees, or by simply pulling the plug on Firefox and allowing it to go out of business just as Netscape itself did before its software product was propped up as free open source project living off Google's life support.

If Google were truly interested in open ideals, it would also abandon Adobe Flash, which also delivers its video via H.264, but does so as a proprietary plugin that pays its own way onto Google's platforms.

Partnered with Adobe's Flash Player, Google can roll out commercial video on Android and Chrome OS and simply have Adobe pay for it as the middleware vendor of a proprietary plugin platform running on top of Google's own. This makes it clear that Google's WebM strategy has little to do with openness, and is really just intended to save Google money.

If the planets align for WebM: a best case scenario

Google has actually created a new impasse of its own: HTML5 video, if forced in principle by Chrome to use WebM as its baseline (and exclusive) codec, will require all web users to either select Google's Chrome, the Firefox or Opera browsers, or install plugins to view WebM content; Google announced it will be supplying plugins for Safari and Internet Explorer. This holds out the potential for an ideal future where every browser plays video via WebM's free codec as a baseline, while Safari and IE could also offer H.264 playback as an option.

However, WebM is worthless on existing mobile devices, most of which can't even install a plugin to play WebM content. This could be addressed in the future by simply upgrading all new mobile devices with new WebM hardware acceleration (which doesn't yet exist), but there are other issues involved, including the lack of commercial viable WebM encoding tools. However, the biggest problem by far is that WebM will eventually run into patent issues from everyone else in the video industry that has already worked to hammer out the vast H.264 specification, which address far more than just the web video role WebM hopes to address.

If WebM isn't already in trouble on the patent front, it certainly will be every time it attempts to improve along the same patented footsteps H.264 developers have already worked their way though at considerable expense. Google may be professing support for open ideals, but its real motivation is to conduct its advertising business without paying to use the technology other companies have already invented. In doing so, it may cause more problems that it attempts to solve.

Open source vs. opening other's source

Google has taken WebKit's browser code and appropriated it into the successful Chrome browser, but Apple, KHTML, and other contributors that helped build the WebKit codebase willingly offered their efforts up as a free software project under a permissive reuse license to encourage its use, specifically in order to enable products like Chrome to exist.

Google's attempt to take commercial technologies and turn them into open source projects under its own control and at the objection of their rightful owners is a very different situation. Apple benefits from sharing WebKit; it does not benefit from Google simply taking the iPhone and replicating its patented features. Oracle similarly benefits from some aspects of open development, but is not interested in giving away its proprietary Java technology to Google for free distribution as part of Android.

Similarly, all of the contributors of the H.264 specification are not going to be content with Google duplicating their patented efforts and offering it for free to enable more efficient distribution of Google's ad platforms. That's why the MPEG LA has already promised to take legal action over WebM patent infringement, and will undoubtedly demand licensing fees from anyone who attempts to use WebM in place of H.264 or borrow further improvements from the H.264 patent pool in order to embellish WebM as a technology in the future.

Apple's "open" is collaborative

In contrast, Apple's decision to promote H.264 in place of proprietary video codecs such as Sorenson or On2 or Microsoft's Windows Media was done with the intent of having world class video technology to use in building its hardware products. Apple solely supported H.264 and the related AAC in the iPod, which helped the new standards take off and, through economies of scale, resulted in widespread, low cost availability of hardware optimized silicon that can play H.264 efficiently on mobile devices from any vendor.

Additionally, Apple's attempts to replace dependance upon the Adobe Flash plugin with ubiquitous web standards including HTML5, H.264, CSS and JavaScript are not based upon duplicating Adobe's technology and offering it up as open source, but rather rely upon existing open standards that can be enhanced and extended without running into Adobe's patent portfolio. And if they do, Apple can negotiate to open those patents by including them into the joint development of those web standards, in the same way Apple has contributed its own patented technologies, royalty free, into HTML5 (such as was the case with the Canvas element Apple invented).

Apple's promotion of open web standards, in particular the open HTML5 specification and the open source WebKit code implementation, demonstrate that the company is aware of the benefits that open software and open standards can provide in creating interoperability and a level playing field. If Apple thought that the same could be done in the area of video codecs, it would have pursued doing just that nearly a decade ago when it began work on implementing H.264.

While Apple had the ability to borrow KHTML's browser code under its open source license to build what would become WebKit and the Safari browser, it could not do the same to build an open video codec, because video technology is progressing too rapidly under the intense competitive pressure of a number of technology companies. That calls for an approach that respects the existing work already created and patented by stake holders.

Incidentally, the open, collaborative development of MPEG standards was what killed the proprietary efforts to develop video codec technologies at Microsoft, Sorenson, and On2 (before Google acquired it). While Sorenson and On2 were already failing five years ago, Microsoft was working hard to displace MPEG standards with its own Windows Media codec. Without Apple's heavy consumer-oriented push behind H.264, the world's video likely would have fallen under the control of Microsoft, as was being confidently predicted to occur by most pundits around 2005.

Apple pays for pre-existing IP, Google not so much

Apple is often cited as a royalty recipient of H.264 by its open source critics, but the company is by far a minority stakeholder in the MPEG patent pool. If Apple actually owned H.264, it wouldn't be licensing it from the MPEG LA; it would be distributing it as closed source technology just like its Cocoa frameworks. Alternatively, if Apple thought it could build a quality implementation of an open video codec based on an existing open source project, it would do so and distribute it for free just like its WebKit software or CUPS printing software or Darwin core OS.

As it is, Apple recognizes that other entities already own those video technologies, so it's paying the MPEG LA to license them, just as it pays to license Microsoft's Exchange ActiveSync, or Amazon's One Click retail patent, or the DVD specification (which includes MPEG-2), or the trademarked name "iOS" from Cisco, among many other things.

Google is trying to pull off a hybrid of those two options, taking proprietary software that is likely to infringe patented technology and "opening" it as a free solution, apparently oblivious of how it will evolve given that all avenues for progress have already been patented. While it has yet to be stopped by patent action from Oracle, Google's premise of a free web codec will definitely be assailed by the collective action of all of the MPEG patent holders, making Google's WebM effort a dead end pursuit that can only help to hold back the commercial progress of HTML5 and H.264 outside of the ideological bubble of the open source movement.

Outlook for WebM not so good

Rather than replacing H.264 with a nearly as good but free alternative, WebM can really only possibly thwart the progress of web publishers who want to serve video that their viewers can see, doing so using open, interoperable web standards. Rather than using HTML5 and H.264, Google hopes to promote HTML5 via WebM, but it is actually just incentivising a return to delivering video via Adobe Flash, which can already reach Opera, Firefox and Chrome users without reencoding existing content from H.264 into WebM (something that is slow and inefficient with the existing tools available).

At the same time, while Google can certainly throw chaos into play by removing H.264 playback from its own free platforms and browsers, that move will likely hurt Google more than it will adoption of H.264. Neither WebM nor Flash are supported on iOS, which is not only a significant percentage of the mobile market, but also represents a far more valuable demographic than Google's Android, which according to Gartner is primarily being deployed in China and emerging markets by no-name "other" manufacturers. If Android can't play H.264, it won't push vendors to jump through hoops to encode for WebM or the poorly performing mobile version of Flash. It will push smartphone users to abandon Android.

Similarly, if the Chrome browser and forthcoming Chrome OS can't play H.264 without involving Flash, it will only make those products less attractive to would-be buyers. Moving from Chrome back to Internet Explorer or Safari is not difficult (and will be even easier if Apple ever fixes the memory leaks and poor performance dogging its own browser), while selling Chrome OS and its inherent limitations as a web-only platform will be very difficult if it can't play industry standard video.

This gives Google very little leverage in trying to force WebM adoption the same way Apple has pushed the adoption of H.264, HTML5, ACC, and other open standards, whether they involve third party licensing or not. Additionally, even if Google removes H.264 support from Chrome and or Android, users (or hardware makers or carriers) can add it back, greatly diluting Google's leverage against H.264 among mobile devices.

Ultimately, Google's efforts to derail H.264 are unlikely to have a significant impact on H.264, but may cause uncertainty that could slow the adoption of HTML5, resulting in H.264 video being delivered instead via Flash on the web, integrated within iOS apps, or served as straight HTML5 H.264 videos that won't play on Chrome, Chrome OS and Android without an H.264 plugin. The primary casualty of those outcomes would be Google itself.