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

[Dave Singer]

I really think that this conversation has morphed from 'should HTML 
recommend or mandate codecs' into mostly 'why apple should support 
ogg/theora'.  Even the first question is a pretty tangential one to 
the design of the tag itself, the CSS, and so on.

Surely people have comments or questions on other aspects of our 
proposal?  There is new stuff, new ideas, and open areas, all ripe 
for discussion....we have engineers standing by, eager to refine and 
improve the video tag design itself...



At 13:51  +0100 3/04/07, Gervase Markham wrote:
>
>The current proposal is for a SHOULD, not a MUST. Do you object to 
>SHOULD as well as to MUST?

I'm not crazy about a SHOULD, no, but we can discuss it later.

>Can you please explain how you believe not specifying a codec at all 
>promotes interoperability?

As I said before, I think you have to distinguish systems 
interoperability, which is driven by integration specifications, and 
technology interoperability, which is driven by technology specs. 
Example:  video codec specs don't mandate an audio codec, even though 
for the most part video support without audio support is not very 
interesting.  But integration specs such as 3GPP PSS, or ISMA 1.0 and 
2.0, do mention video and audio codecs, protocols, minimum 
capabilities, and so on.

Integration specs, to be effective, are, alas, more than one-line 
asides in technology specs.  Technology specs should, I believe, 
stand alone and just document that technology - HTML in this case.

>
>Let us assume, for the sake of argument, that different terms would 
>be required in order for MPEG4 to be implementable in free software. 
>Is Apple offering to help approach the MPEG-LA?

OK, I am not a lawyer and I do not represent the patent holders, and 
it is not my job to help build their business.  I have enough trouble 
building ours.  However, there are both reference and open-source 
implementations of MPEG codecs (e.g. x264);  generally my (possibly 
flawed) perception is that it is their use that is subject to 
license, not their mere existence.

But given that we are not suggesting a mandate for MPEG codecs, 
simply pointing out that - for us and our business - their widespread 
implementation, and competitive landscape, suit our needs, it doesn't 
seem very material.

At 17:47  +0100 3/04/07, Gervase Markham wrote:
>Although I guess it's fairly academic, because it's now pretty clear 
>that Apple doesn't plan to support Theora unless it's forced to by 
>sites not providing an MPEG alternative, and users complaining. 
>Which is a great shame, because Theora/Dirac is the only chance we 
>have of a single codec across all implementations.

The most prevalent codecs *today* are those in cell phones;  heck, 
Nokia has shipped more digital cameras than anyone else (really).  In 
those phones, H.263 and AMR are almost universal (even 3GPP2, which 
uses a different voice codec, mandates AMR for MMS interoperability, 
I believe).  I think ogg/theora support in the mobile world (as a 
specification mandate) is unlikely, so I would disagree that they are 
the only chance we have of interoperability;  the best chance is 
probably getting as close as possible to the mobile world.

At 18:44  +0200 3/04/07, Maik Merten wrote:
>Personally I don't see a reason why Apple couldn't simply queue an Ogg
>Theora component provided by a 3rd party into the QuickTime component

Alas, that wouldn't be Apple then that was complying, merely that we 
make it possible for each end-user to make their browser compliant.

>Devices that do play H.264 usually have a H.264-capable DSP - like the
>Video iPod. That one comes with a Broadcom DSP which is 100%
>reprogrammable and is well suited for Theora decoding (so I am told).
>Now, of course that's implementation work, but so is the whole WHATWG
>spec and I'm sure Broadcom would prefer doing the implementation work
>over losing customers.

We're back to giving Broadcom (and others) business reasons to 
implement codecs, yes.
-- 
David Singer
Apple Computer/QuickTime