| |||||||||||||
An unfortunate descriptionAn unfortunate descriptionPosted Mar 15, 2012 12:54 UTC (Thu) by gmaxwell (subscriber, #30048)Parent article: Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (ars technica)
This isn't "Idealism vs. pragmatism" its "short term pragmatism" vs "long term pragmatism".
…Unless someone actually thinks it's pragmatic to pay $5m/yr for the foreseeable future (with potentially higher fees in the future) just for a single entity to distribute a _single_ application under terms which are not free software friendly.
And of course, this doesn't end in 2028 (or whenever the patents on AVC expire, which is probably much further out because they'll keep adding patents to the pool as they've done for MPEG2) because by that time rolls around there will be H.266 which much better compression, funded by the billions of dollars of extortion income and offered for lower cost licensing terms than H.264 will have at that time (go look at MPEG2 prices vs AVC— they effectively pay you to move off old formats to formats with further patent expiration dates).
So we'll be in the same boat— where the extortion-enabled formats remain more popular, propped up by superlarge companies operating far above the cap and through promotion by rights holders that pay prorated rates due to cross licensing (like Microsoft and Apple).
Because "the codec argument" is overwhelmingly about compatibility the only way out is for a royalty free codec to achieve critical mass market share by being a (defacto) mandatory to implement codec in popular client software. Once this happens the money faucet will dry up for patent encumbered codecs, and we'll start seeing the billions going to the codec industry stop being used to pay for minefields and either go to collaboration on open codecs (after all, the codec efficiency improvements are worth a lot of money to a lot of people who need to ship around media) or be diverted to other profitable ventures.
Unfortunately, a defacto mandatory to implement standard can only come about through incompatibility— which is a path that is extremely painful in the short term.
(Log in to post comments)
An unfortunate description Posted Mar 15, 2012 14:27 UTC (Thu) by rqosa (subscriber, #24136) [Link] > …Unless someone actually thinks it's pragmatic to pay $5m/yr for the foreseeable future (with potentially higher fees in the future) just for a single entity to distribute a _single_ application under terms which are not free software friendly. What "_single_ application" are you talking about? The Gecko library (or any application using it) won't implement H.264 under this proposal — it will instead use an operating system-provided media decoder/playback framework (e.g. GStreamer) for HTML5 video playback. As far as I'm concerned, they should have been using GStreamer (or something similar) all along, rather than reinventing the wheel. Last time I tried them, both Firefox and Chromium would drop frames when playing full-screen video on my 4.5-years old computer (I'm guessing this is because they don't support XVideo), whereas Konqueror (which depends on external QtWebKit and Gstreamer libs) can play the same video perfectly (as can dedicated video player apps, such as mplayer2 and gxine). IIRC, the only justification they gave for not using system libraries was something to the effect of "if we do that, then people will blame us for security vulnerabilities in libraries for which we can't issue bugfixes" — but if all developers operated under that logic, then we'd be back to using static libraries for everything, causing massive duplication of code (and therefore massive duplication of security vulnerabilities, as has repeatedly happened with zlib).
An unfortunate description Posted Mar 15, 2012 15:51 UTC (Thu) by khim (subscriber, #9252) [Link] You've omitted small yet very important piece. IIRC, the only justification they gave for not using system libraries was something to the effect of "if we do that, then people will blame us for security vulnerabilities in libraries for which we can't issue bugfixes … for the libraries which are chock-full of errors". The sad reality is that videocodes are notorious for errors: typical system includes dozens of them, most are obscure yet vulnerable. Hardware-accelerated codecs are especially problematic: they often assume input stream is not just correct but somehow "nice" (does not produce more then certain amount of data when decompressed, etc). Whitelist is important but then you need to keep it up-to-date, which is not trivial. The same is true for 3D, but there, unfortunately, you have little choice: software rendering is just too slow. if all developers operated under that logic, then we'd be back to using static libraries for everything, causing massive duplication of code (and therefore massive duplication of security vulnerabilities, as has repeatedly happened with zlib). Thankfully zlib exist in just one unencumbered form thus you can just use system version everywhere. Codecs exist are produced by literally dozen of different groups and few of them ever bother to think about corrupted videostream. Yes, in ideal world codecs creators will patch them and browsers will use them but in our world you can as well call videoAPI “botnet API” is you are using “system codecs”.
An unfortunate description Posted Mar 15, 2012 16:29 UTC (Thu) by rqosa (subscriber, #24136) [Link] > Whitelist is important but then you need to keep it up-to-date, which is not trivial. Are you saying that it's more difficult for browser developers to keep a whitelist (of codecs and containers) up to date than to implement video/audio demuxing and decoding on their own? I don't believe that. It seems like all that the Gecko developers would need to do is to make a whitelist containing entries for only VP8, Ogg, and Matroska (possibly allowing for users to edit the whitelist on their own installations, at their own risk), and leave it up to GStreamer to decide which particular implementation of those codecs and containers it will use. That way, all of the many other codecs and containers supported by GStreamer are excluded from the "attack surface" that the browser exposes to untrusted remote servers. And by using a mature system-wide library for media playback (or anything else, basically), you will not only avoid missing out on useful capabilities that have already been implemented in that library (for example, I believe that Gecko still does not support GPU-accelerated video scaling, even though GStreamer has had it for a long time now, and Xine, MPlayer, and VLC have all had it for something like 10 years by now!), but you ultimately end up improving the library for all its other users. When app developers adopt the NIH attitude like Mozilla developers have done (or alternately, when they do use third-party libraries, but fork them and build the forked versions into the app, which is what Chromium/Chrome developers tend to do), it violates the engineering principle of modularity (a.k.a. "do one thing and do it well"), and ultimately causes a tragedy-of-the-commons where all app developers need to go to great effort to implement pieces of functionality that have already been implemented elsewhere (thus negating one of the major potential benefits of FLOSS).
An unfortunate description Posted Mar 15, 2012 16:35 UTC (Thu) by rqosa (subscriber, #24136) [Link] > I believe that Gecko still does not support GPU-accelerated video scaling Well, it turns out that Gecko actually does support that, but only with OpenGL and not XVideo, and OpenGL tends to be disabled by default (and maybe doesn't work well on some older GPUs — at least, when I tried running WebGL apps on Firefox on a 945GM GPU, it was totally unusable).
An unfortunate description Posted Mar 15, 2012 18:04 UTC (Thu) by khim (subscriber, #9252) [Link] It seems like all that the Gecko developers would need to do is to make a whitelist containing entries for only VP8, Ogg, and Matroska (possibly allowing for users to edit the whitelist on their own installations, at their own risk), and leave it up to GStreamer to decide which particular implementation of those codecs and containers it will use. What this whitelist will actually accomplish? VP8, Ogg, and Matroska parsers - they all have bugs. Just today I've tried to watch video and it crashed demuxer. I've used alternative one (“lavf” instead of “mkv”) and was able to see the video. But the very fact that I was able to crash player means that this particular version should not be included in whitelist. That way, all of the many other codecs and containers supported by GStreamer are excluded from the "attack surface" that the browser exposes to untrusted remote servers. This still leaves wast attack surface. Unfortunately. When app developers adopt the NIH attitude like Mozilla developers have done (or alternately, when they do use third-party libraries, but fork them and build the forked versions into the app, which is what Chromium/Chrome developers tend to do), it violates the engineering principle of modularity (a.k.a. "do one thing and do it well"), and ultimately causes a tragedy-of-the-commons where all app developers need to go to great effort to implement pieces of functionality that have already been implemented elsewhere (thus negating one of the major potential benefits of FLOSS). Now we are down to basic handwaving. The fact is: codec developers don't consider it a “big deal” if you can crash their creations using “bad files” - and aforementioned “advanced GPU-based capabilities” are especially notorious. When and if most codec developers will start consider such things really important it'll be safe to use them in browser. I, for one, don't hold my breath.
An unfortunate description Posted Mar 15, 2012 18:59 UTC (Thu) by rqosa (subscriber, #24136) [Link] > What this whitelist will actually accomplish? It would decrease the attack surface to exactly the same "size" as it currently is in Gecko's built-in video playback implementation. > But the very fact that I was able to crash player means that this particular version should not be included in whitelist. No, what that really means is that "this particular version" needs to be fixed upstream. (The more users it has, the faster its bugs will be found and fixed — and if Firefox depends on it, that means it has lots of users.) > This still leaves wast attack surface. Unfortunately. Maybe it is a vast attack surface, but it's exactly the same size as the attack surface that Gecko already has. > The fact is: codec developers don't consider it a “big deal” if you can crash their creations using “bad files” That's irrelevant, because Gecko is using the same codec and container libraries (libvpx, libogg, libmatroska) that the rest of the FLOSS ecosystem uses (modulo some changes that the Mozilla developers have made in their in-tree copies of those libraries, maybe). And it hurts the FLOSS ecosystem if they're putting security fixes into their in-tree library copies instead of upstreaming them.
An unfortunate description Posted Mar 15, 2012 19:17 UTC (Thu) by rqosa (subscriber, #24136) [Link] (And libvorbis too, of course.)
An unfortunate description Posted Mar 15, 2012 19:35 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]
> because Gecko is using the same codec and container libraries
As part of the upstream team for libogg, libtheora, and libvoribs, I can say Mozilla is excellent about taking things upstream (admittedly easier becaue they've hired some of the upstream developers). In fact, for the past two years 100% of the their changes to these libraries have been upstream, at least in the SCM, first as far as I can tell.
But that has heck all to do with what distributions actually ship— and some upstreams have longer pipelines or have outright rejected their changes.
For example, when libvpx was first released Fedora shipped a known vulnerable copy of it— even though I pointed it out and protested— because libvpx upstream had not taken the fixes (being shipped in all the browsers) yet because they hadn't decided which way it should be fixed (because the fixes had potential bitstream implications).
Moreover, vulnerabilities can arise from unexpected interactions (e.g. will a different version of a library returns frames with different alignment?) and may have different bugs/features and Mozilla feels responsible for having maximally uniform featureset across platforms (otherwise you get websites OptimizedForFirefoxOnWindows, partially defeating the open web).
An unfortunate description Posted Mar 15, 2012 20:07 UTC (Thu) by rqosa (subscriber, #24136) [Link] > when libvpx was first released Fedora shipped a known vulnerable copy of it Well, the same principle that applies to external library dependencies also applies to Linux distributions— app developers shouldn't try to work around bugs in the distro, they should instead get those bugs fixed. > Mozilla feels responsible for having maximally uniform featureset across platforms (otherwise you get websites OptimizedForFirefoxOnWindows, partially defeating the open web). Oh really? IIRC, they enable WebGL by default on Windows but disable it by default on Linux.
An unfortunate description Posted Mar 15, 2012 19:52 UTC (Thu) by tterribe (✭ supporter ✭, #66972) [Link]
> That's irrelevant, because Gecko is using the same codec and container
> libraries (libvpx, libogg, libmatroska) that the rest of the FLOSS > ecosystem uses (modulo some changes that the Mozilla developers have made > in their in-tree copies of those libraries, maybe).
I maintain these libraries for Mozilla. I do my damndest to make sure they are not vulnerable, and all of my fixes go upstream. Sometimes before they even land in Firefox (because for a number of them, I _am_ the upstream... though the difference is usually no more than a few hours). Because I know that even though the vast majority of our users (on non-Linux systems) will use our in-tree copies, Linux distributions will still insist on building against the system libraries.
Ideally, of course, everything would be fixed everywhere. But the reality is that for the past two years (at least, I didn't check further), 100% of the issues that have been reported against these libraries have been reported to Mozilla first. Distributions then proceeded to not ship the upstream changes, or to ship new upstream code containing new vulnerabilities without proper testing and vetting. This is inevitable: testing is hard, mistakes will happen, and people who have to maintain tens of thousands of packages have different priorities than a project with a few dozens of dependencies (especially with the effort to upgrade repeated independently by every distribution), even though everyone involved is trying to do the right thing. But if your Firefox has been vulnerable to an attack (especially a known one) via a codec library since we first implemented <video>, chances are it's because your distribution compiles it against the system libraries, instead of ours.
An unfortunate description Posted Mar 15, 2012 20:37 UTC (Thu) by rqosa (subscriber, #24136) [Link] > But if your Firefox has been vulnerable to an attack (especially a known one) via a codec library since we first implemented <video>, chances are it's because your distribution compiles it against the system libraries, instead of ours. Consider what's likely to happen, though, if all apps depending on a given library use the system copy, and compare it to what's likely to happen if all apps depending on the library use their own copy. If they're using the system copy, the bug gets found by the first app to trigger it, and then it gets fixed for all users of the library. If the apps are all using bundled copies, it's likely that the fix won't propagate quickly from the first app to the others — and if it does propagate quickly, then it triggers a thundering herd of package updates (which equates to lots of extra work for distro package maintainers). That's what I meant when I said that the use of in-tree dependencies is a tragedy of the commons: when one app uses in-tree dependencies, it might improve that single app in the short term, but in the long term it hurts the FLOSS ecosystem as a whole. Therefore, I argue that the original article here has got it backwards: for Gecko to begin using an operating system-provided GStreamer for video playback is actually the "idealistic" (or "long-term") option, not the "pragmatic" (or "short-term") one.
An unfortunate description Posted Mar 15, 2012 19:15 UTC (Thu) by rqosa (subscriber, #24136) [Link] > VP8, Ogg, and Matroska s/Ogg/Vorbis/
An unfortunate description Posted Mar 15, 2012 16:16 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]
The single application I'm talking about is the Firefox browser.
MPEG-LA _only_ licenses end user applications, and they require various restrictions in the licenses included with those applications (no commercial use, non-transferrable licensing, etc).
The licensing parties are generally quite careful to not license generic infrastructure which could be used to completely moot the licensing (well, limit it to 1x the annual cap for the whole world) via patent exhaustion.
As far as performance goes, Firefox uses GL and the performance is pretty excellent— but it's probably not whitelisted on your system.
In the context of firefox media— everything is bundled is basically where we stand. E.g. firefox ships its own fork of libpng because upstream wouldn't take their patches.
An unfortunate description Posted Mar 15, 2012 16:42 UTC (Thu) by slashdot (guest, #22014) [Link]
Does that mean that using Microsoft's license doesn't cover users of the H.264 codec in Windows 7?
What if Firefox runs Windows Media Player or Flash player in an hidden window (or equivalent hack) and extracts the frames?
What if Firefox automatically downloads ffdshow but doesn't ship it?
What if Firefox automatically downloads a Windows 7 update for Windows Media Player and/or the Microsoft H.264 codec, extracts the binaries from it and runs it on Windows XP via suitable hacks?
Some legal investigation of these things seems quite essential, especially since 6 million dollars per year for H.264 licensing are a significant portion of Mozilla's 43 million income that Wikipedia reports.
An unfortunate description Posted Mar 15, 2012 17:51 UTC (Thu) by khim (subscriber, #9252) [Link] Some legal investigation of these things seems quite essential, especially since 6 million dollars per year for H.264 licensing are a significant portion of Mozilla's 43 million income that Wikipedia reports. This may be so, but do you really feel it's wise to try to find loopholes in licenses (many of which are not available to general public) for critical browser's functionality? It's obvious that lawyers have tried very hard to make sure answer to questions presented above are all “no”. It is possible that they made a mistake in some custom contracts and something like this is possible today. But do you want to rely on the further availability of such loopholes when you know for sure MPEG-LA will try to close them ASAP? Does that mean that using Microsoft's license doesn't cover users of the H.264 codec in Windows 7? Yes and no. The general stance of MPEG-LA is: we don't care about technical details. You may use binaries from Windows ffdshow or Flash, from Media Player or from x264. We don't care. As in: totally. If your program shows encodes or decodes H.264 then it needs a license - period. But yes, this is just a general stance. MPEG-LA it also offers extended license (for example you can distribute Windows Media Player and use it to show video to the user), but of course these licenses are carefully crafted to make sure other vendors will still need to pay if they will try to create some kind of “advanced” functionality (similar to what <video> tag allows). Oh and these licenses are, obviously, are subject to change (this is important to make sure all loopholes similar to what you are discussing) can be closed quickly. Some things are truly hilarious: for example most professional videocams include “only for non-commercial use” MPEG4 license. Of course MPEG-LA will not try to use that clause to sue Hollywood - but it can use it if someone will try to use these things to circumvent MPEG-LA requirements as you've suggested above.
An unfortunate description Posted Mar 15, 2012 18:28 UTC (Thu) by rqosa (subscriber, #24136) [Link] > If your program shows encodes or decodes H.264 then it needs a license - period. If that's true, that means that every program that uses any sort of external media playback API (including DirectShow, GStreamer, xine, QuickTime, and even the ancient "Media Control Interface" from Win3.x and OS/2) without explicitly whitelisting codecs needs an MPEG-LA patent license. But why stop there? Under that reasoning, any software that uses any API whatsoever must be in violation of some patent — because the implementation of that API might contain a patented algorithm. That would apply equally to both library APIs and kernel system call APIs. So to summarize, your reasoning inevitably leads to the conclusion that all software that runs on any operating system is violating every software patent ever. (Of course, what this really tells us is that what you're saying is actually false. It's just like the situation there was in the 1990s with US export restrictions on cryptographic software — developers worked around the restrictions by making their apps not perform cryptography themselves, but instead use external libraries such as OpenSSL, and these libraries were then hosted on servers outside of the US.)
An unfortunate description Posted Mar 15, 2012 20:35 UTC (Thu) by khim (subscriber, #9252) [Link] If that's true, that means that every program that uses any sort of external media playback API (including DirectShow, GStreamer, xine, QuickTime, and even the ancient "Media Control Interface" from Win3.x and OS/2) without explicitly whitelisting codecs needs an MPEG-LA patent license. No. This is covered by broad OS license. It basically covers “personal and non-commercial use” - this is the same terms you'll find on license for bazillion products. But if you'll try to pull the software from one (properly licensed) player or OS and embed it in another player or OS then of course license is not transferred. It's just like the situation there was in the 1990s with US export restrictions on cryptographic software — developers worked around the restrictions by making their apps not perform cryptography themselves, but instead use external libraries such as OpenSSL, and these libraries were then hosted on servers outside of the US. Yahoo! Now you get it. It just so happens that I worked on crypto packages back then thus I know how the whole thing worked from personal experience, not from some narration of narration. Yes, people used external libraries hosted outside of the US. BUT THESE VERSIONS WERE ILLEGAL TO USE IN US BECAUSE OF RSA PATENT. Another, different version of program with PROPERLY LICENSED library was sold in US. It was huge PITA: it was impossible to use one library both in US and outside. US-licensed library was not exportable because of crypto regulations and NON-US version was illegal in US because of RSA patent. When something worked in US and refused to work outside (on vice versa) it was impossible to run two versions side-by-side! These were the days…
An unfortunate description Posted Mar 15, 2012 21:09 UTC (Thu) by rqosa (subscriber, #24136) [Link] > I know how the whole thing worked from personal experience So does anyone who remembers compiling the OpenSSL-enabled variants of programs (e.g. Lynx) that existed back then. > BUT THESE VERSIONS WERE ILLEGAL TO USE IN US BECAUSE OF RSA PATENT. Well, I was actually talking about the former export restriction laws, not the RSA patent. But the same principle applied either way: the legal encumbrance only applied to the library that contains the algorithm in question, not to programs (or other libraries) that call into that library. In other words, if you distribute the program without bundling the legally-encumbered library it uses, you're free from any legal trouble. That's the situation that Mozilla would be in if they made Gecko depend on GStreamer, and then distributed Gecko in only these three ways: as source code (thus not including GStreamer), as a binary built against OS-provided GStreamer (thus not including GStreamer), and as a binary bundled with a custom build of GStreamer that's had all its codecs and containers stripped out except for the ones Mozilla wants to support (thus not including the patented parts of GStreamer). > Another, different version of program with PROPERLY LICENSED library was sold in US. But there wasn't any legal requirement for the US version of the program (not the library) to be "different" from the non-US version. (If they were different from each other, it was because the cryptography libraries were being linked statically, or because the US and non-US cryptography libraries didn't use the same API/ABI as each other, or both of those reasons.)
An unfortunate description Posted Mar 15, 2012 21:52 UTC (Thu) by khim (subscriber, #9252) [Link] But there wasn't any legal requirement for the US version of the program (not the library) to be "different" from the non-US version. There was: patent license. Actual binary was exactly the same, but accompanying license was different.
An unfortunate description Posted Mar 15, 2012 22:09 UTC (Thu) by rqosa (subscriber, #24136) [Link] > Actual binary was exactly the same Well, that hardly qualifies as a "different version of program", then.
An unfortunate description Posted Mar 15, 2012 22:20 UTC (Thu) by rqosa (subscriber, #24136) [Link] And furthermore: in Mozilla's case, they wouldn't need a different license, because in either case (GStreamer or no GStreamer) they wouldn't be distributing any patent-encumbered codecs. (I believe that the only possible legal reason for the "different license" on the software you're talking about there could have been was that it bundled the cryptography library as a .so / .dll along with the executable, or something like that.)
An unfortunate description Posted Mar 16, 2012 5:48 UTC (Fri) by khim (subscriber, #9252) [Link] I believe that the only possible legal reason for the "different license" on the software you're talking about there could have been was that it bundled the cryptography library as a .so / .dll along with the executable, or something like that. No. The fact that it was sold as PGP-compatible solution was basically enough. If your software is useful without H.264 codecs and can only use them is they are found on the target system then you can probably get away with it. But if you'll start actively encourage people to download H.264 codecs from shady sources to get “the full experience” then you may be accused in evasion of patent (that's why Fedora does not link to unofficial repos with codecs, for example).
An unfortunate description Posted Mar 16, 2012 12:07 UTC (Fri) by ekj (guest, #1524) [Link]
But that's mostly a question of wording. "Download h264 codecs from here to make Firefox play those movies" might get you into trouble.
But: "Firefox will play any movie for which your system has the appropriate codecs installed." will definitely not. (it's just a statement of fact, and it doesn't have anything to do with h264 or any other specific codec, it's a general mechanism.)
Did you actually read the article? Posted Mar 15, 2012 17:02 UTC (Thu) by rqosa (subscriber, #24136) [Link] > The single application I'm talking about is the Firefox browser. If you've read the article, you should have seen that no one is proposing to include a H.264 decoder in Gecko (and consequently Firefox) — therefore, the Mozilla Foundation / Corporation won't need to license patents from MPEG-LA in order to distribute Firefox, because Firefox won't include an H.264 decoder. The proposal discussed in the article is, instead, to use an external library (that is, one that is provided by the operating system), which is not distributed by Mozilla Foundation / Corporation. As I've argued in my other post, doing that has many technical benefits and FLOSS-ecosystem benefits of its own (including, like the article says, the ability to use hardware-accelerated codec implementations). (However, if Mozilla Foundation / Corporation goes through with their plans to develop their own smartphone / tablet operating system, then they would once again need to distribute the codec implementations themselves. Even so, though, that wouldn't force them to include H.264 or any other particular codecs in their OS.) > In the context of firefox media— everything is bundled is basically where we stand. E.g. firefox ships its own fork of libpng because upstream wouldn't take their patches. As I've already said, Mozilla dvelopers (and Chromium developers, and all other FLOSS app developers) need to learn to not do stuff like that, because it's bad for the whole FLOSS ecosystem.
Did you actually read the article? Posted Mar 15, 2012 17:11 UTC (Thu) by gmaxwell (subscriber, #30048) [Link] If you've read the article, you should have seen that no one is proposing to include a H.264 decoder This is what you get for paying too much attention to the article rather than the actual discussion. Certainly people are talking about shipping h264— in fact much of the discussion is is driven by boot to gecko. And as far as I can tell no one has given a compelling argument for relaxing the long term commitment to uniform multiplatform support. There were some people apparently thinking that XP users (a majority of firefox users or nearly so) could be covered via wink-and-nod via ffdshow integration. I fully expect the lawyers to squash that right-quick.
Did you actually read the article? Posted Mar 15, 2012 18:01 UTC (Thu) by rqosa (subscriber, #24136) [Link] > shipping h264 … boot to gecko It's clear that Boot2Gecko must be distributed with codecs included (unless it allows for third-party codecs to be installed, and I suppose it isn't going to allow for any third-party software except for JavaScript code that runs on top of Gecko / SpiderMonkey). But that would not require Gecko itself to include an H.264 implementation — for example, Gecko could be changed to use GStreamer, and then Boot2Gecko could include a bundled copy of GStreamer. (And they could strip out from that bundled GStreamer all codecs and containers other than the ones that Boot2Gecko is meant to support.) > ffdshow integration What's that supposed to mean? ffdshow is a codec plugin for DirectShow, so I don't see how Gecko could use it directly. And I don't see any legal issues with making Gecko able to use DirectShow (because, again, in that situation the codec implementations used by Gecko would not be distributed by Mozilla). (Of course, there are plenty of other reasons why Mozilla developers refuse to use DirectShow — the major ones are: it's for Windows only; most of its codec plugins are closed-source; and very very many of its codec plugins have security vulnerabilities which will never be fixed because they're closed-source, or are no longer maintained, or both.)
Did you actually read the article? Posted Mar 15, 2012 20:52 UTC (Thu) by AndreE (subscriber, #60148) [Link]
If everyone knew where to obtain the codec (or that such things exist), then yeah, who cares? Just use DirectShow or QuickTime or GStreamer. But in a world where HTML5 is a standard and people will expect an HTML5 compliant browser to be able to render in all it's glory an HTML5 compliant website, then ensuring that the codec is available is certainly important. This isn't a set and forget scenario, and this is where the legal riskiness becomes an issue.
Did you actually read the article? Posted Mar 16, 2012 0:21 UTC (Fri) by rqosa (subscriber, #24136) [Link] > then ensuring that the codec is available is certainly important This isn't a problem in cases where the "system decoders" are actually bundled with the Mozilla stack (e.g. on mobile devices with Boot2Gecko preinstalled), and it practice it's not a problem on desktop Linux distributions if the "system decoders" are provided by the distribution (because the distros include all of the relevant codecs, unless you're counting the patent-encumbered ones, and those are a problem regardless of who distributes them).
Did you actually read the article? Posted Mar 15, 2012 20:57 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]
As far as I can tell you're just promoting using gstreamer out of some kind of religious view about the "right" way to structure the software, a view which is insensitive to many of the practical engineering challenges which have been described.
I say this because the only value I've seen you articulate around it i the ability to induce patent infringement and then try to claim harmlessness— but here you say that it doesn't even need to enable infringement.
I say this because in order to use gstreamer to enable html5 video need to have a totally redundant and incompatible network stack, or replace huge chunks of gstreamer to use the firefox network stack and cache layer... and you would have to recreate a HTML HTML/CSS rendering layer (which couldn't work with xvideo regardless because of RGV vs YUV color model), unless you want to copy the frames and blow all possibility of acceleration.
Did you actually read the article? Posted Mar 15, 2012 22:01 UTC (Thu) by rqosa (subscriber, #24136) [Link] > the only value I've seen you articulate around it i the ability to induce patent infringement and then try to claim harmlessness No, I wasn't ever suggesting that "the ability to induce patent infringement" is a good reason to adopt GStreamer. I already said here, here, and here what the real values of adopting GStreamer would be; to summarize:
> you would have to recreate a HTML HTML/CSS rendering layer (which couldn't work with xvideo regardless because of RGV vs YUV color model), unless you want to copy the frames and blow all possibility of acceleration. I don't know how it does it, but I do know that QtWebKit uses GStreamer to play HTML native video, and on my system (which is about 5 years old and has a 945GM GPU) it can play native video (WebM from Youtube, among others) in fullscreen (1400 x 1050) without dropping frames, whereas Chromium drops frames like crazy, and Firefox either drops frames or (worse) else it "stutters" (that is, the playback is continuously "pausing" and "unpausing" itself). Or to put it another way: before QtWebKit supported video playback, HTML native video playback had worse performance than even Adobe Flash in every browser that I tried, whereas QtWebKit now gives better video playback performance than Flash. (I'm not completely sure that QtWebKit with GStreamer is using XVideo rather than OpenGL for scaling. However, I do seem to remember trying out both the OpenGL scaler and the XVideo scaler methods in DOSBox, and the OpenGL one was a lot slower on my hardware.)
Did you actually read the article? Posted Mar 15, 2012 22:29 UTC (Thu) by gmaxwell (subscriber, #30048) [Link] Ah. I see where the disconnect is. You're incorrect about the advantages.It allows for hardware-accelerated codec implementations (something that may be required to achieve good performance and battery life on mobile devices);GStreamer is not especially useful for this, when the video needs to remain in the software video pipeline regardless (for effect and overlays) the hardware acceleration support is purely a function of the decoder library. (E.g. OMAP3 accelerated Theora works just fine without gstreamer) It allows for XVideo-based hardware-accelerated video frame scaling (something necessary for good performance on slightly-older desktop/notebook GPUs, like the Intel 945GM);It does not— The HTML5 rendering model is not compatible with XVideo acceleration. HTML5 video tag is not just a dumb player embedded in a browser— we had that over ten years ago and no one wants to use that. HTML5, like flash, allows (and mandates) the ability to have dynamic/interactive overlays and to basically use the whole library of CSS propertys and effects on the videos. (And if it were compatible, XVideo support is trivial and could easily be used in the browser without importing gstreamer) Generalizing the above reason: GStreamer's code is likely to be more mature and more featureful than the current equivalent in GeckoThis is easy to demonstrate as not true. Though I'll grant you that (5) probably is true on account of this. But now you're just demanding that Firefox subsidize gstreamer development without any benefit to Firefox. I'm doubtful this subsidy would even be that valuable for GStreamer, since the motivations and directions are so different. I'm not sure what QtWebKit does— but if it's rendering via xvideo it's either not HTML5 compliant or its only fast in a limited subset of cases where you can't tell the difference between compliance and not. Firefox support is fast and accelerated without special casing— but only if you're using GL rendering, which may be disabled on your system because your GL support is slow or broken. The exact thinking you suggest with "network-effects of a hugely popular application like Firefox" is part of why dumb video player like usage doesn't get special cased. By only accelerating the full imaging model people are encouraged to fix their software and hardware so developers can freely use the full featureset, it also avoids having more code and testcases to cope with an additional 'fallback fastpath'. With regards to the patent situation, it is not any worse than what Mozilla is currently doing — in either case, Mozilla would not be distributing patent-infringing code;Sure it is. Patent infringement doesn't just end at the boundary of what you distribute. If you distribute a kit, even one missing some key but easily obtained component, so that people can assemble a device which violates some patent you have not escaped legal liability. The law does not generally smile on evasive behavior. It's also worse from the perspective of bringing about a world where non-patented formats are widely offered by being incompatible with them.
Did you actually read the article? Posted Mar 15, 2012 23:56 UTC (Thu) by rqosa (subscriber, #24136) [Link] > the hardware acceleration support is purely a function of the decoder library. (E.g. OMAP3 accelerated Theora works just fine without gstreamer) So, you're saying that libtheora itself supports OMAP3-accelerated decoding, so that any frontend to libtheora gets that feature "for free"? > HTML5 video tag is not just a dumb player embedded in a browser The YouTube HTML5 player does things that the old "embedded dumb players" never could, such as: JavaScript play / pause / seek controls, pop-up menus and "drop-up" menus (like drop-down but upside-down) overlayed on the video, text annotations overlayed on the video, picture-in-picture seek-point previews (when dragging the seek bead) overlayed on the video, etc. And it seems to works just fine in QtWebKit with GStreamer. > This is easy to demonstrate as not true. Well, it depends on what features are important to you. For the features I care about, QtWebKit supports them better. > or its only fast in a limited subset of cases where you can't tell the difference between compliance and not Maybe that's what it's doing — but that's just fine for the user as long as the the common cases that need to be fast are fast. (It's sufficient for everything I currently use HTML5 video for to support the case where there's just scaled-up video playing back with no overlays or with a few fully opaque overlays, and QtWebKit handles this just fine.) > but only if you're using GL rendering, which may be disabled on your system because your GL support is slow or broken. Well, it works fine for compositing in KWin (except that there are a few effect plugins that can't be enabled), and for all Linux-native OpenGL games that I've tried (Torus Trooper, No Gravity, Tux Racer and Extreme Tux Racer), but it didn't work for WebGL apps in Firefox. I don't know why… Anyway, nothing you might say can change the fact that, when running on hardware like mine, QtWebKit is the only browser engine for Linux that gives an acceptable user experience for playing HTML native video. And I can hardly believe that it's a coincidence that the one that gives the best user experience is also the one that uses GStreamer. > Patent infringement doesn't just end at the boundary of what you distribute. I won't believe that unless you cite case law supporting it. For one thing, it would imply that any software that uses the POSIX virtual filesystem API (open(2), stat(2), etc.) infringes Microsoft's VFAT patent, because the Linux kernel (or at least older versions of it, which are still out there) violates the VFAT patent. For another thing, that would mean that all software written for the OpenSSL API (even when in source form) was infringing the RSA patent before it expired. And in general (as I said here), if you take that line of reasoning to its logical conclusion, then any software that's written against any external API must infringe all patents that might potentially be infringed by any possible implementation of that existing API. For example, > It's also worse from the perspective of bringing about a world where non-patented formats are widely offered by being incompatible with them. Well in that case, it's bad that the Mozilla software stack is FLOSS, because people might fork it to add support for the patented codecs. And also, if Mozilla did adopt GStreamer, then they could whitelist a few unencumbered codecs and exclude all the rest — as I said here, they probably should do that anyway for security reasons (that is, to shrink the attack surface).
Did you actually read the article? Posted Mar 22, 2012 17:16 UTC (Thu) by wookey (subscriber, #5501) [Link] > Patent infringement doesn't just end at the boundary of what you distribute.It's called 'contributory infringement': http://www.invention-protection.com/ip/publications/docs/Contributory_Patent_Infringement.html It's designed to stop the case where you copy a device but miss out some vital part that would make it infringing and then get that made overseas or bought from some other supplier. That quite a lot like the case of making your browser with everythig except the codec, which you get from elsewhere. Sucks doesn't it? The whole patent system stinks, but you can't say 'they' don't have the legal angles well lined-up. After all, that is 'their' area of expertise. The MPEG-LA and the whole anti-society effects like this stupid inability to standardise an HTML5 codec simply falls out of the incentives that patents and the legal system provide. If it makes you angry then you are a reasonable person. And yes, I know I haven't provided any case law. I'm not sure that there is any directly-applicable (i.e in the software arena). There may well be, but I'm afraid I have more important work to do than try to search it out right now. My point is there there is potentially-relevant law. gmaxwell isn't just making it up. The law does not work the way a reasonable engineer/person thinks it should in this area.
Did you actually read the article? Posted Mar 15, 2012 22:41 UTC (Thu) by rqosa (subscriber, #24136) [Link] Oh, and one more reason: 6. GStreamer is supposed to support multiple platforms, including Windows and MacOS X; so, adopting GStreamer could reduce the amount of platform-specific special case code in Gecko Also, about the redundant network stack: I believe that the same situation is present in KDE; it has its own HTTP client library in KIO, but (IIUC) Phonon-based media players using the GStreamer Phonon backend will use GStreamer's HTTP client implementation instead of KIO's one when playing an Icecast stream, and similarly Konqueror and other QtWebKit-based browsers for KDE will use GStreamer's HTTP implementation when playing HTML5 video. However, one could say that that redundancy still exists even in the case that Firefox / XULRunner / Gecko isn't using GStreamer, because most desktop/notebook Linux installations now (excluding Android) will have both Firefox and GStreamer present.
An unfortunate description Posted Mar 15, 2012 17:01 UTC (Thu) by rillian (subscriber, #11344) [Link] if all developers operated under that logic, then we'd be back to using static libraries for everything, causing massive duplication of code Firefox is already doing this. Upstream builds don't use: system zlib, system libpng, system libjpeg, system libogg, system libvorbis, system libtheora, nor system libvpx. No system codecs at all, in other words. This is partly due to Firefox being a cross-platform application, so it can't rely on timely OS updates for these libraries on, for example, Windows or MacOS, and also on being a big enough organization to be its own distribution for some of the libraries it needs.
An unfortunate description Posted Mar 15, 2012 17:28 UTC (Thu) by rqosa (subscriber, #24136) [Link] > Firefox is already doing this. I know that it is; I'm saying that it shouldn't do that. > it can't rely on timely OS updates for these libraries on, for example, Windows or MacOS For libraries that are part of the system API on Windows / MacOS, Firefox can rely on updated being timely (e.g. by Windows Update). For other libraries, Firefox must include its own bundled copies of them (and be responsible for keeping them up to date), because they're not available otherwise. And on Linux, the official builds of Firefox need to have some bundled libraries because they can't make too many assumptions about what libraries are present on all of the distributions it's supposed to be runnable on. But, that's no excuse for making it difficult or impossible for the distributions to make builds of Firefox / XULRunner / Gecko that use the system libraries from that distribution. It's even less of an excuse for the Mozilla developers to reinvent the functionality of existing pieces of software (e.g. GStreamer) when they could instead use them (either by bundling them or using the system-provided ones). > and also on being a big enough organization to be its own distribution for some of the libraries it needs Well, then maybe they ought to outright fork some of those libraries, or even (in the case the upstream is moribund) entirely take over development of them, so that other software could then use Mozilla's versions as the upstream. (Remember the earlier article / comments where it was stated that Chromium had a bundled fork of libjingle, even though Google is the upstream for both Chromium and libjingle?)
An unfortunate description Posted Mar 16, 2012 12:39 UTC (Fri) by Company (guest, #57006) [Link]
I found it pretty interesting that nobody - including you - did have a look at Linux distributions. Probably because nobody cares about it anymore and we all have non-free repositories enabled? Or live in this murky zone where we expect others to pay for the right to use our software?
Because with H264, the situation will be the same as with MP3: A free Linux distro cannot support it without breaking the law or paying $5M/year.
An unfortunate description Posted Mar 16, 2012 12:42 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]
> including you
I boggle.
An unfortunate description Posted Mar 17, 2012 19:58 UTC (Sat) by Lennie (subscriber, #49641) [Link]
A few days ago I was reading the Mozilla discussion about H.264 and as part of the discussion it was mentioned Debian also supports H.264.
So I checked and I was surprised to find out that a default install of Debian has software in it's default APT-repositories that support H.264.
I have no idea how or why that works.
|
|||||||||||||