Google's Rejection of H.264 in Chrome Means a Unified HTML5 Video Tag is Now a Pipe Dream
Google used a lengthy blog post last Friday to quell the firestorm around its selective dropping of native H.264 video codec support in its Chrome browser and Chromium project, in favor of the VP8 codec and WebM, while still supporting Adobe Flash and Microsoft Silverlight plug-ins for Chrome.
After hundreds of comments on its January 11 Chromium blog chastised the company for slowing down innovation, the clarifying post on January 14, 2011, attempted to segment the argument down to a simple argument around the HTML video tag.
"This week's announcement was solely related to the HTML <video> tag," wrote Mike Jazayeri, the Chromium Project's product manager.
"We believe there is great promise in the <video> tag and want to see it succeed," Jazayeri continued. "As it stands, the organizations involved in defining the HTML video standard are at an impasse. There is no agreement on which video codec should be the baseline standard."
It's odd to hear Google claim its decision will help force the issue, when Google itself was one of the instrumental companies in pushing the H.264 codec toward a tie-breaker.
Before it acquired On2's VP8 codec, which it relaunched as the video codec in the WebM open-source project, Google supported both H.264 and Ogg Theora, an ancient codec that was no match for H.264's quality.
After the acquisition, however, Google rapidly moved to strong-arm support for the codec in both software and hardware encoding/decoding. It claims success in both areas, arguing that is the reason it can now drop support for the more popular codec.
"We acknowledge that H.264 has broader support in the publisher, developer, and hardware community today, though support across the ecosystem for WebM is growing rapidly." wrote Jazayeri. "However there will not be agreement to make it the baseline in the HTML video standard due to its licensing requirements."
For Mozilla, which makes the second-most popular browser (Firefox) and for the esteemed independent browser Opera, licensing requirements have indeed been an issue. What Google doesn't state in its blog posts, however, is the fact that the majority of users don't use Firefox or Opera.
Google's move to abandon the majority of browsers, led by Internet Explorer-the most recent version of which, IE 9, supports H.264 natively-and all iOS devices, which use Safari, appears to guarantee that the impasse won't be addressed anytime soon.
Ian Hickson, who has headed up the draft specification, stated as far back as mid-2009 that the HTML5 video tag would only become reality if all browser makers came to consensus on which codec to support.
"After an inordinate amount of discussions, both in public and privately, on the situation regarding codecs for <video> and <audio> in HTML5," Hickson wrote in mid-2009, "I have reluctantly come to the conclusion that there is no suitable codec that all vendors are willing to implement and ship. Therefore I removed the two subsections in the HTML5 spec in which codecs would have been required, and have instead left the matter undefined. "
Hickson did say at the time that if support for Theora were implemented in all browsers, he could open back up the discussion.
Theora, of course, is now moot given the almost-as-good-as-H.264 nature of VP8. But the following quote from Hickson from mid-2009 could easily have been written after Google's recent announcement on H.264, substituting VP8 for Theora, complete with concerns on patent infringement that have been raised about VP8:
[One option is that] Google ships support for the [Theora] codec for long enough without getting sued that Apple's concern regarding submarine patents is reduced and Theora becomes the de facto codec for the web. Alternatively, the remaining H.264 baseline patents owned by companies who are not willing to license them royalty-free expire, leading to H.264 support being available without license fees, and H.264 becomes the de facto codec for the web.
"When either of these happen, I will reconsider updating HTML5 accordingly," Hickson added.
This is not the time for reconsidering the HTML5 video tag update, if Hickson's stance is still the same. If anything, the move by Google will guarantee that the HMTL5 video tag uncertainty and impasse will continue for some time.
Google's recent move also plays nicely into the hands of Adobe's proprietary player solution, the Adobe Flash Player. Since Flash Player supports H.264, there will be a requirement for Chrome users to now download it or Microsoft's Silverlight in order to play H.264 video, and the <video> tag will become irrelevant, since developers will simply code a fallback to Flash.
Readers of the latest blog post weren't any more impressed with Jazayeri's logic in his latest blog post than they were with the earlier post.
"H.264 is what we need," responded blog commenter Bassguy. "Stop slowing innovation. You're propping up Flash."
Several other commenters took the approach of asking Google why it was picking and choosing between video codecs.
"What about MP3 and AAC support in Chrome?" asked Hugh Isaacs II. "Why hasn't this been removed? Audio matters just as much as video."
To remove these two codecs, though, would render more than just Apple's iPod devices unable to play Google's video and audio: It would have a significant impact on the 99.5% of media players that use MP3 as a standard-not an open standard, but a standard nonetheless.
So Google gets to pick and choose what license-pool codecs it supports, all the while disingenuously claiming that it's supporting open standards.
Google can't have it both ways. While it may be supporting open-source codecs, it can't be supporting standards, since none of the open-source codecs reach anywhere close to a majority of the codec usage on the market today. And if it's going to support standards, in terms of usage, it won't be in the form of open-source codecs.
In addition, and we'll cover this in more detail in a future article, Google's claim that it can get VP8 committed to silicon for either encoding or decoding runs counter to the fact that open-source codecs like VP8 continue to evolve at such a rapid clip that any hardware manufacturer implementing silicon against the current version runs the risk of boxing itself into a problem that's already occurred: There are now two viable branches of VP8, the one Google has retained in house, and another one expanded on by the open-source community.
If hardware is committed to Google's version, it's not really an open-source community version, is it? That approach smells more like a proprietary branch of a codec's code masquerading as open-source code.
It seems Google's having a mid-life identity crisis, creating discord and disruption to such an extent to leave its "don't be evil" slogan in question.
Related Articles
An explanation of HTML5 and HTML5 Video, including history, patent issues, and current use by Apple, Microsoft, Google, Adobe, and others.
10 Mar 2011
A look at key developments that shaped the HTML5 platform, as well as practical and technical resources to help you implement HTML5 Video
10 Mar 2011
Here's a list of articles, videos, websites, and conferences that can help you better understand the issues surrounding the HTML5 Video tag, as well as the HTML5 specification in general.
25 Feb 2011
Last week, MPEG LA issued a patent pool request, which Google brushed off as "old news"
14 Feb 2011
The world of HTML5 video is fragmented, but a recent webinar explains how content providers can best prepare for it.
19 Jan 2011
Pundits have pounced on Google for dropping H.264 support in favor of WebM in the Chrome browser. But what if an all-H.264 world isn't all it's cracked up to be?
18 Jan 2011
With WebM, Google hasn't created any new revenue opportunities, opened any new markets or increased the size of the pie. They've just made it more expensive to get your share, all in the highly ethereal pursuit of "open codec technologies."
12 Jan 2011
Google's decision to open source VP8 in the form of WebM was the opening salvo in yet another codec war. We take a look at encoding efficiency, output quality, and CPU horsepower required for playback of both WebM and H.264.
30 Jul 2010