- From: Dave Singer <singer@apple.com>
- Date: Tue, 3 Apr 2007 11:52:53 -0700
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
Received on Tuesday, 3 April 2007 11:52:53 UTC