posted by Thom Holwerda on Sun 24th Jan 2010 17:59 UTC
IconThis week, both YouTube and Vimeo opened up beta offerings using HTML5 video instead of Flash to bring video content to users. Both of them chose to use the h264 codec, which meant that only Safari and Chrome can play these videos, since firefox doesn't license the h264 codec. Mike Shaver, Mozilla's vice president of engineering, explained on his blog why Mozilla doesn't license the h264 codec.

Shaver explains that h64 is not a suitable codec for Mozilla, because of two main reasons: licensing cost, and the codec's closed nature.

The h264 codec is patented up the wazoo by the MPEG-LA, and while Google, Apple, and Microsoft have paid for a license to include the codecs within their products, the Mozilla foundation has not, and will not do so. Without this license, it is illegal (in many countries) "to use or distribute software that produces or consumes H.264-encoded content. Indeed, even distributing H.264 content over the internet or broadcasting it over the airwaves requires the consent of the MPEG-LA, and the current fee exemption for free-to-the-viewer internet delivery is only in effect until the end of 2010."

Mozilla has a number of clear and well-argued reasons for not buying the license. First, it's very limited. Google, for instance, paid for a license that transfers to users of Chrome, but if you build Chrome from source yourself or extend the browser, the license does not apply. What's even worse is that the license would not carry over towards, for instance, Linux distributors - not acceptable, of course, for Firefox.

"Even if we were to pay the USD 5000000 annual licensing cost for H.264, and we were to not care about the spectre of license fees for internet distribution of encoded content, or about content and tool creators, downstream projects would be no better off," Shaver explains.

The second important reason not to license the h264 codec is a more ideological one. "We want to make sure that the Web experience is good for all users, present and future," Shaver writes, "I want to make sure that when a child in India or Brazil or Kenya discovers the internet, there isn't a big piece of it (video) that they can't afford to participate in. I want to make sure that there are no toll-booth barriers to entry for someone building a whole new browser, or bringing a browser to a whole new device or OS, or making and using tools for creating standard web content."

He adds that "the web is undeniably better for Mozilla having entered the browser market, and it would have been impossible for us to do so if there had been a multi-million-dollar licensing fee required for handling HTML, CSS, JavaScript or the like".

It is very hard to disagree with Shaver on this one. We have seen what happens when we make the web dependant and proprietary - Flash, Internet Explorer 6 - and yet here we are, ten years down the line, ready to fall into the same trap all over again. I don't care if h264 is better now, what matters is that in the future, we haven't locked ourselves into yet another patent-encumbered format that alternative platforms can't make use of.

The specification writers for HTML5 should have the guts to do what's right. It doesn't matter if Theora is (arguably!) worse than h264 - the standard is open, patent-free, and developing at an incredible pace. I'd rather we bite through the sour apple now, instead of having to deal with the lock-in down the line. Here we are, loaded with bad experiences with lock-in on the web, and yet we seem to be doing it all over again. I'm sure we'll blame Microsoft eventually.

Shaver ends his post with a note about using platform-native frameworks, such as DirectShow in Windows, to handle the video format. This solution has been suggested quite often, but Mozilla doesn't see it as an option, because of a multitude of problems.

"There are issues there related to principle (fragmentation of format under the guise of standardized HTML), to effectiveness (about 60% of our users are on Windows XP, which provides no H.264 codec), to security (exposure of arbitrary codecs to hostile content), and to user experience (mapping the full and growing capabilities of [the video tag] to the system APIs provided)," Shaver explains.

e p (31)    158 Comment(s)

Technology White Papers

See More