[whatwg] Codec mess with and tags
Hello, I have been keeping track of the developments of the and tag for awhile now, and I recently noticed that there was a mailing list for discussing the spec. So, I wanted to put forth my comments about this mess regarding codecs I'm seeing sprawled all over the mailing list. First of all, what is the POINT of supporting any codec if it will cause inconveniences to anybody (e.g. patent royalties, high licensing fees, etc.)? The way I see it, there isn't. The HTML 5 specification should definitely support a codec that fulfills the following legal criteria: * No patent royalties for any purpose. Must by totally royalty free for any purpose. * Licensing of the actual specification AND reference implementation of the codec must be permissible enough to allow both commercial and open source to benefit. Ideally, either a sort of "3-clause BSD" type license for implementation would be good. However, an LGPL license might be okay too. Some companies might see the LGPL a little worse than others, so BSD licensing would be preferred. For specification, a non-restrictive freely available specification would be perfect. Preferably Public Domain, but CC-BY, CC-BY-SA, GFDL, or equivalent would be fine too. Now, I am NOT a lawyer, but I do feel that the above legal criteria would be satisfactory to both sides, legal and commercial. Of course, we need to have a GOOD codec too. The codec must: * Be reasonably comparable to MPEG-2 and/or MPEG-4. Most people do not recognize the difference beyond these two, and quality higher than that comes at the cost of file size. * Usable on all major platforms. Windows, Linux, and Darwin/Mac OS X support is a must. Supporting other UNIX platforms is a plus, especially *BSD. Supporting minor platforms such as Amiga OS, BeOS, OS/2, eComStation, etc. is a huge plus as well, but not required. * Decent level of quality to bitrate. This might seem like a quality belonging to the first item on this list, but it isn't. For example, RealVideo at about 1/4 less the bitrate of an DivX video seem remarkably similar. I am no total expert on audio/video technologies, but I feel that what I listed above would be the best criteria for selecting codecs for the HTML 5 and tags. With , the choice is remarkably easy. Support WAV and Ogg Vorbis, at the very least. I would also like to point out that FLAC would be a nice choice for lossless audio encoding, and should be an option too. Maybe Speex, but meh. I don't feel that Speex is really all that necessary outside of web conferencing. With , the choice seems to be harder. Many people seem to want to use the MPEG-LA's own codec specifications in some reduced form. Either way you slice it, you still are pretty likely to have to deal with the MPEG-LA and patents. I do not know of too many different video codecs, since most have seemed to die out or use a profile of the MPEG 4 standard. The only one I am aware of that would fit my own criteria would be Theora. I know some have complained that the theora codec is worse than any of the mpeg4 codecs. Well, Xiph has already admitted to this problem and is working on fixing many of the performance problems and glitches in the codec within the "thusnelda" branch of the theora/vorbis code. Some have complained of lack of support on the platforms for Vorbis/Theora. This is very easily remedied. Xiph provides both DirectShow filters (oggdsf - http://xiph.org/dshow/) and QuickTime components (XiphQT - http://xiph.org/quicktime/) for the entire series of Xiph codecs. Linux distributions include Theora and Vorbis for Xine and GStreamer. There are Java implementations of the codecs available. There are versions of the codecs for even Silverlight 3. Their reference implementations are extremely portable and build on all three major platforms. Licensing is no problem for any of the Xiph codecs. All the implementations are BSD licensed, and the specifications are in the public domain. If somebody wants to make an extremely optimized, high quality version of the theora/vorbis codecs, they can do so. They could even make the implementation closed source and sell it. Though, personally, I would not like to see that. If there are any other options, I would like to hear of them. As far as I can tell, only the Xiph series of codecs fit the criteria I set above. If you feel my criteria is too restrictive or too lax, I want to know what should be changed. I want to know what all of you who care to read this think of it. Sincerely, Neal Gompa (King InuYasha) Quality Assurance, Platform Integration Enano CMS Project
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sat, Jun 6, 2009 at 3:47 PM, Daniel Berlin wrote: > On Sat, Jun 6, 2009 at 4:35 PM, Håkon Wium Lie wrote: > > Also sprach Daniel Berlin: > > > > > >>> "For example, if a patent license would not permit royalty-free > > > >>> redistribution of the Library by all those who receive copies > directly > > > >>> or indirectly through you, then the only way you could satisfy > both it > > > >>> and this License would be to refrain entirely from distribution of > the > > > >>> Library." > > > > > Note that the actual *clause* (not the example) in question says > > > "If you cannot distribute so as to satisfy simultaneously your > > > obligations under this License and any other pertinent obligations, > > > then as a consequence you may not distribute the Library at all. " > > > It then gives the patent example as an example of when you could not > > > fulfill your obligations under the license. The restrictive license > > > in the example falls afoul of this condition (part of #10): "You may > > > not impose any further restrictions on the recipients' exercise of the > > > rights granted herein." Nothing in any licenses we have with other > > > parties imposes any *further restrictions* on the recipients who get > > > ffmpeg from us. You get *exactly* the same set of rights and > > > obligations we got from ffmpeg. > > > As such, we can simultaneously satisfy our obligations under this > > > license (which again does not require us to pass along patent rights > > > we may have obtained elsewhere, it only requires we grant you the > > > rights you find in terms 0-16 and place no further restrictions on > > > you) and any patent licenses we may have, and do not run afoul of this > > > clause. > > > > I get parsing errors in my brain when reading this. While I understand > > that you do not impose any new restrictions (as per #10), I still > > don't understand how you can claim that #11 (the first two quotes > > above) has no relevance in your case. To me, it seems that the example > > in #11 (the first quote) matches this case exactly -- assuming that > > Google has a patent license that does not permit royalty-free > > redistribution. > As i've said in other messages, this example doesn't match this case > at all, since the patent license was not given to us by the same > people who gave us the library, *and* our patent license doesn't even > say anything about the library used to do encoding/decoding. I.E. Our > patent license has 0 to say about our distribution of ffmpeg, only > something to say about our distribution of Chrome, which is only > covered by section 6 of the LGPL 2.1 (which allows distribution under > whatever terms we choose so long as we meet certain requirements, > which we do). > > > I also understand that the LGPL doesn't explicitly "require [anyone] > > to pass along patent rights we may have obtained elsewhere". However, > > it seems quite clear that the intention of #11 is to say that you > > cannot redistribute the code unless you do exactly that. > > What am I missing? > > > That our patent license does not restrict/grant/say anything about > ffmpeg, only Google Chrome, and Google Chrome itself doesn't fall > under the LGPL 2.1 except through section 6. > > --Dan > So are you saying you DO have a patent license for ffmpeg and Chrome? Or don't you?
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sat, Jun 6, 2009 at 4:20 PM, Daniel Berlin wrote: > On Sat, Jun 6, 2009 at 5:00 PM, King InuYasha wrote: > > On Sat, Jun 6, 2009 at 3:47 PM, Daniel Berlin wrote: > >> > >> On Sat, Jun 6, 2009 at 4:35 PM, Håkon Wium Lie > wrote: > >> > Also sprach Daniel Berlin: > >> > > >> > > >>> "For example, if a patent license would not permit royalty-free > >> > > >>> redistribution of the Library by all those who receive copies > >> > directly > >> > > >>> or indirectly through you, then the only way you could satisfy > >> > both it > >> > > >>> and this License would be to refrain entirely from distribution > >> > of the > >> > > >>> Library." > >> > > >> > > Note that the actual *clause* (not the example) in question says > >> > > "If you cannot distribute so as to satisfy simultaneously your > >> > > obligations under this License and any other pertinent obligations, > >> > > then as a consequence you may not distribute the Library at all. " > >> > > It then gives the patent example as an example of when you could > not > >> > > fulfill your obligations under the license. The restrictive > license > >> > > in the example falls afoul of this condition (part of #10): "You > may > >> > > not impose any further restrictions on the recipients' exercise of > >> > the > >> > > rights granted herein." Nothing in any licenses we have with other > >> > > parties imposes any *further restrictions* on the recipients who > get > >> > > ffmpeg from us. You get *exactly* the same set of rights and > >> > > obligations we got from ffmpeg. > >> > > As such, we can simultaneously satisfy our obligations under this > >> > > license (which again does not require us to pass along patent > rights > >> > > we may have obtained elsewhere, it only requires we grant you the > >> > > rights you find in terms 0-16 and place no further restrictions on > >> > > you) and any patent licenses we may have, and do not run afoul of > >> > this > >> > > clause. > >> > > >> > I get parsing errors in my brain when reading this. While I understand > >> > that you do not impose any new restrictions (as per #10), I still > >> > don't understand how you can claim that #11 (the first two quotes > >> > above) has no relevance in your case. To me, it seems that the example > >> > in #11 (the first quote) matches this case exactly -- assuming that > >> > Google has a patent license that does not permit royalty-free > >> > redistribution. > >> As i've said in other messages, this example doesn't match this case > >> at all, since the patent license was not given to us by the same > >> people who gave us the library, *and* our patent license doesn't even > >> say anything about the library used to do encoding/decoding. I.E. Our > >> patent license has 0 to say about our distribution of ffmpeg, only > >> something to say about our distribution of Chrome, which is only > >> covered by section 6 of the LGPL 2.1 (which allows distribution under > >> whatever terms we choose so long as we meet certain requirements, > >> which we do). > >> > >> > I also understand that the LGPL doesn't explicitly "require [anyone] > >> > to pass along patent rights we may have obtained elsewhere". However, > >> > it seems quite clear that the intention of #11 is to say that you > >> > cannot redistribute the code unless you do exactly that. > >> > What am I missing? > >> > > >> That our patent license does not restrict/grant/say anything about > >> ffmpeg, only Google Chrome, and Google Chrome itself doesn't fall > >> under the LGPL 2.1 except through section 6. > >> > >> --Dan > > > > > > So are you saying you DO have a patent license for ffmpeg and Chrome? Or > > don't you? > Why are you conflating both of them together? > Our patent license covers user use of Chrome so they can play > H.264/AVC/etc. > It says nothing about ffmpeg. Zilch. Zero. > If you were to replace ffmpeg in Chrome with another decoder, our > patent license should still cover your use (I would have to double > check this, but this is my recollection). > > --Dan > Mainly because ffmpeg has way more than H.264 and other MPEG4 profile codecs. FFmpeg has a lot more than MPEG4 and MPEG2 and having licenses just for those might not be enough. You would be better off integrating xvid and x264 rather than ffmpeg. Of course, I am not a lawyer, so take my advice with a grain of salt.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sat, Jun 6, 2009 at 5:03 PM, Peter Kasting wrote: > On Sat, Jun 6, 2009 at 2:34 PM, King InuYasha wrote: > >> Mainly because ffmpeg has way more than H.264 and other MPEG4 profile >> codecs. FFmpeg has a lot more than MPEG4 and MPEG2 and having licenses just >> for those might not be enough. >> > > Why are you assuming that the FFMPEG binaries with Google Chrome are > compiled with support for all possible codecs that the FFMPEG sources can be > compiled to support? > > PK > Because until about 10 minutes ago, I was unaware that FFmpeg could be compiled to strip out codecs that you don't want.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sat, Jun 6, 2009 at 8:18 PM, Chris DiBona wrote: > At this point I feel like we're giving open source advice to teams > outside of Google, which is beyond our mission. We're comfortable with > our compliance mission and feel it is accurate and correct. Other > companies and people need to make their own decisions about > compliance. > > Chris > > On Sun, Jun 7, 2009 at 10:03 AM, Daniel Berlin wrote: > > On Sat, Jun 6, 2009 at 8:50 PM, Daniel Berlin wrote: > >> On Sat, Jun 6, 2009 at 7:52 PM, Håkon Wium Lie > wrote: > >> > >>> This if statement seems to be true, and I therefore still don't > >>> understand your reasoning. > >> > >> I've explained my position and reasoning, and we are going to have to > >> agree to disagree, because it's clear neither of us are going to > >> accept the other's viewpoint. > >> > >> My understanding of the example is consistent with the LGPL's goal > >> statement at the start: "Therefore, we insist that any patent license > >> obtained for a version of the library must be consistent with the full > >> freedom of use specified in this license." > >> The goal statement, at least to me, makes clear the example is talking > >> about obtaining a patent license that covers the library directly, not > >> that covers something that uses the library. > > > > Missed a sentence somehow. > > > > My understanding of the example is also consistent with the actual > > legal clause in front of the example, and I use it to inform my > > position on the example. Taking a example from a paragraph out of the > > surrounding context and trying to claim it stands alone seems a bit > > strange to me, but i'm just a simple engilawyer. > > > > > > -- > Open Source Programs Manager, Google Inc. > Google's Open Source program can be found at http://code.google.com > Personal Weblog: http://dibona.com > To me, it seems more like Google doesn't really want to take a position in the matter regarding codecs and is taking the "weird" way out by using ffmpeg. Given Google's dominance in search, which tends to bring people to at least look at Google's products, anything Google does is examined with a fine toothpick and commented about pretty much everywhere. So yes, anything Google does will be taken as an example for others, regardless of the sane way to do it. Even if Google's method is sane to them and not to others, people will take it as otherwise. That's fine if Google doesn't want to take a position, but this squabbling does not help anything at all And the tag will be rendered useless if no default codec is specified. Same for . Whatever... People, Google's choice to use FFmpeg doesn't have anything to do HTML 5 other than it shows Google's neutrality. If they take a position later, they should show it in their browser too, but I have a feeling they won't.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sat, Jun 6, 2009 at 9:16 PM, Chris DiBona wrote: > [snip] > > I think we've taken a very clear position on compliance but... > > [snip] > > This is really a matter for the spec to handle one way or another, not > Google. > > Chris > Compliance does not mean taking a position. It just means you follow the spec as it is currently written. As it is currently written, the default/recommended codec is not specified, so Google can do whatever. The spec is currently not finalized, even though there have been few changes the to and parts of the HTML 5 recently. All people participating in this mailing list are basically working to get that done. Google, having a business primarily in the web, through search, advertisements, etc. has a vested interest in HTML 5. If most of the people interested in the and parts of the spec settle on Theora/Vorbis as the codec pair that must be provided in any browser supporting those tags, then hopefully that part can be finished. This includes Google, by proxy of you, Chris, since you're not really saying that your posts do not reflect on Google, it could be assumed that. I gave my opinion ( http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020190.html ) supporting Theora and Vorbis as the opinion from the Enano CMS Project, which I am affiliated with. I suppose the same would be true for Håkon Wium Lie, since his posts don't say that either. But he is the CTO of Opera, he can say whatever I guess...
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 2:08 AM, David Gerard wrote: > 2009/6/7 Daniel Berlin : > > On Sat, Jun 6, 2009 at 7:52 PM, Håkon Wium Lie wrote: > > >> I do appreciate your willingness not discuss these matters, though. > > > Thanks. > > As I said, it's clear we won't convince everyone, > > > I question the relevance to HTML5 of someone from a completely > proprietary software company closely questioning a direct competitor > on their conformance to the GPL. > > > - d. > Despite being proprietary, Opera Software ASA is the only one that produces an engine that is totally standards compliant. Gecko and WebKit cannot say the same thing, even though they are open source. Also, Opera has a much higher turnaround for implementing new standards into Presto than either of the two others.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 1:55 AM, Kristof Zelechovski wrote: > The VIDEO element will not be useless without a common decoder. Its > usefulness depends on its content: it will be limited to user agents that > support at least one encoding offered by the author. Even if a common > decoder is specified, many authors will not use it because they do not know > it, they do not have the tools, they are reluctant to learn or they consider > the proprietary solution better for production and valid for their target > audience. > > IMHO, > > Chris > Ahh, but the thing is, there ARE tools to make Ogg videos. And more would spring up if Theora was chosen as the common codec. Already quite a few proprietary and open source multimedia manipulation programs support the Ogg container and Ogg Vorbis codec out of the box. A good example being Nero Burning ROM. The thing is, the "audience" won't know the difference. To them, its just a faster player playing videos without crashing their browser or causing it to slow down at odd times. The content makers are not going to have a problem making Theora videos. Besides, most content making software use either DirectShow codecs or ffmpeg on Windows. On Mac, generally they use QuickTime codecs. And on Linux, usually GStreamer or ffmpeg is used. Since Theora/Vorbis codecs for all of those platforms are available, existing software would be able to output Ogg videos. And where the heck would "reluctant to learn" come from? This isn't a programming language, it is a codec! All they have to do is change the selection of codecs on the output of their video. As for "not knowing it," there is already some publicity on Ogg Theora videos from the Mozilla team. And Dailymotion has converted a portion of their library for the purpose of experimenting with it. Wikipedia/Wikimedia uses it already. The Internet Archive also uses it. There is no doubt that people already know it.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 10:23 AM, David Gerard wrote: > 2009/6/7 King InuYasha : > > > And where the heck would "reluctant to learn" come from? This isn't a > > programming language, it is a codec! All they have to do is change the > > selection of codecs on the output of their video. > > As for "not knowing it," there is already some publicity on Ogg Theora > > videos from the Mozilla team. And Dailymotion has converted a portion of > > their library for the purpose of experimenting with it. > Wikipedia/Wikimedia > > uses it already. The Internet Archive also uses it. There is no doubt > that > > people already know it. > > > Wikimedia is blatantly encouraging the use of Firefogg: > > http://firefogg.org/ > > It's an encoding extension for Firefox. Ideal for processing videos > pre-upload. > > (No, I don't know why Wikimedia doesn't have its own on-site > re-encoder for videos uploaded in encumbered formats. Presumably > considered to have some vague legal risk before the Supreme Court uses > in re Bilski to drive the software patents into the ocean, cross > fingers.) > > > - d. > That is a very nice tool to promote. It makes it very easy to upload as Ogg video. The only thing is that sites have to be modified to accept from Firefogg. Nevertheless, it is a rather ingenious tool.
Re: [whatwg] Codec mess with and tags
On Sun, Jun 7, 2009 at 10:30 AM, David Gerard wrote: > 2009/6/7 : > > > There are concerns or issues with all of these: > > a) a number of large companies are concerned about the possible > > unintended entanglements of the open-source codecs; a 'deep pockets' > > company deploying them may be subject to risk here. Google and other > companies have announced plans to ship Ogg Vorbis and Theora or are shipping > Ogg Vorbis and Theora, so this may not be considered a problem in the > future. > > > Indeed. There are no *credible* claims of submarine patent problems > with the Ogg codecs that would not apply precisely as much to *any > other codec whatsoever*. > > In fact, there are less, because the Ogg codecs have in fact been > thoroughly researched. > > This claimed objection to Ogg is purest odious FUD, and should be > described as such at every mention of it. It is not credible, it is a > blatant and knowing lie. > > > - d. > Xiph made sure their codecs don't infringe on active patents before recommending it. And on top of it, Theora, which is descended from On2's VP3, has patents from VP3, but On2 made those patents available royalty free for any purpose, so there is NO concern there at all. Dirac is available from the BBC and is also patent-free. Vorbis is patent free as well. FLAC, Speex, the whole lot of them are extremely safe to use, legally. And certainly the Ogg container doesn't have patents against it...
Re: [whatwg] Codec mess with and tags
On Sun, Jun 7, 2009 at 9:06 PM, Peter Kasting wrote: > On Sun, Jun 7, 2009 at 5:10 PM, Nils Dagsson Moskopp < > nils-dagsson-mosk...@dieweltistgarnichtso.net> wrote: > >> > I do note that in a vacuum, there isn't a problem with not specifying >> > any codec, as IIRC no codecs are specified for the tag and yet >> > practically most browsers implement a common subset and the web >> > basically works. >> >> still, there was the issue with gif patents. just to remind you. >> > > Yes, but I'm not sure how that relates at all to the statement I made that > specifying no codecs for does not prevent there from being a number of > broadly-supported codecs. > > (But to reassure you, the days of ribbon campaigns and hostility to Unisys > are indeed something I was around for.) > > PK > Didn't all major browsers back then support the BMP format? I seem to remember that most pages back then either used BMP or GIF. But you are right about that. However, it took an inordinately long time before a patent-free image format began to dominate the web space. Mainly because we didn't have PNG for a very long time. With HTML5 and the tag, we can avoid that by specifying a codec that is patent-free and all that jazz. Really what we need is someone that is really good at the art of persuasion, and setting them on Google, Apple, and the other naysayers for Ogg video to convince them that Ogg Theora and Vorbis is the best choice for the common codec to standardize on.
Re: [whatwg] Codec mess with and tags
On Sun, Jun 7, 2009 at 10:24 PM, Peter Kasting wrote: > On Sun, Jun 7, 2009 at 8:13 PM, King InuYasha wrote: > >> Google, Apple, and the other naysayers for Ogg video >> > > I think you are officially Wasting Our Time when you say something like > "Google... and the other naysayers" about a company that is _shipping Ogg > audio and video support in a product today_. > > PK > > P.S. I don't know what your point about BMP was. In the spirit of sharing > information utterly irrelevant to the thread, I wrote Chromium's BMP > decoder. How does that help you? I don't know, just like I don't know how > this whole email series helps anyone. Sigh. > Actually, the Google part was an accident. I forgot to change it out and write a different company name, which I now forgot... Sorry Google people! -.-;
Re: [whatwg] H.264-in- vs plugin APIs
On Sat, Jun 13, 2009 at 10:58 AM, Maik Merten wrote: > Mike Shaver wrote: > > Yep, I'll reach out to the o3d guys directly as well, see if they have > > the source video for that clip. More than happy to do the > > measurements on this side, I know what a pain travel can be... > > I'll happily provide encoding-assistance if wanted :-) > > Maik > I would be willing to as well, if wanted :)
Re: [whatwg] H.264-in- vs plugin APIs
On Sun, Jun 14, 2009 at 12:27 PM, Simon Spiegel wrote: > > On 14.06.2009, at 04:02, Silvia Pfeiffer wrote: > >> >> >> As for Safari and any other software on the Mac that is using the >> QuickTime framework, there is XiphQT to provide support. It's a >> QuickTime component and therefore no different to installing a Flash >> plugin, thus you can also count Safari as a browser that has support >> for Ogg Theora/Vorbis, even if I'm sure people from Apple would not >> like to see it this way. >> > > It's actually quite different, on a technical level and for the user. Flash > is a browser plugin and XiphQT is an additional Quicktime codec. Quicktime > has supported third party codec for years; the whole point of this is that > any app which uses Quicktime can make use of these third party codecs – like > Safari does. A browser plugin like Flash OTOH is useless outside the > browser. So like I said: these are quite different things on several level. > > Simon > > > -- > Simon Spiegel > Steinhaldenstr. 50 > 8002 Zürich > > Telephon: ++41 44 451 5334 > Mobophon: ++41 76 459 60 39 > > > http://www.simifilm.ch > > „Was soll aus mir mal werden, wenn ich mal nicht mehr bin?“ Robert > Gernhardt > > > > It's all well and good that XiphQT can be used to support and tags in Apple's build of WebKit for Safari, which I have tested and see to be truth, but a problem I see is that people won't KNOW where to get the codecs. I remember that QuickTime used to be able to grab codecs and install them from the internet like RealPlayer does now. For future versions of QuickTime, like the rumored QuickTime X, will that be brought back? It makes sense that QuickTime should be able to search and grab the XiphQT codecs if they are needed.
Re: [whatwg] H.264-in- vs plugin APIs
On Mon, Jun 15, 2009 at 12:49 AM, Michael Dale wrote: > I have requested that a few times as well... Some went so far to even make > a mock up page: http://people.xiph.org/~j/apple/preview/ > > It would or course be much more ideal if we could get the component into > quicktime codec lookup system. Is there any criteria or process that has > been made publicly available? Are there any guidelines or special request > mechanisms that we have missed? Eric or anyone at apple reading this list: > if you have _any_ information as to how a codec component gets into the > quicktime codec lookup system; it would be great if you could inform us. > > --Michael Dale > > > > Silvia Pfeiffer wrote: > >> I'm sorry, but there is quite a bit of frustration from the past >> hidden in my paragraph. For the last 4 years we have been trying to >> get XiphQT added to the list of QuickTime components on Apple's >> external components webpage at >> http://www.apple.com/quicktime/resources/components.html . We have >> seen proprietary codecs added one after the other but Xiph codecs >> continuously being ignored even though we requested addition multiple >> times and through different people. I'm sorry to say but that has >> indeed caused a feeling of being rejected on purpose. We would love to >> see this situation rectified. >> >> Regards, >> Silvia. >> >> On Mon, Jun 15, 2009 at 2:48 AM, Eric Carlson >> wrote: >> >> >>> Silvia - >>> >>> On Jun 13, 2009, at 7:02 PM, Silvia Pfeiffer wrote: >>> >>> >>> As for Safari and any other software on the Mac that is using the QuickTime framework, there is XiphQT to provide support. It's a QuickTime component and therefore no different to installing a Flash plugin, thus you can also count Safari as a browser that has support for Ogg Theora/Vorbis, even if I'm sure people from Apple would not like to see it this way. >>> Speaking of misinformation and hyperbole, what makes you say "people >>> from >>> Apple" want to hide the fact that Safari supports third party QuickTime >>> codecs? We *could* have limited WebKit to only support QuickTime's >>> built-in >>> formats, but did not specifically so customers can add other formats as >>> they >>> choose. >>> >>> We have never tried to hide this, it is ridiculous to imply otherwise. >>> >>> eric >>> >>> >>> >> > I don't even think QuickTime has a codec lookup system. For codecs that are unavailable, it just points me to the page, even if the codec doesn't exist on that page. I remember that either QuickTime 4 or 5 had a codec lookup and download system... Not sure about QuickTime 6. Definitely not QuickTime 7. Maybe QuickTime X will have one again?
Re: [whatwg] Codecs for and
On Wed, Jul 1, 2009 at 2:12 AM, Maciej Stachowiak wrote: > > I'm not sure I have much useful information to add to this discussion, but > I wanted to address a few points: > > On Jun 30, 2009, at 10:54 PM, Gregory Maxwell wrote: > > >> Then please don't characterize it as "it won't work" when the >> situation is "it would work, but would probably have unacceptable >> battery life on the hardware we are shipping". >> > > I don't believe I ever said "it won't work" or made any claim along those > lines. All I said was that some products use dedicated hardware for H.264, > and no such hardware is available for Theora. There was an implication that > this claim was a smokescreen because really it was all just programmable > hardware; that is not the case. > There wasn't much for h.264 when it was being standardized. There was committment, yes, but little actual hardware until after H.264 was standardized and the big names of the time requested the chips: Creative, Samsung, etc. > > > The battery life question is a serious and important one, but its >> categorically different one than "can it work at all". (In particular >> because many people wouldn't consider the battery life implications of >> a rarely used fallback format to be especially relevant to their own >> development). >> > > If Theora is only going to be a rarely used fallback format, then it > doesn't seem like a great candidate to mandate in external specs. Indeed, > others have argued that inclusion in the HTML5 spec would drive far greater > popularity. If it's going to be widely used, it needs power-efficient > implementations on mobile. > > Battery life is a very important consideration to mobile devices. To give > an example of a concrete data point, the iPhone 3G S can deliver 10 hours of > video playback on a full charge. It's not very persuasive to say that > availability of hardware implementations is unimportant because, even though > battery life will be considerably worse, video will still more or less > function. > I believe he means in the context of the current situation that Theora is rarely used fallback format. I expect that it would change, given time and a clear push for Theora. That's why I believe the HTML 5 and codec situation is so important. If Theora and Vorbis are standardized here, and all the major browsers (except Internet Explorer, of course) were to support it, then users who want to have those videos on the personal portable media players would ask the companies to add support for them. Things would probably snowball from there. > > > On Jun 30, 2009, at 11:03 PM, Silvia Pfeiffer wrote: > > It's a chicken and egg problem then. Once there is volume in Theora >> (speak: uptake), the vendors will adapt their hardware to support it. >> But we will not adopt Theora because we require hardware support. I >> think requiring hardware support is therefore an unfair requirement - >> when H.264 was being standardised, no hardware support (i.e. ASICs) >> were available either. >> > > I believe the wide availability of H.264 hardware is in part because H.264 > was developed through an open standards process that included the relevant > stakeholders. In addition, H.264 was included in standards such as Blu-Ray, > HD-DVD and 3GPP. This created built-in demand for hardware implementations. > I believe hardware implementations were available before H.264 saw > significant deployment for Web content. > > It's not clear if a similar virtuous cycle would repeat for other codecs. > Might happen, but it took a lot of industry coordination around H.264 to > build the ecosystem around it that exists today. So I don't think it's > reasonable to assume that hardware implementations will just appear. > > > Regards, > Maciej > > I would like to point out that we do have one of the most influential hardware manufacturers participating in this: Apple. If they asked for Theora hardware decoders, they would get them. Which annoys me so much.. They would have quite a lot to gain from supporting Theora, and they refuse to. If they added Theora and Vorbis to the default set of QuickTime codecs, then everybody would be happy, since Safari uses QuickTime. As for the hardware thing, Apple's iPod is the most popular portable media player. So, any hardware decoder chip manufacturer would be salivating to get a contract with Apple, and if Apple requested a chip for Theora decoding, then companies would get it done pronto in hopes of winning a contract bid with Apple. Then other companies needing hardware decoders for Theora could get them too. As it is, Apple is stonewalling efforts to convince them to support Theora and Vorbis. Additionally, the Theora spec was only finalized last November, you can't expect all the companies around the world to announce hardware Theora decoders the next day or something? They need a business case and an opportunity. The opportunity is here. The business case would be the simple fact people want to be a
Re: [whatwg] Codecs for and
On Wed, Jul 1, 2009 at 4:41 AM, Anne van Kesteren wrote: > On Tue, 30 Jun 2009 21:39:05 +0200, Peter Kasting > wrote: > >> There is no other reason to put a codec in the spec -- the primary reason >> to spec a behavior (to document vendor consensus) does not apply. "Some >> vendors agreed, and some objected violently" is not "consensus". >> > > The "vendor consensus" line of argument seems like a very dangerous > slippery slope. It would mean that whenever a vendor refuses to implement > something it has to be taken out of the specification. I.e. giving a single > vendor veto power over the documentation of the Web Platform. Not good at > all in my opinion. > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > We had a vendor majority, right? Of the four major vendors of browsers participating (Mozilla, Google, Opera, Apple), three have committed to including the codecs in one form or another for usage with the and tags (Mozilla, Opera, Google). I agree it would have been better would a full consensus, but the fact is that all of these companies look towards their goals. Mozilla wants to move towards its vision of the Open Web (which I personally agree with), Opera has said some time back they plan to support it, Google is fence-sitting by including ffmpeg due to their ideal of being universal (and doing a good job of it too), and Apple's vision of an Apple-centric world means they use the MPEG4 stuff, because it fits more with their current offerings of iPod, iPhone, Macs, and the Apple TV without exerting more effort to comply. We would never get everyone to agree. However, Apple didn't shut the Theora stuff out entirely. They left it open through QuickTime, which is fine. If we went through and put the Theora and Vorbis recommendation through, and the browsers implement it, then pressure would eventually make Apple somehow concede and do something about the situation. At the very least, add the XiphQT codec pack to the listing of codecs when QuickTime errors out and opens Safari to a list of codecs. If we push through it with the codecs, I don't think there will be too much of a problem at all.
Re: [whatwg] Codecs for and
Perhaps Google will finally be able to break this horrible deadlock by doing just that. :) On Mon, Aug 10, 2009 at 6:44 PM, Sam Kuper wrote: > In recent news, Google may be about to open source On2 codecs, perhaps > creating a route out of the HTML 5 video codec deadlock: > http://www.theregister.co.uk/2009/08/06/google_vp6_open_source/ >
