Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
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
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
2009/6/7 Daniel Berlin dan...@google.com: On Sat, Jun 6, 2009 at 7:52 PM, Håkon Wium Liehowc...@opera.com 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.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 2:08 AM, David Gerard dger...@gmail.com wrote: 2009/6/7 Daniel Berlin dan...@google.com: On Sat, Jun 6, 2009 at 7:52 PM, Håkon Wium Liehowc...@opera.com 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 giecr...@stegny.2a.plwrote: 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
2009/6/7 King InuYasha ngomp...@gmail.com: 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.
Re: [whatwg] Codec mess with video and audio tags
2009/6/7 jjcogliati-wha...@yahoo.com: 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.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 10:23 AM, David Gerard dger...@gmail.com wrote: 2009/6/7 King InuYasha ngomp...@gmail.com: 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 video and audio tags
On Sun, Jun 7, 2009 at 10:30 AM, David Gerard dger...@gmail.com wrote: 2009/6/7 jjcogliati-wha...@yahoo.com: 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 video and audio tags
On 7 Jun 2009, at 16:30, David Gerard wrote: 2009/6/7 jjcogliati-wha...@yahoo.com: 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. How is it incredible? Who has looked at the submarine patents? They by definition are unpublished! Yes, certainly, published patents are well researched, but this is not the objection that anyone has made to it. -- Geoffrey Sneddon
Re: [whatwg] Codec mess with video and audio tags
2009/6/7 Geoffrey Sneddon foolist...@googlemail.com: How is it incredible? Who has looked at the submarine patents? They by definition are unpublished! Yes, certainly, published patents are well researched, but this is not the objection that anyone has made to it. It is not credible to claim that any other codec whatsoever does not have the same problems - and paying Thomson or the MPEG-LA does *not* protect one from submarine claims from others, as Microsoft found out to its cost with MP3 - nor is it credible to claim that Ogg formats have more such problems. - d.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Hello, 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? At this point, I am just as confused as Hakom. I am curious if someone has contacted the FSF for the interpretation of the LGPL in this particular case. It would make a lot of people's life easier if they could license patents from MPEG-LA and redistribute ffmpeg. We are on a similar situation with Moonlight where we ended up distributing proprietary codecs for VC1 (also MPEG-LA licensed) instead of the open source ffmpeg. Today our answer for those that want to use ffmpeg (and it is my personal choice as well, since I rather dogfood open source software) is to compile Moonlight from source code and use the ffmpeg code themselves instead of depending on proprietary codecs to be installed. Miguel.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
You guys would probably be less confused if you actually stuck to the terms of the license instead of trying to parse the examples :) In any case, I doubt its worth asking the fsf, since at least in the US, only the ffmpeg folks would have standing to enforce, so its their view that really matters. I'd be interested in knowing what the ffmpeg folks think (for example, if they felt what we were doing was not right, I'm fairly positive we'd just switch to differently licensed libraries). On Jun 7, 2009 2:08 PM, Miguel de Icaza mig...@novell.com wrote: Hello, I also understand that the LGPL doesn't explicitly require [anyone] to pass along patent righ... At this point, I am just as confused as Hakom. I am curious if someone has contacted the FSF for the interpretation of the LGPL in this particular case. It would make a lot of people's life easier if they could license patents from MPEG-LA and redistribute ffmpeg. We are on a similar situation with Moonlight where we ended up distributing proprietary codecs for VC1 (also MPEG-LA licensed) instead of the open source ffmpeg. Today our answer for those that want to use ffmpeg (and it is my personal choice as well, since I rather dogfood open source software) is to compile Moonlight from source code and use the ffmpeg code themselves instead of depending on proprietary codecs to be installed. Miguel.
Re: [whatwg] Codec mess with video and audio tags
On Sun, 7 Jun 2009, David Gerard wrote: 2009/6/7 Geoffrey Sneddon foolist...@googlemail.com: How is it incredible? Who has looked at the submarine patents? They by definition are unpublished! Yes, certainly, published patents are well researched, but this is not the objection that anyone has made to it. It is not credible to claim that any other codec whatsoever does not have the same problems - and paying Thomson or the MPEG-LA does *not* protect one from submarine claims from others, as Microsoft found out to its cost with MP3 - nor is it credible to claim that Ogg formats have more such problems. Every codec has the same problem; the difference is that companies like Apple have already taken on the patent risk with MPEG-LA licensed codecs and are not willing to double their exposure. (Other companies like Google apparently _are_ willing to take this risk.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Codec mess with video and audio tags
On Fri, Jun 5, 2009 at 8:24 PM, King InuYashangomp...@gmail.com wrote: 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.)? Originally Ogg support was required by HTML5, AFAIK. However, Apple has stated that it is not willing to ship Ogg support. Thus the requirement was removed from the spec, on the basis that there was no point in specifying behavior as required that wasn't going to be consistently available anyway. This is usually how HTML5 operates: if some browsers say they aren't willing to implement a feature, the spec is revised. (Not counting IE, since Microsoft doesn't participate in the WHATWG.) This ensures that the spec is an accurate reflection of reality rather than misleading authors into assuming something will be universally supported when the spec author knows it won't. Apple's stated reason for not supporting Ogg was fear of legal liability from unknown patent-holders. Now that Google is shipping Ogg, if it faces no legal challenges despite its deep pockets (2008 revenue: ~$22 billion), we can hope that Apple will be willing to ship Ogg as well. Once all the browser vendors involved in the WHATWG are willing to use Ogg, I'd assume it could be re-added as a requirement. 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. You can't ever be sure that a codec is royalty-free, unless it's so old that all patents would have expired. There might be someone holding a patent that would cover Ogg, which the Ogg developers were unaware of when they made the standard. Such a patent-holder could potentially come out of nowhere to sue a large corporation for a lot of money as soon as they start using the codec.
Re: [whatwg] the cite element
On 6/6/2009 4:10 AM, Kristof Zelechovski wrote: Instead of: liqMan is the only animal that laughs and weeps./qbr / -- citeWilliam Hazlitt/cite/li Consider: liqMan is the only animal that laughs and weeps./qbr / (William Hazlitt)/li Reads equally good, if not better. Bibliographic references are a topic of its own, and it is not going to be solved with the CITE element alone. Bibliography is a form of a database while hTml is mostly about text. The best HTML approximation to a list of bibliographical references is a table, except that tables tend to be unreadable when they are too wide. You could also use A HREF=urn:ISBN:.CITEA brief history of time/CITE/A and let the UA figure out the details. Removing the default style from CITE is too fragile: using the style attribute makes the code messy and using a class will not survive copy-paste. Chris Thank you for your reply. As you say, HTML neither is a ready-made bibliography-publishing system, nor will it become one. The default styling of the cite element should not change. It does make sense, however, to allow the cite element to be used more broadly than just for titles. Arising from the change, one additional use out of many for the cite element would be for whole bibliographic entries. Under the current spec, we would have: Smith, John. citeThe Triumph of HTML 5/cite. 2015. New York: Faraway Press. Yet, since the author is citing the work, and a work comprises more than just its title, that is unsatisfactory. The example below would reflect the author's intent. cite class=bibliography-itemSmith, John. iThe Triumph of HTML 5/i. 2015. New York: Faraway Press. /cite Regards, Andrew Hagen contact2...@awhlink.com
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Also sprach Daniel Berlin: However, let me ask *you* a question. Why do you rely on the example instead of the actual clause from that part of the conditions? You realize the example has roughly no legal effect, right? It does not add or modify the terms and conditions of the license. I'm a spec guy, not a lawyer. When we write specs, we typically insert specific examples that help clarify the more general conditions in the text. Often, an example will describe a common scenario and state, in simple terms, the outcome. To me, it seems that the LGPL is written the same way. The first two sentences of #11 are general conditions. The third sentence contains a specific example to help clarify what the more general conditions say. Current specs typically state that the examples are non-normative, while the general statements are normative. I do not know if the same rules apply to legal licenses -- LGPL itself doesn't say. As to your question: I'm not really relying on anything. I've merely said that I don't understand your interpretation of #11. You guys would probably be less confused if you actually stuck to the terms of the license instead of trying to parse the examples :) The example in #11 seems fairly clear. Do you see any incompatibilities between the example text and the general clauses? Cheers, -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
Re: [whatwg] Codec mess with video and audio tags
--- On Sun, 6/7/09, David Gerard dger...@gmail.com wrote: From: David Gerard dger...@gmail.com Subject: Re: [whatwg] Codec mess with video and audio tags To: whatwg@lists.whatwg.org Date: Sunday, June 7, 2009, 9:30 AM 2009/6/7 jjcogliati-wha...@yahoo.com: 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*. I fully agree that any codec can have the possibility that there may be unknown patents that read on them. In fact, there are less, because the Ogg codecs have in fact been thoroughly researched. I have looked for evidence of that there has been any patent research on the Ogg codecs. I assume that Google, Redhat and others have at least done some research, but I have yet to find any public research information. I probably am just missing the pointers to this, so could you please tell me where I can find results of this research? Thank you. 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.
Re: [whatwg] Codec mess with video and audio tags
On Mon, Jun 8, 2009 at 7:15 AM, Ian Hickson i...@hixie.ch wrote: Every codec has the same problem; the difference is that companies like Apple have already taken on the patent risk with MPEG-LA licensed codecs and are not willing to double their exposure. (Other companies like Google apparently _are_ willing to take this risk.) It's not a doubling of exposure to submarine patents; there is only increased exposure for techniques that are used by Ogg Theora and NOT by H.264 etc, which isn't much AFAIK. Although maybe there are other factors; perhaps the MPEG-LA has a response plan to submarine patents on its codecs that gives comfort to its licensees. Anyway, it's fruitless to speculate on companies' motives. We can never really know. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sat, Jun 6, 2009 at 9:18 PM, Chris DiBonacdib...@gmail.com 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. There may be a real legal problem here, but I don't think it matters much. An LGPL loophole via naming in licenses--whatever. I'm sure there are resources available to license or rewrite whatever you need if that falls through. The incredibly sucky outcome is that Chrome ships patent-encumbered open web features, just like Apple. That is reprehensible. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
[whatwg] Fwd: Codec mess with video and audio tags
2009/6/7 jjcogliati-wha...@yahoo.com: I have looked for evidence of that there has been any patent research on the Ogg codecs. I assume that Google, Redhat and others have at least done some research, but I have yet to find any public research information. I probably am just missing the pointers to this, so could you please tell me where I can find results of this research? I refer you back to this very list: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg08442.html http://theora.org/faq/#24 I'm sure that won't be enough for you. But beyond that, your homework is yours. - d.
Re: [whatwg] Codec mess with video and audio tags
On Fri, Jun 5, 2009 at 5:24 PM, King InuYasha ngomp...@gmail.com wrote: The HTML 5 specification should definitely support a codec that fulfills the following legal criteria: At the end of the day, the spec does not mandate vendor behavior; rather vendor consensus informs the spec. For various reasons that (as roc mentioned) it is usually unhelpful to speculate on, there has been no vendor consensus on codecs. Perhaps that will change in the future as Google ships a browser with Theora and H.264 enabled, or as Xiph improves the quality of Theora, or as websites begin using some codec(s) broadly. Or perhaps it will not. I doubt anyone has a crystal ball. 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 img tag and yet practically most browsers implement a common subset and the web basically works. PK
Re: [whatwg] Codec mess with video and audio tags
Am Sonntag, den 07.06.2009, 16:37 -0700 schrieb Peter Kasting: 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 img 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. -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
The incredibly sucky outcome is that Chrome ships patent-encumbered open web features, just like Apple. That is reprehensible. Reprehensible? Mozilla (and all the rest) supports those same open web features through its plugin architecture. Why don't you make a stand and shut down compatibility with plugins from flash, quicktime and others? How long would Firefox last in the market if it were incompatible with those? Honestly. Chris
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Am Montag, den 08.06.2009, 09:24 +0900 schrieb Chris DiBona: The incredibly sucky outcome is that Chrome ships patent-encumbered open web features, just like Apple. That is reprehensible. Reprehensible? Mozilla (and all the rest) supports those same open web features through its plugin architecture. Why don't you make a stand and shut down compatibility with plugins from flash, quicktime and others? How long would Firefox last in the market if it were incompatible with those? Honestly. Please, stay calm. Flash is also evil[tm] (read: detrimental to accessibility and compatibility) too and I think you know that. Also, the status quo (various proprietary plugins) says nothing about how something should be (accessible, interoperable standards); this is called the is-ought-problem, please read up on it. Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Hello Dan, In any case, I doubt its worth asking the fsf, since at least in the US, only the ffmpeg folks would have standing to enforce, so its their view that really matters. The FSF might be able to provide some guidance on the intentions of the license as this seems to be the bit that is confusing. Is the example provided in the debated question part of the license or not;But most importantly which one of the two interpretations is the valid one.If your interpretation is correct, this opens a lot of doors not only for Chromium but for plenty of other software (both using ffmpeg and not using ffmpeg). I'd be interested in knowing what the ffmpeg folks think (for example, if they felt what we were doing was not right, I'm fairly positive we'd just switch to differently licensed libraries). Right, if this is a problem, the fix is straight forward. We went with a separate (and proprietary) implementation of the codecs for Moonlight because we understood the license differently. Miguel.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
I'm perfectly calm, what people need to realize is that this issue is actually not about submarined patents (more like aircraft carrier patents) or tricky corner cases for the lgpl., but that the internet users prefer more quality in their codecs/megabyte/second. So long as this is true this issue will not be resolvable cleanly and the kind of puritism that Robert mentioned is achievable only upon expiration of said patents or dramatic quality improvements of the free codecs. You can claim Humians as much as you like, the rest of us are trying to ship software here. Chris On Mon, Jun 8, 2009 at 9:29 AM, Nils Dagsson Moskoppnils-dagsson-mosk...@dieweltistgarnichtso.net wrote: Am Montag, den 08.06.2009, 09:24 +0900 schrieb Chris DiBona: The incredibly sucky outcome is that Chrome ships patent-encumbered open web features, just like Apple. That is reprehensible. Reprehensible? Mozilla (and all the rest) supports those same open web features through its plugin architecture. Why don't you make a stand and shut down compatibility with plugins from flash, quicktime and others? How long would Firefox last in the market if it were incompatible with those? Honestly. Please, stay calm. Flash is also evil[tm] (read: detrimental to accessibility and compatibility) too and I think you know that. Also, the status quo (various proprietary plugins) says nothing about how something should be (accessible, interoperable standards); this is called the is-ought-problem, please read up on it. Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Mon, Jun 8, 2009 at 12:24 PM, Chris DiBona cdib...@gmail.com wrote: Reprehensible? Mozilla (and all the rest) supports those same open web features through its plugin architecture. People don't usually think of Flash as part of the open Web (except for certain Adobe evangelists). Why don't you make a stand and shut down compatibility with plugins from flash, quicktime and others? How long would Firefox last in the market if it were incompatible with those? Honestly. Even if supporting plugins was against our principles, which I'm not convinced of, it's currently impossible to drop support for them and remain relevant, so we'd have to compromise, but that wouldn't make plugins right. If patent-encumbered codecs delivered via video become essential for Web browsing then we'll have to make some compromises, but that wouldn't change their reprehensibility. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Am Montag, den 08.06.2009, 09:42 +0900 schrieb Chris DiBona: I'm perfectly calm, what people need to realize is that this issue is actually not about submarined patents (more like aircraft carrier patents) or tricky corner cases for the lgpl., That sounds too qood to be true — so can we throw that argument out then and ask Nokia and Apple why they won't pull a Google and just implement both h264 and Theora natively ? but that the internet users prefer more quality in their codecs/megabyte/second. So long as this is true this issue will not be resolvable cleanly and the kind of puritism that Robert mentioned is achievable only upon expiration of said patents or dramatic quality improvements of the free codecs. Well, Vorbis seems to be performing better than MPEG Layer 3 bitrate-wise, but wasn't really a killer. So I don't really buy that argument. Same about FLAC vs. WAV. You can claim Humians as much as you like, the rest of us are trying to ship software here. I was just tryin' to keep the discussion fair. Rhetoric tricks are something for politicians, not suitable for an engineering discussions I believe we are having here. Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Mon, Jun 8, 2009 at 12:42 PM, Chris DiBona cdib...@gmail.com wrote: I'm perfectly calm, what people need to realize is that this issue is actually not about submarined patents (more like aircraft carrier patents) or tricky corner cases for the lgpl., but that the internet users prefer more quality in their codecs/megabyte/second. So long as this is true this issue will not be resolvable cleanly and the kind of puritism that Robert mentioned is achievable only upon expiration of said patents or dramatic quality improvements of the free codecs. You can claim Humians as much as you like, the rest of us are trying to ship software here. Historically a lot of the Web standards community, even many people at large for-profit companies, have felt it very important that Web standards be usable royalty-free. There were big battles when that situation was threatened in the past. I personally care about it just as much as shipping software. In that context, helping make H.264 an essential part of the open Web is reprehensible. If your only goal is to ship software with the best bitrate/quality tradeoff, OK, but you can't complain when you get flak. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
I'm okay with Flak, and I really do believe in shipping free/unemcumbered software (see our lgpl discussion earlier). That said, I dislike when I'm accused of being reprehensible by another browser vendor. It seems unfairly nasty to me. Thinking out loud: One thing that was mentioned in an earlier post: Vorbis. I am also of the mind that Vorbis is of higher quality/mb/sec and statically than is mp3. The only real problem is that people don't pirate with it, so the demand isn't there, but I think it is a superior codec. For video, I worry that for theora to become 'better' than h264, it will need to infringe on the same patents it is designed to avoid. That said, I feel like I've been threadjacking this list for too long now, and for that I apologize, it seems like we're gong down a codec rathole that may or may not have any relevance for the spec in the end. Chris On Mon, Jun 8, 2009 at 10:10 AM, Robert O'Callahanrob...@ocallahan.org wrote: On Mon, Jun 8, 2009 at 12:42 PM, Chris DiBona cdib...@gmail.com wrote: I'm perfectly calm, what people need to realize is that this issue is actually not about submarined patents (more like aircraft carrier patents) or tricky corner cases for the lgpl., but that the internet users prefer more quality in their codecs/megabyte/second. So long as this is true this issue will not be resolvable cleanly and the kind of puritism that Robert mentioned is achievable only upon expiration of said patents or dramatic quality improvements of the free codecs. You can claim Humians as much as you like, the rest of us are trying to ship software here. Historically a lot of the Web standards community, even many people at large for-profit companies, have felt it very important that Web standards be usable royalty-free. There were big battles when that situation was threatened in the past. I personally care about it just as much as shipping software. In that context, helping make H.264 an essential part of the open Web is reprehensible. If your only goal is to ship software with the best bitrate/quality tradeoff, OK, but you can't complain when you get flak. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6] -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 9:27 PM, Chris DiBonacdib...@gmail.com wrote: I'm okay with Flak, and I really do believe in shipping free/unemcumbered software (see our lgpl discussion earlier). That said, I dislike when I'm accused of being reprehensible by another browser vendor. This line of argument is incorrect in a couple of ways. Firstly, it is an ad hominem argument, stating that my employer makes my statement somehow unacceptable. Secondly, I didn't say anything about /you/. I wrote about the practice of shipping encumbered software and calling it open. It seems unfairly nasty to me. What is unfair or nasty about it? That said, I feel like I've been threadjacking this list for too long now, and for that I apologize, it seems like we're gong down a codec rathole that may or may not have any relevance for the spec in the end. Actually, the spec used to mention Ogg specifically. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 6:41 PM, Robert Sayre say...@gmail.com wrote: I wrote about the practice of shipping encumbered software and calling it open. Where is the language where Google is calling H.264 open? The closest I know of is Google Chrome is made possible by the Chromium open source project and other open source software (from Tools-About Google Chrome), which links to a page containing links to the FFMPEG homepage and license. I don't see that as saying what it sounds like you claim something somewhere is saying? In the end I personally view hostility towards patent-encumbered video formats the same way I view hostility toward non-GPL free software licenses: a stance I understand, but not one I agree with. More importantly for this thread in particular, I'm not sure what the purpose of stating that opposition here is. I thought the purpose of this thread was to resolve questions people had about the use of FFMPEG vis-a-vis its license. This is probably going to be an ineffective forum if your hope is to dissuade Google from shipping H.264 support. PK
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 7:43 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I don't think the particular parallel you've drawn there is the appropriate one. And I think you failed to answer the line in my email that asked what the point of this tangent is. PK
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 10:45 PM, Peter Kasting pkast...@google.com wrote: On Sun, Jun 7, 2009 at 7:43 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I don't think the particular parallel you've drawn there is the appropriate one. And I think you failed to answer the line in my email that asked what the point of this tangent is. PK I split the thread specifically because I agreed with your position that the encumbered codec angst was unrelated the LGPLv2 licensing concerns. I apologize for not saying so directly. Much of my email was presenting a position as to why the concerns related to these formats keep arising within whatwg and why these concerns have practical implications for the standard. Frankly, the legality of Google's software while interest is almost entirely off-topic, though of some interest to implementers. I felt guilty for the two messages I posted on the subject a few days ago. As switch in focus to the codec compatibility issues is a move back on topic, although that horse is already well beaten at this point. Cheers.
Re: [whatwg] Codec mess with video and audio tags
On Sun, Jun 7, 2009 at 9:06 PM, Peter Kasting pkast...@google.com 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 img 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 img 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 video 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 video and audio tags
On Sun, Jun 7, 2009 at 8:13 PM, King InuYasha ngomp...@gmail.com 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.
Re: [whatwg] Codec mess with video and audio tags
On Sun, Jun 7, 2009 at 10:24 PM, Peter Kasting pkast...@google.com wrote: On Sun, Jun 7, 2009 at 8:13 PM, King InuYasha ngomp...@gmail.com 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! -.-;
