- From: Dave Singer <singer@apple.com>
- Date: Tue, 27 Mar 2007 09:04:47 -0700
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
Received on Tuesday, 27 March 2007 09:04:47 UTC