Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
On Sat, 2007-03-24 at 11:31 -0700, Kevin Marks wrote: On 3/23/07, Christian F.K. Schaller [EMAIL PROTECTED] wrote: On Fri, 2007-03-23 at 08:12 -0700, Kevin Calhoun wrote: On Mar 23, 2007, at 2:56 AM, Maik Merten wrote: MPEG4 adoption to the web has been poor from my point of view. Today I'd guess the absolute king in marketshare is Flash video, then following Windows Media, then followed by QuickTime (that may carry MPEG4... but the container is not MPEG) and perhaps a bit of RealVideo in between. Are you talking container or codecs here? AVI is a significant container format, with some variant of MPEG4 codecs in. My point was that the MPEG4 standard, including both its codecs and its container is not in very wide use on the net. There are some use seen of MPEG4 codecs in both Quicktime container (as I mentioned), but also as you mention the DVD/DVB ripping people are often using MP3 and MPEG4 part 2 their TV and DVD 'divx' rips. That said I don't really consider the P2P people's use part of 'the web' in the context of this mailing list as they do no or little integration of video inside webpages in the style of Flash video, windows media player or the quicktime player. So to make my point 100% clear, there is very little use of MPEG4 which is a combination of a container format and a set of audio and video formats on the web. There is some use of some of the parts of MPEG4 seen on the web and the Internet in general in conjunction with other technologies like the Quicktime format and the 'DivX' communities. Just a quick correction here: QuickTime does support the MPEG-4 container format. Yes, but that is the opposite of the stated issue. The issue is that the .mov files out there are actually not valid MPEG4 files. Which means that with a MPEG4 compliant demuxer one would not be able to demux a Quicktime file. So Maik's claim still stand, MPEG4 has almost no adoption on the web. Apple could have solved this of course by making sure .mov was MPEG4 compliant, which would have been a natural step after pushing so hard to make the quicktime container format the basis for the MPEG4 container format, but I guess the temptation of proprietary lock-in was to big. This is entirely backwards. the QT file format is not proprietary, it is openly documented. There is a patent issue around hint tracks that Apple could resolve, but other than that case (and it is a very marginal one, designed only to be read by streaming serves for stored content which is outside the scope for user agents anyway). If you are referring the docs provided by Apple they specifically state that they do not grant any license for anything and that they are only meant to be used for developing software for Apple platforms. On top of that Apple do offer a license for the Quicktime format on their website which do require you among other things to promise to only support the Quicktime container format. Another weakness of MPEG4/Quicktime as a container format is that its not very well suited to live streaming, which I think is a relevant weakness to the usecase of this group. MPEG4 defines a subset of codecs and support levels. QT allows arbitrary codecs to be contained. So Apple could not make QT files MPEG4 compliant retrospectively without a time machine. What Apple have done is support export to compliant MPEG4 files from all their editing products, and default to them in many cases (the .m4a files iTunes makes, the m4v ones that iMovie makes, and the audio with chapters and visual frames in that GarageBand makes are all mpeg4). All of these are played by iPods as well as clients Apple freely distributes for Mac and Windows (iTunes), and browser plugins, paying the encoding and decoding license fees. This is muddied by the iTunes store DRM that IS designed to be proprietary and prevent interoperability, but as Steve Jobs said recently, this is a very small fraction of media files. Now, if you want a fallback standard that is genuinely widely interoperating without patent issues, you could pick QuickTime with JPEG video frames and uncompressed audio. Millions of digital cameras support this format already, as do all quicktime implementations back to 1990, as well as WMP and RealPlayer and all the open source players. Others have commented on why this would be a useless fallback so I will refrain from answering. Christian
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
On Mar 26, 2007, at 6:58 AM, Christian F.K. Schaller wrote: On Sat, 2007-03-24 at 11:31 -0700, Kevin Marks wrote: Are you talking container or codecs here? AVI is a significant container format, with some variant of MPEG4 codecs in. My point was that the MPEG4 standard, including both its codecs and its container is not in very wide use on the net. There are some use seen of MPEG4 codecs in both Quicktime container (as I mentioned), but also as you mention the DVD/DVB ripping people are often using MP3 and MPEG4 part 2 their TV and DVD 'divx' rips. I think you will find a lot of it is actually in the MPEG4 container format. Apple's implementation can handle both, and most of are authoring tools generate MPEG4 audio and video by default. Regards, Maciej
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Kevin Marks schrieb: Now, if you want a fallback standard that is genuinely widely interoperating without patent issues, you could pick QuickTime with JPEG video frames and uncompressed audio. Millions of digital cameras support this format already, as do all quicktime implementations back to 1990, as well as WMP and RealPlayer and all the open source players. Well, that would be a desperate measure. It won't work for web video at all because compression efficiency is lousy (or even worse). People could just as well embed animated GIF films and provide a transcript ;) Maik Merten
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
I actually agree with this -- I think that MPEG-4 already has lots of heavy weight behind it and is quite a good format with lots of existing implementations. Theora/Vorbis are definitely the upstarts in this; they should live and die on their technical merits and adoption, not because of philosophical (i.e. open source) reasons. Personally, I think that Theora is quite strong quality-wise, but it's severely lacking on the adoption front. To that end, I'd suggest that the spec not specifically require Theora support, but instead /suggest/ that implementations support Theora, MPEG-4, or both. I don't agree with the earlier comment that Theora would be good for 'everyone' -- there are far more content producers out there with MPEG-4 software, hardware, and knowledge than there are Theora content producers. Specifying Theora as the baseline could just as easily have the opposite effect than intended: content authors could simply say 'thanks, but no thanks' and continue using their plugin based solutions. I think that is a far, far worse alternative. - Vlad Sent via BlackBerry from Cingular Wireless -Original Message- From: Maciej Stachowiak [EMAIL PROTECTED] Date: Thu, 22 Mar 2007 13:49:00 To:Håkon Wium Lie [EMAIL PROTECTED] Cc:whatwg@lists.whatwg.org, [EMAIL PROTECTED] Subject: Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements) On Mar 22, 2007, at 2:16 AM, Håkon Wium Lie wrote: I think having a single baseline codec will make video immensely more attractive to authors than it otherwise would be. I also believe from the point of view of Mozilla (or any other open source project) Theora is vastly more attractive than MPEG. If we don't ship MPEG and other vendors don't ship Theora, then the video element will be hobbled from the start. Yes, a baseline format seems good for everyone -- users, authors, open source and closed source browsers -- except for vendors pushing a proprietary media platform. I think you are implying that Apple's arguments against Ogg as a baseline are made in bad faith. That is an unfair implication. To the extent we have a media platform we want to promote, it is MPEG-4, a format and codec family that is an ISO standard. This format family is available in many hardware and software implementations, including open source implementations. While it is covered by patents, you certainly cannot call it proprietary. Our concerns about Ogg are legitimate, and should be addressed directly rather than insinuating that we have ulterior motives. Regards, Maciej
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Not in the EU, no such thing as a software patent. On 23 Mar 2007, at 04:55, Ian Hickson wrote: On Fri, 23 Mar 2007, Robert Sayre wrote: MPEG-4 is proprietary, because it is covered by patents. I hate to be the one to break this to you, but CSS is covered by patents, HTML is covered by patents, the DOM is covered by patents, JavaScript is covered by patents, and so forth. Proprietary technologies are those that are under the control of a single vendor. MPEG-4 is not proprietary. It's not available under royalty free licensing. But it is not under the control of a single vendor. That is the important difference, not whether the technology is patented or not. -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.'
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Hi Vladimir, Lets put any idea of using MPEG4 in the standard at rest right away. Unless someone has a brilliant idea for who the open source and freely distributable Firefox would avoid becoming non-distributable in large parts of the world, and still conform to the standard by including MPEG4 support, then that is a no-go from the beginning. Firefox is the major participant here dwarfing for instance Safari's market share. Theora/Dirac/Vorbis is the only solutions which can be chosen which has any hope of working out for all comers, while MPEG4 is dead-on-arrival for major participants from the get-go. All w3c standards are royalty free and there is no reason why this proposal should be different in that regard. And as Håkon Wium Lie pointed out in another email, the latest SVG standard already mandates Vorbis support, so half of what is needed is already specified in another major web standard. Personally I don't have strong preferences between Theora and Dirac as they both have their strenghts and weaknesses. But I think both could feet the needs of this standard well. Christian On Fri, 2007-03-23 at 07:09 +, [EMAIL PROTECTED] wrote: I actually agree with this -- I think that MPEG-4 already has lots of heavy weight behind it and is quite a good format with lots of existing implementations. Theora/Vorbis are definitely the upstarts in this; they should live and die on their technical merits and adoption, not because of philosophical (i.e. open source) reasons. Personally, I think that Theora is quite strong quality-wise, but it's severely lacking on the adoption front. To that end, I'd suggest that the spec not specifically require Theora support, but instead /suggest/ that implementations support Theora, MPEG-4, or both. I don't agree with the earlier comment that Theora would be good for 'everyone' -- there are far more content producers out there with MPEG-4 software, hardware, and knowledge than there are Theora content producers. Specifying Theora as the baseline could just as easily have the opposite effect than intended: content authors could simply say 'thanks, but no thanks' and continue using their plugin based solutions. I think that is a far, far worse alternative. - Vlad Sent via BlackBerry from Cingular Wireless -Original Message- From: Maciej Stachowiak [EMAIL PROTECTED] Date: Thu, 22 Mar 2007 13:49:00 To:Håkon Wium Lie [EMAIL PROTECTED] Cc:whatwg@lists.whatwg.org, [EMAIL PROTECTED] Subject: Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements) On Mar 22, 2007, at 2:16 AM, Håkon Wium Lie wrote: I think having a single baseline codec will make video immensely more attractive to authors than it otherwise would be. I also believe from the point of view of Mozilla (or any other open source project) Theora is vastly more attractive than MPEG. If we don't ship MPEG and other vendors don't ship Theora, then the video element will be hobbled from the start. Yes, a baseline format seems good for everyone -- users, authors, open source and closed source browsers -- except for vendors pushing a proprietary media platform. I think you are implying that Apple's arguments against Ogg as a baseline are made in bad faith. That is an unfair implication. To the extent we have a media platform we want to promote, it is MPEG-4, a format and codec family that is an ISO standard. This format family is available in many hardware and software implementations, including open source implementations. While it is covered by patents, you certainly cannot call it proprietary. Our concerns about Ogg are legitimate, and should be addressed directly rather than insinuating that we have ulterior motives. Regards, Maciej -- Business Development Manager Fluendo S.A. Office Phone: +34 933175153 Mobile Phone: +34 678608328
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Gareth Hay schrieb: Not in the EU, no such thing as a software patent. To my knowledge the MPEG patents are *not* software patents but are what I know as Verfahrenspatente (crudely translated that would be Method patents - anyone knowning the correct term?). Those patents are valid here. However, no matter what kinds of patents they are: The MPEG-LA collects money from european companies.
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
[EMAIL PROTECTED] schrieb: I actually agree with this -- I think that MPEG-4 already has lots of heavy weight behind it and is quite a good format with lots of existing implementations. Theora/Vorbis are definitely the upstarts in this; they should live and die on their technical merits and adoption, not because of philosophical (i.e. open source) reasons. Personally, I think that Theora is quite strong quality-wise, but it's severely lacking on the adoption front. Well, personally I don't see why adoption elsewhere would matter for web video. If the spec was about a plugin based video tag then it may matter as it would rely on whatever codecs there are deployed, but we're talking about shipping a decoder of whatever base format happens to get chosen. So it'll work out of the box, which is what matters. MPEG4 adoption to the web has been poor from my point of view. Today I'd guess the absolute king in marketshare is Flash video, then following Windows Media, then followed by QuickTime (that may carry MPEG4... but the container is not MPEG) and perhaps a bit of RealVideo in between. As for Ogg: It's predominant on Linux just like Windows Media is predominant on Windows. There's a whole ecosystem relying on the Ogg set of codecs - and it seems they're doing fine. To that end, I'd suggest that the spec not specifically require Theora support, but instead /suggest/ that implementations support Theora, MPEG-4, or both. The current spec says that UAs may implement whatever video format they like, but that they should implement Ogg Vorbis and Ogg Theora. If Apple wants to adopt MPEG4 (they can afford this and are member of the MPEG Industry Forum, so their will to adopt MPEG should be rather clear) they can do so. As long as nobody proposes another format that can be distributed freely without licensing issues I'd strongly propose keeping the Ogg codecs in a SHOULD state. I don't agree with the earlier comment that Theora would be good for 'everyone' -- there are far more content producers out there with MPEG-4 software, hardware, and knowledge than there are Theora content producers. Specifying Theora as the baseline could just as easily have the opposite effect than intended: content authors could simply say 'thanks, but no thanks' and continue using their plugin based solutions. I think that is a far, far worse alternative. I don't really see how the current production chain happens to be a problem. If you're happening to produce content in MPEG you nowadays have to convert your content to Flash Video anyway. It's no problem to instead convert to Ogg Theora (there are existing and easy to use tools for that). Your existing content most likely isn't suitable for web streaming anyway due to bitrate concerns - so in most cases a conversion stage is inevitable.
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
It is an Urban Legend that there are no software patents in the EU. True enough there is no 'EU' software patents, but a lot of member states do have them. I suggest going the MPEG LA's webpage and looking at the patent lists they have there for MPEG4. You will notice that a lot of the patents are from EU countries. Christian On Fri, 2007-03-23 at 08:35 +, Gareth Hay wrote: Not in the EU, no such thing as a software patent. On 23 Mar 2007, at 04:55, Ian Hickson wrote: On Fri, 23 Mar 2007, Robert Sayre wrote: MPEG-4 is proprietary, because it is covered by patents. I hate to be the one to break this to you, but CSS is covered by patents, HTML is covered by patents, the DOM is covered by patents, JavaScript is covered by patents, and so forth. Proprietary technologies are those that are under the control of a single vendor. MPEG-4 is not proprietary. It's not available under royalty free licensing. But it is not under the control of a single vendor. That is the important difference, not whether the technology is patented or not. -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.' -- Business Development Manager Fluendo S.A. Office Phone: +34 933175153 Mobile Phone: +34 678608328
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Maciej Stachowiak schrieb: This is true of hardware audio decoders, but not hardware video decoders, which use dedicated circuit blocks. If Ogg suddenly became popular it would likely be a several year pipeline before there were any hardware decoders. I'd say that any hardware player using hard-wired codec functionality is a bad design. There are many embedded CPUs out there that also contain DSP functionality. Those can easily support Theora. Most Flash video uses on the Sorenson Spark codec which is based on H.263. This is a much less processor-intensive codec than more modern options, but also gives worse compression. H.264 has been approved as one of the codecs for 3GPP so you can expect it to be supported by mobile devices in the future. Modern hardware decoders these days support H.263, MPEG-4 Part II, and H.264. These also happen to be the 3GPP codecs. Those devices can also easily decode Theora on their general purpose CPUs as has been demonstrated on the Nokia web tablet devices - without even touching the DSP functionality! Plus we're talking of web video here. That means we should choose a codec that also decodes well on mobile platforms that don't have hardware accelerated codecs on-board (like PocketPCs or gaming consoles). Although I can see why Apple would want to support the MPEG codecs (they're technically good and are popular and Apple is involved with MPEG) I don't see why this rules out Theora being mentioned as base format. Apple can safely ignore this and still be compliant, while stripping out mentioning Ogg Theora may lead to no base format being in place at all.
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
* Christian F.K. Schaller wrote: All w3c standards are royalty free and there is no reason why this proposal should be different in that regard. And as Håkon Wium Lie pointed out in another email, the latest SVG standard already mandates Vorbis support, so half of what is needed is already specified in another major web standard. Neither is true, there is no gurantee for the former, and the latter would be more accurately characterized as, in 2004 there was a pro- posal to mandate Vorbis support in a possible future SVG 1.2 Full Recommendation. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Hi Bjoern, There is a w3c policy in place regarding this: http://www.w3.org/Consortium/Patent-Policy-20040205/ Since I assume you knew about that I guess your claim about no guarantee is more about 'there might be submarine patents', yes this is true. But there is a major difference to a standard falling victim to such and actively incorporating royalty bearing patented technology. And for SVG I have been on the SVG-w3c mailing list and at least there seems to be no clamor for removing it from the proposed spec. But sure enough it hasn't been finally approved. Christian On Fri, 2007-03-23 at 11:49 +0100, Bjoern Hoehrmann wrote: * Christian F.K. Schaller wrote: All w3c standards are royalty free and there is no reason why this proposal should be different in that regard. And as Håkon Wium Lie pointed out in another email, the latest SVG standard already mandates Vorbis support, so half of what is needed is already specified in another major web standard. Neither is true, there is no gurantee for the former, and the latter would be more accurately characterized as, in 2004 there was a pro- posal to mandate Vorbis support in a possible future SVG 1.2 Full Recommendation. -- Business Development Manager Fluendo S.A. Office Phone: +34 933175153 Mobile Phone: +34 678608328
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Hi Gareth, This is a strange way of looking at the issue. Once a patent is granted it is by definition valid and enforceable. It is the people opposing it who have to prove their non-legality at that point and not the other way around. So sure a lot of software patents might be challenged around Europe, but the main burden of proving they are non-valid falls on the people opposing the patent and not the patent holder. So until someone have successfully challenged all the patents involved and gotten them found invalid they are by definition valid. A granted patent is valid until a court of law finds it invalid, not invalid until a court of law finds it valid. Be aware that I do not support the idea of software patents, not in the slightest, but one have to accept that in many places around the world they are 'the law of the land'. One should work to change the law, not pretend it doesn't exist. Christian On Fri, 2007-03-23 at 10:30 +, Gareth Hay wrote: As i said in a previous post, this is a very grey area.[1][2] So much so that many of the granted patents are being opposed, and until the outcome of these oppositions, neither one of us can comment on the true legality of them. I would suggest backing away from any such areas where software patentability becomes an issue. Case law hasn't sufficiently established the legality in my country, europe and many, many territories. [1]http://en.wikipedia.org/wiki/Software_patents#In_Europe [2]http://en.wikipedia.org/wiki/ Software_patents_under_the_European_Patent_Convention#Inventive_step_tes t On 23 Mar 2007, at 10:02, Christian F.K. Schaller wrote: It is an Urban Legend that there are no software patents in the EU. True enough there is no 'EU' software patents, but a lot of member states do have them. I suggest going the MPEG LA's webpage and looking at the patent lists they have there for MPEG4. You will notice that a lot of the patents are from EU countries. Christian On Fri, 2007-03-23 at 08:35 +, Gareth Hay wrote: Not in the EU, no such thing as a software patent. On 23 Mar 2007, at 04:55, Ian Hickson wrote: On Fri, 23 Mar 2007, Robert Sayre wrote: MPEG-4 is proprietary, because it is covered by patents. I hate to be the one to break this to you, but CSS is covered by patents, HTML is covered by patents, the DOM is covered by patents, JavaScript is covered by patents, and so forth. Proprietary technologies are those that are under the control of a single vendor. MPEG-4 is not proprietary. It's not available under royalty free licensing. But it is not under the control of a single vendor. That is the important difference, not whether the technology is patented or not. -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.' -- Business Development Manager Fluendo S.A. Office Phone: +34 933175153 Mobile Phone: +34 678608328 -- Business Development Manager Fluendo S.A. Office Phone: +34 933175153 Mobile Phone: +34 678608328
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Hi, Even interoperability at the API and markup level would be a huge step forward relative to the current state of web video. While also having a single universally implemented codec would also be good, that may not presently be feasible. A huge step that does not go all the way is not enough in this case. If the end result is still you are not sure if a user has this codec then a web site designer will not care about the fact that the API is the same, and the user will still not have guaranteed working video. Regarding the specific issue of mobile devices this is a highly speculative argument. There is nothing stopping Theora chips from being produced and since many 'hardware decoders' are actually programmable DSP's this is even less of an real argument. This is true of hardware audio decoders, but not hardware video decoders, which use dedicated circuit blocks. If Ogg suddenly became popular it would likely be a several year pipeline before there were any hardware decoders. There are cameras with embedded Ogg/Theora encoding that I've actually seen and work. I would be surprised if there are no Theora hardware decoders, but I'm not in that business so I haven't seen any. The BBC is working on Dirac, a codec that is not even stable yet, and they are planning to have a hardware encoder/decoder within the year. Several year pipeline sounds over-pessimistic. Case in point: my Nokia N800 certainly does not play H264. The Flash videos that it can play are not played using hardware decoder support. I don't know many hardware players that actually play H264 - I'm guessing the iPod video is one of the few, and that player does not support web browsing. Most Flash video uses on the Sorenson Spark codec which is based on H. 263. This is a much less processor-intensive codec than more modern options, but also gives worse compression. H.264 has been approved as one of the codecs for 3GPP H263 is mandatory for 3GPP, H264 is only suggested, and having dealt with several phones for streaming I can tell you that not all phones support H264. Phones only support a select few widths and heights anyway, so I doubt phones are relevant to this discussion at the moment. I am sure that if everyone else starts supporting Theora and Vorbis then Apple will quickly start feeling comfortable, it's the way the market works. Apple doesn't currently support WMV, despite it being a popular format for video on the web, so I'm not sure that follows. Me neither. But that argument sounds a lot like Apple will only support a codec that it already supports. If Apple is unwilling to budge from that, then we're not discussing about inter-operating :) Thomas
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Gareth Hay wrote: At best, we can only conclude that this is a very grey area throughout different regions of the world, and as such, is not only out with the scope of this list, but possibly of the spec itself. That's a non-sequitur. Why does it not follow? The fact that there is legal uncertainty about an issue does not mean it is out of scope of the list. If there were legal uncertainty about whether it's even possible to embed any sort of video in the browser without violating a patent, the topic of embedding video in the browser would still be in scope. In other words, the scope of this list or of the spec does not vary depending on the legal situation in different world regions. Therefore, what you said is a non-sequitur. Unless legal advice can be sought from all potential markets, I think we are all arguing in vein and should conclude to distance ourselves from including this type of thing in the spec. That's the fallacy of unattainable perfection. Ok, so in risk analysis terminology, it is a risk to seek no legal advice on a legal topic, to reduce that risk we should get the input of as many different qualified legal persons from as many different regions as possible. As others have pointed out, every current standard with which the WHAT-WG works has legal issues associated with it. Up to this point, WHAT-WG has not let that fact paralyse it until lawyers give the go-ahead. I am not denying the need to examine the legal situation when deciding on our attitude to the codec question. I am denying that the situation is so unclear that a person of ordinary intelligence (and we have many people smarter than that) cannot understand the shape of it and make working decisions accordingly. Gerv
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
I defer on the legal side, i really do, On 23 Mar 2007, at 12:18, Christian F.K. Schaller wrote: I mean what have we truly achieved if the new VIDEO element means that web page developers still have to support Windows Media for Windows clients, MPEG4 for Apple systems and Ogg for Linux/Unix systems? I think in that case most web developers would be more than happy to just stick to using flash video, at least they can get away with encoding once and have a decent chance of all platforms supporting it. For the video tag to work in the situation you describe, across platforms and browsers means introducing a codec into the spec. *If* this is possible, it then depends on browser developers following the spec, *If* they do that, it is still possible for developers to use the video they already have encoded, in the new video tag (as I can't see a video tag working if you *require* a specific codec for all content), to the exclusion of those who's UA don't support it, and a lot of people will only care if it works in IE. I'm with you, we should aim for the sky, I just think there are too many road blocks in the way. Gareth
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
I am not denying the need to examine the legal situation when deciding on our attitude to the codec question. I am denying that the situation is so unclear that a person of ordinary intelligence (and we have many people smarter than that) cannot understand the shape of it and make working decisions accordingly. And I am suggesting without specialist help from those qualified in law, it is absolutely pointless for us to debate it, as there is *no* way to make an informed and accurate decision on the matter. Intelligence doesn't enter into the argument, after all, if it did, we would all defer our legal queries to Steven Hawkin, so we have another non-sequitur. Once again, I am leaving the thread, as we are getting nowhere, it's off topic, and a waste of both our respective time.
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Also sprach Bjoern Hoehrmann: the SVG 1.2 WD requires support for Ogg Vorbis: http://www.w3.org/TR/2004/WD-SVG12-20041027/media.html And as Håkon Wium Lie pointed out in another email, the latest SVG standard already mandates Vorbis support, so half of what is needed is already specified in another major web standard. .. the latter would be more accurately characterized as, in 2004 there was a pro- posal to mandate Vorbis support in a possible future SVG 1.2 Full Recommendation. From 2004 and onwards there has been rough consensus among the 45 or so authors of SVG 1.2 that SVG user agents are required to support the Ogg Vorbis audio format. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Kevin Calhoun schrieb: Just a quick correction here: QuickTime does support the MPEG-4 container format. Okay, thanks for pointing that out so confusion doesn't spread. When thinking of QuickTime I was mostly thinking of older .mov files that you can still see floating around here and there and do not contain MPEG codecs. IIRC the MPEG4 container was more or less derived from QickTime's .mov container, so I'm not sure if .mov actually *is* actually the MPEG4 container by now. Maik Merten
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
On Fri, 2007-03-23 at 08:12 -0700, Kevin Calhoun wrote: On Mar 23, 2007, at 2:56 AM, Maik Merten wrote: MPEG4 adoption to the web has been poor from my point of view. Today I'd guess the absolute king in marketshare is Flash video, then following Windows Media, then followed by QuickTime (that may carry MPEG4... but the container is not MPEG) and perhaps a bit of RealVideo in between. Just a quick correction here: QuickTime does support the MPEG-4 container format. Yes, but that is the opposite of the stated issue. The issue is that the .mov files out there are actually not valid MPEG4 files. Which means that with a MPEG4 compliant demuxer one would not be able to demux a Quicktime file. So Maik's claim still stand, MPEG4 has almost no adoption on the web. Apple could have solved this of course by making sure .mov was MPEG4 compliant, which would have been a natural step after pushing so hard to make the quicktime container format the basis for the MPEG4 container format, but I guess the temptation of proprietary lock-in was to big. Christian
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
On Mar 23, 2007, at 8:29 AM, Maik Merten wrote: Kevin Calhoun schrieb: Just a quick correction here: QuickTime does support the MPEG-4 container format. Okay, thanks for pointing that out so confusion doesn't spread. When thinking of QuickTime I was mostly thinking of older .mov files that you can still see floating around here and there and do not contain MPEG codecs. IIRC the MPEG4 container was more or less derived from QickTime's .mov container, so I'm not sure if .mov actually *is* actually the MPEG4 container by now. They're still distinct in a number of particulars. For example MPEG-4 refines a number of details in the way that media streams are described. These refinements are very nice but couldn't be shoehorned back into the .mov file format without introducing software compatibility problems. One of the main differences it that the MPEG-4 container format specification imposes restrictions on the types of audio and video objects it accepts, so while a well-formed QuickTime movie file can carry WMV, for example, an MPEG-4 file cannot. Anyway it appears that I got your original assertion backwards. Thanks for the clarification.
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Maciej Stachowiak wrote: - Even if all browsers end up supporting Ogg Theora/Vorbis, these are not the best-compression codecs available. So a large-scale video content provider that wants to save on bandwidth may wish to provide H.264/AAC content to those browsers that can handle it, even if all browsers could handle a lower-quality codec as well. - Many mobile devices cannot practically implement decoding in software, and rely on custom hardware which can handle only a fixed set of codecs. While hardware decoders for H.264 are widely available, I don't think there are any for Ogg Theora. Even in cases where the CPU in theory has the power to do some software decoding, this will be a much bigger battery drain than hardware decoding. So you really want the ability to serve the right codec to such devices. So while your average blogger may only upload media content in one codec, larger scale video service providers may want to take advantage of codec-based selection. This seems like a problem that can be solved by content negotiation. Content negotiation has the advantage that it doesn't potentially add extra requests to find the right representation: the browser just says here's what I support and the server does the best it can, or returns an explicit I don't have anything for you message. (Not Acceptable) However, as others have pointed out, MIME types only represent the container format and not the codecs inside, so content negotiation would need to be extended to somehow allow audio and video codecs to be presented in addition to container formats. Note that this problem applies when doing object-style fallback on the video element too, as you need to specify something in the type=... attribute to avoid the browser having to request every representation in turn to reject it.
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
On Mar 22, 2007, at 1:29 AM, Martin Atkins wrote: However, as others have pointed out, MIME types only represent the container format and not the codecs inside, so content negotiation would need to be extended to somehow allow audio and video codecs to be presented in addition to container formats. Note that this problem applies when doing object-style fallback on the video element too, as you need to specify something in the type=... attribute to avoid the browser having to request every representation in turn to reject it. There's a MIME extension for codecs (see link in the published proposal). But it's impractical to specify all codecs and codec profiles the UA can support in an Accept: header, compared to specifying the codecs used by a specific media item. Regards, Maciej
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Maciej Stachowiak schrieb: - As mentioned above, some devices may have a much harder time implementing Ogg than other codecs. Although a SHOULD-level requirement would excuse them, I'm not sure it's appropriate to have it if it might be invoked often. Ogg Theora decoding has been demonstrated on a wide range of platforms, including lower-end ARM hardware - and that's with ignoring all the DSP and SIMD extensions the more funky ARM things have. I'd be surprised if there was a device capable driving a reasonable browser that couldn't somehow get Theora working. - Although the Ogg codecs don't have known patents that aren't RF licensed, it's not completely clear that none of the patents out there on video/audio encoding apply. Often, parties holding a submarine patent wait for a company with very deep pockets (like Apple, or Microsoft, or Google) to infringe on the patent before they sue. On the other hand, MPEG codecs have been implemented by many large corporations already, and no patents have appeared besides the ones that can be licensed from MPEG-LA for a fee. So, ironically, for a large company that has no problem the patent fees, Ogg may carry more patent risk than MPEG. Theora was based on VP3, which was a commercial codec developed by On2. VP6 is also based on VP3, so it seems (through VP4 and VP5) and is widely deployed by Adobe in form of the Flash players. If submarines are out there now would be a pretty good time to get after On2 and Adobe. MPEG-LA gives zero security against submarine patents. Just ask Microsoft what licensing MP3 did to increase their security. Plus big parts of the free software world just can't pay the fees or are against the very idea of having to license patents. Anyway, trying to decide upon a codec by looking at submarine patents is plain impossible by its very nature. So instead of trying to avoid submarines the companies with deep pockets should lobby a complete redesign of the patent system. Sooner or later they'll get hit - if not by video codecs than by something else. - Placing requirements on format support would be unprecedented for HTML specifications, which generally leave this up to the UA, with de facto baseline support being decided by the market. Unprecedented perhaps. That doesn't mean it doesn't make sense. If there is no baseline format most browsers on most platforms can support the whole idea of video becomes 100% uninteresting. We are very sympathetic to the desire for interoperability, and we would really like there to be a codec that every browser can feel comfortable implementing. But we are not sure such a codec exists at this time (except for really primitive things, if you want to count animated GIF or APNG as video codecs). In case you can't be convinced there is a a suitable format what do you propose? Dropping video?
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Robert O'Callahan / Maciej Stachowiak wrote: - Placing requirements on format support would be unprecedented for HTML specifications, which generally leave this up to the UA, with de facto baseline support being decided by the market. It's not unprecedented in W3C; the SVG 1.2 WD requires support for Ogg Vorbis: http://www.w3.org/TR/2004/WD-SVG12-20041027/media.html I think having a single baseline codec will make video immensely more attractive to authors than it otherwise would be. I also believe from the point of view of Mozilla (or any other open source project) Theora is vastly more attractive than MPEG. If we don't ship MPEG and other vendors don't ship Theora, then the video element will be hobbled from the start. Yes, a baseline format seems good for everyone -- users, authors, open source and closed source browsers -- except for vendors pushing a proprietary media platform. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
On Mar 22, 2007, at 2:16 AM, Håkon Wium Lie wrote: I think having a single baseline codec will make video immensely more attractive to authors than it otherwise would be. I also believe from the point of view of Mozilla (or any other open source project) Theora is vastly more attractive than MPEG. If we don't ship MPEG and other vendors don't ship Theora, then the video element will be hobbled from the start. Yes, a baseline format seems good for everyone -- users, authors, open source and closed source browsers -- except for vendors pushing a proprietary media platform. I think you are implying that Apple's arguments against Ogg as a baseline are made in bad faith. That is an unfair implication. To the extent we have a media platform we want to promote, it is MPEG-4, a format and codec family that is an ISO standard. This format family is available in many hardware and software implementations, including open source implementations. While it is covered by patents, you certainly cannot call it proprietary. Our concerns about Ogg are legitimate, and should be addressed directly rather than insinuating that we have ulterior motives. Regards, Maciej
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
On 3/22/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: To the extent we have a media platform we want to promote, it is MPEG-4, a format and codec family that is an ISO standard. Not a particularly high bar for a Web standard. This format family is available in many hardware and software implementations, including open source implementations. They don't seem to be distributable outside of Sweden and Hungary. While it is covered by patents, you certainly cannot call it proprietary. MPEG-4 is proprietary, because it is covered by patents. Our concerns about Ogg are legitimate, Disagree. Your objections involve proving a negative. and should be addressed directly rather than insinuating that we have ulterior motives. Agree. The problem with bringing up patent issues on technical mailing lists is that it's likely no one can evaluate them with any degree of expertise. As a result, it is not possible for WG members to distinguish between legal issues that Apple has no control over and Apple's chosen corporate strategy. I will add once again that I think this topic is inappropriate. We don't get email containing GPL code samples, and it would be nice not to get weird legal email as well. -- Robert Sayre
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
On Fri, 23 Mar 2007, Robert Sayre wrote: MPEG-4 is proprietary, because it is covered by patents. I hate to be the one to break this to you, but CSS is covered by patents, HTML is covered by patents, the DOM is covered by patents, JavaScript is covered by patents, and so forth. Proprietary technologies are those that are under the control of a single vendor. MPEG-4 is not proprietary. It's not available under royalty free licensing. But it is not under the control of a single vendor. That is the important difference, not whether the technology is patented or not. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
On Fri, 23 Mar 2007, Robert Sayre wrote: On 3/23/07, Ian Hickson [EMAIL PROTECTED] wrote: I hate to be the one to break this to you, but CSS is covered by patents, I hate to be the one to break this to you, but you don't [know] anything about patents. Many engineers have trouble accepting this. I actually know far more than I want to about patents. What is it that I don't know that is relevant here, though? The technologies I listed _are_ covered by patents, yet they are not proprietary. This seems like a relevant counterexample to your argument. It's not available under royalty free licensing. But it is not under the control of a single vendor. That is the important difference, not whether the technology is patented or not. Proprietary technologies can come from a group of vendors as well. Yes, if that group is closed. The International Standards Organisation is, however, not one such case. If the ISO standards are proprietary, then that would make most W3C and ECMA standards proprietary too, in which case I really don't know what use or meaning the term would have. I'm not arguing in favour of any of the MPEG-4 profiles as a baseline codec. However, arguing that we should dismiss MPEG-4 because it is proprietary is incorrect. It is not royalty-free, which is a good argument against it, but it is centainly not proprietary. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
On 3/23/07, Ian Hickson [EMAIL PROTECTED] wrote: On Fri, 23 Mar 2007, Robert Sayre wrote: On 3/23/07, Ian Hickson [EMAIL PROTECTED] wrote: The technologies I listed _are_ covered by patents, yet they are not proprietary. This seems like a relevant counterexample to your argument. If I have to pay someone because they own something, that seems like a pretty good indicator of a proprietary technology. Why would I have to pay money if no one owns the codec? It's not the codec owners you have to pay money to. You have to pay money to the people whose techniques are used in the codec algorithms. They don't own the codec, they own a government-granted temporary monopoly on the ideas that the codec makes use of. Seems like you're splitting hairs. Here's the definition of proprietary, according to the [definition] link helpfully provided by Google search, sense 3: http://www.answers.com/proprietaryr=67 3. Owned by a private individual or corporation under a trademark or patent: a proprietary drug. So there it is, right there in the dictionary. You can always tell that a technical mailing list off on some ridiculous tangent when people are pasting dictionary definitions of words into threads. -- Robert Sayre
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
On Mar 22, 2007, at 3:33 AM, Christian F.K. Schaller wrote: A fallback without a mandated 'minimum' codec is next to worthless. Standards with similar goals of interoperability, like DLNA, have ended up choosing some mandated codecs (which are all 'older' codecs) and some optional higher quality codecs. A standard which does not mandate any codecs in this area quickly becomes a joke as you might easily end up having no two implementations actually be interoperable. Even interoperability at the API and markup level would be a huge step forward relative to the current state of web video. While also having a single universally implemented codec would also be good, that may not presently be feasible. Regarding the specific issue of mobile devices this is a highly speculative argument. There is nothing stopping Theora chips from being produced and since many 'hardware decoders' are actually programmable DSP's this is even less of an real argument. This is true of hardware audio decoders, but not hardware video decoders, which use dedicated circuit blocks. If Ogg suddenly became popular it would likely be a several year pipeline before there were any hardware decoders. Case in point: my Nokia N800 certainly does not play H264. The Flash videos that it can play are not played using hardware decoder support. I don't know many hardware players that actually play H264 - I'm guessing the iPod video is one of the few, and that player does not support web browsing. Most Flash video uses on the Sorenson Spark codec which is based on H. 263. This is a much less processor-intensive codec than more modern options, but also gives worse compression. H.264 has been approved as one of the codecs for 3GPP so you can expect it to be supported by mobile devices in the future. Modern hardware decoders these days support H.263, MPEG-4 Part II, and H.264. These also happen to be the 3GPP codecs. We are very sympathetic to the desire for interoperability, and we would really like there to be a codec that every browser can feel comfortable implementing. But we are not sure such a codec exists at this time (except for really primitive things, if you want to count animated GIF or APNG as video codecs). I am sure that if everyone else starts supporting Theora and Vorbis then Apple will quickly start feeling comfortable, it's the way the market works. Apple doesn't currently support WMV, despite it being a popular format for video on the web, so I'm not sure that follows. Regards, Maciej
[whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
On Mar 21, 2007, at 6:16 PM, Ian Hickson wrote: * I'm concerned about the type attribute for content negotiation. Historically, type attributes are very badly implemented and even less reliably used. Conditional fallback in general is badly implemented and bug-prone especially in the context of dynamic changes. In addition, I'm not convinced there is much in the way of multi-codec data on the Web that would be addressed by this. ON FALLBACK I think the lack of multi-codec data is in part because it's not easy to automatically present the right video stream out of several streams using object. It's hard enough to write the object markup to work in all browsers with a single codec! But I think that having a good mechanism to do this is important. Here are some reasons: - Even if all browsers end up supporting Ogg Theora/Vorbis, these are not the best-compression codecs available. So a large-scale video content provider that wants to save on bandwidth may wish to provide H.264/AAC content to those browsers that can handle it, even if all browsers could handle a lower-quality codec as well. - Many mobile devices cannot practically implement decoding in software, and rely on custom hardware which can handle only a fixed set of codecs. While hardware decoders for H.264 are widely available, I don't think there are any for Ogg Theora. Even in cases where the CPU in theory has the power to do some software decoding, this will be a much bigger battery drain than hardware decoding. So you really want the ability to serve the right codec to such devices. So while your average blogger may only upload media content in one codec, larger scale video service providers may want to take advantage of codec-based selection. I think the fallback mechanism specified avoids some of the pitfalls of other fallback mechanisms: A) It is specified to take the declared type as authoritative for fallback purposes, so dynamic fallback and its attendant complexities do not have to get involved. B) It lets you select based on codec and even codec profile, not just container format. C) The video syntax itself is simple enough that it won't reduce to an incomprehensible jumble like it sometimes does with object. However, it's true that in general you may also want to consider issues such as screen size and data rate when choosing from several available video options. QuickTime has a concept of selector movies than can choose to download one of several separate resources based on such criteria, but it makes more sense to do it in markup or CSS. We discussed the possibility of using CSS media queries to account for screen size and data rate. However, this has a couple of issues: - You probably still want a mechanism for codec-based selection. Exposing available codecs to media queries seems like it will be very complex, comparing to declaring what codecs you use and letting the UA decide. - To emulate fallback with CSS media queries, you need to make sure your queries are mutually exclusive, which generally means query 2 has to include not query1 and..., query 3 has to negate both queries 1 and 2, and so forth. This seems more complex to author than a fallback model. All that being said, we are not entirely sure what the best approach is for screen size and data rate fallback, but type seems like a good model for format-based fallback. ON RECOMMENDED OR MANDATED CODECS We think it is a mistake to require Ogg support, even as a SHOULD- level requirement, for several reasons. - As mentioned above, some devices may have a much harder time implementing Ogg than other codecs. Although a SHOULD-level requirement would excuse them, I'm not sure it's appropriate to have it if it might be invoked often. - Although the Ogg codecs don't have known patents that aren't RF licensed, it's not completely clear that none of the patents out there on video/audio encoding apply. Often, parties holding a submarine patent wait for a company with very deep pockets (like Apple, or Microsoft, or Google) to infringe on the patent before they sue. On the other hand, MPEG codecs have been implemented by many large corporations already, and no patents have appeared besides the ones that can be licensed from MPEG-LA for a fee. So, ironically, for a large company that has no problem the patent fees, Ogg may carry more patent risk than MPEG. - Placing requirements on format support would be unprecedented for HTML specifications, which generally leave this up to the UA, with de facto baseline support being decided by the market. We are very sympathetic to the desire for interoperability, and we would really like there to be a codec that every browser can feel comfortable implementing. But we are not sure such a codec exists at this time (except for really primitive things, if you want to count animated
[whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
- As mentioned above, some devices may have a much harder time implementing Ogg than other codecs. Although a SHOULD-level requirement would excuse them, I'm not sure it's appropriate to have it if it might be invoked often. OK, let's assume Theora is a bad format for some devices. If someone wants to target those devices with a better codec, they can do so, and use Theora as the fallback. If they don't care, they use Theora and at least the content is still playable on the devices. What's the problem here? It's still a net win over the no-standard-codec alternative. - Although the Ogg codecs don't have known patents that aren't RF licensed, it's not completely clear that none of the patents out there on video/audio encoding apply. Often, parties holding a submarine patent wait for a company with very deep pockets (like Apple, or Microsoft, or Google) to infringe on the patent before they sue. On the other hand, MPEG codecs have been implemented by many large corporations already, and no patents have appeared besides the ones that can be licensed from MPEG-LA for a fee. So, ironically, for a large company that has no problem the patent fees, Ogg may carry more patent risk than MPEG. Just because no patents have appeared against MPEG doesn't mean there aren't any outside the MPEG-LA pool. Submarines can surface at any time. See Forgent. - Placing requirements on format support would be unprecedented for HTML specifications, which generally leave this up to the UA, with de facto baseline support being decided by the market. Just because previous HTML specifications have been deficient in this regard doesn't mean we have to repeat the mistake. I think having a single baseline codec will make video immensely more attractive to authors than it otherwise would be. I also believe from the point of view of Mozilla (or any other open source project) Theora is vastly more attractive than MPEG. If we don't ship MPEG and other vendors don't ship Theora, then the video element will be hobbled from the start. Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
On Mar 21, 2007, at 9:14 PM, Robert O'Callahan wrote: - As mentioned above, some devices may have a much harder time implementing Ogg than other codecs. Although a SHOULD-level requirement would excuse them, I'm not sure it's appropriate to have it if it might be invoked often. OK, let's assume Theora is a bad format for some devices. If someone wants to target those devices with a better codec, they can do so, and use Theora as the fallback. If they don't care, they use Theora and at least the content is still playable on the devices. What's the problem here? It's still a net win over the no-standard- codec alternative. There are devices that have a hardware video decoder but not enough CPU power for even relatively simple video. These could justifiably omit Ogg under the SHOULD clause. Others would simply burn battery at an unacceptable rate while doing software video decoding. Would these too be justified in omitting Ogg support under the SHOULD clause? If so, then not much interoperability is being gained, ultimately. So, ironically, for a large company that has no problem the patent fees, Ogg may carry more patent risk than MPEG. Just because no patents have appeared against MPEG doesn't mean there aren't any outside the MPEG-LA pool. Submarines can surface at any time. See Forgent. While it's hard to have certainty, I am pointing out that the relative risk assessment can look different depending on one's position. - Placing requirements on format support would be unprecedented for HTML specifications, which generally leave this up to the UA, with de facto baseline support being decided by the market. Just because previous HTML specifications have been deficient in this regard doesn't mean we have to repeat the mistake. I think having a single baseline codec will make video immensely more attractive to authors than it otherwise would be. I also believe from the point of view of Mozilla (or any other open source project) Theora is vastly more attractive than MPEG. If we don't ship MPEG and other vendors don't ship Theora, then the video element will be hobbled from the start. I agree that a baseline set of codecs would be good. I'm just not sure it is possible to reach consensus on what that set should be. From Apple's point of view, MPEG is significantly more attractive than Ogg. Regards, Maciej
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
On 3/22/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: There are devices that have a hardware video decoder but not enough CPU power for even relatively simple video. These could justifiably omit Ogg under the SHOULD clause. Is there something that prevents implementation of ogg hardware video decoders? That sounds like a possible technical point. While it's hard to have certainty, I am pointing out that the relative risk assessment can look different depending on one's position. Sounds like an interesting discussion for two lawyers. It certainly seems like it would be difficult to speak for all Gecko or WebKit embedders, though. -- Robert Sayre
