Weekly Edition
Return to the Development page
| |||||||||||||
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (ars technica)
Ars technica covers
the discussion (the very
long discussion) in the Mozilla community about relaxing its stand on
patent-encumbered codecs. "Andreas Gal, Mozilla's director of
research, announced on a public mailing list today that he wants to proceed
with a plan that would enable H.264 decoding on Mozilla's Boot2Gecko (B2G)
mobile operating system. The proposed change would allow the video element
in Mozilla's HTML rendering engine to rely on codecs that are supplied by
the underlying operating system or dedicated video hardware."
(Thanks to Paul Wise).
(Log in to post comments)
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 14, 2012 21:54 UTC (Wed) by slashdot (guest, #22014) [Link]
Installing ffdshow will give you an H.264 codec on Windows XP.
Similarly, ffmpeg via gstreamer provides it on Linux, and I guess Mac OS X also supports it (via QuickTime?).
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 14, 2012 22:15 UTC (Wed) by bkero (guest, #51988) [Link]
ffdshow and ffmpeg do this without a license from MPEG LA, and thus they're legally nebulous, if not outright illegal. This isn't something Mozilla would consider acceptable, as this could open them up to lawsuit.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 14, 2012 22:30 UTC (Wed) by slashdot (guest, #22014) [Link]
The user would install ffdshow on its own, obviously.
Also, it's probably likely that there is some freely downloadable Microsoft software that installs the codecs.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 20:58 UTC (Thu) by AndreE (subscriber, #60148) [Link]
Users installing is suboptimal because it removes the guarantee that content is accessible,and just makes the user activity illegal rather than the software providers.
As for the freely available Microsoft download, I presume you are joking right? If MPEG-LA allowed their codecs to be freely redistributable we wouldn't even be having this discussion in the first place.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 23:05 UTC (Thu) by wmf (guest, #33791) [Link]
For example, QuickTime is free and it includes H.264.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 16, 2012 1:38 UTC (Fri) by AndreE (subscriber, #60148) [Link]
Free under what conditions? Can I extract QuickTime codecs and use them with another product? Can I use them in another operating system with some wrapper?
The details of the license agreement you agree to are important
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 23:56 UTC (Thu) by elanthis (guest, #6227) [Link]
First, they don't care in the least if there are free downloads. Every major browser other than Firefox is already free and already includes h.264 playback. The consortium certainly wants money, but that is between them and the distributor of the software, not the users. The big players are just paying large yearly fees rather than per-user fees.
Second, there will still be an argument, because free downloads are not the same thing as Free downloads. Internet Explorer is free, but it's definitely something that many in the Open Web camp have major issues with.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 16, 2012 1:51 UTC (Fri) by AndreE (subscriber, #60148) [Link]
MPEG-LA certainly do care who is paying for their licenses. Those "free" downloads or system codecs are paid by someone and come with strict usage conditions.
Do you seriously think that Firefox can get away with not paying for a bundled codec, and instead provide a direct link to download an unlicensed package?
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 14, 2012 23:10 UTC (Wed) by sytoka (subscriber, #38525) [Link]
No patent in Europe ;-)
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 1:02 UTC (Thu) by cortana (subscriber, #24596) [Link]
http://www.mpegla.com/main/programs/AVC/Pages/PatentList.... lists plenty of patents from countries throughout Europe.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 16:52 UTC (Thu) by JanC_ (guest, #34940) [Link]
The fact that a patent is listed doesn't always mean it's legally enforcable, or does apply at all, it just means that those companies are of the opinion that those patents are valid and apply. That leaves it to the users to decide if they want to take the risk...
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 14, 2012 22:28 UTC (Wed) by slashdot (guest, #22014) [Link]
And another thing: patents expire after 20 years, so in at most around 10 years H.264 will be a fully free codec.
However, it's essential to make sure that any future codecs don't include any patented technology, unless the patents are perpetually licensed at no cost to all open source software.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 14, 2012 22:43 UTC (Wed) by lambda (subscriber, #40735) [Link] According to OSNews, there is at least one patent in the H.264 pool that despite being filed in 2003, managed to get a 4-year extension, and thus won't expire until 2027. So, we have at least 15 years left of H.264 being not free.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 14, 2012 22:52 UTC (Wed) by slashdot (guest, #22014) [Link]
Interesting.
The description for that patent says:
The good news is that I assume that "fields" here refers to the two fields of interlaced video, and Web content in 2023 will hopefully never be interlaced.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 14, 2012 22:58 UTC (Wed) by slashdot (guest, #22014) [Link]
There seem to be other patents with a 2026 expiration that might be essential though.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 10:08 UTC (Thu) by amonnet (subscriber, #54852) [Link]
This looks like an improved algorithm to enhance encoding efficiency. It might not be required to encode; it's surely not needed to decode.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 0:35 UTC (Thu) by drag (subscriber, #31333) [Link]
MPEG-4 AVC has seen many periodic releases with new features. Effectively the H.264 used in streaming video today is not really the same H.264 that was released in 2003. It's a family of codecs with various profiles and constraints. I am sure that MPEG-LA members were able to bundle newer and newer patents in each update. Also I suppose many patents that affected even the earliest versions of H.264 were filed long after the actual release of the standard.
All of that means that H.264 only gets slightly less worse in 2023. Realistically we are looking at 2033-ish for all of H.264's features available today.
This sort of thing is typical of all patent-friendly standard groups. GSM is notorious, for example, for releasing newer variations for the sole purpose of introducing more patent fees.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 15:44 UTC (Thu) by RogerOdle (subscriber, #60791) [Link]
Are any patents, hardware or software, really working? Every time they get challenged these days 90% get declared invalid for violating prior art or for not being patentable in the first place. Why should we think video patents are any different. H.264 was not developed in a vaccumn, it was developed by experienced video engineers practicing the same state or the art as any other.
Patents are supposed to promote the development of technology. Do they? Why wouldn't a H.264 patent holder delay introducing an "improvement" in order to extend the life of the monopoly? In this case, patents hinder progress instead of aiding it.
In case anyone is curious, the concept of video compression/encoding is at least as old as color TV itself. Originally, it was done to reduce broadcast radio bandwidth using analog techniques. That was 50+ years ago. Data compression theory goes way back in time also. Finding a way to combine the two without doing something that it obvious to someone to practices the art is almost impossible. The patent office grants patents only because something looks different so we see patents that represent mere differences in style but no real technical advance.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 21:08 UTC (Thu) by AndreE (subscriber, #60148) [Link]
I imagine that if it were so straight forward to invalidate then it would have been already. There is a lot of financial might behind h264 so it is a rather daunting task.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 21:38 UTC (Thu) by RogerOdle (subscriber, #60791) [Link]
Nothing in law is straight forward. Proving something is law has no real relationship to proving something scientifically. People in the industry who do video work know that the patents are mostly rubbish. But you can not just challenge them and expect the powers that be to get right on it. Someone has to pay for it and that means the one doing the challenging has to put up the money. A large portfolio means there are a lot of separate pieces that would need to be challenged and the fees are for each piece. There is no process in place for a challenge to be paid for by the tax payer. This is unfortunate when you consider that this situation is created by a government agency in the first place. It is because the patent office is not really capable of doing comprehensive research in the first place that allows it to injure the public by issuing bad patents. How could they, they can not be experts in every possible branch of technology. We need a system that lowers the cost for challenging patents.
Could we implement some kind of system like a wiki where interested parties can post evidence of prior art against particular patents? There could be some kind of ranking mechanism to allow qualified experts to weigh in on the particular comments. If some threshold is reached then a reconsideration of the patent in question would be triggered automatically. This would be paid for by taxes if there was good reason to believe that the patent should not have been issued in the first place. Something like this could reduce the cost for fixing the mess we are in.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 16, 2012 6:44 UTC (Fri) by AndreE (subscriber, #60148) [Link]
You say that nothing is so straight forward about the law...yet in the post I replied you imply that these video codecs are just like the apparent 90% of patents that are found invalid. That's a pretty straightforward (and simplistic) assertion, isn't it?
You seem to think that no one has looked at these patents searching for obvious contests to their validity. Plenty of patents get invalidated, but I think you are smoking something strong if you believe that video codecs haven't been closely scrutinised by competitors and by anti-patent proponents.
If you really think from a legal perspective that these patents are rubbish, then I suggest you provide some pretty in-depth analysis as to why, and raise the relevant patents with the USPTO for post-grant review
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 16, 2012 15:19 UTC (Fri) by pboddie (subscriber, #50784) [Link] If you really think from a legal perspective that these patents are rubbish, then I suggest you provide some pretty in-depth analysis as to why, and raise the relevant patents with the USPTO for post-grant review That's yet another unfair aspect of the patent system: the obligation is apparently on those threatened by patents to spend serious amounts of time and money demonstrating the invalidity of those patents, presumably so they can then be threatened with another bundle of them, obtained comparatively cheaply at the local patent bureaucracy. It's all like someone showing up at your house and claiming that you haven't bought or otherwise legally acquired anything found inside. Really, I don't know why we put up with all this. "It's how the system is" sounds like a feeble justification for letting aggressors and cartels shake everybody down one by one.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 21:30 UTC (Thu) by drag (subscriber, #31333) [Link]
> Are any patents, hardware or software, really working?
Yes. Lawyers just have to know how much it would cost to litigate and defeat the patent and set licensing terms accordingly. This is what they do on regular basis and it works. Otherwise they wouldn't bother.
> Patents are supposed to promote the development of technology.
Depends on how much of the BS you buy into.
> Do they?
Nope.
> Why wouldn't a H.264 patent holder delay introducing an "improvement" in order to extend the life of the monopoly?
Maybe. It depends on what they think they could make the most money from. Businesses tend to think in surprisingly short term basis so they probably want the patents to get out into the market place ASAP. Although this isn't always true.
> In case anyone is curious, the concept of video compression/encoding is at least as old as color TV itself.
Yes, but using the federal government court system, backed by the policing power of the state, to carve out business monopolies that benefit you and yours to the expense of freedom and economics of the rest of the population has been around much much longer then compression techniques.
The legal framework modern patents are founded on date back before the American revolution to European folks, especially England. 'Letters of patent' were special legal documents issued by the monarchy (and later style governments) that awarded special privileges and markets for all sorts of different stuff. Monopolies over things like transporting wool, merchant shipping with certain countries or regions, types of production, and all sorts of stuff like that. Patents were used to even legalize piracy (real pirates).
So patents are a bit of a tradition at this point. A tradition people that people are increasingly capable of exploiting.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 21:57 UTC (Thu) by khim (subscriber, #9252) [Link] The legal framework modern patents are founded on date back before the American revolution to European folks, especially England. 'Letters of patent' were special legal documents issued by the monarchy (and later style governments) that awarded special privileges and markets for all sorts of different stuff. Monopolies over things like transporting wool, merchant shipping with certain countries or regions, types of production, and all sorts of stuff like that. Patents were used to even legalize piracy (real pirates). Well, history does not repeat itself, but it does rhyme. The decree which was important for the industrial revolution (and established current patent law) actually abolished most such patents. Perhaps it's time to repeat the experience?
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 21:05 UTC (Thu) by AndreE (subscriber, #60148) [Link]
"Only 10 years"? 10 years ago Firefox hadn't even been released.
Ten years is a long time to wait and in the meantime vendor dependence becomes entrenched and new, "better", and undoubtedly patent encumbered licenses will be created.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 20:34 UTC (Thu) by AndreE (subscriber, #60148) [Link]
Well if we go with system codecs then what's the point of the HTML5 in the first place?
The certainty for developers and users that content is accessible if the standard is implemented disappears
Carpe diem, Google Posted Mar 14, 2012 22:13 UTC (Wed) by boog (subscriber, #30882) [Link]
It really is a shame that Google have not followed through on their promise to drop H.264 from chrome. Chrome, Firefox and Opera together would definitely sway the market. Unfortunately, Google don't even seem to be able to take a decision on this, let alone the right one. Asleep at the wheel (of the driverless car?).
The opportunity is now and will soon be gone forever.
Carpe diem, Google Posted Mar 14, 2012 22:36 UTC (Wed) by landley (guest, #6789) [Link]
Google isn't the company it was even 3 years ago:
http://blogs.msdn.com/b/jw_on_tech/archive/2012/03/13/why...
Those who fight Facebook become Facebook. (The rest treat it like "AOL: The Next Generation" and are content to wait it out.)
Carpe diem, Google Posted Mar 14, 2012 23:12 UTC (Wed) by shmerl (guest, #65921) [Link]
Dropping it from Chrome wouldn't have helped anyway. If they could drop it from Youtube point blank, it could send a serious kick to Apple and Microsoft, who so far refused to implement WebM in various flavors of Safari and IE. That kind of move really could deal a blow to H.264. But Google got no guts to do it now.
Carpe diem, Google Posted Mar 15, 2012 0:23 UTC (Thu) by drag (subscriber, #31333) [Link]
Well so far I have not really ran into a youtube video that I couldn't actually download in Webm format. I suppose there is older stuff or premium content I won't be able to do that, but so far I haven't ran into it.
While Google is far from perfect and there is no reason to trust them beyond how far you can throw a data center, it's hard to fault them. After all they not only created and open sourced a format that is competitive with H.264 for the web they provided a very nice browser platform that brought it to 17+% of the world market. Along with Mozilla's effort that means that if you are encoding a webm video for the web you know that the majority of people can actually view it, which in my eyes is a huge win.
Carpe diem, Google Posted Mar 15, 2012 5:43 UTC (Thu) by shmerl (guest, #65921) [Link]
What I meant is not just provide all the content in WebM on Youtube, but to remove all H.264 content from there. Only this kind of drastic move could tip the balance.
Carpe diem, Google Posted Mar 15, 2012 6:26 UTC (Thu) by drago01 (subscriber, #50715) [Link]
You don't make money through advertising by limiting your userbase. Google is just driven by business decisions.
Carpe diem, Google Posted Mar 15, 2012 16:59 UTC (Thu) by ewan (subscriber, #5533) [Link]
It's a game of chicken. If Google were to announce that WebM would be required for YouTube in (say) three months time, would MS and Apple blink first and add support to their software? If they did, then everyone would still be able to access YouTube.
Carpe diem, Google Posted Mar 15, 2012 20:53 UTC (Thu) by shmerl (guest, #65921) [Link]
Yes, and so far Google didn't have courage for it.
Carpe diem, Google Posted Mar 15, 2012 6:24 UTC (Thu) by drago01 (subscriber, #50715) [Link]
They did not drop it for the same reason Mozilla wants to add it now. It would render there browser less functional then the competition. And user do not care about why they can't see specific content. So in order to not loose and keep gaining markedshare they had to keep it.
Carpe diem, Google Posted Mar 15, 2012 23:09 UTC (Thu) by wmf (guest, #33791) [Link]
> Chrome, Firefox and Opera together would definitely sway the market.
Actually no. The market would then keep using H.264 with Flash.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 14, 2012 23:16 UTC (Wed) by etiennez (guest, #53056) [Link]
"We will support decoding any video/audio format that is supported by existing decoders present on the system, including H.264 and MP3. There is really no justification to stop our users from using system decoders already on the device, so _we will not filter any formats_,"
What about poor security of random codecs installed in the system?
White list system decoding for h264/mp3 if you really should (h264 in <video> is still better than h264 in a flash blob), and continue to push vp8/vorbis as the supported formats by Mozilla.
For windows XP (and linux distro), just let websites interested in using h264 give instructions to theirs users to install a system decoder, I fail to see why Mozilla, who in principle oppose h264 for the web, should care.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 14, 2012 23:41 UTC (Wed) by rillian (subscriber, #11344) [Link]
This is addressed later in the Mozilla dev-platform thread. A number of people are in favour of strictly limiting the exposed decoders, for pretty much those reasons.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 0:21 UTC (Thu) by josh (subscriber, #17465) [Link]
> For windows XP (and linux distro), just let websites interested in using h264 give instructions to theirs users to install a system decoder, I fail to see why Mozilla, who in principle oppose h264 for the web, should care.
Websites won't bother doing that; they'll just continue using Flash fallbacks like they do now, and people using Firefox won't get native HTML5 video. This represents one of the major reasons Mozilla now considers adding H.264: given a choice between <video> with a suboptimal codec and Flash with a suboptimal everything, adding H.264 would at least let people transition fully to <video>.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 1:16 UTC (Thu) by Trelane (subscriber, #56877) [Link]
> Websites won't bother doing that; they'll just continue using Flash fallbacks like they do now, and people using Firefox won't get native HTML5 video.
No, they won't bother doing that, just like they don't bother supporting Linux now. They will just encode it in h264 and tell us Linux users (and the ever-diminishing XP users) to install Windows 8, 9, 2018, XLP, fhqwhgads, or whatever it's called. I mean, they don't care about us now, why would they buy Flash to start?
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 1:18 UTC (Thu) by Trelane (subscriber, #56877) [Link]
At least until the 4 or 9 or however many years the MPEG-LA said noncommerial streaming will remain free....
Ah, our sight. It is so darned short.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 5:08 UTC (Thu) by keeperofdakeys (subscriber, #82635) [Link]
It wouldn't really benefit MPEG-LA to do this. If use of the codec is free (check), and use of the codec is wide spread (check), then it means makers of encoders/decoders have no choice but to pay the licensing fee, even if it is ridiculous. Being non-committal keeps their options open as well.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 10:17 UTC (Thu) by drago01 (subscriber, #50715) [Link] At least until the 4 or 9 or however many years the MPEG-LA said noncommerial streaming will remain free....I don't see how they can even charge for that. As long as the encoder that created the material is properly licensed they have no right on the content itself. Some jurisdictions seem to be completely off base.
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 20:27 UTC (Thu) by bawjaws (guest, #56952) [Link]
MPEG-LA committed to keep free-to-consumer web use free indefinitely after initially trying to keep their rent-seeking options open. It's one of the concessions Mozilla and Google won by taking their stance. Of course it just made it harder for them (just like linux on netbooks extended the life, and reduced the price, of XP) It doesn't really feel like a victory, but it is
See para 2 for details:
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Patent_lice...
Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (arstechnica) Posted Mar 15, 2012 20:42 UTC (Thu) by josh (subscriber, #17465) [Link]
That "concession" just makes it easier for MPEG-LA to extort money from the developers of the software that supports H.264 for those end users. Because the end users don't see a cost (and because no sane system would allow such a cost to exist), the end users can adopt H.264 more widely, oblivious to the costs they impose on developers.
An unfortunate description Posted Mar 15, 2012 12:54 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]
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.
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.
|
|||||||||||||