H.264 Getting Dropped from Chrome

If you pay any attention to the plodding chaos that is the development of HTML5, then you’ve probably seen the discussions around the video element and how best to encode videos. Over a year and half ago Ian Hickson gutted the video and audio portions of the HTML5 specification to remove all references to codecs, disconnecting the two competing standards, H.264 and Ogg Theora, from the next HTML standard. He did this in an email announcement to the WHATWG list, explaining the issues with licensing and browser support for both options.

At the time Safari refused to implement support for Ogg Theora, Opera and Mozilla refused to support H.264, Internet Explorer was silent, and only Google Chrome implemented both (though Google said it could not provide the H.264 codec license to Chromium third-party distributors).

A year and half later and Google has dropped support for H.264 from Chrome as of two days ago. While Google has hung its argument on the hook of license restrictions, it’s probable that Google is really just pushing its own WebM format.

The licensing argument is simple — the compression parts of H.264 are patented by MPEG-LA. While MPEG-LA has opened up the H.264 license for the web (after originally saying it wouldn’t collect royalties until 2016), it’s conceivable that move was intended to get the web hooked on it. And then it’s fair to assume the patent trolling might begin (history indicates the odds are good).

This announcement and the logic behind it has started off a mini-firestorm among developers on the leading edge of HTML5.

Ars Technica wrote up a pretty scathing review of Google’s move in the article Google’s dropping H.264 from Chrome a step backward for openness, suggesting Google’s real issue is about control over its own WebM format. The article goes into more detail about Google acquisition of the company responsible for developing what is now WebM and compares and contrasts the licenses of these and other standards.

Haavard Moen, who works for Opera, takes some time to disassemble the argument made by Ars Technica in his post Is the removal of H.264 from Chrome a step backward for openness? He breaks it up into 11 points, corrects or contextualizes them, and then suggests that the bulk of the points aren’t even relevant to the discussion at hand.

The chart below (and its comments) were unabashedly stolen and marked up from a graphic by Bruce Lawson (of Opera Software fame). He uses it to outline which browsers support which codec. I have added a column to list Ogg Theora.

The two browsers that only support h264 video are Internet Explorer 9 and Apple Safari, the vendors of which have a financial stake in the codec:
www.mpegla.com/main/programs/AVC/Pages/Licensors.aspx

The column in the chart asking about the MPEG-LA licensing pool is intended to show that the only browsers still supporting H.264 are those with a financial stake. Bruce updated his post with a link from a site visitor that claims that Microsoft gets far less from its financial commitment to H.264 than it pays in.

An argument that keeps popping up is that Google should drop support for Flash, given that it is not an open standard. I have dismissed this immediately on the argument that Flash has been here for a very long time, and it’s not practical to drop support for a technology that is already driving millions of sites, at least not without the myopic world view that Apple lugs around.

That argument, however, made it into the post from John Gruber’s blog, Daring Fireball, titled Simple Questions for Google Regarding Chrome’s Dropping of H.264. Remy Sharp was quick to respond on his own blog with My take on Google dropping H.264.

While Flash is only a part of that debate, it’s further insight into the arguments we’re hear from both sides. Some of the arguments will lean on a perceived double standard, as we see with the Flash example; some will lean on license debate, as we see with the constant references to MPEG-LA versus WebM and its background; some will lean on the quality of the video, which I intentionally left out of this post; and some will lean on who wants to be the next big monopoly for the burgeoning growth of video on the web.

For the average developer, it might be best to wait until the dust settles. You’ll still be making decisions based on browser support in the end anyway.

Related

• Google Chrome drops H.264 support to focus purely on open technologies like WebM
• Google nixes direct H.264 support in Chrome
• The backlash over Google’s HTML5 video bet from C|NET.
• Google reveals plan to remove H.264 support from Chrome from ars technica.
• An Open Letter from the President of the United States of Google from MSDN.
• Microsoft mocks Google’s Web video decision from C|NET.
• GIF, H.264, and Patents from John Gruber

UPDATE: More Links from around the Innertubes

These links came rolling out this past weekend (January 14-16) and offer more arguments for and against H.264 and Google’s decision.

• More about the Chrome HTML Video Codec Change from the Chromium blog.
• Why the Future of Online Video Is in Serious Trouble [OP-ED] from Mashable.
• VIDEO debate, cutting to the chase by John Dowdell from Adobe.
• John Gruber responds with Adobe’s John Dowdell on Chrome Dropping H.264 at Daring Fireball (instead of responding right on the blog, where two men can have an open debate).
• Why the Web needs WebM by Anne van Kesteren, who works at Opera.

Update (January 21, 2011)

• A Simple Explanation Of The Huge WebM Versus H.264 Debate

Update: April 6, 2023

Thanks to a post by Bruce Lawson, I discovered the paper The Most Dangerous Codec in the World: Finding and Exploiting Vulnerabilities in H.264 Decoders, with the following abstract:

We introduce and evaluate H26FORGE, domain-specific infrastructure for analyzing, generating, and manipulating syntactically correct but semantically spec-non-compliant video files. Using H26FORGE, we uncover insecurity in depth across the video decoder ecosystem, including kernel memory corruption bugs in iOS, memory corruption bugs in Firefox and VLC for Windows, and video accelerator and application processor kernel memory bugs in multiple Android devices.

I tend to agree with Bruce — we should have used Ogg Theora.