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

[Charles Pritchard]

whatwg-request at lists.whatwg.org wrote:
> Message: 3
> Date: Tue, 30 Jun 2009 04:50:31 +0000 (UTC)
> From: Ian Hickson <ian at hixie.ch>
> Subject: [whatwg] Codecs for <audio> and <video>
> To: WHATWG <whatwg at whatwg.org>
> Message-ID: <Pine.LNX.4.62.0906292331380.1648 at hixie.dreamhostps.com>
>
> After an inordinate amount of discussions, both in public and privately, 
> 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.
>   
There are many considerations when supporting video codecs, licensing, 
hardware, complexity, cost.

Can the standard simply address video containers (OGG, MKV, AVI) ?
Each container is fairly easy to implement and codecs can be identified 
within the container.
Vendors can decide on their own what to do with that information.

I'd appreciate for the container formats to be supported, so I can get a 
nice message saying:
Your codec "####": Vorbis, is not supported by your computer without a 
plugin,
and/or have the ability to right click, hit properties,
and get some data even without supporting the codec.

I've come across a few wav and avi files, where I've needed to download 
the file,
and download a helper application to simply identify what codec I need 
to install.

If the browser had at least [properly] supported the container, it would 
have saved me quite a bit of time and effort.

Better to say: "Codec XXX not installed"
instead of: "I don't know what it is, good luck with that".
I realize the codec="" attribute provides hints, it's a pain for the 
document author.

As far as I know, there are no patent issues for popular container formats.


-Charles

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