Microsoft announces H.264 support for Google's Chrome
The announcement ratchets up the war of words between the two companies, following a complaint from Google earlier this week that Microsoft's Bing search engine was appropriating its search results to improve its own.
By adding H.264 video playback back for Windows Chrome users, Microsoft's Dean Hachamovitch, the head of Internet Explorer development, said his company hopes to bypass a series of significant issues raised by Google's WebM strategy, related to intellectual property liability and risk, the open development of web standards, and simple video playback consistency.
Google itself announced plans to promote WebM via web plugins for Internet Explorer and Apple's Safari browser two weeks ago, making Microsoft's alternative proposal a straightforward neutralization of Google's strategy.
HTML5 Video Wars
Microsoft and Google, along with Apple, Mozilla and Opera, have been working for years to address the issue of how best to deliver video on the web. The newly emerging HTML5 specification enables publishers to simplify web audio and video embedding using media tags that hand raw multimedia content to the browser for playback (just like JPEG or PNG graphics files), rather than relying on a separate plugin architecture such as Apple's QuickTime or Adobe Flash to handle multimedia.
Commercial software vendors, including Microsoft and Apple, favor using the International Standards Organization's MPEG H.264 video codec, a mature and sophisticated specification developed by the technology community and offering consistent playback across the web, PC desktop and mobile devices because it is well supported by existing hardware. Other MPEG stakeholders, from Nokia to Sony (and realistically, every hardware maker), also favor H.264.
However, free software enthusiasts, principally Mozilla and Opera, have been pushing the case for Ogg Theora, a rival codec that is distributed by an organization that (unlike MPEG) does not charge royalties for its use. Ogg Theora isn't nearly as mature or as sophisticated, resulting in far less efficient distribution and a very limited use scenario only appropriate for low quality web videos.
Until last year, the situation appeared to be resolving itself as the market picked H.264 as the de facto standard for delivering HTML5 video. But last summer, Google threw fuel on the embers of the debate by acquiring the original developer of the proprietary codec that became Ogg Theora and releasing its newer sibling codec (VP6, rebranded by Google as WebM) as a new royalty free alternative to H.264.
While enthusiastically embraced by Mozilla, Opera and Wikipedia, most commercial vendors demonstrated no interest in switching to or even adding support for WebM in their HTML5 video distribution plans. Three weeks ago, Google announced plans to remove H.264 video playback from Chrome in an effort to push WebM to gain traction, again inflaming the situation and casting doubt on the prospects for the future of HTML5 video entirely.
Without consistent support for HTML5 video using a codec that every browser can play, video producers appeared forced back to supporting Adobe Flash for H.264 video distribution rather than using HTML5 at all, defeating a cornerstone feature of HTML5: its plugin-free support for integrated media playback. As critics pointed out, this would have no impact on whether H.264 were actually generating royalties, but only really impede the adoption of HTML5 over Flash as the vehicle for video on the web.
On page 2 of 3: H.264 vs WebM
The problem Google attempted to solve with WebM only affects web browsers that ignore their underlying operating system's support for media playback. Microsoft's Windows, Apple's iOS and Mac OS X, and Google's Android all natively support H.264 video playback. There is also unofficial support for H.264 playback on Linux, just as there is unofficial support for playing DVDs and other royalty-based content formats on that platform.
However, Mozilla's Firefox, Opera, and Google Chrome all ignore the underlying OS' media support to handle video themselves. For Windows users, Microsoft has announced H.264 support for Firefox via a plugin that reverses this behavior, and is now similarly adding back H.264 playback support for Chrome; both plugins take advantage of Windows' native ability to play H.264. This effectively neutralizes Google's efforts to force adoption of WebM.
Unlike Apple, Microsoft has said it will also support WebM in Internet Explorer 9 via a plugin. While WebM codec support can be added to QuickTime via a component plugin, Apple has shown no interest in working to push WebM as a standard because, like Flash, it is not supported on iOS devices and support cannot be added by third parties; Apple would have to do the work itself.
WebM an issue for mobile operating systems
Like Flash and Java, Apple has no interest in adding parallel support for WebM as an alternative way to play media content on its mobile devices, because doing so would require lots of duplicative work (for Apple, not third parties) just to add another, less efficient way to do the same thing its devices can already do.
Microsoft has no significant mobile business, so it lacks Apple's stern opposition in pushing a secondary web format that would complicate its efforts. Microsoft's Hachamovitch wrote that the company is "agnostic and impartial" about the actual video formats in use on the web, as long as they don't raise problems related to intellectual property liability and risk, the open development of web standards, and simple video playback consistency.
"Our support for H.264," Hachamovitch wrote, "results from our views about a robust Web and video ecosystem that provides a rich level of functionality, is the product of an open standards process like the W3Câs HTML5 specification, and has been free from legal attacks. Microsoft is agnostic and impartial about the actual underlying video format for HTML5 video as long as this freedom continues."
On page 3 of 3: Three WebM issues raised by Microsoft
The first issue Hachamovitch detailed relates is the protection of those who want to use HTML5 video. "Looking at video format support as a vote on who is for or against an open and free Internet is tempting but also naÃ¯ve," Hachamovitch wrote, noting the reality of software patents and the minefield of patent infringement.
"There is absolute certainty that some parties believe they hold valid and unique inventions (patents) and they will assert those rights if they think they are being infringed," Hachamovitch noted. "Historically, providing new audio-video-image formats that are entirely free from infringement has been a lengthy and challenging process. Even when we have set out to do this ourselves, we have ultimately ended up being challenged."
That was an apparent reference to Microsoft's VC-1/Windows Media codec, which was found to infringe upon existing MPEG patents, ultimately pushing Microsoft to collaborate with MPEG as a royalty payer rather than fight against it. Microsoft has noted that it "pays into MPEG-LA about twice as much as it receives back for rights to H.264."
"Offers of 'free' or 'royalty-free' source code and strong assertions that the technology is 'not patent encumbered' donât help when a patent holder files a complaint that your video, your site, or your product infringes on her intellectual property. The only true arbiter of infringement, once itâs asserted, is a court of law. Asserting openness is not a legal defense," Hachamovitch wrote.
He then chastised Google for failing to indemnify WebM users from future patent attacks. "If Google were truly confident that the technology does not infringe and is not encumbered by patents whatsoever, wouldnât this indemnification be easy?" Hachamovitch also referenced Google's comment at its WebM summit that the new codec has "no known royalty requirements," adding, "thatâs quite different from no royalty requirements."
Hachamovitch also wrote that Microsoft "is willing to commit that we will never assert any patents on VP8 if Google will make a commitment to indemnify us and all other developers and customers who use VP8 in the future. We would only ask that we be able to use those patent rights if we are sued first by somebody else.
"If Google would prefer a patent pool approach, then we would also agree to join a patent pool for VP8 on reasonable licensing terms so long as Google joins the pool and is able to include all other major providers of playback software and devices," Hachamovitch added, perhaps inadvertently highlighting the fact that once WebM creates a legitimate patent pool it will, like VC-1, end up with the same royalty situation as H.264, the very "problem" Google is hoping so solve.
Issue 2: Open development of web standards
The second major issue addressed by Hachamovitch is where WebM came from, and what legitimately makes it a web standard. Rather than being the product of open, community development like MPEG portfolio standards, WebM is simply a proprietary codec Google bought and then "opened" as a suggested (but not official) standard.
However, as Hachamovitch points out, Google says that specification it released to the Internet Engineering Task Force was "not binding," and that only the actual implementation in code was. "Reverse engineering a standard from sample source code is a poor practice," Hachamovitch wrote.
That's a wildly new perspective to come out of the company that just pushed its proprietary Office document formats through a standards organization in a very similar way to create Office Open XML. In that battleground, Google has supported the rival OpenDocument effort, intended to create an open document specification that isn't just an "opened" version of Microsoft's proprietary format that may still be patent encumbered and has known issues between the standard in the specification and what exists in practice.
With WebM, Google's shoe is on the other foot, advocating as a "standard" something that actually originated as proprietary software developed without community input and which has no real standards backing apart from the code instance Google offers, which is known to differ from the specification it delivered to the IETF.
"What are Googleâs plans for turning WebM into a genuinely open standard, one that is based on consensus like the rest of W3Câs HTML5 effort?" Hachamovitch asked. "Separating the current implementations from the specification and test suites so that independent implementations are free to emerge from the community and compete and improve is a crucial step that the W3C has taken with HTML5. When will Google enable that to happen for WebM?"
Issue 3: Simple video playback consistency
Hachamovitch also threw down a third problem for WebM, asking, "Concerns for openness were key reasons given for removing H.264 support from Chrome. Android currently supports H.264 and there are no announced plans to drop it. Will Google drop H.264 support from Android?
"Is Google committed that YouTube (and other Google video services) will continue to work with devices that lack support for WebM? The lack of consistency across devices, Web services, and the PC is a challenge for the community."
Hachamovitch also noted hardware acceleration as being a key factor in preventing any attempts to quickly roll out WebM as a credible alternative to H.264.
"Developers want confidence that what they write will work for consumers. Consumers and businesses want confidence that video on the Web will continue work â and that they will not face legal risk for using it. Googleâs decision to drop support for H.264 from its browser seems to undermine these goals," Hachamovitch concluded.
The future of HTML5 video
The unfolding situation between Google and Microsoft marks a dramatic role reversal in the two tech giants, one where Microsoft is standing up for community developed open standards and interoperability between devices, while Google is advocating the use of software it owns in preference to existing, superior standards adopted by the industry years ago, a decision that threatens to derail HTML5 and push web developers back to using Adobe Flash.
Google maintains that WebM is necessary because, "to use and distribute H.264, browser and OS vendors, hardware manufacturers, and publishers who charge for content must pay significant royaltiesâwith no guarantee the fees wonât increase in the future."
There's still the potential that Google could step up to the plate and pledge to indemnify WebM users from patent risks, something HP and Oracle have done for their Linux users. Google could also shift WebM to a neutral third party and set up a legitimate community of development. The core problem being that WebM is likely already infringing upon MPEG and other patents, and that there is little that can be done to modernize WebM without running into new patent issues.
Another alternative for Google would be to simply cover the licensing costs of H.264 for free and open source users, which is currently a small population. However, Google hopes to advance Chrome OS as an alternative platform for mainstream netbook and tablet users next year, and could be forced to pay for H.264 licensing in its free OS unless it can deliver an alternative in the meantime, making its willingness to support H.264 increasingly suspect.