On H.264 Revisited

Once again the debate over H.264 has come up in the Mozilla community. I’ve been a strong advocate of the WebM/VP8 codec given its liberal license and abilities and still am, but agree H.264 needs to be supported. It’s a requirement for mobile (B2G), and becoming necessary on the desktop.

A little over a year ago Chrome talked about dropping support for H.264. To date they have not done so, or given any indication that is even still in the plans as far as I know. In 2010 Adobe said they would be supporting WebM (link in that same blog post). They too have failed to live up to their promises. In either case I’ve found no indication on the internet they ever plan to go forward with those plans.

I suspect in Google’s case they were pressured by various providers and mobile partners who don’t want to encode or support another encoding. Google’s been trying to woo anyone/everyone for the purposes of Google TV and presumably YouTube. It’s likely just not worth it for them to push. There are various theories floating around about Adobe including a lack of clear Flash strategy in an HTML5 world. Adobe does however have a “tools” strategy. Perhaps time will tell.

Furthermore Apple and Microsoft are fundamentally opposed to WebM as they are both licensors for H.264. The odds of them supporting something that hurts their bottom line unless the rest of the web is threatening to leave them behind is nearly 0.

I question however if it should be bundled vs. using system codecs. Windows XP aside, system codecs mean that Microsoft and Apple are essentially responsible for making it work as well as the expense. Plugins could be used for OS’s that don’t ship with the appropriate codecs.

It’s time to put some effort into a JavaScript player for WebM and make that liberally licensed. Browsers still aren’t quite there, but eventually the day will come when that’s workable. The web will then gain the ability to have video play on any (modern) device. Just not natively. That is the backdoor for an open codec.

The real issue is larger than the <video/> element. It’s software patents and their ability to undermine innovation and progress. It’s important to keep this in mind. Just look at mobile. It’s completely possible that the entire mobile industry could come to a halt over patent lawsuits and fear of lawsuits. All it takes is a company willing to press the button. Google spent $12.5 billion in what is essentially the patent equivalent of nuclear proliferation. That’s how real the threat is perceived. H.264 is arguably a fart in a hurricane.

15 thoughts on “On H.264 Revisited

  1. Realistically, I don’t think WebM has any chance of being widely accepted, any more than Theora before it. H.264 has issues, but it’s what the world is actually using.

    If I film a video clip using my camera, I’ve got an H.264 file. If the browsers support H.264, all I need to do is chuck that file on a server, and people can see it. If not, there’s the extra effort of converting files, which from a user point of view, is a pain in the neck.

      • Somewhat, yes. Your problem is that people are already happily using H.264 for pretty much everything *except* HTML5 video. If you want them to use WebM, you need to either make the inconvenience go away, or convince them it’s worth putting up with the inconvenience. It seems pretty clear that that’s a losing game.

      • This is where Mozilla’s standards politics fails the practicality test. Not only does Mozilla often take the harder position on licensing and other politics – which is often to be admired despite it’s impracticality – but they fail to provide software solutions to reduce the inconvenience, as you put it. Mozilla has relied on the open source community to do this for them and this can take an incredibly long time and may never happen at all. Open source is not known for it’s efficiency and attention to the timelines of the market! When Mozilla inherited WebM it really should have provided an end-to-end publishing solution to support it. Instead it allowed people to keep on going with their existing toolchain since there was (and still is?) a lack of WebM alternatives.

    • Realistically, far most people, that throws a video on the net (and don’t use some service, e.g. youtube, vimeo or facebook, that converts the video anyway), will probably edit/resize it first, and therefore it does not matter if the output format is different that the input format.

  2. I found it funny and slightly angry that there are now Mozillian coming out and state they are a strong advocate of the WebM/VP8 codec but should still support H.264…

    This isn’t directly to you, but general Mozilla Dev.
    Is this a PR tactics? I means honestly where were these people when they decide NOT to support H.264?

    The problem is software patents, not H.264 itself. And we have all seen the recent patents problems.

    Not defending for Apple or Microsft, but the reason for them to choose H.264 over WebM just because they are both licensors for H.264 is just nonsense. The money they received from it is so little they could care less about it. But the threat of using a non patents protected codec in a software patents world is simple asking the company to rush into minefield.

    And to conclude, nothing wrong with both codec. The root of all evil is Software patents.

  3. > Furthermore Apple and Microsoft are fundamentally opposed to WebM as they are both licensors for H.264. The odds of them supporting something that hurts their bottom line unless the rest of the web is threatening to leave them behind is nearly 0.

    Well that’s just not true. Microsoft pays into MPEG-LA about twice as much as it receives back for rights to H.264.

    http://blogs.msdn.com/b/ie/arc.....n-ie9.aspx

  4. It’s not PR tactics. It’s an honest conversation about the pros and cons of supporting H.264 or not. Robert, this post kind of hits the nail on the head. We’ve seen few words and no action on the Chrome front, which has done a lot of damage to the cause for WebM.

  5. This is perfect timing since a first-time developer has written code to support GStreamer in Firefox, including H.264, just this week. Chris Double is set to review it. Great work Alessandro Decina! See Bug 422540.

    If Mozilla looks to the future, surely the mission to spread the open web has to go forward and include big-arse displays and possibly dedicated media players? It is hard to imagine anybody accepting a B2G style system running their big-arse display if it doesn’t play video encoded in common codecs already supported in the manufacturer’s own walled-garden software.

    The two biggest restrictions behind the decision not to support H.264 seem to be security footprint and licensing politics/patents. Robert makes a good point that leaving the responsibility of codec licensing and management to the host OS wherever possible (B2G wouldn’t apply here I guess) reduces Mozilla’s exposure to the political/patent issue. In security terms, what are the implications? Can they be any worse than hosting the constantly-updating swiss cheese ware known as Adobe Flash Plugin?

  6. Do you guys know how much it would cost Mozilla to support H264 in Firefox?

    Because I guess this is the real issue until WebM or Theora become standards.

      • As I remember, the big opposition wasn’t the cost, but rather that suddenly there’d be a part of Firefox that’d be under legal terms similar to the Firefox trademark.

        The big problem with patent licensing as it relates to open-source is that, suddenly, whether or not you’re allowed to compile and distribute the code (unmodified or otherwise) under a name like IceWeasel depends on whether you’re on the Mozilla org-chart.

      • Unless you just compile it without whichever aspects you don’t agree on?

        As for the pathetic iceWeasel name, would the world really be any worse off if that vanished? No!

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>