[whatwg] on codecs in a 'video' tag.

[Gervase Markham]

Dave Singer wrote:
> At 9:48  +0100 28/03/07, Gervase Markham wrote:
>> Dave Singer wrote:
>>> Yes.  I re-iterate;  we have nothing aganist the Ogg or Theora 
>>> codecs;  we just don't have a commercial reason to implement them, 
>>> and we'd rather not have the HTML spec. try to force the issue.  It 
>>> just gets ugly (like the 3G exception).
>>
>> But that's circular reasoning. "We don't have a commercial reason to 
>> implement Ogg or Theora, and so we'd rather not have the HTML spec 
>> give us a commercial reason."
> 
> No, writing it into the HTML specification is not a commercial reason.  

Assuming you have commercial reasons for supporting HTML 5 (which I 
suspect you do, otherwise you wouldn't be here) then having Ogg 
specified gives you a commercial reason to support it.

If that's not a commercial reason, then what would be a commercial 
reason? If everyone else implemented it?

> That's an attempt to force the issue by fiat.

But any specification for anything could be described as "an attempt to 
force the issue by fiat". That' just loaded language.

Why don't we all just go away and implement what we think is best for 
HTML 5, and then put a spec together after the fact? Then we wouldn't be 
forcing any issues, and there would be no "fiat". But we all know how 
well this approach to standards works.

> No matter what the spec. says, if broad support became a reality, then 
> yes, it may be in our commercial interests.  

So Apple's strategy is to wait and see what codec everyone else 
implements, and then implement that one?

> And at that point there 
> would be many companies using the codec in a money-making way, with 
> 'pockets', and we'd be clearer about the likelihood of IPR challenges.

There are plenty of such companies already, as another poster has 
pointed out.

>> If you have nothing against Ogg or Theora, and your "interest in 
>> multi-vendor multimedia standards is deep and long-lasting, 
>> interoperable, and very open", and other parties have said that a 
>> baseline codec for video needs to be open and (as far as can be 
>> discerned) patent and royalty-free, then surely your position must one 
>> one of the following:
>>
>> - You don't actually want a baseline codec in the spec - i.e. you 
>> don't actually have a commitment to interoperability
> 
> we have a strong commitment to interoperability in each spec. on its own 
> right

So what is your plan for promoting interoperability among 
implementations of <video>?

>> - You do want a baseline codec in the spec, but you are happy for it 
>> to be someone other people can't implement - i.e. you don't actually 
>> have a commitment to multi-vendor multimedia standards
> 
> anyone *can* implement the codecs we implement;  they may choose not to, 
> for commercial reasons (e.g. they don't like the license)

Oh c'mon, that's a ridiculous definition of the word "can". How exactly 
"can" the KDE project implement a codec in Konqueror which requires 
royalties? How "can" the Mozilla project implement such a codec without 
removing the redistributability of Firefox?

Yes, browsers "can" implement such codecs if they stop being open source 
and freely redistributable. Just as the W3C "can" have lots of cool 
ideas in their specs if they changed the patent policy to not require 
royalty-free licences. But most people wouldn't accept that as a 
reasonable definition of "can".

> Until someone starts using the Ogg family to make money, and in such a 
> way that any possible IPR owners consider it in their business interests 
> to start enforcing their IPR, the situation remains in question.  We 
> have nothing against these codecs, but we are not currently feeling like 
> being the guinea-pig...

Other posters have commented on this better than I.

> - we'd an HTML specification which is clear and interoperable on the 
> HTML level, and is in a similar position to the img tag on what may be 
> embedded (it mentions only examples)

As another example of specifications requiring support for other 
specifications, SVG viewers are required to support both JPEG and PNG:
http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers

And I haven't seen anyone writing standards like "Yes, we support SVG, 
but not the bit which says we need to support JPEG and PNG".

Gerv