H.264, WebM, Chrome, and the Verizon iPhone
The Google Chrome team announced on Tuesday that they would be dropping support for the H.264 video codec within the next couple of months. Before I explain what that means, I’d just like to point out the timing of this announcement.
Virtually everyone in the tech field, and even a sizable portion of the less-tech-savvy American population, knew for a while that Verizon would be announcing a deal with Apple, some time around this week, which would allow consumers to purchase and use an iPhone on the Verizon Wireless network. This announcement has been anticipated for several years. Google knew that people would be upset by their decision to discontinue support for H.264 in Chrome, and they didn’t want this decision to be the headline of the day when they announced it, so it would seem as though they waited for the Verizon iPhone deal to be announced so they could sneak it in and not raise too much attention. And, to some extent, it worked; if nothing else, it dealt a small blow to the amount of coverage the iPhone deal received, and went rather undetected outside of tech-specific news media.
So, what are H.264 and WebM, exactly?
H.264 and WebM are video file formats. They’re similar enough that there’s been some debate about whether WebM might be infringing on some H.264 patents, but different enough that H.264 hardware decoders (which are a more efficient way to play the videos than using the CPU directly, thus saving battery life on mobile devices) aren’t well suited for WebM videos.
Great. So, what’s the problem? Why the controversy?
The problem is inconsistent support.
Apple has invested a lot in H.264; all recent Macs, iPhones, and iPads have H.264 hardware decoders, so for the sake of battery life, Apple wants people to encode their videos using H.264. In general, they’ve succeeded pretty well; other than built-in browser support, the only way to get a video to play in a web browser is through Flash, and since iOS devices don’t support Flash, H.264 is the only real option to reach that segment of the population. Apple’s desktop browser, Safari, also supports only H.264 by default.
But Mozilla, not wanting to have to bow down and pay license fees to the MPEG-LA, the organization that owns the rights to the H.264 format, has pledged virtually exclusive support to the (free, open source) WebM format for non-Flash video in its Firefox browser. The same is true for a lesser-known, but still influential, browser called Opera.
Microsoft has pledged built-in support for H.264 in its forthcoming IE9 browser, and will support WebM, too, albeit through an optional codec installation. Previous versions of Internet Explorer, which continue to have a significant share of the browser market, support neither.
So, the only way to reach every user without having to encode videos more than once is to use Flash. Now that Chrome has announced that it will soon drop support for H.264, Firefox and Opera are no longer the lone holdouts forcing multiple formats, or Flash, and combined, Firefox, Opera and Chrome hold 33% of the market worldwide. If we count IE9 as H.264-only, then around 25% of the market will be H.264-only; if we count IE9 as supporting both, then only Safari and iOS users, about 6% of the market, will be H.264 only.
My Opinion
I think Microsoft should reconsider its decision to only support H.264 out-of-the-box in IE9. If, in addition to including WebM support by default, they drop built-in H.264 and perhaps make that an extra codec to install, then I could even see Steve Jobs bowing to the masses and adding WebM support to Safari and iOS; Apple, at that point, would be the lone holdout.
Because manufacturers are already working on hardware-based WebM decoders, and because WebM is unencumbered by licensing and other restrictions, I believe it will ultimately become the de-facto standard for delivering video online. I support the Chrome team’s decision to drop H.264 support at this early stage in the HTML5 landscape; it would have been much harder for everyone to make the switch later on.