File Under: Multimedia, Web Basics

W3C Drops Audio and Video Codec Requirements From HTML 5

The stewards of the web have removed the sections of the HTML 5 draft specification that would recommend web browsers support audio and video playback using a specific codec.

Ian Hickson, one of the primary authors of the HTML 5 draft at the Worldwide Web Consortium, made the announcement on the WHATWG mailing list Tuesday after fielding hundreds of e-mails’ worth of community comments over the past year and a half. Hickson cites the inability to reach a consensus on which codec should be implemented across all browsers as the primary reason for the decision.

The setback is sure to put a freeze on the main promise of open video and audio support in HTML 5 — the broad implementation of a single, plug-in free media playback environment in the next generation of web browsers, enabling people to watch movies and listen to songs inside the browser without having to download any additional software.

Hickson’s post, in part:

After an inordinate amount of discussions, both in public and privately, on the situation regarding codecs for <video> and <audio> in HTML 5, I have reluctantly come to the conclusion that there is no suitable codec that all vendors are willing to implement and ship.

I have therefore removed the two subsections in the HTML 5 spec in which codecs would have been required, and have instead left the matter undefined, as has in the past been done with other features like <img> and image formats, <embed> and plugin APIs, or Web fonts and font formats.

The current situation is as follows:

  • Apple refuses to implement Ogg Theora in Quicktime by default (as used by Safari), citing lack of hardware support and an uncertain patent landscape.
  • Google has implemented H.264 and Ogg Theora in Chrome, but cannot provide the H.264 codec license to third-party distributors of Chromium, and have indicated a belief that Ogg Theora’s quality-per-bit is not yet suitable for the volume handled by YouTube.
  • Opera refuses to implement H.264, citing the obscene cost of the relevant patent licenses.
  • Mozilla refuses to implement H.264, as they would not be able to obtain a license that covers their downstream distributors.
  • Microsoft has not commented on their intent to support <video> at all.

(Sorry if I’ve mischaracterised any positions above; the positions are relatively subtle and so it’s likely that I have oversimplified matters.)

I considered requiring Ogg Theora support in the spec, since we do have three implementations that are willing to implement it, but it wouldn’t help get us true interoperability, since the people who are willing to implement it are willing to do so regardless of the spec, and the people who aren’t are not going to be swayed by what the spec says.

Things are stuck in a stalemate, and, since the web’s main governing body is choosing to play it neutral and not push any vendors into support for one codec over the other, it’s unlikely there will be a quick resolution.

Others inside and outside the WHATWG have begun voicing their opinions.

Silvia Pfeiffer, an W3C invited expert and a member of Xiph.org, the non-profit group that oversees development of the Ogg media container, takes issue with Hickson’s last point, arguing that a strict requirement is a good thing:

Inclusion of a required baseline codec into a standard speaks more loudly than you may think. It provides confidence — confidence that an informed choice has been made as to the best solution in a given situation. Confidence to web developers, confidence to hosting providers, confidence also (but less so, since they are gatekeepers in this situation) to browser vendors.

In my opinion, including a baseline codec requirement into a W3C specification that is not supported by all Browser Vendors is much preferable over an unclear situation, where people are forced to gather their own information about a given situation and make a decision on what to choose based on potentially very egoistic and single-sided reasons/recommendations.

In fact, it is a tradition of HTML to have specifications that are only supported by a limited set of Browser Vendors and only over time increasingly supported by all — e.g. how long did it take for all browser vendors to accept CSS2, and many of the smaller features of HTML4 such as fixed positioning…

Sam Kuper, an open standards advocate and another W3C invited expert, backs up her argument:

Waiting for all vendors to support the specified codec would be like waiting for them all to be Acid3 compliant. Better to specify how browsers should behave (especially if it’s how most of them will behave), and let the stragglers pick up the slack in their own time under consumer pressure.

David Singer, a QuickTime engineer and Apple employee, also voiced his opinion, speaking on behalf of his team at Apple:

I just wanted to say that we’re not happy with the situation. We continue to monitor it, to take what action we can, and we continue to hope that we will, at some time, find a solution that reaches consensus.

It’s ironic that the announcement comes the same day as the release of the new version of Firefox, the second-most popular browser (behind Internet Explorer) which now ships with full native support for media playback using the Ogg Theora and Ogg Vorbis codecs.

As for the future of video codecs on the web, Hickson sees a few possible outcomes, “all of which will take several years”:

1. Ogg Theora encoders continue to improve. Off-the-shelf hardware Ogg Theora decoder chips become available. Google ships support for the codec for long enough without getting sued that Apple’s concern regarding submarine patents is reduced. => Theora becomes the de facto codec for the Web.

2. The remaining H.264 baseline patents owned by companies who are not willing to license them royalty-free expire, leading to H.264 support being available without license fees. => H.264 becomes the de facto codec for the Web.

When either of these happen, I will reconsider updating HTML5 accordingly.

Of course, the debate runs much deeper than what I’ve cited here. Follow along by reading the mailing list archives, which are available to the public.

See Also: