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

[Silvia Pfeiffer]

On Fri, Jul 3, 2009 at 9:26 AM, Ian Hickson<ian at hixie.ch> wrote:
>
>> > Going forward, I see several (not mutually exclusive) possibilities, 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.
>>
>> This to me is a defeat of the standardisation process. Standards are
>> not there to wait for the market to come up with a de-facto standard.
>> They are there to provide confidence to the larger market about making
>> a choice - no certainty of course, but just that much more confidence
>> that it matters.
>
> Actually HTML5 is largely built on the idea of speccing the de-facto
> standards, either long after they were implemented, or in tandem with them
> being implemented. Very little of HTML5 has been ahead of implementations.

What about Internet Explorer, the browser with the largest market
share? Bascially all of HTML5 is ahead of being implemented in IE. I
don't think that argument holds.


> No; my only argument against Theora is that Apple won't implement it.

What about XiphQT? It doesn't matter that Apple doesn't natively
support Theora - the software exists to provide the support.
Therefore, the argument that "Apple doesn't support Theora" doesn't
hold up. It's not Apple that matters, but their browser. Safari and
Webkit have Theora support. There is an implementation.

In fact, I have not heard Apple object violently to an inclusion of
Theora into the specification as baseline codec. I have only heard
them object to a native implementation in Safari for submarine patent
threat reasons.


>> Including a Theora prescription and having it only partially supported
>> with at least give a large part of the world an interoperable platform
>> and that's all HTML has traditionally been.
>
> The same argument could be made for H.264.

Except that H.264 does not qualify any of the royalty-free
requirements that W3C has for standardising technology.


>> You've said a couple of things that I perceive as contradictory, here.
>> You've said that you want to help bring about interoperability, but then
>> you've also said that you're only documenting what it is that the
>> browser makers are implementing.  There is room in the standards bodies
>> world for both goals, and both goals, at times are valid and beneficial.
>> But, if your intent is to help bring about interoperability, *real*
>> interoperability, then I think its pretty clear that the way forward
>> involves specifying a baseline codec.
>
> The way forward involves getting to the point where we can specify a
> baseline codec, yes. But we do that _after_ everyone agrees on a baseline
> codec. While it may appear that I write stuff in the spec and the browser
> vendors then agree to it, in practice it's usually the other way around.

That I can understand. But in this case, you should leave the
paragraph in the spec that states the need for a baseline codec, since
the situation hasn't changed and we are still striving for a baseline
codec.

Regards,
Silvia.