Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Google Chrome Drops H264 Support

Google Chrome Drops H264 Support

This item in japanese


The Google Chromium blog discussed the HTML Video Codec Support in Chrome, and announced that the WebM/VP8 codec will be part of HTML5's <video> tag support as well as Theora. However, the bombshell comment was:

Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.

The HTML5 specification cannot agree on a standard for video on the web, as open source foundations (like Mozilla) cannot afford the H264 licensing fees for the code, whilst Chrome supports both open-source and licensed software. Meanwhile, Apple is driving H264 adoption with its hardware and software choices and has no interest in supporting an open-source codec which may have patent issues surrounding it.

Until recently, Chrome was seen as best-of-both since the HTML5 video tag would support both WebM and H264 video. Unlike existing objects (which use a plug-in architecture to allow extension after the fact), the HTML5 video tag does not permit additional codecs to be installed. As a result, Firefox, Opera and (in the future) Chrome will be unable to see H264 encoded videos.

The reverse is also true; users of Safari or iPhone/iPod devices won't be able to see WebM encoded content – but since H264 is a widely used standard (it's the encoding used under the covers for Flash as well as Blu-Ray discs) the balance of video encoding is heavily in the H264 camp. Since there is less video available in WebM, there's less of a pressing reason to encode for it, which is why Chrome is making this change.

The hope is, by making Chrome only understand WebM encoded videos for the video tag (like Mozilla and Opera), Google will switch the balance of power to encourage the wider adoption of the WebM codec. The comments are highly polarised on the matter, with more against the move than for it:

  • This is a really poor decision for users and site designers alike. Right now I can encode video in one codec, H.264 and serve it to all modern browsers and mobile platforms, using either the video tag or a Flash wrapper.

    If Chrome drops H.264 support from the video tag, then Chrome users will just get H.264 with a Flash wrapper. I'm not encoding in another codec. Peace.

  • As a content publisher and developer using HTML , I'm taking this opportunity to make the necessary changes to my sites so that Chrome also gets the Flash plugin fallback that IE and Firefox get. Bandwidth is expensive, and h.264 is a miracle-worker in that regard.
  • Interesting move. IE9 will ship with h264 and webm support, while safari, flash, iOS devices, portable gaming devices, some consoles, and the majority of 3G-capable phones (see 3gpp standard) only handle h264 as a sane web video format.

    Every platform which doesn't support h264 either ships with flash preinstalled, or has an install base of over 90%. Clearly, the format which has won is H264 - the single video format every browser supports, everywhere. This remains true until google retracts their recent statement on bundling Flash with Chrome.

The Flash issue is that despite dropping H264 support, Flash is still supported, which is a closed-source. Ironically, Flash is the best way of serving H264 video to browsers that don't have built-in support, so the majority of video publishers are just going to serve the same video content as a Flash object rather than transcoding.

  • Let's be realistic here: Chrome is ~10% of the browser market. Their decision to support WebM over h.264 won't kill HTML5 . In fact, once fireFox 4 is released with WebM, the majority of users with non-beta browsers that support HTML5 video will be using WebM.
  • It is a mistake to suggest this decision supports some nebulous "open source community". Google is making a choice here that supports the web. Anyone who thinks that h264 is free in any way is mistaken. Google seems to be taking a longer term view here, and should be applauded for accepting some short term pain in exchange for very real, very measurable long-term benefits.
  • To those that are saying that it is a stupid move, you are the stupid ones. Me as a user, I want a one universal web browser codec. I don't want to switch to Google Chrome and then see that it cannot play the video that Firefox plays, or Safari. If all the browsers move to OGG Theora codec, it'll be legit, and will teach Apple a thing or two about the cost of licensing H.264 codec.
  • The only reason to drop H264 is to hit iOS users in their faces, when Youtube drops H264. The war has already begone.

Whilst H264 is licensed, consumption of the video over the internet is free (and will be for the lifetime of the license), hardware and software decoders have fees associated with it. InfoQ have covered this before and the situation is unlikely to change; hardware device manufacturers will continue to build H264 support into products (since it's required for Blu-Ray players already). The ideological split has no common ground, which is why Chrome tried to appease both groups with dual support initially.

Ars Technica has generated a similar amount of comments on its story on Google removing H264 support from Chrome, though they also note:

Microsoft's substantial browser market share and the popularity of Apple's devices simply can't be ignored by the content producers. It's likely that many content producers will continue using H264 and will simply use Flash instead of the HTML5 video tag to display video content to browsers that don't natively support the H264 codec.

Whatever the outcome, Chrome dropping H264 support is unlikely to change the way producers generate content, even if the way they serve it does change. And with Android devices being able to run Flash, it seems that the hardware standard will remain H264 for some time to come.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • This is a content battle, not a technology battle.

    by Clinton Begin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Let's face it... Apple isn't making any friends. In the past year, they've pushed every other platform in town out of their world, by trashing Flash publicly (and people listened) and pushing professional support for Java off of their platform. Through their license agreements they've also stifled any attempt for anyone else to support such platforms (such as Adobe CS5's ability to publish directly to native iOS). They've also refused to allow apps built for such platforms to be sold in their dominant App Store.

    Apple has made some very hard plays. So let's not feel sorry for them here. It's time someone kicked them back.

    Apple has dominated the music space and the rich mobile content (apps) space. This is clear. Apple is openly and fiercely competing against Google Android at every turn. And they are winning.

    One area they have not yet dominated is video. Google owns social video via YouTube... nothing else comes close. And because the major content providers like Sony, Universal, Disney, Fox, NBC, ABC, CBS and others are so tightly restricted with regulations and copyrights, social video is really all that matters right now. If anything, the mobile carriers will own syndicated television and movie content through their various affiliations.

    So this is Google's play to turn YouTube into a feature of Chrome and Android (and inherently PCs etc.). This is their punch in the face. In one move, Google can make it very hard for YouTube content to be available on iOS, iPhone, and iPad. All it would take is to support only Ogg and Flash on Youtube... nothing else. Apple could easily respond by suddenly offering support for either, and they would pretty much have to. This would wrestle away their control over the video codec space.

    In a sense this is Google's only play, as Android Apps are finding it difficult to compete with the iTunes App Store, nor do they have any equivalent to iTunes Music Store.

    Thus YouTube becomes iTunes for Android, only for social video. This is only step one though... Android has a lot of catching up to do.

    The wildcards in this space are Adobe and Microsoft.

    Despite all of the bad press Adobe received in the past 12 months, Flash continues to dominate, and is more than just video. The Flash SDKs currently offer a unified platform for Android, Playbook, Web, Desktop Windows, Linux and Mac (AIR) -- it's everything Java ever wanted to be on the client side.

    Microsoft on the other hand, dumped their rising and increasingly successful Silverlight on the web to focus it strictly on Windows Mobile 7, and thus left the market wide open for Flash to continue to dominate. Shortly after Microsoft and Adobe seemed to have a lot of talking to do, and IE9 beta came with a preview of Flash with hardware acceleration. It would seem that there's a lot of cooperation between the two. Yet there's no flash on WM7 yet.

    To me, although expensive, Adobe is a perfect acquisition target for either Google or Microsoft

    Google could easily use it as a replacement platform for the next Android -- migrating Java apps to AS3 apps is fairly straightforward given that the language syntax is very similar and the Android SDK APIs are proprietary (not standard Java) anyway. Furthermore, this could get Google away from Java and thus away from Oracle. Furthermore, Flash seems to be a popular selling point for Android phones and tablets.

    On the other hand, Microsoft could use Adobe too. Mostly just because they don't have a dominant play in anything else, and this would give them one, at least for a short time. Most importantly, they would keep it away from Google and Android, and perhaps just use it as leverage to further their Windows Mobile 7 platform, as well as the rich web. Even though Microsoft supports H264, I don't think that's relevant. There's far more at play here than a video codec.

    At the end of the day, H264 as a technology doesn't matter. What matters is the content (music, video and apps), who controls it, and how the technology can be used to limit the availability of the content to the advantage of a given platform.

    2011 will be an interesting year.

  • Re: This is a content battle, not a technology battle.

    by chen chuan,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I would not consider migrating Java apps to AS3. We tried Flex + blazeDS + Spring + Hibernate to build our app, the result is not good:

    1. Flex is hard to learn.
    2. Flex is difficault for GUI team to do look and feel design. Change layout messed with changing AS3 code.
    3. Flex has so many namespaces to work with, difficault to find which one to use for a novice.

    Correct me if I am wrong.

    --A novice to Flex.

  • Re: This is a content battle, not a technology battle.

    by Gavin Siller,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Our organization has successfully implemented a complex Financial Needs Analysis application using Flex/AIR about 3 years ago (on Flex 2).

    1) Learning Flex is not trivial but is definitely worthwhile for a rich UI.
    2) Using the "code behind"/ MVP pattern we were able to allow for separation of responsibilities between front end and business logic developers.
    3) Reading, coding, making mistakes, reading, fixing. It's what we do for a living.

    All that being said, HTML5 is going to change things. Our solution was built a while ago (still in production, latest version of Flex and AIR now) when a very rich UI and an occasionally connected client were critical success factors.

    Interesting times (as always)

  • Re: This is a content battle, not a technology battle.

    by Clinton Begin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I would not say you're "wrong", as Flex is definitely NOT perfect.

    But personally I think AS3 - just the language - is better than Java and JavaScript (as in cleaner and more enjoyable to work in).

    Flex is better than Swing for sure -- in every conceivable way. It's also on par with WinForms as a desktop application solution, but has the added bonus of being cross platform.

    But you can't really compare Flex to HTML, as it should be used to solve almost entirely different problems. Flex is great where you would consider Swing or WinForms, and it compares on that level. But Flex should not be compared to HTML. If your building a web application, and can do it with HTML, you should. The major reason is end-user experience. Flex is not "web like".

    That said, regarding Android, I was not talking about Flex... that would be tragic on Android. On Android I think a custom Android UI/component framework specifically for Android could be very successful.


  • Re: This is a content battle, not a technology battle.

    by Kra Larivain,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I wouldn't say moving an app from java to as3 is straightforward.
    Even though the two languages look close, as3 lacks a few features widely use by java developpers:
    - no equals method defined on object. This is a *big* pain to workaround, believe me,
    - no method overloading
    - no private constructor
    - no block level definition of variables.
    - flash is single threaded by design. This is very important as it is too easy to block the main ui thread with processing or big request

    Porting from one to another is possible, but not straightforward.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p