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
