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

[Dave Singer]

At 13:26  +0200 27/03/07, Maik Merten wrote:
>It's good to know that Apple considers interoperability as something
>important.
>
>Of course in case of the iPod the highly proprietary DRM scheme is
>preventing true interoperability if someone condiders DRM a must for his
>business needs and Apple's credibility concerning true, termless
>interoperability sadly is taking some damage there.

I think we're getting well off topic of HTML here, but a good 
discussion of the problems here can be found in Steve Jobs' open 
letter.

>
>What matters here in the context of web-video is Apple's commitment to
>get <video> working on all platforms and all environments (either
>proprietary or free software or whatever categories there may be).

We'd really like to get to a good design on this, as the mess of 
embed/object plug-ins we feel is limiting both functionality and 
interoperability.

>
>>  We also have been sometimes openly critical of licensing terms and
>>  problems around codecs;  we supported the attempt to get a a
>>  royalty-free baseline for H.264, for example.  We recognize the value of
>>  research and invention, but we also realize that to realize a value from
>>  a use of those inventions, the use has to happen and make business
>>  sense.  It's a balance...
>
>Well, too bad there's no royality-free, termless licensing for a
>baseline of H.264. The current terms (
>http://www.mpegla.com/avc/AVC_TermsSummary.pdf ) absolutely question the
>suitability of H.264 for free browsers (beer and speech).

It would be tempting to go into a discussion of the IPR concerning 
the baseline of H.264, but it's really off-topic and obviously 
delicate.

>And to make matters worse you of course need a MPEG audio codec, too,
>which adds to the overal costs.

well, you could match an mpeg video codec with an audio codec from 
somewhere else, technically.

>
>
>>  We really feel that the HTML spec. should say no more about video and
>>  audio formats than it does about image formats (which is merely to give
>>  examples), and we should strive independently for audio/video
>>  convergence.  We'd really like to discuss the 'meat' of the proposal --
>>  the tags, the CSS, and so on!
>
>The whole point of the spec is to make sure implementations are
>compatible.  Just discussing the "meat" and ignoring how things work out
>in practice may backfire.

I think the example of SVG (a 'markup' language) having a codec 
requirement that 3GPP then had to explicitly write-out is 
instructive.  The attempt there didn't work.

There are, or should be, two levels of specification:  base 
technologies, and integration specifications.  For example, ISMA 
publishes integration specs on continuous media;  if uses MPEG 
codecs, IETF RTSP/RTP, and so on.  3GPP does the same, effectively. 
In 3G terminals, your image support and video support are defined by 
the matching 3GPP specs.

There is, alas, no group publishing an integration specification, or 
even recommendation, on what a 'web browser' on the general internet 
must, or should do.  It's an interesting exercise to ask what such a 
spec. should include or cover.  What's clear is that if done 
thoroughly, it's a lot of work, and does not belong 'inside' the HTML 
specification itself.  The HTML spec. should instead cover what the 
HTML means, and how it must be processed -- including fall-back.
-- 
David Singer
Apple Computer/QuickTime