Re: Codecs for <video> and <audio>

Hi Ian,

On Tue, Jun 30, 2009 at 4:14 PM, Ian Hickson<ian@hixie.ch> wrote:
> On Tue, 30 Jun 2009, Doug Schepers wrote:
>> >
>> > 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.

This decision comes at a very unfortunate time. I am not sure when you
last had discussions with other people about this issue, but things
have changed just in the last 2 weeks substantially and I can actually
see a possibility toward solving this issue.

If I understand you correctly, your main problem is that the major
browsers do not support a common encoding format for the <audio> and
<video> tag.

I think we have a common understanding that the only formats that
satisfy the royalty-free and acceptable quality requirements and are
being considered by the Browser Vendors for support are Ogg Theora and
Ogg Vorbis - none of the MPEG codecs qualifies the royalty-free
condition. The only issues Browser Vendors have with Ogg Theora (and
to a lesser extent with Ogg Vorbis) are the perceived threat of
submarine patents.

The current situation WRT Ogg Theora and Ogg Vorbis is as follows:

Firefox: has built-in support
Opera: is developing built-in support
Chrome: is developing built-in support
Safari/Webkit: has support through the QuickTime framework after
installing XiphQT
IE: has no in-build <video> tag support, so a Web developer will
require use of a javascript library anyway; the javascript library can
the use the java player cortado to provide support for Ogg
Theora/Vorbis

So, the current situation for Ogg Theora/Vorbis is actually pretty
good with Chrome, Opera and Firefox already being on board.

Further, at the Open Video Conference last week, we had a good
representation of Browser vendors attend (nobody from Microsoft,
unfortunately). The following interesting news items wrt Ogg
Theora/Vorbis have been communicated:

* an open source project has been started to develop an ActiveX
control for Ogg Theora/Vorbis for IE. That would bring IE support for
Ogg Theora/Vorbis to the same level as Safari/Webkit support with the
need to install additional software in the form of the DirectShow
filters oggcodecs and the ActiveX control, removing the need to have a
javascript library + java pleyer provide <video> and <audio> tag
implementation.

* many content owners are moving towards Ogg Theora/Vorbis as their
preferred codec to use, in particular mid-size platforms, who will be
hit most badly by the upcoming need for royalty payments of e.g.
h.264; Dailymotion as one of the largest video hosting sites behind
YouTube have already encoded 300,000 videos to the Ogg Theora/Vorbis
format. Archive.org and Wikipedia are other large sites that support
Ogg Theora/Vorbis, Wikipedia even exclusively so.

* since Chrome is implementing Ogg Theora/Vorbis support and therefore
Google is exposing themselves to the submarine patent threat, Apple
may be in a position to also adopt Ogg Theora/Vorbis support since the
threat is then shared across a larger number of large players

So, with respect, I understand the difficult situation that you're
finding yourself in to make a decision about including a required
baseline codec for the <audio> and <video> elements. But I really
wonder if this decision really has to be made right now at this
instant or whether there is still time to wait and see what happens in
the market during the next months. It is my gut feeling that over the
next few months, Ogg Theora/Vorbis will find increasing support, in
particular since in 2010 MPEG LA will have to make a decision on the
licensing conditions to be associated with H.264, which so far had a
grace period.


>> It's not clear to me why you also had to remove the audio codecs (last I
>> check, WAV was in there... has there been some change in the IP claims
>> there?)...
>
> I didn't really see much value in having the section purely to require a
> small subset of WAVE functionality. WAVE in this context is only really
> useful during development, and since codecs are going to be a mess anyway,
> the author can just use whatever debugging-specific codec his main UA
> supports instead. (I've also received requests from browser vendors to not
> require WAVE support in the first place, though I have up to this point
> managed to convince them to keep WAVE support regardless.)

Further to this topic, I wonder why Vorbis was not able to qualify for
the <audio> tag as a baseline codec.


> The only reason we were considering having a section for <video> was to
> encourage the browser vendors to implement a common codec.
<...>
>> Mandated formats increase the consistency and value of the open Web
>> platform, which is centered around HTML, and HTML5 should express and
>> reinforce that.
>
> I don't think that mandating formats actually affects what browsers
> implement, in practice. We can only mandate what they're already willing
> to implement anyway.


You are being placed in a very difficult position here, having to deal
with contradictory requirements. On the one hand, the reason to have a
baseline codec is to encourage browser vendors to implement a common
codec. This is what a good standard should do and what the W3C should
encourage because standards are about compatible implementation -
sometimes even against what the one or other market player would
prefer. On the other hand, a standard that is not supported by all the
market players becomes irrelevant for interoperability, and that is
what the WHATWG does - it is a group that helps different browser
vendors to come to an agreement.

However, there is a way out of this predicament: even if not all
browser vendors support a common standard - if there is software
available that can extend a browser to provide the support for the
standard, then compatibility can be provided through the back door. It
is not a situation that is desirable, however it is the situation that
we have found ourselves in with flash and video for the last decade
and it is workable. It is the reason why flash became the de-facto
standard for video on the Web.

So, given the current situation, I can still see a solution for having
a baseline codec that is supported in all browsers (even if not by all
browser vendors), which is supporting the intention to "encourage the
browser vendors to implement a common codec".


>> > If anyone knows of another way to get consensus on this issue, please
>> > do let the working group know.
>>
>> Within W3C, we continue to try to find a solution to this problem, not
>> only for the decoding, but the encoding as well.  If we make progress,
>> you can be sure that we will let the HTML WG know right away.
>
> Excellent, thanks. I shall similarly continue to seek solutions for this.

I have the hope that even if the WHATWG is not able to support a
common baseline codec because of conflicting Browser Vendor
intentions, it is still possible in the W3C and public-html working
group to come to an agreement on Ogg Theora/Vorbis as the common
baseline codec.

Best Regards,
Silvia.

Received on Tuesday, 30 June 2009 07:57:44 UTC