On Chrome Dropping H.264

The Chrome team announced they are dropping support for H.264.

WebM Support

WebM support will be growing quickly as Firefox 4 rolls out (Firefox upgrade adoption is legendary). Chrome commands sizable market share and is pushing the Chrome OS platform. Opera is also supporting WebM.

Apple and Microsoft could join the party and bundle WebM support along with the other codecs they support at any time, though they are licensors for H.264 and wouldn’t benefit from WebM market penetration. Microsoft’s implementation does allow for VP8 support if a codec is installed. I’m not aware of anything for Safari and am rather certain nothing can be done for the iPhone without Apple intervening.

On the hardware side AMD, ARM, Nvidia are backing WebM. Broadcom announced support, as did Qualicomm and TI. These are major vendors for mobile chips. Intel is working on stuff too.

H.264 Trouble

H.264 is problematic and bad for the web for many reasons I’ve mentioned here before as well as great posts by roc and shaver. I’ll leave it at that rather than rehash.

There was buzz a while back about H.264 being “free” (quotes intentional), but it’s not really “free” if you read the fine print. As Peter Csathy of Sorenson Media notes:

But, you say, MPEG LA recently announced that it will no longer charge royalties for the use of H.264. Yes, it’s true – MPEG LA recently bowed to mounting pressure from, and press surrounding, WebM and announced something that kind of sounds that way. But, I caution you to read the not-too-fine print. H.264 is royalty-free only in one limited case – for Internet video that is delivered free to end users. Read again: for (1) Internet delivery that is (2) delivered free to end users. In the words of MPEG LA’s own press release, “Products and services other than [those] continue to be royalty-bearing.”

That’s hardly “free”. That’s just one potential use case that’s now royalty exempt. The reason they are doing that is presumably if they can get H.264 adoption high enough, all the other cases will be paying and therefore subsidizing this one case.

WebM is licensed a little different: Patent wise, it’s irrevocably royalty free. License is about as liberal as you can get.

There’s no proprietary html, css, or images (GIF was, now it’s dead) used across the web. Why should video be any different? The key to success and growth has always been an open platform that’s low cost and encourages innovation.

Implementing Today

For anyone who suggests that this further fragments the market, that’s not really true. Adobe Flash actually creates an excellent shim to help migrate away from Flash to <video/>. Allow me to explain:

Adobe will soon be supporting WebM through Flash. Adobe already support H.264 in Flash. For legacy browsers and those who won’t support WebM, you have the option of delivering a Flash experience just like most websites do today. There are websites doing this today via Flash and H.264. For modern browsers you can just use <video/>. Once your non-WebM market share drops low enough, you can get rid of the Flash experience. Soon enough you’ll be able to push WebM to your Flash users. The benefit of switching your Flash experience to WebM as a middle step would be one encoding for both delivery mechanisms vs. using H.264 and WebM in parallel. Of course if you’re supporting mobile you likely need H.264 for a bit longer but likely use a smaller resolution and different profile for mobile consumption.

No matter what there will be two delivery mechanisms for those looking to push video using HTML5 to users today. The only thing that changes is the lean towards standardizing on the actively developed WebM codec vs. H.264.

All new technology has speed bumps, that’s the cost of being on the bleeding edge. However this is a positive turn as things are now starting to line up. The most awesome thing is that the codec, HTML5 specs, and some of the most popular browsers in the world are open and inviting feedback and contributions to improve things.

11 thoughts on “On Chrome Dropping H.264

  1. It certainly doesn’t increase market fragmentation. Having Firefox and Chrome standardising on WebM, will hopefully pressure Apple to follow that example, particularly if sites like YouTube drop H.264 entirely. And if I remember correctly, Microsoft’s stand is that IE9 will support anything the OS has codecs for, so if WebM seems to be catching on, they’ll eventually go with the trend by providing WebM support in Windows…

  2. “Adobe will soon be supporting WebM through Flash.” -> I haven’t heard anything about that since the WebM announcement in May. Do you have any more recent information about it?

  3. On the contrary, most free things aren’t that great. WEBM is no different. It is inferior to h264 in compression quality. Beside, h264 is already widely used in all kind of hardware. Look what Ubuntu was trying to away with mp3, their attempt to promote ogg didn’t get anywhere. I see no reason to do away with h264.

  4. “I see no reason to do away with h264.”

    What about : “It’s NOT free for those who want to make even a small amout of money with a video (ads included !)” ?

  5. A wider adoption of a technology drives further development of that technology.
    Wouldn’t that indicate that the quality of WebM would increase with the rise in usage?

  6. Pingback: Thoughts on Google dropping support for the H.264 video codec in Google Chrome - Robert's talk

  7. “Adobe will soon be supporting WebM through Flash”
    Agree except maybe for “soon”…

    @ au contraire : you give yourself a counter-example with Ogg Vorbis which is far superior to mp3

  8. Note that your link to roc’s article is broken. Looks like an “herf” in place of an “href.” (feel free to delete this)

  9. Pingback: Chrome Drops H.264: Good, Bad or Indifferent? |

Leave a Reply

Your email address will not be published. Required fields are marked *

Connect with Facebook

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>