[whatwg] on codecs in a 'video' tag.
singer at apple.com
Tue Mar 27 09:04:47 PDT 2007
At 13:26 +0200 27/03/07, Maik Merten wrote:
>It's good to know that Apple considers interoperability as something
>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
>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
>> 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
>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.
More information about the whatwg