W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2009

[whatwg] Codecs for <audio> and <video>

From: Mikko Rantalainen <mikko.rantalainen@peda.net>
Date: Tue, 30 Jun 2009 12:31:34 +0300
Message-ID: <4A49DB76.60400@peda.net>
Ian Hickson wrote:
> on the situation regarding codecs for <video> and <audio> in HTML5, 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 HTML5 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.

Short summary:

Theora is supported by everyone else but Apple and Microsoft, H.264 can
only be supported (in theory) by Apple, Google and Microsoft because of
patent licensing.

Patent licensing issues aside, H.264 would be better baseline codec than
Theora.

> 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 interoperabiliy, 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.

I don't know about Microsoft but Apple has displayed willingness to
implement what specifications say (see http://acid3.acidtests.org/ for
example). By W3C standards a spec can get REC status if it has at least
two implementations and we already have three. The current HTML 5 spec
already has stuff not implemented by every vendor, why should <video> be
different?

I'd suggest one of the two choices (I prefer the first one):

(1) Specify Theora as the baseline codec. Hopefully it will be tested by
acid4 test (or by some other popular test) and Apple will either
implement it regardless of the assumed patent risks or finds the actual
patent owners and acquires the required licenses for Theora to be
implemented by Apple. In the future, if Apple implements Theora, then
perhaps even Microsoft will do so, too.

(2) Specify {Theora or H.264} as the baseline. That way all vendors that
have displayed any interest for <video> could implement the spec.
Authors would be required to provide the video in both formats to be
sure that any spec compliant user agent is able to display the content,
but at least there would be some real target set by the spec. However, I
think that this just moves the H.264 patent licensing issue from browser
vendors to content authors: if you believe that you cannot decode H.264
without proper patent license there's no way you could encode H.264
content without the very same license. As a result, many authors will
not be able to provide H.264 variant -- and as a result the Theora would
become de facto standard in the future.

-- 
Mikko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090630/b60e7a44/attachment.pgp>
Received on Tuesday, 30 June 2009 02:31:34 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:13 UTC