The promise of HTML5's <video> tag was a simple one: to allow web pages to contain embedded video without the need for plugins. With the decision to remove support for the widespread H.264 codec from future versions of Chrome, Google has undermined this widely-anticipated feature. The company is claiming that it wants to support "open codecs" instead, and so from now on will support only two formats: its own WebM codec, and Theora.

Google's justification doesn't really add up, and there's a strong chance that the decision will serve only to undermine the use of the <video> tag completely. This is not a move promoting the open web. If anything, it is quite the reverse.

The <video> tag in HTML5 has been contentious since its inception due to question of codecs. Should the HTML5 specification mandate support for specific codecs, and if so, which should be required? Originally, the specification chose a particular compression algorithm for the <video> tag: the Theora algorithm. This decision was opposed by many parties involved in web standards for a range of reasons; as a result, the language of the specification was changed, so that it avoided specifying any particular algorithm. While this didn't make everyone involved particularly happy, it allowed work on the specification to proceed without endless arguments about video codecs. Though some opposed the decision, in truth it was hardly unprecedented: the HTML specification for the preexisting <img> tag for embedding still images does not mandate any particular format, either.

This meant that it was up to different browser vendors to pick their own preferred codecs. Apple and Microsoft (for the as-yet unreleased Internet Explorer 9) picked H.264 and H.264 alone. Firefox picked Theora and, in Firefox 4, WebM. Until this latest announcement, Chrome supported Theora, WebM, and H.264; in the future, it will support only Theora and WebM, just like Firefox. The reason Google has given for this change is that WebM (which pairs VP8 video with Vorbis audio) and Theora are "open codecs" and H.264 apparently isn't.

Openness can't be the issue

This explanation is lacking, to say the least. It appears to be a conflation of several issues: openness, royalty-freedom, and source code availability, among others. In the traditional sense, H.264 is an open standard. That is to say, it was a standard designed by a range of domain experts from across the industry, working to the remit of a standards organization. In fact, two standards organizations were involved: ISO and ITU. The specification was devised collaboratively, with its final ratification dependent on the agreement of the individuals, corporations, and national standards bodies that variously make up ISO and ITU. This makes H.264 an open standard in the same way as, for example, JPEG still images, or the C++ programming language, or the ISO 9660 filesystem used on CD-ROMs. H.264 is unambiguously open.

In contrast, neither WebM's VP8 nor Theora were assembled by a standards body such as ISO. VP8 was developed independently and entirely in secret by the company On2, prior to the company's purchase last year by Google. Theora was created by a group of open-source developers based on early work also done by On2. Though Theora's development can be described as an open, community process (albeit different in nature and style to the more formal processes and procedures used by the standards bodies), no such claim can be made of VP8. At the time of its development, VP8 was a commercial product, licensed by On2. Keeping the specifics of its codec secret was a deliberate goal of the company. Though it has since been published and to some extent documented, the major design work and decision-making was done behind closed doors, making it at its heart quite proprietary.

Google is now building a community around WebM (similar to that around Theora), but it hasn't taken any steps to submit WebM to ISO, ITU, or SMPTE for formal open standardization. The company is preferring to keep it under its own sole control.

For Google to claim that it is moving to "open codecs" is quite absurd: H.264 is very much an open codec. WebM is not.

It's about (cost) freedom

What H.264 isn't, however, is royalty-free. ISO and ITU do not require the members working on their various standards and specifications to give up any specific patent claims that may cover the technology that they define. As such, while H.264 is an open standard, there are several hundred different patents that cover the various techniques that it uses to achieve high quality compression—for example, estimating motion from frame to frame, removal of the block artifacts that result from the compression, and the final stage of lossless compression applied to the encoded video.

The result is that anyone wanting to distribute an implementation of H.264 must obtain licenses for all of the different patented techniques that they use, and these licenses typically come at some cost. To ease this burden, licenses for the full set of patents are available from the company MPEG-LA. MPEG-LA redistributes the income it makes from licenses to the various patent holders.

MPEG-LA's license terms for H.264 set out a range of fee schedules depending on the exact nature of the H.264 implementation. Importantly to web users, video that is distributed over the web and which is, importantly, not behind any kind of a paywall, is royalty-free. This means that uploading a video to a site such as YouTube and then rebroadcasting that video to all and sundry is free. For browser developers, the situation is not quite so happy: browsers include H.264 decoders, and these are subject to royalties. The size of the necessary payment depends on the number of units shipped—browsers with fewer than 100,000 users would likely not need to pay a royalty at all—but in any case is capped at $6.5 million (equivalent to about 65 million users), annually, until 2015.

Both VP8 and Theora are, however, royalty-free. Both were designed to avoid existing video patents. Theora was designed to use no patented techniques at all. VP8 does include patented techniques, but these techniques were developed and patented by On2. Google, as present owner of those patents, is permitting their use, in any application, without payment of any royalty.

At least to a point: the threat with both of those codecs is that they may, in fact, infringe on one or more patents, in spite of efforts to the contrary. If this turns out to be the case, one or both of the codecs might end up in a very similar position to H.264, as far as royalties are concerned.