|
|
Log in / Subscribe / Register

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

On his blog, Christopher Blizzard looks at HTML5 and the patent-encumbered H.264 video codec. Blizzard draws a parallel between the GIF patent situation 5+ years ago and the current situation with H.264. "Remember, this is still very early in H.264's history so the licensing is very friendly, just like it used to be for MP3. The companies who own the IP in these large patent pools aren't in this for the fun of it — this is what they do. They patent and they enforce and then enjoy the royalties. If they are in a position to charge more, they will. We can expect that if we allow H.264 to become a fundamental web technology that we'll see license requirements get more onerous and more expensive over time, with little recourse."

to post comments

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 25, 2010 17:56 UTC (Mon) by xav (guest, #18536) [Link]

Nice position, but will that analysis be widely known, or will people just shout at Firefox because "it breaks html5" ?

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 25, 2010 18:10 UTC (Mon) by ctwise (guest, #10952) [Link] (29 responses)

This situation won't be resolved until Google (or, possibly, Apple) buys H.264 outright and releases
it to the general public, or until a better codec exists that matches or exceeds H.264 in
performance and hardware support. Neither solution is likely to happen soon.

buying a specification is hard; en.swpat.org pages

Posted Jan 25, 2010 18:53 UTC (Mon) by coriordan (guest, #7544) [Link] (27 responses)

Two aspects make it hard for any wealthy friend to buy freedom for us:

  • If you pay off the 22 companies that are currently claiming a share of the MPEG-LA royalties, you still don't have certainty that other companies won't demand royalties.
  • There's the format, and there're related features. If a friend buys the patents needed for the format, we might still find that as soon as we develop it a bit, we walk straight into more minefields.

I've gathered some documentation about this and other topics on the swpat.org documentation wiki. It's publicly editable, help very welcome: H.264, Audio-video patents, HTML5, Harm to standards.

buying a specification is hard; en.swpat.org pages

Posted Jan 25, 2010 19:34 UTC (Mon) by Oddscurity (guest, #46851) [Link] (26 responses)

Ogg Theora looks to be doing nicely compared to h264 and that's based off of VP3. I wonder if VP8 might end up being released too, if Google's bid on On2 is to go through.

Theora does not produce quality comparable to H.264

Posted Jan 26, 2010 10:18 UTC (Tue) by DonDiego (guest, #24141) [Link] (25 responses)

Theora does not stack up well towards H.264, no matter what its proponents may claim. Call it a sad fact if you will, but it remains a fact. To get comparable quality out of Theora, you have to spend considerably (>50%) more bandwidth, see

http://www-cs-faculty.stanford.edu/~nick/theora-soccer/

Theora does not produce quality comparable to H.264

Posted Jan 26, 2010 14:34 UTC (Tue) by patrick_g (subscriber, #44470) [Link] (19 responses)

>>> Theora does not stack up well towards H.264, no matter what its proponents may claim. Call it a sad fact if you will, but it remains a fact.

Concerning the comparison with H264 perhaps you will find this link interesting.

Theora does not produce quality comparable to H.264

Posted Jan 26, 2010 16:51 UTC (Tue) by DonDiego (guest, #24141) [Link] (18 responses)

I know that comparison and it is completely flawed. Since it's the only one that ever produced this positive results for Theora it gets repeatedly posted over and over again. This is starting to feel like discussing evolution with creationists. Reason does not seem to play a role. Not even the Theora devs themselves claim that Theora produces quality comparable to H.264, because they know very well that it does not.

Here is a good comparison of different codecs and codec implementations when dealing with animation material:

http://x264dev.multimedia.cx/?p=102

This is comparable to the (in)famous YouTube video quality link in that it deals with animation material. The result is that the most recent libtheora release can beat MPEG-2, which is quite an achievement for a codec based off of VP3, but nowhere near H.264.

Theora does not produce quality comparable to H.264

Posted Jan 26, 2010 18:40 UTC (Tue) by patrick_g (subscriber, #44470) [Link] (17 responses)

From the article :

"This is a test on anime, nothing else; it inherently biases towards video formats with smaller transform size (like H.264), so the results are not generalizable to non-animated material"

I must add that I never said that Theora produces quality better than H.264. Your comparison with evolution vs creationists is insulting. I know very well that H.264 is better than Theora...even the author of my link know that :

"Theora isn't the most efficient video codec available right now.But it is by no means bad, and it is substantially better than many other widely used options. By conventional criteria Theora is competitive. It also has the substantial advantage of being unencumbered, reasonable in computational complexity, and entirely open source".

The conclusion is that Theora is "good enough".

Theora does not produce quality comparable to H.264

Posted Jan 26, 2010 18:52 UTC (Tue) by DonDiego (guest, #24141) [Link] (16 responses)

No. The comparison is flawed and thus must not be employed to draw any sort of conclusion. Any conclusion drawn from flawed assumptions is flawed itself.

Theora does not produce quality comparable to H.264

Posted Jan 26, 2010 21:12 UTC (Tue) by Trelane (subscriber, #56877) [Link] (15 responses)

Maybe you can start by telling us how it's flawed?

Theora does not produce quality comparable to H.264

Posted Jan 26, 2010 21:47 UTC (Tue) by DonDiego (guest, #24141) [Link] (14 responses)

First off, video and audio are combined. This skews any sort of sensible comparison because Theora receives higher bitrate than H.264. Also, at least at that moment YouTube encoded just H.264 baseline profile while the Theora encoding was tweaked to be optimal. Basically H.264 has all the odds stacked against it. Still the resulting quality is better and the file smaller...

Theora does not produce quality comparable to H.264

Posted Jan 26, 2010 22:11 UTC (Tue) by Trelane (subscriber, #56877) [Link] (13 responses)

As discussed in the source, video and audio are in practice seldom divorced. It was intended as a real-world test, and real-world it was. As mentioned, the sound quality in the Ogg version was better than in the YouTube version. You're good with lower sound quality in exchange no/little change in video performance? (Usually, audio is the thing people are more sensitive to!)

"YouTube encoded just H.264 baseline profile while the Theora encoding was tweaked to be optimal."

Yes, it was in answer to "YouTube can't use Theora." It naturally used YouTube to compare against.

"Still the resulting quality is better and the file smaller..."

Actually, the Ogg bitrates were slightly lower (486 vs 490kbps, 325 vs 327kbps).

Theora does not produce quality comparable to H.264

Posted Jan 26, 2010 22:38 UTC (Tue) by DonDiego (guest, #24141) [Link] (12 responses)

This test gets referenced all the time in an attempt to prove that Theora can compete with H.264 in raw quality or quality per bit. But no matter how often this falsehood gets repeated, it remains untrue.

The Vorbis audio does not sound better to my ears, on the contrary. It would also be a very big surprise if 64kbit Vorbis could beat 106.5kbit AAC.

So if I apply your argument that audio is more important, H.264 wins two times, because it allows dedicating more bits to the audio while preserving a slightly higher video quality.

> Actually, the Ogg bitrates were slightly lower (486 vs 490kbps,
> 325 vs 327kbps).

False:

-rw-rw-r-- 1 diego staff 13871183 Jan 26 22:41 bbb.h264
-rw-rw-r-- 1 diego staff 15009926 Jan 26 22:41 bbb.theora

The clip is 284 seconds long, so the bitrate is 423kbps for Theora and 390kbps for H.264.

This test also says nothing about the suitability of Theora for YouTube. Judging from this sample, YouTube still has ample room for improvement in the H.264 encoding pipeline. You can rest assured that they know about this and will eventually tweak their system to produce better results.

Theora does not produce quality comparable to H.264

Posted Jan 26, 2010 22:50 UTC (Tue) by Trelane (subscriber, #56877) [Link] (11 responses)

"This test gets referenced all the time in an attempt to prove that Theora can compete with H.264 in raw quality or quality per bit. But no matter how often this falsehood gets repeated, it remains untrue."

So far, that's all tangential accusation and precious little fact.

"The Vorbis audio does not sound better to my ears, on the contrary. It would also be a very big surprise if 64kbit Vorbis could beat 106.5kbit AAC."

Umm, ok. Didn't know your ears were the benchmark here.

"So if I apply your argument that audio is more important, H.264 wins two times, because it allows dedicating more bits to the audio while preserving a slightly higher video quality."

Except that you're wrong?

"False:

-rw-rw-r-- 1 diego staff 13871183 Jan 26 22:41 bbb.h264
-rw-rw-r-- 1 diego staff 15009926 Jan 26 22:41 bbb.theora"

du -bs bbb_*
17307153 bbb_theora_486kbit.ogv
17753616 bbb_youtube_h264_499kbit.mp4

dir bbb_*
-rw-r--r-- 1 auser agroup 17307153 2010-01-26 16:40 bbb_theora_486kbit.ogv
-rw-r--r-- 1 auser agroup 17753616 2010-01-26 16:40 bbb_youtube_h264_499kbit.mp4

Sure you downloaded the right files? Oddly, your file names aren't the ones from the site. (http://people.xiph.org/~greg/video/ytcompare/bbb_theora_4... and http://myrandomnode.dyndns.org:8080/~gmaxwell/ytcompare/b...) What's going on here?

"The clip is 284 seconds long, so the bitrate is 423kbps for Theora and 390kbps for H.264."

The bitrate was included in the captions. Bitrate isn't filesize divided by time either.

"This test also says nothing about the suitability of Theora for YouTube. Judging from this sample, YouTube still has ample room for improvement in the H.264 encoding pipeline. You can rest assured that they know about this and will eventually tweak their system to produce better results."

Except that YouTube is shipping with it now, and the results are at worst comparable, one codec without costing anyone a patent penny. So yes, YouTube can use Theora now.

In addition, if we count future tweaking in, Theora doens't lose again. From your link at http://www-cs-faculty.stanford.edu/~nick/theora-soccer/:
"With this 1.1alpha version, Theora requires somewhere around 60% more bandwidth than Mpeg-4, but Theora is being actively improved, so we'll see. The Mpeg-4 we have today is the result of years of tuning on the encoders."

So basically, it's comparable to what's currently in use, while at the same time being royalty-free. I don't see a loss there, friend.

Theora does not produce quality comparable to H.264

Posted Jan 27, 2010 0:25 UTC (Wed) by DonDiego (guest, #24141) [Link] (10 responses)

> The Vorbis audio does not sound better to my ears, on the contrary.
> It would also be a very big surprise if 64kbit Vorbis could beat
> 106.5kbit AAC."

> Umm, ok. Didn't know your ears were the benchmark here.

The AAC stream captures the water sound better than the Vorbis stream to my ears. Anyway, bit by bit AAC and Vorbis are roughly comparable codecs. But you seem to expect that Vorbis can beat AAC with 60% of the bitrate. This is not at all realistic, Vorbis is an excellent audio codec, but not fairy dust.

> Sure you downloaded the right files? Oddly, your file names aren't
> the ones from the site. What's going on here?

I extracted the raw video streams from the containers in order to be able to compare video sizes directly.

> > The clip is 284 seconds long, so the bitrate is 423kbps for Theora
> > and 390kbps for H.264.

> The bitrate was included in the captions.

The bitrate in the captions refers to the complete file together with audio and container overhead. That number is thus not suitable for video bitrate comparison.

> Bitrate isn't filesize divided by time either.

What we care about here is the total/average bitrate for the whole clip, i.e. file size divided by time.

> In addition, if we count future tweaking in, Theora doens't lose again.
> From your link at http://www-cs-faculty.stanford.edu/~nick/theora-soccer/:
> With this 1.1alpha version, Theora requires somewhere around 60% more
> bandwidth than Mpeg-4, but Theora is being actively improved, so we'll
> see. The Mpeg-4 we have today is the result of years of tuning on the
> encoders."

The Theora we have today is also the result of years of tuning on the encoders. The question is how far tweaking can get it. There is a limit to the quality you can coax out of the Theora bitstream format. The 60% bitrate difference quoted above is a *lot* of ground to cover.

Note that H.264 decoders are also being improved. Much more work is being dedicated to H.264 encoders than to Theora encoders. If you don't believe me, compare the x264 development activity to libtheora and keep in mind that libtheora is the only Theora encoder, but x264 is not the only H.264 encoder.

This is not a good vs. evil fight. It's a technical question. Compression formats are not created equal. Theora technology is two generations behind H.264. You cannot expect Theora to improve beyond H.264, much less since all patented techniques are out of bounds. I'm sorry that it's not a fair race, but facts remain facts.

Theora does not produce quality comparable to H.264

Posted Jan 27, 2010 3:48 UTC (Wed) by paulj (subscriber, #341) [Link]

Note that H.264 decoders are also being improved. Much more work is being dedicated to H.264

E.g. the BBC apparently have been able to reduce the bitrate of their High-Def H.264 broadcasts by 16% without loss of quality, thanks to newer, better encoding technology.

You've missed the point.

Posted Feb 3, 2010 21:56 UTC (Wed) by gmaxwell (guest, #30048) [Link] (8 responses)

I spent time in the article explaining the role of audio. I'd appreciate if you wouldn't make it out as though I were attempting to mislead anyone.

I'm also completely baffled regarding the mention of "raw quality" in your comment. Are you really attempting to say that there is some issue with raw quality? If you crank the bitrate sufficiently pretty much any codec should be transparent.

...and of course the comparison is saying something about the suitability of Theora for Youtube, the fact that they could possibly improve their H.264 processing chain doesn't change the fact that Theora was working OKAY compared to what they actually were using. If you're nitpicking about a couple of kbit/sec here or there, you're missing the point. It's intended to be an order of magnitude comparison to give some perspective. When people here codec ricers blather on with hyperbolic language about which codec is superior, they tend to think of enormous differences. But the differences are usually not enormous in a comparison unless you run it right up against the quality/bitrate knee.

Personally, I think it is insane to compare the files without container overhead. What else do you care about when transferring a file than the whole system? If one container has higher overhead than another, then thats a cost you're going to have to deal with in the real world.

I did also put up a strict buffer constrained rate controlled and lower bitrate file for people who emailed asking about that but since the screenshot looked the close enough to me I didn't think it was worth adding links to it and trying to explain the benefits that strict rate control has for streaming all post-publication.

You comment that "The Theora we have today is also the result of years of tuning on the encoders." is laughably, but sadly, wrong. The Theora encoder has had no more than one person working on it part-time at a time for the past two years, and had a number of years gulf of no active development. Go look at the SVN history. There simply haven't been the resources available to go work on it, and the overwhelming majority of the people working on "open source" video encoding have been contributing to the patent encumbered formats... they are more exciting because they are ahead and avoiding patents is nasty boring work.

With a bit of available funding and attention it made enormous progress in a short span of time and the ptalarbvorm development branch is already obviously improved vs 1.1 (about 2dB on SSIM on average, and casual subjective testing seems to suggest that much or somewhat more). There will be no miracles: After all, from a format perspective H.264 is nearly a superset of Theora, but there is clearly a decent amount of room for improvement.

No, I made the point I wanted to make.

Posted Feb 4, 2010 15:36 UTC (Thu) by DonDiego (guest, #24141) [Link] (7 responses)

> I spent time in the article explaining the role of audio. I'd appreciate if you wouldn't make it out as though I were attempting to mislead anyone.

Correct. You were not trying to mislead anyone. However, people are misreading your comparison and drawing the wrong conclusions.

> I'm also completely baffled regarding the mention of "raw quality" in your comment. Are you really attempting to say that there is some issue with raw quality? If you crank the bitrate sufficiently pretty much any codec should be transparent.

I spoke imprecisely. I meant bit-by-bit quality.

> ...and of course the comparison is saying something about the suitability of Theora for Youtube, the fact that they could possibly improve their H.264 processing chain doesn't change the fact that Theora was working OKAY compared to what they actually were using.

This assumes that YouTube is not planning ahead for a future in which they may wish to stream 1080p video to desktops worldwide. Do you think this is a realistic assumption?

> If you're nitpicking about a couple of kbit/sec here or there, you're missing the point. It's intended to be an order of magnitude comparison to give some perspective.

I'm not nitpicking, I'm putting your comparison in perspective. You sacrifice audio quality to achieve a not-quite-on-par video quality.

If you can live with that, fine. But your comparison is being touted as proof that Theora produces bit-by-bit quality comparable to H.264. As you very well know, this is simply not true.

> Personally, I think it is insane to compare the files without container overhead. What else do you care about when transferring a file than the whole system? If one container has higher overhead than another, then thats a cost you're going to have to deal with in the real world.

I agree, but the container overhead is higher for Ogg, so that's another drawback for Theora. What are you trying to say?

I know that Theora encoders still have room for improvement. I never disputed that fact. However, the same applies to H.264 encoders. Due to the technical superiority of the format and the different amount of work being dedicated to both, the gap is more likely to widen further than it is to shrink.

Also, I take issue with your putting open source video encoding in quotes. These are the people that are keeping Linux viable as a general-purpose desktop platform. They deserve thanks, not criticism.

No, I made the point I wanted to make.

Posted Feb 4, 2010 16:34 UTC (Thu) by gmaxwell (guest, #30048) [Link] (6 responses)

I agree, but the container overhead is higher for Ogg, so that's another drawback for Theora. What are you trying to say?
I'm not in much of a position to speak about MP4/QT container overhead, but the container overhead of Ogg is fairly low when Ogg is used in the typical way. Ffmpeg does a rather brain-dead thing and only ever places one packet per Ogg page which enormously increases the overhead at lower bitrates, but as far as I'm aware every other tool won't do that. If you are interested in low overhead, Ogg can be as low as ~0.433% (presuming big packets, like video). Is a streamable, seekable, MP4 file in that ballpark? Better seems ... unlikely... to me, or inconsequential if it's the case.
I'm putting your comparison in perspective. You sacrifice audio quality to achieve a not-quite-on-par video quality.
If you want to argue it out, I can arrange a blind listening test on the audio. My audio will win. :) AAC-LC isn't all that hot. Really.

But I don't we need to argue that— take a gander at This Theora vs the YT H.264, or for the lazy the Theora still vs the YT h.264 still.

So there you have, lower bitrate pure video than the H.264, same keyframe interval, same input, etc. How do you think it looks?

Would sir like his hat medium or rare?

Obviously we don't know anything about the YT cpu consumption, so you can still argue that. The theora encoder is pretty fast, I've seen others compare it to the fast mode in x264, even though its not deeply optimized at all. But we have no idea how fast YT's tools are. I concede the encoder cpu consumption is usually relevant, and that other H264 encoders are better, ... and I never claimed otherwise. Can you concede that, for the purpose of this test, that the quality/bitrate is basically there?

Also, I take issue with your putting open source video encoding in quotes. These are the people that are keeping Linux viable as a general-purpose desktop platform. They deserve thanks, not criticism.

It's in quotes because people are widely ignorant about the implications, it isn't intended as an insult. Open source in the context of the tools for encumbered media formats doesn't quite mean the same thing as it does for most other pieces of open source software.

Obviously I'm mostly discussing high end encoders when I made that point.

There is a fine line between embracing the encumbered world enough to capture their users and outright embracing it. When the resulting tools are widening the gap between unencumbered and encumbered formats, its doing the format owners a much bigger favour than its doing everyone else. ::shrugs::

It's also a little frustrating that some of the popular tools like ffmpeg don't offer world-class support for the things like Ogg/Theora while a few of their developers are spending a lot of time and effort slinging unadulterated FUD. Can you sense my finger wagging? Come on, at least look at the freeking priority dates, dude.

No, I made the point I wanted to make.

Posted Feb 4, 2010 16:51 UTC (Thu) by gmaxwell (guest, #30048) [Link]

Erp. And it seems that VLC, of at least some versions, is performing a bizarre post-decode blurring on Theora and not H.264. Doesn't appear to be the libtheora post-processing filter... Only discovered this today, but you ought not view in VLC if you're comparing the videos.

Cheers.

No, I made the point I wanted to make.

Posted Feb 5, 2010 0:53 UTC (Fri) by DonDiego (guest, #24141) [Link] (4 responses)

I'm afraid your intuitions about container overhead are quite far off from reality. Let's see:
17307153 bbb_theora_486kbit.ogv
15009926 bbb_theora_486kbit.theora
 2107404 bbb_theora_486kbit.vorbis
--------
  189823

17753616 bbb_youtube_h264_499kbit.mp4
13898515 bbb_youtube_h264_499kbit.h264
 3796188 bbb_youtube_h264_499kbit.aac
--------
   58913

Ogg has more than 300% the overhead of MP4 here. You wanted to talk about the Youtube case, so there is no escaping that number here.

I made a listening test of both audio streams myself. To my ears the waterfall in the beginning really sounds like water for the AAC stream, the Vorbis stream is much more washed out.

I'm happy to see your latest encoder branch make further progress. I'll be even more happy to see it perform in a straight comparison with x264 and various FFmpeg encoders. If you want to have credibility, perform a fair test.

Can you concede that, for the purpose of this test, that the quality/bitrate is basically there?
No. My whole point is that this test is worthless because it avoids the most sticky points. You should pitch Theora against the best H.264 encoders, not against an encoding pipeline which obviously has huge room for improvement. You should also take future developments into account. 1080p should be the benchmark, not the horrible quality Youtube currently offers.

FFmpeg's Ogg muxer produces high overhead because Ogg is a deeply flawed container format and so far nobody has been willing to go out of their way to work around its deficiencies. We continue to have the fastest Vorbis decoder around and our Theora decoder has seen considerable speeups recently. David Conrad has a branch with some serious tweaks that is on its way to getting merged. It should at least match libtheora 1.1 in speed and eventually surpass it when further tweaks get applied. We clearly have no world-class support yet, but it's slowly improving. Also, we accept patches, yours are welcome as well.

There is the "encumbered" world, the "unencumbered" world and the real world. In the real world people try to listen to music and watch movies. FFmpeg, VLC, MPlayer, x264 and the rest of the bunch enable people to do just that. Without them free software desktop market share would be orders of magnitude smaller and decreasing. You seem to think this is worth sacrificing in order to avoid a patent threat that some day might affect some person in some part of the world. I wholeheartedly disagree.

I'll stop wondering about submarine patents the moment you guys earn my trust by publishing your findings. And yes, I'm wagging my finger at you. You act exactly as if you had something to hide. "There is no toxic waste drop here. We have made a study and come to the conclusion that this water is safe. We cannot show you the study, but you can *trust* us!" Trust is not something that is handed out for free, you have to earn it through integrity and transparency. I just wanted to say something about Iraq and weapons of mass destruction, but I'll shut up before I dig myself in deeper ;-)

No, I made the point I wanted to make.

Posted Feb 5, 2010 14:13 UTC (Fri) by gmaxwell (guest, #30048) [Link] (3 responses)

I wasn't giving you an intuition, I was giving you a format maximum: You can put about 64k of payload in an Ogg page or up to 255 packets. For that file that using maximum size pages would give an ogg overhead of 82887 bytes. Had I used larger page sizes in my comparison I would have no longer been using default settings, which was one of my goals. I'm not sure how you're writing out those files for your mp4 comparison, I'm guessing they still have some container headers, but reading the samplesizes directly from the mp4 dump brings me to 86245 bytes of container overhead, which is pretty similar.

not the horrible quality Youtube currently offers
Well, what can I say? I wrote a clearly described specific comparison about YT because of an outrageous goggler quote. Now you're running around the internet calling my statements fraudulent because they weren't a comparison with something else.

Without them free software desktop market share would be orders of magnitude smaller and decreasing.
I fail to see how advancing the state of the art in the best encumbered format encoders does much of anything to preserve free desktops by helping people "listen to music and watch movies". But to each his own. There are perfectly viable ways to get legally licensed encoders for your desktop even if tools like ffmpeg didn't exist, but its existence wasn't something that I was protesting.

I'll stop wondering about submarine patents the moment you guys earn my trust by publishing your findings.
You could at least get the terminology right. A "submarine patent" isn't what you should be worried about, submarine patents are an old technique for making effectively secret patents that could last for decades, scary indeed. This loophole was closed in the mid-90s. All the submarines were forced to surface.

The way the patent system is setup you are very strongly discouraged from disclosing your research: The parties suing for infringement have the stronger position and making them aware of your position allows them to avoid arguing particular things. For example "my own work is prior art for that claim" and "I don't practice that technique" are mutually exclusive defences. If the attacker knows how you will defend they can make the legal battle much longer and more expensive to win. Don't hate the player, hate the game.

The whole purpose of Xiph is to produce/promote unencumbered formats. We expend a fair amount of additional effort, and accept considerable limits because of what techniques we're not permitted to practice. Knowingly allowing something encumbered would be self-defeating in the most enormous way. Of course, mistakes could be made.

What I can give point to you is a decade of shipment, by a large number of parties (some with decently deep pockets) with no publicly known litigation related the formats, which is better than you can say for many mpeg standards. I can also point you to shipments by large organizations who had their own legal teams look at it. I'm sorry if thats not enough for you, but as far as I can tell nothing would be.

What you were doing by slinging a bunch of irrelevant patent numbers was pure FUDing, in a particularly vile way. I think it speaks a lot to your motivation and character, and it's a warning about the futility of engaging with you which I should have heeded.

Cheers.

No, I made the point I wanted to make.

Posted Feb 7, 2010 21:21 UTC (Sun) by DonDiego (guest, #24141) [Link] (1 responses)

I used 'mplayer -dumpaudio' and 'mplayer -dumpvideo' to extract the audio and video streams.

> Well, what can I say? I wrote a clearly described specific comparison about YT because of an outrageous goggler quote. Now you're running around the internet calling my statements fraudulent because they weren't a comparison with something else.

Your comparison is constantly being presented to me and others as proof that Theora is as good as H.264. If that was not your intention, fine. It does not change the fact that your comparison is being misread all the time. And sorry, but you are not exactly going out of your way to prevent this.

> > Without them free software desktop market share would be orders of magnitude smaller and decreasing.

> I fail to see how advancing the state of the art in the best encumbered format encoders does much of anything to preserve free desktops by helping people "listen to music and watch movies".

Simple. People use their computers to listen to music and watch movies. There are popular formats to make music and movies available in digital form. If no free software is available to handle these formats, people will use something else to get at their movies and songs. Free software loses, badly.

> But to each his own. There are perfectly viable ways to get legally'licensed encoders for your desktop even if tools like ffmpeg didn't exist, but its existence wasn't something that I was protesting.

Fluendo is much more recent than FFmpeg or MPlayer. But if Fluendo is an alternative option for you, then you don't value free software. I'm not such a person.

Container conundrum

Posted Mar 9, 2010 20:59 UTC (Tue) by gmaxwell (guest, #30048) [Link]

So, I'm reasonably confident that your claimed mp4 overhead is simply incorrect. I don't know why.

I measured it as 86245 using one method (segment sizes from mp4dump). A friend who has implemented the mp4 demux checked the file and also calculated 86245 using his own method. My guess was that mplayer must be including packet length data in the dump output, but I just repeated your method and got 13871183 bytes video, 3796188 bytes audio. Resulting in 86245. Exactly the same figure calculated by two other distinct methods.

Perhaps you could explain why I'm getting a different figure using exactly the same method as you? I'm using Mplayer SVN-r29800-4.4.2.

I remuxed the above Theora file we were discussing for minimum overhead using a copy of libogg with the default 4k page size target removed:

http://people.xiph.org/~greg/video/ytcompare/bbb_theora_4...

This file has 84604 bytes of container overhead.

This is somewhat lower overhead than your mp4 file. Now that I understand a bit more about the mp4 format I find it actually somewhat surprising— Ogg provides a lot of properties that MP4 does not. Like being incrementally written in a complete form.

I hope this update convinces you to discontinue spreading these mistaken claims.

Cheers.

No, I made the point I wanted to make.

Posted Feb 7, 2010 21:34 UTC (Sun) by DonDiego (guest, #24141) [Link]

> > I'll stop wondering about submarine patents the moment you guys earn my trust by publishing your findings.

> You could at least get the terminology right. A "submarine patent" isn't what you should be worried about, submarine patents are an old technique for making effectively secret patents that could last for decades, scary indeed.

I'm not a native speaker and was indeed unfamiliar with the meaning you connect to the term "submarine patent". Note however, that this very same confusion exists between the German and English Wikipedia entries.

Theora DID not produce quality comparable to H.264

Posted Jan 26, 2010 23:02 UTC (Tue) by rickmoen (subscriber, #6943) [Link] (1 responses)

I can't help noticing that the basis of comparison was the Theora 1.0 codec, which was certainly relevant in June 2009, when the author wrote that comparison, but is no longer. It would be accurate to say that Theora did not stack up well towards H.264. However, I hear that things have changed.

Rick Moen
rick@linuxmafia.com

Theora DID not produce quality comparable to H.264

Posted Jan 27, 2010 0:30 UTC (Wed) by DonDiego (guest, #24141) [Link]

No, the test was done with 1.1 alpha current from that date. 1.1 is indeed much improved over 1.0, but the alpha already carried all the quality improvements. See also

http://x264dev.multimedia.cx/?p=102

which clearly shows how far 1.1 improves over 1.0 and also how it fares compared to other codecs.

Theora does not produce quality comparable to H.264

Posted Feb 2, 2010 9:01 UTC (Tue) by greycells (guest, #63306) [Link] (2 responses)

Given the choice between paying the piper's escalator prices for the next 20 years or using a Free* codec that is (already) better than flash and likely to continuously improve, I'll take the latter every time.

Let's face it, when streaming to mobile devices, quality ain't the issue. When streaming to fixed devices, bandwidth is not (usually) an issue. Either way, most users won't notice the difference between h264 and Theora.

Unfortunately, greed overrules the common good every time so we're likely stuck with h264 in order to pay those 1000+ patent holders their pound of flesh (http://lwn.net/Articles/371751/).

*not as in beer

Theora does not produce quality comparable to H.264

Posted Feb 2, 2010 15:15 UTC (Tue) by DonDiego (guest, #24141) [Link]

> Given the choice between paying the piper's escalator prices for the next
> 20 years or using a Free* codec that is (already) better than flash and
> likely to continuously improve, I'll take the latter every time.

Flash is many things, I assume you refer to the H.263 video transported in FLV containers as used by Adobe Flash. That's a codec from the same generation as Theora, the quality is horrible and it's insufficient for all serious usage.

In any case, it's not a way forward. Video quality on the web has to improve, not remain on the current crappy level. H.264 is considered to be the tool to achieve that, so you have to compare H.264 with Theora, not some ancient legacy codec, which is clearly on its way into obsolescence.

Also notice that H.264 will continuously improve and likely at a much higher rate than Theora since it receives more development resources and is a more advanced design to start with.

> Let's face it, when streaming to mobile devices, quality ain't the issue.

False. Nowadays mobile devices have high-definition displays and this trend will not reverse itself in the future, on the contrary. Just think 5 years into the future.

> When streaming to fixed devices, bandwidth is not (usually) an issue.

False. Content providers have to pay for bandwidth and content consumers often have to pay for bandwidth as well. Just think of mobile devices, bandwidth is expensive there and nobody wants to squander it.

Theora does not produce quality comparable to H.264

Posted Feb 2, 2010 15:20 UTC (Tue) by farnz (subscriber, #17727) [Link]

Note that Flash video is H.264 in modern Flash versions. And, as we know that H.264 is better than Theora, your claim that the Free codec is already better than Flash is trivially false.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 26, 2010 19:37 UTC (Tue) by martinfick (subscriber, #4455) [Link]

But where the hardware support matters the most: phones, the hardware is typically more quickly obsolete anyway (quicker than on PCs). This means that it doesn't matter as much what is out there today for the long, or even the mid term. No need to give up when the landscape can be completely redrawn in only a few years.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 25, 2010 19:17 UTC (Mon) by nhippi (guest, #34640) [Link] (18 responses)

There is a major difference to the GIF debacle. GIF was always implemented in software. OTOH H.264 decoding happens mostly in hardware[1].

Even on PC's, H.264 is supported in hardware by recent nvidia (purevideo HD) and ati cards (avivo HD)- and I presume intel follow. Lets see if intel will do it on a codec on their GMA graphics chips or with SSE264 extension featuring DECODE264 SIMD instruction will be interesting to see...

Why is that relevant? Because if implemented in hardware, the software doesn't need a patent license. When implemented in hardware, it will be no more relevant than the patented X86 instructions are to users. Sure, they eliminate competition, but it doesn't free software from using them.

I'm afraid mozilla has choosen an fight they can't win. IE, safari and chrome will support H.264, and someone will write a firefox plugin to do it as well. The only thing the fight will create is delay in html5 video adoption - and meanwhile the video still gets distributed in H.264 - in flash container. Which leads to the question:

Is it more important to eliminate flash or H.264? Mozilla has seemingly taken the latter one as more important.

[1] Which actually might be a DSP executing firmware.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 25, 2010 19:28 UTC (Mon) by coriordan (guest, #7544) [Link] (3 responses)

I don't keep up to date on low-level systems programming anymore, so I've two questions that might be obvious:

1. Are the codecs in unwritable memory on the cards? Or do they get put there by injecting binary blobs into the cards on bootup/upgrade? If the latter, then we should replace those binardy blobs with free software. So that "solution" only works if we accept binary blobs?

2. Say I want to encode a video into H.264, and say I want to modify a H.264 video and save it in another format. Wouldn't I need H.264 software on my harddisk for these tasks? The blob in my video card wouldn't do this for me, would it? (I know these tasks aren't what Firefox does, but if we accept it for online video, we'll be stuck with it for other things)

Right? Wrong?

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 25, 2010 19:46 UTC (Mon) by Oddscurity (guest, #46851) [Link] (2 responses)

The way I understand it: nVidia's VDPAU doesn't even do all of the decoding
on the GPU, it just accelerates some parts like colour conversion,
deblocking and other parts of the inner loop.

So it's still software, part of which runs on the CPU as implemented in the
driver, and part of which ends up running on the GPU.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 25, 2010 19:54 UTC (Mon) by drag (guest, #31333) [Link]

Yeah.

Like stated above there are 22 different companies involved in the Mpeg
group. And if the GSM folks are any indication of how these sort of industry
'IP' groups operate they do everything they can to shovel as many patents
into the pool as possible.

So it's likely that there are dozens and dozens of patents covering all
sorts of different aspects of the codecs, and software and hardware related
to the codecs. So even if the video card folks build codecs-as-hardware they
still only likely take a some patents out of the equation and not all of
them. Meaning that even with hardware acceleration your still not going to
escape from the licensing requirements.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 25, 2010 21:02 UTC (Mon) by nhippi (guest, #34640) [Link]

> The way I understand it: nVidia's VDPAU doesn't even do all of the decoding
> on the GPU, it just accelerates some parts like colour conversion,
> deblocking and other parts of the inner loop.

I believe that is what the early VDPAU versions did. Later versions offload full decoding to the video card. Then again, this is based on external observations of cpu load rather than knowing what the VDPAU library really does..

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 25, 2010 19:34 UTC (Mon) by Imroy (guest, #62286) [Link] (2 responses)

I don't know about all of those pieces of hardware, but I'm sure the nVidia and ATI implementations are simply running on the GPU - I seriously doubt they would devote so much effort and chip area to having a squillion little processing units, and then add separate MPEG-1/2/4 video decoders in hardware as well. So the decoders are still software. And they'd be licensed of course.

Oh, and I can't find anything about this "DECODE264" instruction.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 25, 2010 19:43 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

"I seriously doubt they would devote so much effort and chip area to having a squillion little processing units, and then add separate MPEG-1/2/4 video decoders in hardware as well."

Yet they do exactly this. And the main reason is power consumption. Specialized ASICs are still faster even compared to GPGPU.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 25, 2010 20:47 UTC (Mon) by nhippi (guest, #34640) [Link]

> Oh, and I can't find anything about this "DECODE264" instruction.

It was a joke. The latest intel processors already have AESDEC and AESENC so..

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 25, 2010 19:42 UTC (Mon) by Per_Bothner (subscriber, #7375) [Link] (9 responses)

Remember, broadcasters also have to pay non-trivial money to the patent pool, so you can't host an H.264 on your web-site without infringing. Also, those prices are scheduled to go up, so some big players (possibly including Google) have an incentive to find an alternative.

Is it more important to eliminate flash or H.264? While Flash is more annoying because of bugs etc, it is in principle the lesser evil, since (I believe) it can be legally re-implemented in Free Software. H.264 cannot, in many parts of the world.

how implementable Flash is

Posted Jan 25, 2010 21:12 UTC (Mon) by coriordan (guest, #7544) [Link] (3 responses)

I'd've thought that implementing Flash would raise lots of patent problems, but this doesn't seem to have happened. When I heard Rob Savoye of Gnash complaining about software patents last February, he was complaining about codec patents.

I can't find any info online right now, but I seem to remember him saying the the main legal difficulty with implementing Flash is that he can't hire any programmers in the USA because there's a draconian clause in Adobe's licence that's enforceable in the USA and nowhere else. Something about "if you use this software, you agree not to use the gained knowledge for the purpose of writing a competing program". Not sure where you'd find the details... anyone know what I'm talking about?

how implementable Flash is

Posted Jan 25, 2010 21:50 UTC (Mon) by MarkVandenBorre (subscriber, #26071) [Link]

I've talked to Rob in the past and heard him say exactly the same. I seem to vaguely remember him writing that this situation has changed somewhat for the better though. But don't quote me on that.

how implementable Flash is

Posted Jan 26, 2010 2:20 UTC (Tue) by butlerm (subscriber, #13312) [Link] (1 responses)

Something about "if you use this software, you agree not to use the gained knowledge for the purpose of writing a competing program"
It it is somewhat questionable whether a term like that in a retail end user license agreement would in fact be enforceable, especially if the user of the software was not the person who installed it. Courts in the United States have decided both ways. If the EFF wanted to do something useful, they would find people with standing to challenge the extremely dubious arguments behind retail shrinkwrap licenses and push the counterargument based on traditional legal reasoning and copyright law until the disingenuousness of the idea that consumers do not own "copies" of software they buy of the shelf (and the consequent nullity of most end user SLAs) is obvious to every judge in the country.

how implementable Flash is

Posted Jan 26, 2010 13:31 UTC (Tue) by dannyobrien (subscriber, #25583) [Link]

If the EFF wanted to do something useful, they would find people with standing to challenge the extremely dubious arguments behind retail shrinkwrap licenses and push the counterargument based on traditional legal reasoning

It's funny you should say that... actually EFF is heavily involved in this fight (it was counsel on two of the three cases listed on the page you linked to), and I do believe we're expecting to work on a number of key cases in this area in the next year. We generally describe this as the fight over first sale (partly because the fight also includes patent issues as well as shrinkwrap licenses), but it's the same counterargument.

Blizzard: HTML5 video and H.264 - what history tells us and wihy we're standing with the web

Posted Feb 2, 2010 9:37 UTC (Tue) by njwhite (guest, #51848) [Link] (1 responses)

While Flash is more annoying because of bugs etc, it is in principle the lesser evil, since (I believe) it can be legally re-implemented in Free Software. H.264 cannot, in many parts of the world.

I think it's still the case though that codecs you send over flash are still patentable (and largely patented). Which is why the gnash devs get so annoyed that people get annoyed when it doesn't work with youtube, because they won't distribute the codecs themselves, so have to hope that the distributions will (and often distributors get it wrong).

Even if flash is perfectly reimplemented, then, we still have all the problems with codec patent issues.

gnash codecs

Posted Feb 2, 2010 17:21 UTC (Tue) by DonDiego (guest, #24141) [Link]

gnash could just distribute the codecs themselves. We've been doing it at FFmpeg/MPlayer for 10 years without problems. If they are afraid to do it themselves, they should get a hoster that is not.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Feb 2, 2010 15:19 UTC (Tue) by DonDiego (guest, #24141) [Link] (2 responses)

> Flash is in principle the lesser evil, since (I believe) it can be legally
> re-implemented in Free Software. H.264 cannot, in many parts of the world.

This is wrong, please get a clue about patents. It is not illegal to implement a patented technique, in free or proprietary software, anywhere in the world.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Feb 2, 2010 16:41 UTC (Tue) by Trelane (subscriber, #56877) [Link] (1 responses)

This is wrong, please get a clue about patents. It is not illegal to implement a patented technique, in free or proprietary software, anywhere in the world.
http://www.uspto.gov/web/offices/pac/doc/general/index.html#patent
The right conferred by the patent grant is, in the language of the statute and of the grant itself, “the right to exclude others from making, using, offering for sale, or selling” the invention in the United States or “importing” the invention into the United States. What is granted is not the right to make, use, offer for sale, sell or import, but the right to exclude others from making, using, offering for sale, selling or importing the invention. Once a patent is issued, the patentee must enforce the patent without aid of the USPTO.
(emphasis mine)

patents and legality

Posted Feb 3, 2010 1:47 UTC (Wed) by DonDiego (guest, #24141) [Link]

Correct. The patent holder receives a *right*, not an obligation. That very much does not make the act of implementing a patented technique illegal. The patent holder may choose never to enforce rights or you may reach some sort of deal.

This is very much unlike stealing or murder, where the state has an obligation to go after you and where you can never be excused or make a deal.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 26, 2010 2:05 UTC (Tue) by roc (subscriber, #30627) [Link]

> Why is that relevant? Because if implemented in hardware, the software
> doesn't need a patent license.

Even if it was true that all hardware supported H.264 so there were no free software issues on the client, there would still be huge problems for content providers and Web authors, as Blizzard's post explains.

> Is it more important to eliminate flash or H.264? Mozilla has seemingly
> taken the latter one as more important.

No, it's a strategic issue.

Flash is deeply entrenched on the Web. Reducing its usage is a long-term project, which first requires us to create standards-based alternatives for Web authors to use instead of Flash. We're doing tons of work on that, but we're still far away from being able to disable Flash and still have a browser a lot of people would use.

On the other hand, <video>+H.264 is still very new on the Web, and there is Flash fallback, so pushing back against it is still possible without wiping out our market share and destroying all our influence over the Web.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 25, 2010 20:26 UTC (Mon) by danpb (subscriber, #4831) [Link] (138 responses)

While I'm a supporter of Ogg Theora/Vorbis & its potential use with HTML5, but mozilla's position is putting current firefox users in a no-win position, (ab-)using them as a stick to beat up other companies. Currently the options for consuming/publishing video on web pages are Flash plugin, Java plugin or HTML5 video. Obviously 99% of the web currently uses Flash and that *already* exposes everyone to non-free codecs. As a user I want to eliminate use of Flash for videos from my browser for a number of reasons

- closed source
- uses non-free codecs
- has a poor security record
- has bad accessibility

HTML5 video + h264 addresses 3 out of these 4 major problems with the current de-facto standard of flash video which would be a massive step forward from the current position. This blog posting focuses only on the choice between h264 and Theora in the context of HTML5 video & the issue of IP/patent licensing around h264, and thus denies firefox users the chance to benefit from other aspects of HTML5.

I'm not suggesting Mozilla distribute h264 codecs themselves, since clearly that's not viable with the licensing scheme. This is not a new problem though & it has been solved by every open source media player that exists today - allow for 3rd party codecs to be plugged in via GStreamer or an equivalent system. If it ends up being a choice between Firefox with either Flash or HTML5/Theora, or a WebKit browser with either Flash or HTML5+option to plugin any possible codec, then Firefox is going to loose.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 25, 2010 21:14 UTC (Mon) by coriordan (guest, #7544) [Link] (135 responses)

The problem is that if we take the short term near-win, over time we walk ourselves into a situation that's hard to get out of when things get bad or when we want a full win.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 25, 2010 22:37 UTC (Mon) by danpb (subscriber, #4831) [Link] (125 responses)

I guess the answer depends on how likely you think it is that Mozilla's stance on Ogg Vorbis/Theora will eventually win over other browser vendors and/or or major content publishers like Youtube. If there's still a realistic chance of getting more major backers to agree on Ogg Theora/Vorbis as the standard baseline codec, then the short term pain would indeed be worth it, but if we end up with no single dominant codec then IMHO its inevitable that firefox will have to provide a way to drop-in support for other codecs. I'd like to believe the former scenario is still possible, but its looking more like the latter is happening every day.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 25, 2010 23:11 UTC (Mon) by drag (guest, #31333) [Link] (124 responses)

I guess the answer depends on how likely you think it is that Mozilla's stance on Ogg Vorbis/Theora will eventually win over other browser vendors and/or or major content publishers like Youtube.

They won't win. At least not with the approach they are taking.

Making it difficult for users to add H.264 support is a antifeature. They are intentionally making their program do things most people don't want it to do in order to forward a specific political viewpoint.

I don't have a problem with political viewpoints or trying to advance a issue through software, but to do in the manner that Firefox/Mozilla folks are doing it is just shooting themselves in the foot.

If they use native codecs for systems they port to.. such as DirectShow, Gstreamer, and Quicktime then the lack of H.264 support (Windows XP does not have H.264 support) is not something that they have to burden on themselves. Then it becomes the fact that H.264 licensing is shit, not that Mozilla has a crusade against it.

Then in addition they can bundle encoding and decoding codecs into the native systems for Theora.

One of the biggest hurdles for Theora Ogg is the fact that nobody has support for it in the client. If you download and install Firefox, which most people are doing, then bundling Theora support to get installed into the native media framework's system will mean that a huge portion of the audience can actually view and create content in that codec.

That is something that has not happened at all yet for any open source codec.. whether it's Ogg Vorbis, Ogg Speex, Flac, or Ogg Theora. They can make it simple for other applications to support it as well as providing easy to use encoding software for popular websites uploads. Which is something nobody does right now; since nobody wants to pay the licenses for the software.

That way they can promote Theora by making it easy to use rather then trying to make H.264 harder to use... which is not going to work because Opera, Safari, Chrome, and eventually IE will make using H.264 easy.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 26, 2010 3:09 UTC (Tue) by roc (subscriber, #30627) [Link] (123 responses)

> Making it difficult for users to add H.264 support is a antifeature. They
> are intentionally making their program do things most people don't want
> it to do in order to forward a specific political viewpoint.

Not at all. Integrating an H.264 codec, or integrating support for various system codec frameworks, are features that we have chosen to not add, features that would require major engineering effort to create and support, given we need faithful adherence to the HTML5 spec. If you don't believe this, you can take the Firefox source and show us how easy it is.

See also http://weblogs.mozillazine.org/roc/archives/2009/06/direc....

> They can make it simple for other applications to support it as well as
> providing easy to use encoding software for popular websites uploads.

Making Firefox install apparently unrelated software that will be picked up and used by other applications would be a support nightmare. Being responsible for keeping that software up to date with security patches would also be a nightmare (especially if Firefox is uninstalled). Furthermore, some people would be very upset to find Firefox installing unrelated software and changing the behaviour of other applications.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 26, 2010 9:51 UTC (Tue) by DonDiego (guest, #24141) [Link] (45 responses)

> > Making it difficult for users to add H.264 support is a antifeature.
> > They are intentionally making their program do things most people don't
> > want it to do in order to forward a specific political viewpoint.

> Not at all. Integrating an H.264 codec, or integrating support for various
> system codec frameworks, are features that we have chosen to not add,
> features that would require major engineering effort to create and
> support, given we need faithful adherence to the HTML5 spec.

You could just have used FFmpeg instead of the Xiph libraries.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 26, 2010 13:08 UTC (Tue) by __alex (guest, #38036) [Link] (42 responses)

ffmpeg has absolutely no royalty paid decoders in it at all and basically an
enormous liability for everyone involved.

Things like gstreamer, directshow and quicktime at least provide the
possibility of a legal decoder with paid up royalties for H.264 even if in
practice it'll likely be ffmpeg that people actually use ;)

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 16:58 UTC (Tue) by DonDiego (guest, #24141) [Link] (41 responses)

You can of course use FFmpeg and pay the MPEG-LA if you are so inclined. There are companies that do it. The MPEG-LA could not care less which implementation is used.

Mozilla could use a system FFmpeg just like Chrome does. No patent liabilities would be incurred on Mozilla.

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 17:09 UTC (Tue) by __alex (guest, #38036) [Link] (3 responses)

It's not nearly as simply as just dropping ffmpeg in instead of Xiph though. As
you said, they'd have to pay for the license themselves for one. Outsourcing
decoding to system APIs get's around that.

Also I'm not sure they could pay MPEG-LA and still maintain the re-
distribution rights that the MPL gives you. You would need to pay the MPEG-
LA to distribute any modified version of the Gecko engine.

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 17:33 UTC (Tue) by DonDiego (guest, #24141) [Link] (2 responses)

> It's not nearly as simply as just dropping ffmpeg in instead of Xiph
> though. As you said, they'd have to pay for the license themselves for
> one. Outsourcing decoding to system APIs get's around that.

False. There is no need for Mozilla to distribute FFmpeg libraries with H.264 decoding capabilities themselves.

> Also I'm not sure they could pay MPEG-LA and still maintain the
> redistribution rights that the MPL gives you. You would need to pay
> the MPEG-LA to distribute any modified version of the Gecko engine.

This is nonsense FUD. Please back up your claims or refrain from making them.

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 17:45 UTC (Tue) by __alex (guest, #38036) [Link] (1 responses)

So they ship with support for ffmpeg but without compiling H.264 into it? It
would make it easier for individuals to sneak around the patent restrictions
but that's exactly the sort of thing Mozilla don't want to enable. Yes they
could do this, and it doesn't seem unreasonable for them to do it. It doesn't
result in them shipping an H.264 enabled product though.

Well I can hardly predict the outcome of any potential legal action against
Mozilla or predict their lawyers own views. However it seems clear that
section 3.6 of the MPL provides you with redistribution rights of modified and
unmodified executables.

If Mozilla is offering me redistribution rights to an H.264 decoder as part of a
derivative of a Covered Work then presumably they would need to pursue a
non-standard license with the MPEG-LA. The standard license and fee
structure does not cover redistribution.

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 18:44 UTC (Tue) by DonDiego (guest, #24141) [Link]

Mozilla could either ship an FFmpeg version adapted to their fears or none at all, whatever they wish.

Mozilla is not giving you redistribution rights to FFmpeg. They cannot because they are not the authors. The FFmpeg project does it. No contract with the MPEG-LA is required to do this, much less some sort of non-standard one.

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 17:16 UTC (Tue) by pboddie (guest, #50784) [Link] (12 responses)

You can of course use FFmpeg and pay the MPEG-LA if you are so inclined. There are companies that do it. The MPEG-LA could not care less which implementation is used.

So that's the argument, is it? Just pay up? There are people who redistribute Mozilla software, you know, and the whole business has significant implications for Free Software implementations of Web technologies. And let us not forget all the companies who would rather have various MPEG-related technologies embedded in Web standards instead of ones which are ostensibly unencumbered.

Mozilla could use a system FFmpeg just like Chrome does. No patent liabilities would be incurred on Mozilla.

Which brings us back to the patent licensing controversy where Google's licence covers Google, naturally, and Google's "evangelists" insist that they're not violating the licensing terms of FFmpeg even according to the spirit of those terms.

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 18:34 UTC (Tue) by DonDiego (guest, #24141) [Link] (11 responses)

> > You can of course use FFmpeg and pay the MPEG-LA if you are so
> > inclined. There are companies that do it. The MPEG-LA could not
> > care less which implementation is used.

> So that's the argument, is it? Just pay up?

I never said anything of the sort. I just had to counter the nonsense claim that Fluendo codecs are in any way more "legal" than those from FFmpeg. Those from FFmpeg are fast free software, Fluendo gives you slow proprietary software. If, for whatever weird reason, company X feels the need to pay the MPEG-LA, they have the liberty to do the wrong thing.

> There are people who redistribute Mozilla software, you know, and the
> whole business has significant implications for Free Software
> implementations of Web technologies.

Spare me the condescending tone please.

There are people who have been writing and distributing multimedia software for more than the last decade. We never had any sort of problem to speak of. Much less than in the area of word processors or web browsers, which nobody is afraid to distribute.

> > Mozilla could use a system FFmpeg just like Chrome does. No patent
> > liabilities would be incurred on Mozilla.

> Which brings us back to the patent licensing controversy where Google's
> licence covers Google, naturally, and Google's "evangelists" insist
> that they're not violating the licensing terms of FFmpeg even
> according to the spirit of those terms.

Google is violating neither the letter nor the spirit of FFmpeg's license. What gives you such weird ideas?

FFmpeg vs. MPEG-LA royalties

Posted Jan 27, 2010 15:02 UTC (Wed) by pboddie (guest, #50784) [Link] (10 responses)

So that's the argument, is it? Just pay up?
I never said anything of the sort. I just had to counter the nonsense claim that Fluendo codecs are in any way more "legal" than those from FFmpeg.

If you want implementations of the MPEG cartel's technologies in Mozilla software, then you more or less have to advocate that the Mozilla organisation pays up: they aren't going to get away with distributing the software as a US-based organisation without doing so. The alternative is that Mozilla doesn't incorporate such technologies.

Yes, it is a disgrace that people can use patents to paint legitimately distributed software as not being "legal" and to undermine the licensing terms of Free Software. The ways to get around this include campaigning for an end to software patents and avoidance of encumbered technologies until the former objective is achieved.

There are people who redistribute Mozilla software, you know, and the whole business has significant implications for Free Software implementations of Web technologies.
Spare me the condescending tone please.

Well, it is about redistribution. High-profile distributors given the choice of either being pursued by an aggressive patent cartel or not distributing an application, all because encumbered technology was embedded in a Free Software application, will not choose the former option regardless of any insistence that the licensing fees are optional.

Google is violating neither the letter nor the spirit of FFmpeg's license. What gives you such weird ideas?

Oh, just some weird Web site called LWN.net...

FFmpeg vs. MPEG-LA royalties

Posted Jan 28, 2010 10:44 UTC (Thu) by DonDiego (guest, #24141) [Link] (9 responses)

> > > So that's the argument, is it? Just pay up?

> > I never said anything of the sort. I just had to counter the nonsense
> > claim that Fluendo codecs are in any way more "legal" than those from
> > FFmpeg.

> If you want implementations of the MPEG cartel's technologies in Mozilla
> software, then you more or less have to advocate that the Mozilla
> organisation pays up: they aren't going to get away with distributing
> the software as a US-based organisation without doing so. The
> alternative is that Mozilla doesn't incorporate such technologies.

Why? Because you say so even though the MPEG-LA licensing terms disagree?

> Yes, it is a disgrace that people can use patents to paint legitimately
> distributed software as not being "legal" and to undermine the licensing
> terms of Free Software. The ways to get around this include campaigning
> for an end to software patents and avoidance of encumbered technologies
> until the former objective is achieved.

Avoidance is not viable when everything except "Hello World!" is patented, which is the situation we are in now...

> > > There are people who redistribute Mozilla software, you know, and
> > > the whole business has significant implications for Free Software
> > > implementations of Web technologies.

> > Spare me the condescending tone please.

> Well, it is about redistribution. High-profile distributors given the
> choice of either being pursued by an aggressive patent cartel or not
> distributing an application, all because encumbered technology was
> embedded in a Free Software application, will not choose the former
> option regardless of any insistence that the licensing fees are optional.

VLC, MPlayer and FFmpeg are not high-profile distributors? It seems that
Then we shall have to switch to low-profile distributors for our free software then.

> > Google is violating neither the letter nor the spirit of FFmpeg's
> > license. What gives you such weird ideas?

> Oh, just some weird Web site called LWN.net...

A patent license from the MPEG-LA does not in any way interact with the LGPL. How would it? If Google has an MPEG-LA license and passes along FFmpeg to you it can only do so under the full terms of the LGPL. And this is what Google is doing: Distributing FFmpeg with all the rights that we passed along to them attached, as specified by the LGPL.

Anything else is impossible. The LGPL clearly states that if obligation X keeps you from distributing without passing along all rights, you may not distribute at all.

Even if they wanted to, neither Google nor the MPEG-LA can restrict the rights we granted you under the LGPL. FFmpeg is LGPLed, period. Not even a decree from the pope himself can change that. If somebody passes along FFmpeg to you, it happens under the terms of the LGPL.

Google can make any side deals they want. If those side deals prevent them from distributing according to the terms of the LGPL, then Google has a problem, but nobody else. Nobody else made a side deal. It doesn't matter if you get your FFmpeg from us directly or from Google. You are not a party to any sort of side deal, thus you are not affected by such side deals.

Note that this is how both FFmpeg and the Software Freedom Law Center see the issue. I never felt there was anything to clarify there, but apparently people are willing to take random quotes from random people as facts just because they are reprinted at lwn.net...

FFmpeg vs. MPEG-LA royalties

Posted Jan 28, 2010 12:36 UTC (Thu) by pboddie (guest, #50784) [Link] (8 responses)

Why? Because you say so even though the MPEG-LA licensing terms disagree?

From the location mentioned previously, I can find a summary of the terms - the real terms being sent out only on request, it would seem - which clearly impose restrictions on the purposes for which encoder/decoder products can be used. So, in fact, even if someone does obtain a licence from the cartel, it isn't clear whether that licence covers the whole spectrum of distribution given that Free Software doesn't distinguish between "personal consumer use" and "providers".

Avoidance is not viable when everything except "Hello World!" is patented, which is the situation we are in now...

It's true that patent claims are ubiquitous, but when the choice is to proliferate known patent-encumbered technologies licensed by an active enforcement organisation, or to seek to use other technologies that are not known to be encumbered and are more easily defended, the responsible path is the latter not the former.

VLC, MPlayer and FFmpeg are not high-profile distributors? It seems that Then we shall have to switch to low-profile distributors for our free software then.

As others have pointed out, the lack of interest in pursuing these projects is no guarantee that they will not be pursued in the future. And not only does the organisation producing a Web browser with 30% or so market share have to worry about this, but they also have to worry about the effects on those who redistribute their software under the much more high-profile brand that they maintain. A set-top box manufacturer selling products based directly on FFmpeg would need to be sniffed out by the cartel's enforcement department, but one selling products with Firefox branding would be very visible indeed.

A patent license from the MPEG-LA does not in any way interact with the LGPL. How would it? If Google has an MPEG-LA license and passes along FFmpeg to you it can only do so under the full terms of the LGPL. And this is what Google is doing: Distributing FFmpeg with all the rights that we passed along to them attached, as specified by the LGPL.

Such a patent licence cannot interact with the LGPL for redistribution to be permissible under those terms. But given what I've read about segmenting the recipients of the software (from the summary, above), it's quite possible that Google claim that Chrome is for "personal consumer use" whilst anyone else who repackages Chrome (as Chromium, for example) is not their responsibility. Thus, the latter group are burdened with dealing with the cartel when they seek to distribute, rather than use, the software, particularly if it turns out that the software is intended for "personal computer use" or for "providers".

You can claim that the patent licence is merely some kind of "insurance". No-one is being forced to buy such insurance, but in practical terms a set of extra obligations are being added to certain recipients of the software. Whether people manage to sneak around section 11 of LGPLv2.1 or not on this basis - and I am reminded of the whole Microsoft/Novell covenant scheme - the lasting impression is that various principles of Free Software have been undermined.

Note that this is how both FFmpeg and the Software Freedom Law Center see the issue. I never felt there was anything to clarify there, but apparently people are willing to take random quotes from random people as facts just because they are reprinted at lwn.net...

Some more "random quotes" for you here. Of course, you can claim that it's merely a case of sour grapes that the GStreamer people are publishing advice from the FSF that conveniently supports their position. Again, we can probably only take Google's word for it that their agreement with the cartel is compatible, but as I note above, even if our trust is well-placed - that Google have not technically done "evil" - the consequences may not be so benign.

FFmpeg vs. MPEG-LA royalties

Posted Jan 28, 2010 15:21 UTC (Thu) by DonDiego (guest, #24141) [Link] (7 responses)

> So, in fact, even if someone does obtain a licence from the cartel, it
> isn't clear whether that licence covers the whole spectrum of
> distribution given that Free Software doesn't distinguish between
> "personal consumer use" and "providers".

And why should we care in the least? If such issues exist, they are between the MPEG-LA and its licensee. None of it affects the general public.

> > VLC, MPlayer and FFmpeg are not high-profile distributors? It seems
> > that Then we shall have to switch to low-profile distributors for
> > our free software then.

> As others have pointed out, the lack of interest in pursuing these
> projects is no guarantee that they will not be pursued in the future.
> And not only does the organisation producing a Web browser with 30% or
> so market share have to worry about this, but they also have to worry
> about the effects on those who redistribute their software under the
> much more high-profile brand that they maintain.

You seem to think that FFmpeg is some sort of fringe software product. The opposite is the case. YouTube uses it, Facebook uses it, it is used in Hollywood postproduction, it is the basis of VLC and most free and a lot of the proprietary transcoding solutions. So it touches most multimedia files that are consumed nowadays at some point of their existence. FFmpeg or VLC are not escaping the attention of the MPEG-LA due to living in some sort of small niche. There are many companies that use FFmpeg and are MPEG-LA licensees at the same time.

> A set-top box manufacturer selling products based directly on FFmpeg
> would need to be sniffed out by the cartel's enforcement department, but
> one selling products with Firefox branding would be very visible indeed.

Trust me, it's not hard to find out whether some program or set-top box uses FFmpeg. It's much easier to verify it uses MPEG-LA technology of some sort. Just perusing the feature list should be enough.

> > A patent license from the MPEG-LA does not in any way interact with
> > the LGPL. How would it? If Google has an MPEG-LA license and passes
> > along FFmpeg to you it can only do so under the full terms of the
> > LGPL. And this is what Google is doing: Distributing FFmpeg with
> > all the rights that we passed along to them attached, as specified
> > by the LGPL.

> Such a patent licence cannot interact with the LGPL for redistribution
> to be permissible under those terms. But given what I've read about
> segmenting the recipients of the software (from the summary, above),
> it's quite possible that Google claim that Chrome is for "personal
> consumer use" whilst anyone else who repackages Chrome (as Chromium,
> for example) is not their responsibility. Thus, the latter group are
> burdened with dealing with the cartel when they seek to distribute,
> rather than use, the software, particularly if it turns out that the
> software is intended for "personal computer use" or for "providers".

So? Such are the sad facts of life. They may also have to deal with the cartel if they get FFmpeg directly from us.

> You can claim that the patent licence is merely some kind of
> "insurance". No-one is being forced to buy such insurance, but in
> practical terms a set of extra obligations are being added to certain
> recipients of the software. Whether people manage to sneak around
> section 11 of LGPLv2.1 or not on this basis - and I am reminded of the
> whole Microsoft/Novell covenant scheme - the lasting impression is that
> various principles of Free Software have been undermined.

I think the main confusion stems from not differentiating between patent licensors and patent licensees. Google is just a licensee. A patent license is not theirs to hand out.

There are indeed free software licenses that have provisions about allowing to use your *own* patents as related to a specific piece of software. However, the LGPL v2.1 is not one of them and Google is not an MPEG-LA licensor.

> > Note that this is how both FFmpeg and the Software Freedom Law Center
> > see the issue. I never felt there was anything to clarify there, but
> > apparently people are willing to take random quotes from random
> > people as facts just because they are reprinted at lwn.net...

> Some more "random quotes" for you here. Of course, you can claim that
> it's merely a case of sour grapes that the GStreamer people are
> publishing advice from the FSF that conveniently supports their position.

This is completely in line with what I am saying. Where do you see anything that does not support my position?

The LGPL forbids extra restrictions, but Google is not placing any extra restrictions on FFmpeg. They are distributing exactly as required by the LGPL. Please point out the exact infringing action and the section of the LGPL it violates.

> Again, we can probably only take Google's word for it that their
> agreement with the cartel is compatible, but as I note above, even if
> our trust is well-placed - that Google have not technically done "evil"
> - the consequences may not be so benign.

Again, what do we care if Google is complying with their MPEG-LA contract? It's entirely between them to resolve any issues they might have.

FFmpeg vs. MPEG-LA royalties

Posted Jan 28, 2010 17:27 UTC (Thu) by pboddie (guest, #50784) [Link] (6 responses)

I think the main confusion stems from not differentiating between patent licensors and patent licensees. Google is just a licensee. A patent license is not theirs to hand out.

Yes, but the "obligations" I mentioned are administered by a third party. Google acknowledges such obligations by obtaining a patent licence - you or I may refuse to do so - and it is this acknowledgement which acts as an admission that recipients of the very code they distribute may also have to obtain a patent licence. This undermines Free Software precisely because it opens the affected works up to potentially limitless claims from anyone who feels that their "intellectual property" is being infringed, and the copyright licence is then no longer the ultimate arbiter of the rights or privileges it describes.

I would have a hard time obtaining a patent licence grant only for myself and then distributing Free Software affected by such a grant to others, but I guess my own standards of behaviour are different from those of others.

This is completely in line with what I am saying. Where do you see anything that does not support my position?

Right at the very end:

If you take a license which doesn't allow others to distribute original or modified versions of libmad practicing the same patent claims as the version you distribute, then you may not distribute at all.

Although this refers to the GPL, the same language supporting this conclusion appears in the LGPL.

FFmpeg vs. MPEG-LA royalties

Posted Jan 28, 2010 20:13 UTC (Thu) by DonDiego (guest, #24141) [Link] (5 responses)

> > I think the main confusion stems from not differentiating between
> > patent licensors and patent licensees. Google is just a licensee.
> > A patent license is not theirs to hand out.

> Yes, but the "obligations" I mentioned are administered by a third
> party. Google acknowledges such obligations by obtaining a patent
> licence - you or I may refuse to do so - and it is this acknowledgement
> which acts as an admission that recipients of the very code they
> distribute may also have to obtain a patent licence. This undermines
> Free Software precisely because it opens the affected works up to
> potentially limitless claims from anyone who feels that their
> "intellectual property" is being infringed, and the copyright licence
> is then no longer the ultimate arbiter of the rights or privileges it
> describes.

There is nothing that requires admission. Do you think we can play pretend and say that the file libavcodec/h264.c in FFmpeg implements "Hello World!" or that a transcoding tool by the filename "ffmpeg" cannot in fact convert from one MPEG format to the other? You cannot solve problems by shutting up and there are no sleeping dogs to wake here.
Not talking about software patents does not make them any less harmful.

I have said it multiple times already, let me repeat it: FFmpeg is not a secret in the industry and not a secret to the MPEG LA.

> > This is completely in line with what I am saying. Where do you see
> > anything that does not support my position?

> Right at the very end:

> "If you take a license which doesn't allow others to distribute original
> or modified versions of libmad practicing the same patent claims as the
> version you distribute, then you may not distribute at all."

Again: no problem for us. Apparently Google is not bound by such an agreement. And if they are, it's their problem. Or the MPEG LA's problem depending on your point of view.

FFmpeg vs. MPEG-LA royalties

Posted Jan 29, 2010 12:07 UTC (Fri) by pboddie (guest, #50784) [Link] (4 responses)

You cut this out in your reply which makes my point clear:

I would have a hard time obtaining a patent licence grant only for myself and then distributing Free Software affected by such a grant to others, but I guess my own standards of behaviour are different from those of others.

In case it isn't obvious to you, I'm putting myself in Google's position here.

Again: no problem for us. Apparently Google is not bound by such an agreement. And if they are, it's their problem.

The fact that this is Google's problem was my point four messages ago when I wrote:

Which brings us back to the patent licensing controversy where Google's licence covers Google, naturally, and Google's "evangelists" insist that they're not violating the licensing terms of FFmpeg even according to the spirit of those terms.

By "the spirit of those terms" take a look at the first quote above. And if the FSF's legal opinion were to stand on this matter, one would have to reassess Google's position beyond the mere spirit of those terms.

Naturally, the participants in the FFmpeg project, which I presume includes yourself, may not need to worry about being served with an injunction. After all, why would the cartel want to prevent the proliferation of software which is, according to them, subject to their licensing programme? It's a nice way of generating business.

Getting such technologies into an open standard is a bonus for the cartel (and a danger for everyone else), once everyone has convinced themselves that there's no risk in providing them to others (where "risk" includes unforeseen budget items related to patent licences that one was assured were not necessary), which was the caution given in the referenced article. It's distasteful to burden Free Software with such liabilities (see first quote, above, again) even if one's advice to people amounts to "it's cool" and "don't worry about it" (selective enforcement of patents is noted in the referenced article, by the way), but to burden open standards with them - noting the background of lobbying that goes on for "non-discriminatory licensing" in open standards (by patent holders) that would open the door for such inclusion - would push the boundaries of tastelessness still further. This is all covered adequately by the referenced article, of course.

FFmpeg vs. MPEG-LA royalties

Posted Jan 31, 2010 10:07 UTC (Sun) by DonDiego (guest, #24141) [Link] (3 responses)

> You cut this out in your reply which makes my point clear:

> > I would have a hard time obtaining a patent licence grant only for
> myself and then distributing Free Software affected by such a grant to
> others, but I guess my own standards of behaviour are different from
> those of others.

> In case it isn't obvious to you, I'm putting myself in Google's position
> here.

So you want them to get a patent license valid for every person on earth? That basically means buying out all those patents. Do you think such a thing would be available at all? At a price Google would be willing and able to pay?

The alternative would be for Google to not get a patent license and exclude itself from using multimedia technologies. That's not an option. And please don't start the Theora fairy tales again, it's not an alternative.

> Which brings us back to the patent licensing controversy where Google's
> licence covers Google, naturally, and Google's "evangelists" insist that
> they're not violating the licensing terms of FFmpeg even according to
> the spirit of those terms.

>By "the spirit of those terms" take a look at the first quote above. And
> if the FSF's legal opinion were to stand on this matter, one would have
> to reassess Google's position beyond the mere spirit of those terms.

What do you call the "FSF's legal opinion" on the matter? I know for sure that Eben Moglen agrees with us (FFmpeg) that patent side deals do not have any bearing at all on LGPLv2.1-licensed code, such as FFmpeg. The Software Freedom Law Center works for FFmpeg, BTW.

> Naturally, the participants in the FFmpeg project, which I presume
> includes yourself,

Correct. My name is Diego Biurrun and I work on FFmpeg.

> may not need to worry about being served with an injunction. After all,
> why would the cartel want to prevent the proliferation of software which
> is, according to them, subject to their licensing programme? It's a nice
> way of generating business.

Your bitterness does FFmpeg a disservice. We're a big part of the free software computing stack, thus making Desktop Linux viable. In this day and age, computing without multimedia support is unthinkable.

FFmpeg vs. MPEG-LA royalties

Posted Feb 4, 2010 13:16 UTC (Thu) by pboddie (guest, #50784) [Link] (2 responses)

So you want them to get a patent license valid for every person on earth? That basically means buying out all those patents. Do you think such a thing would be available at all? At a price Google would be willing and able to pay?

It doesn't mean buying those patents at all, but merely licensing them, which I'm sure has happened on a large scale before. But if Google's licence means that only they are practising the associated patent claims when distributing the code, and that recipients are not able to do so without a trip via the cartel's toll booth, then I think this contradicts the advice given by the FSF. Sure, you can claim that people aren't obliged to pay up to the cartel, but that's like claiming people don't have to pay their road tax or their television licence.

What do you call the "FSF's legal opinion" on the matter?

Well, I referenced the advice given by the FSF to the GStreamer project above and in a previous comment. If that's not their legal opinion then maybe you ought to tell the GStreamer people.

Your bitterness does FFmpeg a disservice. We're a big part of the free software computing stack, thus making Desktop Linux viable. In this day and age, computing without multimedia support is unthinkable.

I'm not bitter about FFmpeg, although to claim such a thing makes for a great distraction from the points being made in the original article(s). I'm merely pointing out that there are valid reasons for considering other multimedia technologies that don't appear on the MPEG cartel's pricing menu.

(And really, I don't have that much to say about Theora, so maybe you're grouping me together with a bunch of other people. Now something like Dirac is interesting because it's definitely a "professional" format and one whose patent infringement status has been thoroughly investigated by an organisation who should be able to comment on such matters with some certainty. I'm sure that some people might like to brush such formats aside and insist that everyone should get with the MPEG programme - in which case I'd really have suspicions about those people if their arguments were not limited to "it's what people on Windows expect".)

FFmpeg vs. MPEG-LA royalties

Posted Feb 5, 2010 10:53 UTC (Fri) by DonDiego (guest, #24141) [Link] (1 responses)

> Sure, you can claim that people aren't obliged to pay up to the cartel, but that's like claiming people don't have to pay their road tax or their television licence.

This is a good comparison in fact. Nobody would think about banning cars and television worldwide just because in some parts of the world you have to pay a tax to use them.

FFmpeg vs. MPEG-LA royalties

Posted Feb 5, 2010 14:18 UTC (Fri) by pboddie (guest, #50784) [Link]

Sure, you can claim that people aren't obliged to pay up to the cartel, but that's like claiming people don't have to pay their road tax or their television licence.
This is a good comparison in fact. Nobody would think about banning cars and television worldwide just because in some parts of the world you have to pay a tax to use them.

Right, but I'm not advocating a "ban". I'm saying that by introducing a de-facto standard based on known-encumbered technologies, Google and friends are setting people up for such taxation. And I think that there are those of us that grudgingly accept things like genuine taxes and regulations because there is some kind of pretense of accountability and common sense behind their imposition. So, although some Free Software project may let you, for example, operate some kind of radio station, one has to grudgingly accept that for various reasons, there may be other restrictions from place to place that curtails the practical exercise of the freedoms/rights/privileges described in the software licence.

Where patents are concerned, however, there are those of us who do not consider them to be legitimate, not least because the system that upholds patents is not accountable - it's practically set up to enrich itself as its primary objective. Now, when such instruments collide with Free Software licensing, I would certainly wish to disregard them entirely and insist that they impose no limitations on the freedoms/rights/privileges described in the software licence. However, in practice, patents are used to undermine the usage and distribution of Free Software.

By licensing the MPEG patents for themselves (contrary to advice which apparently casts this strategy in a dubious light), Google acknowledges an obligation which resides beyond the software licence; through their market position, they proliferate this obligation, and then "to compete with Windows" or "to provide a proper experience" everyone becomes exposed to this obligation; since this obligation may impose unreasonable burdens on some parties (it may not be affordable for them to license the patents, for example, or maybe the cartel tells someone that they live in a "bad" country), it thereby excludes people from exchanging Free Software, thus dividing the community between the rich (with the privilege of using and distributing Free Software) and everyone else.

Google's actions are more like a strong dose of car advocacy, or even an act to mandate car ownership, when having a car at the very least probably doesn't make sense for many people, and it might even be an unwanted financial burden for others. All I and others are trying to do is to encourage more sustainable alternatives.

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 17:22 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (21 responses)

If Mozilla used the same method as Chrome no mainstream distribution would
be able to include it at all. Using ffmpeg directly is not a option for
them.

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 17:35 UTC (Tue) by DonDiego (guest, #24141) [Link] (20 responses)

This is complete nonsense. By my last count all mainstream distributions except for Fedora distribute H.264 decoders.

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 17:47 UTC (Tue) by __alex (guest, #38036) [Link] (19 responses)

Debian and Ubuntu don't.

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 18:36 UTC (Tue) by DonDiego (guest, #24141) [Link] (18 responses)

This is false, please make your homework before spouting nonsense. Both Ubuntu and Debian ship FFmpeg with H.264 decoding capabilities enabled.

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 18:54 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Is it enabled out of the box or some non supported repository? There is a
big difference You seem to have left out SUSE as well

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 20:43 UTC (Tue) by DonDiego (guest, #24141) [Link]

> Is it enabled out of the box or some non supported repository?
> There is a big difference.

It is enabled out of the box.

> You seem to have left out SUSE as well

openSUSE does not include FFmpeg and lists it on

http://en.opensuse.org/Application_black_list

but they appear to ship VLC. At least

http://software.opensuse.org/search

reveals VLC packages hosted on opensuse.org. No idea what those packages contain and how they are configured. If somebody can enlighten us, I'm all ears.

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 20:52 UTC (Tue) by __alex (guest, #38036) [Link] (2 responses)

My apologies you are right. Debian merely disables the H.264 encoder not the
decoder.

http://git.debian.org/?p=pkg-
multimedia/ffmpeg.git;a=blob_plain;f=debian/README.Debian;hb=9f02f559
4fe25fdda9e409f987841b3be2272db4

>Currently the following video encoders are disabled in the ffmpeg package:
>H263, H264, MPEG2 video, MPEG4 and MS-MPEG4. No *decoders* are
>disabled in any the ffmpeg package!

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 21:24 UTC (Tue) by DonDiego (guest, #24141) [Link] (1 responses)

> My apologies you are right. Debian merely disables the H.264
> encoder not the decoder.

BTW, this is completely irrational. The MPEG-LA charges the same amount for encoders as it does for decoders.

FFmpeg vs. MPEG-LA royalties

Posted Jan 27, 2010 0:54 UTC (Wed) by cortana (subscriber, #24596) [Link]

Debian's policy is to ignore patents until there is evidence that patent holders are forcing people to pay up.

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 21:32 UTC (Tue) by roc (subscriber, #30627) [Link] (12 responses)

I guess they're not important enough to be sued by MPEG-LA.

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 21:50 UTC (Tue) by DonDiego (guest, #24141) [Link] (11 responses)

As is Mozilla.

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 22:03 UTC (Tue) by roc (subscriber, #30627) [Link] (10 responses)

We probably have ten times as many users as Ubuntu and Debian. That's not a bet we would be comfortable taking.

Plus, living at the ongoing mercy of the MPEG-LA just isn't a good idea. Blizzard's latest blog post recaps the efforts of patent holders to squeeze out the last drop of royalties out media patents near the end of their life:
http://www.0xdeadbeef.com/weblog/2010/01/html5-video-and-...

And aside from all that, there are huge licensing problems for content providers that don't go away even if we think we're somehow immune.

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 22:16 UTC (Tue) by DonDiego (guest, #24141) [Link] (9 responses)

VLC has many users as well (and they include FFmpeg), nobody ever bothered them. You should read the MPEG-LA licensing terms. They only talk of fees per unit *sold*. Mozilla does not sell Firefox. Neither does FFmpeg sell H.264 decoders. There is no problem for either of us.

FFmpeg vs. MPEG-LA royalties

Posted Jan 27, 2010 1:28 UTC (Wed) by roc (subscriber, #30627) [Link] (8 responses)

I don't know why MPEG-LA hasn't sued VLC, but selective enforcement is dangerous precisely because it's opaque and unpredictable. And Firefox still has a lot more users, more usage, and a much higher profile than VLC.

It's highly questionable that the MPEG-LA considers Mozilla to already have a patent license just because we don't "sell" Firefox. You don't get a license just by meeting the terms, you have to explicitly enter into an agreement. So I suggest you prove your point by obtaining a free license from the MPEG-LA to distribute a large number of units of a product with a price of zero. Let me know when you've got that.

Beyond that, what if someone sells a product that includes Firefox? What if the MPEG-LA revises their license terms? What if the corporations that run the MPEG-LA just decide they don't like us? You'd have us bet everything on the long-term goodwill of the MPEG-LA. That would be extremely foolish.

FFmpeg vs. MPEG-LA royalties

Posted Jan 27, 2010 11:58 UTC (Wed) by DonDiego (guest, #24141) [Link] (7 responses)

> And Firefox still has a lot more users, more usage, and a much higher
> profile than VLC.

Yes, but the MPEG-LA knows about VLC and FFmpeg and they have never moved a finger. Why would they? To skim off all the money we have made so far, i.e. nothing, and get lots of bad press in return?

> It's highly questionable that the MPEG-LA considers Mozilla to already
> have a patent license just because we don't "sell" Firefox. You don't
> get a license just by meeting the terms, you have to explicitly enter
> into an agreement. So I suggest you prove your point by obtaining a free
> license from the MPEG-LA to distribute a large number of units of a
> product with a price of zero. Let me know when you've got that.

Go look at the terms. You don't need a license from the MPEG-LA (and neither does FFmpeg) because you don't qualify for requiring one:

http://www.mpegla.com/main/programs/AVC/Pages/Agreement.aspx

> Beyond that, what if someone sells a product that includes Firefox?

Then they have a problem to deal with depending on who they are, how much money they have and in which country they reside? But why does that concern you? Software patents on multimedia technology are in no way special. You did not stop shipping plugin support in Firefox when Microsoft got sued. There is a multitude of other software patents that apply to Mozilla software. Why is this case in any way special?

> What if the MPEG-LA revises their license terms?

The new licensing terms should come out any moment now since they were slated to be replaced in January. I'm just as curious as you are.

> What if the corporations that run the MPEG-LA just decide they don't
> like us? You'd have us bet everything on the long-term goodwill of
> the MPEG-LA. That would be extremely foolish.

They sue you and get no money out of you. Then you have to stop US downloads for Firefox or offer a crippled version instead. Their loss. However, it will make the software patent nonsense newsworthy and fuel the discussion.

What exactly are you afraid of? I was never afraid that somebody might make me pay a billion bucks. I never had them and never will. So what exactly is it that you are fearing?

I can imagine hilarious scenarios of course: airport controls for software patent contraband :-)

FFmpeg vs. MPEG-LA royalties

Posted Jan 27, 2010 23:55 UTC (Wed) by roc (subscriber, #30627) [Link] (4 responses)

> Yes, but the MPEG-LA knows about VLC and FFmpeg and they have never moved
> a finger. Why would they?

OK, VLC and FFmpeg are not interesting because they have no money. But as soon as anyone with money wants to distribute VLC or FFmpeg, then they could be a target.

> Go look at the terms. You don't need a license from the MPEG-LA (and
> neither does FFmpeg) because you don't qualify for requiring one:
> http://www.mpegla.com/main/programs/AVC/Pages/Agreement.aspx

I don't see anything in there which says we wouldn't require one. Can you quote specific text that implies certain distributors of codecs don't require a license?

Typically when a patent holder makes a patent available royalty-free they don't say that "you don't require a license" ... that doesn't make much sense, since it's axiomatic that everyone who infringes a patent "requires a license". Instead they make a blanket grant of a free license to everyone, or grant something equivalent like a covenant to not sue. For example, see
http://www.microsoft.com/Interop/osp/default.mspx

> You did not stop shipping plugin support in Firefox when Microsoft got
> sued. There is a multitude of other software patents that apply to
> Mozilla software. Why is this case in any way special?

Patents that are essential for implementing a Web standard (as the MPEG-LA patents threaten to be), are much more of a problem than patents like the Eolas patent that can be worked around or avoided in particular browser implementations.

Also, "stop shipping plugin support" was never been an option since it would not leave us with a viable browser. And yes, if shipping an H.264 codec is ever a necessity for being a viable browser, we'll try to find a way to ship one somehow. Compromise is better than irrelevance.

> They sue you and get no money out of you.

They'd get money. http://blog.lizardwrangler.com/2009/11/19/state-of-mozill...

> Then you have to stop US
> downloads for Firefox or offer a crippled version instead. Their loss.

We'd be out millions of dollars and back where we started ... actually, even worse, since we would have to return to our free-codec efforts having lost time and credibility.

And remember, this entire discussion ignores the issues for content providers. Even if H.264 decoding was entirely unencumbered, having to pay MPEG-LA taxes to publish video on the Web is unacceptable.

FFmpeg vs. MPEG-LA royalties

Posted Jan 28, 2010 12:55 UTC (Thu) by DonDiego (guest, #24141) [Link] (3 responses)

> > Yes, but the MPEG-LA knows about VLC and FFmpeg and they have never
> > moved a finger. Why would they?

> OK, VLC and FFmpeg are not interesting because they have no money. But
> as soon as anyone with money wants to distribute VLC or FFmpeg, then
> they could be a target.

I think the fundamental problem is that you are the sort of person that wants insurance policies and buys them, while I am not.

> > Go look at the terms. You don't need a license from the MPEG-LA (and
> > neither does FFmpeg) because you don't qualify for requiring one:
> > http://www.mpegla.com/main/programs/AVC/Pages/Agreement.aspx

> I don't see anything in there which says we wouldn't require one. Can
> you quote specific text that implies certain distributors of codecs
> don't require a license?

There is nothing in there which says you require one.

Scenarios for which you require a license are listed and they do not apply to you, isn't that enough?

> > Then you have to stop US downloads for Firefox or offer a crippled
> > version instead. Their loss.

> We'd be out millions of dollars and back where we started ... actually,
> even worse, since we would have to return to our free-codec efforts
> having lost time and credibility.

There are two points I think you are not assessing correctly:

1) H.264 video + AAC audio + MP4 container as industry standard

Multimedia used to be completely fragmented with a multitude of competing and incompatible standards fighting for market share. Now we have a standard for lossy video and audio and it is being adopted across the board. It is not just used for web video, it is used on Bluray disks, it is used in cinemas and in Hollywood production, it is used by the ripping scene, it is used by video sharing sitesa already.

All these places now have the encoding infrastructure in place and no interest in changing or exchanging it.

2) viable alternatives

Let's face it, Vorbis is an excellent audio codec, but Theora is not a state of the art video codec and Ogg is a horrible container. Theora still has room for improvement of course, but it will never close the gap to more modern video codecs. Comparatively little effort is being spent on it and it must fight with one hand behind its back due to avoiding anything that might be patented. Even without such a handicap Theora will never be able to match the quality standards of more modern video codecs.

Keep in mind that web video is not YouTube and the unspeakable quality it offers nowadays. Think a few years into the future and web video will all be high-definition content.

> And remember, this entire discussion ignores the issues for content
> providers. Even if H.264 decoding was entirely unencumbered, having
> to pay MPEG-LA taxes to publish video on the Web is unacceptable.

This reminds me of something: Mozilla made a study about possible submarine patents on Theora. What did you find? Why was the study never published? If you found nothing, there surely wouldn't be a reason to keep mum about it, don't you agree?

FFmpeg vs. MPEG-LA royalties

Posted Jan 28, 2010 20:29 UTC (Thu) by roc (subscriber, #30627) [Link] (1 responses)

> I think the fundamental problem is that you are the sort of person that
> wants insurance policies and buys them, while I am not.

Maybe that is because we have built up a large organization that serves hundreds of millions of users, and you have not. Or maybe it's because we're used to seeing and fighting threats to the open Web.

> Scenarios for which you require a license are listed and they do not
> apply to you, isn't that enough?

No. The document lists scenarios for which a license is offered and is silent about other scenarios. More about this in the other part of the thread.

> There are two points I think you are not assessing correctly:

How great H.264 is is not the issue here. The licensing is the problem.

> This reminds me of something: Mozilla made a study about possible
> submarine patents on Theora. What did you find? Why was the study never
> published? If you found nothing, there surely wouldn't be a reason to
> keep mum about it, don't you agree?

For reasons I honestly don't understand, our lawyers tell us not to talk about it. All I can do is point to our actions in distributing Theora.

FFmpeg vs. MPEG-LA royalties

Posted Jan 31, 2010 11:37 UTC (Sun) by DonDiego (guest, #24141) [Link]

> > I think the fundamental problem is that you are the sort of person
> > that wants insurance policies and buys them, while I am not.

> Maybe that is because we have built up a large organization that serves
> hundreds of millions of users, and you have not.

Oh, VLC alone has over a hundred million downloads, add to that all other multimedia software based on FFmpeg. Then think of YouTube and Facebook, which are probably the largest users of FFmpeg and how many users they have.

FFmpeg is less visible than Firefox, but by no means do I believe it has less users. I'll turn your argument around:

If tomorrow all copies of Firefox deleted themselves, most people will curse and fire up the alternative browsers that are likely already installed on their machines.

If tomorrow all copies of the FFmpeg libraries delete themselves, a lot of things will stop working where no viable replacement is available or only available for a considerable amount of money.

Free software multimedia will be reduced to dealing with the <5% of fringe content for which alternative libraries exist. Large content providers will have to reengineer their backend infrastructure.

> Or maybe it's because we're used to seeing
> and fighting threats to the open Web.

Maybe we act the way we do because we have been treading the patent-filled lands of multimedia for a decade or more. You are the newbies here, not us.

> > There are two points I think you are not assessing correctly:

> How great H.264 is is not the issue here. The licensing is the problem.

I'm not particularly fond of H.264 myself. It's far too complex a standard and the quality to decoding complexity tradeoff is forcing me to upgrade my vintage hardware.

However, we finally have an open standard for lossy video encoding. This is great news in the world of multimedia.

> > This reminds me of something: Mozilla made a study about possible
> > submarine patents on Theora. What did you find? Why was the study
> > never published? If you found nothing, there surely wouldn't be a
> > reason to keep mum about it, don't you agree?

> For reasons I honestly don't understand, our lawyers tell us not to talk
> about it. All I can do is point to our actions in distributing Theora.

This confirms the rumors that there are submarines lurking in the Theora ocean. Nothing else can explain your actions and why Nokia (who supposedly holds patents that Theora infringes) is afraid of touching Theora.

FFmpeg vs. MPEG-LA royalties

Posted Feb 1, 2010 14:29 UTC (Mon) by nye (subscriber, #51576) [Link]

>1) H.264 video + AAC audio + MP4 container as industry standard

Just to take this discussion further off track:

I think it's interesting to look at the technologies used as standard by pirate groups. Since they are already infringing copyrights, these people tend to have very little interest in any legal or philosophical issues attached to any particular technology, and gravitate towards the technically superior solution.

For HD, pirated video is almost exclusively H264, plus AAC or Vorbis (no clear winner here), in a Matroska container. For whatever reason, nobody seems willing to use MP4 unless they have to for compatibility with hardware (and perhaps software) produced by companies with a vested interest in that container.

Not especially relevant, but I found it interesting...

FFmpeg vs. MPEG-LA royalties

Posted Jan 28, 2010 8:15 UTC (Thu) by cmccabe (guest, #60281) [Link] (1 responses)

> > What if the corporations that run the MPEG-LA just decide they don't
> > like us? You'd have us bet everything on the long-term goodwill of
> > the MPEG-LA. That would be extremely foolish.

> They sue you and get no money out of you. Then you have to stop US
> downloads for Firefox or offer a crippled version instead. Their loss.

Mozilla made $78 million in revenue in fiscal 2008. That's not "no money." They don't want to encourage users to adopt a patented codec that will end up costing them. Can you really blame them?

Anyway, IE still has a huge honking market share and probably won't implement any kind of HTML5 video. I wonder if someone will write a plugin to do it. I'm not familiar with how the plugin architecture works so I don't even know if such a plugin would be feasible.

> I can imagine hilarious scenarios of course: airport controls for software
> patent contraband :-)

I can imagine some kind of futuristic tablet computing device where installing unauthorized software was impossible. All software would have to be approved by some centralized authority, who would be an easy target for patent litigation. In that case, distributing free software that used patented codecs could easily become impossible.

Of course, that could never happen. Pure science fiction :)

FFmpeg vs. MPEG-LA royalties

Posted Jan 28, 2010 10:52 UTC (Thu) by DonDiego (guest, #24141) [Link]

> I can imagine hilarious scenarios of course: airport controls for software
> patent contraband :-)

> I can imagine some kind of futuristic tablet computing device where
> installing unauthorized software was impossible. All software would have
> to be approved by some centralized authority, who would be an easy target
> for patent litigation. In that case, distributing free software that used
> patented codecs could easily become impossible.

Apple ships an H.264 decoder with that device already, patent license and all. So no problem from that side...

FFmpeg vs. MPEG-LA royalties

Posted Jan 26, 2010 21:33 UTC (Tue) by roc (subscriber, #30627) [Link] (1 responses)

Chrome doesn't use a system FFmpeg. They ship their own FFmpeg, which Google has paid MPEG-LA to obtain a license for.

FFmpeg vs. MPEG-LA royalties

Posted Jan 31, 2010 11:46 UTC (Sun) by DonDiego (guest, #24141) [Link]

I'll have to note here that Google likely had an MPEG LA license anyway, same as all the other big players. Since they calculate with the cost of that license to operate, browser or not, no extra costs are incurred if they ship H.264 support. That's one of the reasons why MPEG LA patent licenses do not make them break a sweat.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 26, 2010 21:35 UTC (Tue) by roc (subscriber, #30627) [Link] (1 responses)

How would using FFmpeg help us access system H.264 codecs on Windows (Directshow) and Mac (Quicktime)?

system H.264 codecs

Posted Jan 26, 2010 22:50 UTC (Tue) by DonDiego (guest, #24141) [Link]

FFmpeg can provide system H.264 codecs on Windows (ffdshow) and Mac (Perian).

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 26, 2010 12:41 UTC (Tue) by __alex (guest, #38036) [Link] (75 responses)

"It's too hard." is a scapegoat and a hole that developers who simply don't
want to do something often go and hide in. You are exploiting your position
as an expert in the community to justify your own bias to people who aren't
not intimately involved in the details.

If Mozilla want to play the long game and pursue a Free Software compatible
solution that's a laudable goal but they shouldn't hide behind qualitative and
short-termist argument like how hard implementation and maintenance will
be at the same time.

Has anyone even attempted to integrate gstreamer, ffmpeg, directshow or
quicktime into Gecko? I've not seen any developer forks with that functionality
so I suppose not.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 26, 2010 16:24 UTC (Tue) by TRS-80 (guest, #1804) [Link]

Has anyone even attempted to integrate gstreamer, ffmpeg, directshow or quicktime into Gecko?
Songibrd uses GStreamer on all platforms, and they spent quite a bit of time and money to make it work well on Win32/OS X.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 26, 2010 21:30 UTC (Tue) by Trelane (subscriber, #56877) [Link] (72 responses)

Some links relevant to the discussion:
http://robert.accettura.com/blog/2010/01/21/youtube-html5...
http://robert.accettura.com/blog/2009/07/06/debating-ogg-...
http://weblogs.mozillazine.org/roc/archives/2009/06/direc...

Of particular interest to you is Mozilla Bug 422540,
https://bugzilla.mozilla.org/show_bug.cgi?id=422540
"GStreamer backend for HTML5 video element" which seems well underway.

The gstreamer backend has been a part of the plan from the beginning, see Mozilla bug tagged "video" https://bugzilla.mozilla.org/show_bug.cgi?id=video "Implement WHATWG Video spec"\

So everyone can quit with the grandstanding, mozilla-bashing, and drama queening and get back to work. Synopsis: Using platform-specific media systems will not work, at least because of DirectShow (see the mozillazine link above). To fill the gap, Moz is integrating gstreamer support into Gecko. They can't provide MPEG-LA licensing to downstream users, so they used a patent-free codec for an initial implementation and hoped others would go along with it. In addition, they have been working on gstreamer, in order to support additional codecs. If you want to write an h.264 deocder, then, you can do so and write it for the gstreamer backend. Meanwhile, with GStreamer in place, Dirac and other future Free codecs can also be implemented without as much necessary work.

gstreamer decoders

Posted Jan 26, 2010 22:10 UTC (Tue) by DonDiego (guest, #24141) [Link] (71 responses)

> If you want to write an h.264 deocder, then, you can do so and write
> it for the gstreamer backend.

gstreamer already uses FFmpeg to decode almost everything.

gstreamer decoders

Posted Jan 26, 2010 22:12 UTC (Tue) by Trelane (subscriber, #56877) [Link] (70 responses)

So? Using GStreamer != using FFMPeg.

You may use FFMPeg in the GStreamer system, but it's hardly synonymous.

gstreamer decoders

Posted Jan 26, 2010 22:46 UTC (Tue) by DonDiego (guest, #24141) [Link] (69 responses)

I just wanted to clarify that gstreamer uses FFmpeg to decode most videos already and that there is no point in writing an H.264 decoder for gstreamer since such a thing already exists and is in widespread use. People are constantly confused about this.

Fluendo also offers an alternative H.264 decoder that hooks into gstreamer. In exchange for money they take away your freedom. It's tasteless.

gstreamer decoders

Posted Jan 26, 2010 22:54 UTC (Tue) by Trelane (subscriber, #56877) [Link] (47 responses)

"there is no point in writing an H.264 decoder for gstreamer since such a thing already exists and is in widespread use"

Unless you need a patent license, in which case you're going to want to use Fluendo's codec.

"Fluendo also offers an alternative H.264 decoder that hooks into gstreamer. In exchange for money they take away your freedom."

Umm, jein. Unlike FFmpeg, they *have* a patent license. So, you know, you don't get sued. With software patents, you're screwed either way. Pretty sure Fluendo *can't* ship a Free codec; it's almost certainly in the MPEG-LA license terms. I've asked the MPEG-LA to clarify their position towards Free and open source codecs for their FAQ; we'll see if anything comes of it. So, really, either way your freedom is gone.

Shipping known-patented code without a license is tasteless IMHO. Same as selling your friend stolen goods.

gstreamer decoders

Posted Jan 27, 2010 11:36 UTC (Wed) by DonDiego (guest, #24141) [Link] (46 responses)

> > there is no point in writing an H.264 decoder for gstreamer since such
> > a thing already exists and is in widespread use

> Unless you need a patent license, in which case you're going to want to
> use Fluendo's codec.

See below for details about patent licenses..

Note that Fluendo contacted us (FFmpeg) some time ago to negotiate a patent exception for FFmpeg's H.264 decoder. The request was declined. I think they then licensed some proprietary H.264 decoder from somewhere. Writing one from scratch is an entirely nontrivial task.

What Fluendo offers you is common and garden-variety proprietary software. If this is compatible with your moral standards, fine. But presenting them as the champions of software freedoms is - IMNSHO - tasteless.

> > Fluendo also offers an alternative H.264 decoder that hooks into
> > gstreamer. In exchange for money they take away your freedom."

> Umm, jein. Unlike FFmpeg, they *have* a patent license. So, you know,
> you don't get sued. With software patents, you're screwed either way.
> Pretty sure Fluendo *can't* ship a Free codec; it's almost certainly
> in the MPEG-LA license terms.
> Shipping known-patented code without a license is tasteless IMHO.
> Same as selling your friend stolen goods.

What makes you think that? Please get a clue before making such broad and insulting claims. Patent licenses are completely orthogonal to software licenses and not tied to any software implementation. In fact, you can get them separately and there are companies that do exactly that. The two most prominent users of FFmpeg are YouTube and Facebook, both are MPEG-LA licensees. Also, why would the MPEG-LA care which software you run after they have received their money?

All the claims about a license being required in order to be "legally" allowed to use or even distribute H.264 decoding software are completely made up. Check the MPEG-LA licensing terms yourself:

http://www.mpegla.com/main/programs/AVC/Pages/Agreement.aspx

They only speak of selling products, not of using or distributing software.

I don't need a license from the MPEG-LA, neither does FFmpeg or VLC and neither do you or 99.9% of the world's population. The problem only exists for companies that deal in MPEG technologies, have deep enough pockets and reside in certain parts of the world where the legal system is antisocial. Now I'm very sorry that people find themselves in such a situation and I have personally fought against the problem spreading. But holding the rest of the world hostage to account for the situation of a chosen few is not helpful.

> I've asked the MPEG-LA to clarify their position towards Free and open
> source codecs for their FAQ; we'll see if anything comes of it.
> So, really, either way your freedom is gone.

Send me an email if/when you see results. Or have our beloved editor in chief post it as a news story. It will surely be newsworthy.

gstreamer decoders

Posted Jan 28, 2010 0:00 UTC (Thu) by roc (subscriber, #30627) [Link] (2 responses)

> All the claims about a license being required in order to be "legally"
> allowed to use or even distribute H.264 decoding software are completely
> made up. Check the MPEG-LA licensing terms yourself:
> http://www.mpegla.com/main/programs/AVC/Pages/Agreement.aspx
> They only speak of selling products, not of using or distributing software.

Ah, this seems to be the source of your confusion.

MPEG-LA can sue anyone who's practicing the claims of their patents who doesn't have a license. If they don't offer a license that covers your usage, that's too bad for you.

gstreamer decoders

Posted Jan 28, 2010 11:10 UTC (Thu) by DonDiego (guest, #24141) [Link] (1 responses)

> > All the claims about a license being required in order to be "legally"
> > allowed to use or even distribute H.264 decoding software are
> > completely made up. Check the MPEG-LA licensing terms yourself:
> > http://www.mpegla.com/main/programs/AVC/Pages/Agreement.aspx
> > They only speak of selling products, not of using or distributing
> > software.

> Ah, this seems to be the source of your confusion.

I'm not confused about how patent licensing works.

> MPEG-LA can sue anyone who's practicing the claims of their patents who
> doesn't have a license.

Yes, they *can*, but they do not have to. Also, they can just flatly deny you a license. Patent licensing is not compulsory. I know all that.

But the MPEG-LA is a patent pool. It's designed to maximize revenue for the parties forming the patent pool and simplify the access to patents for licensees. Denying you a license is not in their best interest, nor is suing every single entity that distributes technology that may infringe on their patents.

> If they don't offer a license that covers your
> usage, that's too bad for you.

We're going in circles here. Why are you so hell-bent on getting a license? The MPEG-LA states that licenses are only necessary in certain circumstances. When I point out that these circumstances don't apply to you, you sense impending doom instead of being happy...

gstreamer decoders

Posted Jan 28, 2010 20:49 UTC (Thu) by roc (subscriber, #30627) [Link]

> Denying you a license is not in their best interest, nor is suing every
> single entity that distributes technology that may infringe on their
> patents.

Denying us a free license is certainly in their best interest. They could extract millions of dollars a year in revenue from us. Ditto for every other entity with significant income.

> The MPEG-LA states that licenses are only necessary in certain
> circumstances.

I haven't found that stated anywhere. The MPEG-LA offers a license that covers certain circumstances. For all other circumstances, it is silent.

Maybe you're arguing that the MPEG-LA's silence about those other circumstances indicates that they don't care and would not choose to sue over those cases? That is extremely doubtful; it would be a most unwise business practice to forgo licensing for unforeseen product categories. And I already explained why relying on the beneficence of the MPEG-LA is not desirable.

My guess is that the MPEG-LA has simply not considered the possibility that an organization which could afford to pay significant licensing revenue would give away for free software that includes an H.264 codec.

Anyway, you can settle this. Go ahead and ask the MPEG-LA to declare that free distribution of FFmpeg does not require a patent license. If you get that in writing, that would be really interesting.

gstreamer decoders

Posted Jan 28, 2010 22:56 UTC (Thu) by Trelane (subscriber, #56877) [Link] (42 responses)

Dunno your email, so here's their response. First, my email:
Sent: Tuesday, January 26, 2010 5:51 PM
To: QandA
Subject: Free and Open Source implementations of MPEG-4 Visual?
Hello.
I read through the FAQ and can't find out if Free and Open Source
developers and products need to license the MPEG-LA patents for
MPEG-4 Visual. It was alleged (http://lwn.net/Articles/370985/)
in a comment that royalties are only necessary for products sold,
not for free products. Is this correct? Could you please comment
on the licensing options for Free (e.g. GPL) and open source
implementations of MPEG-4 Visual, specifically h.264? What about
downstream users/developers/distributors of Free and open source
software?
I'll post your reply to the above comment list when I've received it.
Thank you very much,

==========REPLY==========
Subject: RE: Free and Open Source implementations of MPEG-4 Visual?
Dear Joseph,
Thank you for your message. We appreciate you contacting MPEG LA
regarding our Licenses and I will be happy to assist you.

By way of background, I would like to point out that the Licenses
offered by MPEG LA are provided as a convenience and an alternative to
negotiating direct licenses with many individual patent owners. While
MPEG LA offers the Licenses to the marketplace, it is the patent owners
participating in our Licenses (not MPEG LA) who establish the License
terms and royalty rates.

Our MPEG-4 Visual Patent Portfolio License includes 29 patent owners
contributing more than 900 patents that are essential for use of the
MPEG-4 Visual (Part 2) Standard. Our AVC Patent Portfolio License
includes 25 patent owners contributing more than 1,000 patents that are
essential for use of AVC/H.264 Standard ("MPEG-4 Part 10").

Under the Licenses, coverage is provided and rights are granted for (a)
manufacturers to make and sell MPEG-4 Visual/AVC Products and (b) for
such MPEG-4 Visual/AVC Products to be used to deliver MPEG-4 Visual/AVC
Video content. The Licenses were set up this way so as to apportion the
royalty at points in the product/service chain where value is received,
and also to not place the full royalty burden on one party in the chain
(e.g., an encoder maker).

In response to your specific question, under the Licenses royalties are
paid on all MPEG-4 Visual/AVC products of like functionality, and the
Licenses do not make any distinction for products offered for free
(whether open source or otherwise). But, I do note that the Licenses
addresses this issue by including annual minimum thresholds below which
no royalties are payable in order to encourage adoption and minimize the
impact on lower volume users. In addition, the Licenses also include
maximum annual royalty caps to provide more cost predictability for
larger volume users.

I would also like to mention that while our Licenses are not concluded
by End Users, anyone in the product chain has liability if an end
product is unlicensed. Therefore, a royalty paid for an end product by
the end product supplier would render the product licensed in the hands
of the End User, but where a royalty has not been paid, such a product
remains unlicensed and any downstream users/distributors would have
liability.

Therefore, we suggest that all End Users deal with products only from
licensed suppliers. In that regard, we maintain lists of Licensees in
Good Standing to each of our Licenses at http://www.mpegla.com.
I hope this explanation is helpful. If you have further questions or
would like additional information, please feel free to contact me
directly.

Best regards,

Allen

Allen Harkness
Director, Global Licensing
MPEG LA
5425 Wisconsin Avenue
Suite 801
Chevy Chase, MD 20815
U.S.A.
Tel: (+1)-301-986-6660
Fax: (+1)-301-986-8575
Email: aharkness@mpegla.com
http://www.mpegla.com

gstreamer decoders

Posted Jan 28, 2010 23:04 UTC (Thu) by Trelane (subscriber, #56877) [Link] (32 responses)

at http://www.mpegla.com/main/programs/M4V/Pages/Licensees.a...

187. Fluendo S.A.
281. Google Inc.

I don't see ffmpeg as a licensor.

gstreamer decoders

Posted Jan 29, 2010 7:53 UTC (Fri) by roc (subscriber, #30627) [Link] (29 responses)

Thanks a lot, Trelane. I hope that puts to rest Don Diego's argument that free software doesn't need to be licensed.

gstreamer decoders

Posted Jan 29, 2010 14:45 UTC (Fri) by pboddie (guest, #50784) [Link] (27 responses)

And the definitions of "product chain", "end product", "end product supplier" and "End User" would probably need investigating before anyone thinks that Google has now licensed the patents from the cartel for everyone. Just to preempt any jubilation that H.264 is now "safe" for genuinely open standards, of course.

gstreamer decoders

Posted Jan 30, 2010 2:38 UTC (Sat) by Trelane (subscriber, #56877) [Link] (26 responses)

I replied, with questions for clarification:
==========MY REPLY==========
Allen,

Thank you for the information. I think I grok, but I do have two
questions:

From Allen Harkness on Thursday, 28 January, 2010:
>In response to your specific question, under the Licenses royalties are
>paid on all MPEG-4 Visual/AVC products of like functionality, and the
>Licenses do not make any distinction for products offered for free
>(whether open source or otherwise). But, I do note that the Licenses
>addresses this issue by including annual minimum thresholds below which
>no royalties are payable in order to encourage adoption and minimize the
>impact on lower volume users. In addition, the Licenses also include

What are these thresholds? Ideally, I'd like numbers, but information
on whether it's monetary or downloads is more than I have now.

>maximum annual royalty caps to provide more cost predictability for
>larger volume users.

How does this work in an open source or Free software setup, where
the source code is modifiable and re-distributable? Are downloads
from the licensee only covered?

Two scenarios come to mind:
1) A corporation has a customized (i.e. modified) build of Google's
Chrome (which includes an implmentation of ffmpeg), and then
re-distributes this modified binary to all of the workstations at
the company. Is this covered by Google's license?

2) A corporation downloads one copy of Chrome from Google, and redistributes
these internally to its workstations. Is this covered by Google's license?

3) Same scenarios as above, but for a home user distributing to others.

Thanks!

-Joseph
==========END REPLY==========

I've not received an answer to date. I'll post if they respond back.

Also, I'd like to take this moment to thank Fluendo for providing a licensed method. I hate software patents, particularly for what are otherwise open standards. Maybe we need patentleft to kick things off? It is, after all, another license in the end.

Finally, I'll also go ahead and say that all my videos that I have control over are Theora. :)

gstreamer decoders

Posted Jan 31, 2010 11:55 UTC (Sun) by DonDiego (guest, #24141) [Link] (23 responses)

> Also, I'd like to take this moment to thank Fluendo for providing a
> licensed method.

A company is thanked for providing proprietary software. This must be a precedent on lwn.net. Anyway, you could have said that you don't care about free software right at the start. That would have saved us going back and forth about the finer points.

gstreamer decoders

Posted Jan 31, 2010 13:21 UTC (Sun) by nix (subscriber, #2304) [Link] (14 responses)

Given his earlier actions in poking MPEG LA with a stick, apparently in
the hope they'd wake up and say 'ffmpeg? what's that? stop, now!', I think
his not caring about free software goes without saying. Or, rather, given
a choice between free software and his being right, his being right would
come first every time.

(apologies for sexist phrasing, but this particular odious characteristic
is in my experience restricted to males. Generally young ones.)

gstreamer decoders

Posted Jan 31, 2010 20:37 UTC (Sun) by Trelane (subscriber, #56877) [Link] (8 responses)

"Given his earlier actions in poking MPEG LA with a stick, apparently in
the hope they'd wake up and say 'ffmpeg? what's that? stop, now!', I think
his not caring about free software goes without saying."

It wasn't poking with a stick, your assumptions about my motivation are completely off the mark, and your conclusion based on the above is also completely wrong. Fortunately, I don't have to prove myself to random jerks on the Internet.

"Or, rather, given a choice between free software and his being right, his being right would come first every time."

Also incorrect. Not surprising. I think your own prejudices color your perceptions here.

gstreamer decoders

Posted Feb 1, 2010 0:45 UTC (Mon) by nix (subscriber, #2304) [Link] (7 responses)

Well, what was I supposed to think? If your supposition that ffmpeg had
been ignored by the MPEG LA because they were beneath their notice had
proven correct, your own actions would have done nothing less than bring
another patent attack on free software. Well done.

gstreamer decoders

Posted Feb 1, 2010 1:09 UTC (Mon) by Trelane (subscriber, #56877) [Link] (2 responses)

That was never my supposition. Perhaps you are thinking of
"
Posted Jan 26, 2010 21:32 UTC (Tue) by roc (subscriber, #30627) [Link]
I guess they're not important enough to be sued by MPEG-LA.
"

All I did was ask for clarification on their FAQ. At worst, I hastened the inevitable by some unknowable quantity. At best, my email has helped show better where the licensing necessities are.

gstreamer decoders

Posted Feb 1, 2010 1:14 UTC (Mon) by Trelane (subscriber, #56877) [Link] (1 responses)

ugh. my thinking with a screaming baby ain't the clearest. at best would have been a fairytale ending of "GPL implementation is OK with us!" at worst i've improved our (or just my) knowledge of the licensing situation at the cost of *perhaps* hastening the inevitable by some unknowable quantity.

gstreamer decoders

Posted Feb 4, 2010 0:30 UTC (Thu) by nix (subscriber, #2304) [Link]

Screaming baby explains everything, I think. Rationality is not expected
under those circumstances. (Sanity is hard enough to maintain.)

gstreamer decoders

Posted Feb 1, 2010 16:04 UTC (Mon) by bronson (subscriber, #4806) [Link] (3 responses)

So you're a fan of security through obscurity nix? I'm surprised.

I don't see a downside to getting everything into the open. It might mean some short term difficulty for the ffmpeg project (difficulty that I'm sure they're expecting anyway), but it means long-term stability for everybody.

Nice work Trelane. You're doing this for all of us. Thanks!

gstreamer decoders

Posted Feb 1, 2010 16:36 UTC (Mon) by Trelane (subscriber, #56877) [Link]

It still wasn't my intent to get anyone in trouble. Let's be clear on that point. I was solely looking for information (and if they'd said "Oh, we never thought of that! GPL is a great license, and you totally can consider yourselves covered!" or something like that, that'd've been great. As it is, we now know a bit more about implementations they don't care about making pay (see the thresholds I asked to be clarified.) And we have it in writing (as much as email is; I do have logs too))

It's also the start of a dialog, if they choose to go there. I'd be willing to talk with them about Free Software and patents and direct them at more knowledgeable people. Let's try to keep this positive!

legal trouble

Posted Feb 2, 2010 15:29 UTC (Tue) by DonDiego (guest, #24141) [Link]

For some reason people keep expecting trouble for us and expecting that we expect trouble. We have had zero trouble in the 10 odd years of our existence and are firmly convinced that we will see the same amount of trouble in the next decade. See also

http://multimedia.cx/eggs/legal-threat-00001/

gstreamer decoders

Posted Feb 4, 2010 1:14 UTC (Thu) by nix (subscriber, #2304) [Link]

The law and security have the same relationship to each other as theology
has to religion: that is, none to speak of.

gstreamer decoders

Posted Jan 31, 2010 23:25 UTC (Sun) by DonDiego (guest, #24141) [Link] (2 responses)

Quit worrying about FFmpeg keeping a low profile. We're not a secret to any of the players in the industry and not to the MPEG LA.

gstreamer decoders

Posted Feb 1, 2010 0:52 UTC (Mon) by nix (subscriber, #2304) [Link]

Oh I'm not worrying. I entirely believe you: ffmpeg is too influential for
MPEG LA not to know about it. But *if* the supposition (bandied about by
several here including IIRC Trelane) were true that ffmpeg had been
ignored because it was too ignorable or not a revenue generator or
something, then Trelane had just poked a dragon (or at least a troll) with
a stick. This is generally considered a bad idea, even if it turns out
that the dragon knows who you are and doesn't want to eat you today.

gstreamer decoders

Posted Feb 1, 2010 19:45 UTC (Mon) by rawler (guest, #60308) [Link]

Personally, my guess would be that ffmpeg may be too influential. Banning
ffmpeg for patent-reasons would be pretty much poking not the bear, but the
bee-hive of pissed of techno-geeks everywhere.

As the mail states, there are intentional exceptions for low-volume (in
business speak, roughly the same as low-income) "in order to encourage
adoption". I would assume that for peace:s sake, MPEG LA is avoiding
confrontation to much provide the patent opposition with too much fuel for
their fire, and further de-rail wide-spread adoption.

gstreamer decoders

Posted Feb 1, 2010 14:38 UTC (Mon) by nye (subscriber, #51576) [Link] (1 responses)

>(apologies for sexist phrasing, but this particular odious characteristic
>is in my experience restricted to males. Generally young ones.)

I think this kind of comment is highly out of place on LWN.

gstreamer decoders

Posted Feb 4, 2010 1:12 UTC (Thu) by nix (subscriber, #2304) [Link]

It's from personal experience with myself. We were all young and stupid
once.

gstreamer decoders

Posted Jan 31, 2010 20:41 UTC (Sun) by Trelane (subscriber, #56877) [Link] (7 responses)

"Anyway, you could have said that you don't care about free software right at the start. That would have saved us going back and forth about the finer points."

Nice troll. You almost had me going there.

gstreamer decoders

Posted Jan 31, 2010 23:23 UTC (Sun) by DonDiego (guest, #24141) [Link] (6 responses)

Thanks for the compliment, but I will have to insist:

If you thank Fluendo for providing you with "legally licensed" proprietary software, then you should build a throne for Google, which is providing you with "legally licensed" free software, don't you think?

Do you also thank Adobe for "legally licensed" Flash and Microsoft for "legally licensed" Windows 7? They all come with an MPEG LA license..

gstreamer decoders

Posted Jan 31, 2010 23:36 UTC (Sun) by Trelane (subscriber, #56877) [Link] (5 responses)

If they work for Linux, providing a Free stack for multimedia and multimedia streaming and DVR functionality, then yes. Yes, I do. Your "throne" exaggeration is a bit extreme, though. I thank Google for their work on Chrome, although whether their patent license extends to you if you build Chrome and ffmpeg is murky at best (see also Fluendo and their MP3 plugin proprietary vs BSD-licensed). That's why I asked MPEG-LA for more information.

I also buy Codeweavers Crossover Office because they help Wine to a great degree.

"Do you also thank Adobe for "legally licensed" Flash"

I thank them for having a Linux plugin. I don't like Flash over Free, patent-free standards, though. (See also the "I produce Theora content") I'm doing my part to keep us viable now (Fluendo and their plugin work) and in the future (Fluendo's Free software, Theora/Xiph, and my FSF membership).

and Microsoft for "legally licensed" Windows 7?"

If I ran Windows, I'd thank them for licensing the codec.

You do nobody any favors when your patent protection plan is the equivalent of burying your head in the sand, putting your fingers in your ears and saying "There ain't no patent threat" three times fast. You counter it by helping establish Free, patent-free standards and filling the gap until we get to that point.

gstreamer decoders

Posted Feb 1, 2010 14:26 UTC (Mon) by DonDiego (guest, #24141) [Link] (4 responses)

Fluendo is not a free software company. They stopped significant contributions to gstreamer years ago. They are a common and garden-variety proprietary software shop now. Why you would thank them for offering products for sale to you is beyond me, but hey...

gstreamer decoders

Posted Feb 1, 2010 15:34 UTC (Mon) by Trelane (subscriber, #56877) [Link] (3 responses)

"Fluendo is not a free software company. They stopped significant contributions to gstreamer years ago. They are a common and garden-variety proprietary software shop now."

From poking around in wikipedia and talking to GStreamer people, this isn't entirely accurate, although it's not entirely inaccurate either. My information was apparently out of date.

"Why you would thank them for offering products for sale to you is beyond me, but hey..."

Had you stopped prior to this sentence, this would have been a helpful and informative post. This sentence took that work and overshadowed it by jerkishness.

gstreamer decoders

Posted Feb 2, 2010 15:41 UTC (Tue) by DonDiego (guest, #24141) [Link] (2 responses)

> > "Fluendo is not a free software company. They stopped significant
> > contributions to gstreamer years ago. They are a common and
> > garden-variety proprietary software shop now."

> From poking around in wikipedia and talking to GStreamer people, this
> isn't entirely accurate, although it's not entirely inaccurate either.
> My information was apparently out of date.

I got the information from Edward Hervey who works on gstreamer (and for Collabora, the company that funds gstreamer development nowadays) and hangs around in the #ffmpeg-devel IRC channel. Just look at the gstreamer commit graph of thomasvs, who works for Fluendo and commented in this discussion before:

http://www.ohloh.net/accounts/thomasvs
http://www.ohloh.net/p/gstreamer/contributors/14925011355589

> > Why you would thank them for offering products for sale to you is
> > beyond me, but hey..."

> Had you stopped prior to this sentence, this would have been a helpful
> and informative post. This sentence took that work and overshadowed it
> by jerkishness.

You're not exactly a role model either, but the remark was dead serious. I never felt like thanking a supermarket for offering me goods for sale. Why would you thank any company for offering you their goods?

gstreamer decoders

Posted Feb 2, 2010 16:35 UTC (Tue) by Trelane (subscriber, #56877) [Link] (1 responses)

I got my information from several sources on #gstreamer and #fluendo. (note also that their gstreamer contributions are only a portion of what they do, s.a. flumotion, their streaming and recording several FOSS events, etc.)

"Why would you thank any company for offering you their goods?"

If it was the only place or one of the few places to get it legally, I'd be pretty grateful for it. Perhaps that's what you're not comprehending. Maybe we're just different people and see things differently, eh?

Fluendo vs. FFmpeg

Posted Feb 3, 2010 1:40 UTC (Wed) by DonDiego (guest, #24141) [Link]

Your continuous claim that FFmpeg is illegal is insulting. Your lack of appreciation for software freedom is sad.

gstreamer decoders

Posted Feb 1, 2010 20:06 UTC (Mon) by rawler (guest, #60308) [Link] (1 responses)

> What are these thresholds? Ideally, I'd like numbers, but information
> on whether it's monetary or downloads is more than I have now.
From http://www.mpegla.com/main/programs/avc/Documents/AVC_Ter...

"royalties (beginning January 1, 2005) per legal entity are 0 - 100,000
units per year = no royalty"

gstreamer decoders

Posted Feb 2, 2010 2:08 UTC (Tue) by Trelane (subscriber, #56877) [Link]

Awesome! Thanks for the info! Hooray for information with sources!

gstreamer decoders

Posted Feb 1, 2010 0:37 UTC (Mon) by DonDiego (guest, #24141) [Link]

That's not my take on the issue, nor could it be since copyright and patent licenses are orthogonal.

What I'm saying is that only corporations with deep pockets in certain parts of the world need to worry at all. You seem convinced that you are such an entity. Very well, good luck with your HTML 5 efforts. I don't care what browser makes my life without Flash more bearable, but I'm certainly willing to switch browsers to enjoy the privilege.

Then again, I'm convinced that you will punt and use system infrastructure to decode video in the medium-term future. Hopefully you will manage without hurting your market share too much...

gstreamer decoders

Posted Jan 29, 2010 8:09 UTC (Fri) by roc (subscriber, #30627) [Link]

BTW the list of H.264 licensees is here:
http://www.mpegla.com/main/programs/AVC/Pages/Licensees.aspx

gstreamer decoders

Posted Jan 30, 2010 12:34 UTC (Sat) by DonDiego (guest, #24141) [Link]

FFmpeg is not an MPEG LA licensee, nor will it be in the future.

gstreamer decoders

Posted Jan 31, 2010 5:09 UTC (Sun) by luya (subscriber, #50741) [Link]

More reasons to switch to Theora. If only manufacturers of multimedia devices follow the suite. =/

End User use of H.264

Posted Jan 31, 2010 16:00 UTC (Sun) by jrincayc (guest, #29129) [Link] (4 responses)

I have wondered what would happen if an end user requests a H.264 license for their own use. Has anyone ever tried this?

End User use of H.264

Posted Feb 1, 2010 19:47 UTC (Mon) by jxself (guest, #63302) [Link] (2 responses)

jrincayc: Yes. They refused to license to me.

End User use of H.264

Posted Feb 3, 2010 8:38 UTC (Wed) by DonDiego (guest, #24141) [Link] (1 responses)

What did you try?

End User use of H.264

Posted Mar 29, 2010 17:43 UTC (Mon) by jxself (guest, #63302) [Link]

I contacted MPEG-LA and asked for a license. They quickly sent me one (I asked for MPEG-2, MPEG-4 and H.264.) After the licenses arrived I signed and returned them. They later contacted me because I was an end-user and would not license to me. (Email copied below.)

I'm glad that I tried. If they're now saying that end users can be held responsible, I will keep these signed licenses (and the entire email chain) in my records. In the event that I am sued my plan is to pull these out and say, "look -- I tried to get licensed -- they refused" and go on about how it doesn't seem quite right to refuse to license to me while also suing me for not being licensed. Anyway, here's the relevant snippet from the email.

"Although our Licenses do not directly provide coverage for an end user and anyone in the product chain may be held responsible for an unlicensed product, a royalty paid for an end product by the end product supplier would render the product licensed in the hands of the end user. Therefore, the end user would not normally pay a royalty to MPEG LA for using such a product, but where a royalty has not been paid, such product is unlicensed.

In this case, as you appear to be the end user, we suggest that you choose a player from a licensed supplier. In that regard, we maintain lists of Licensees in Good Standing to each of our Licenses in the corresponding sections of our website http://www.mpegla.com.

Finally, please note that since you will not benefit from coverage under the Licenses, we will not execute the signed Licenses that you have returned to us."

End User use of H.264

Posted Feb 1, 2010 20:02 UTC (Mon) by rawler (guest, #60308) [Link]

Interesting idea. A single home-user would surely fall under the mentioned
"low volume threshold" of 100.000 units, so it would be interesting to see
if there are any hidden fixed costs. Please post if you do decide to try it.

If nothing else, if someone wants to break the system, a suggestion on
Slashdot for each and every Open-Source user to do so (nomatter whether it
will be granted or not), would probably give them a very tough week in their
sales department. ;)

gstreamer decoders

Posted Feb 4, 2010 23:36 UTC (Thu) by PaulWay (guest, #45600) [Link] (2 responses)

> Our MPEG-4 Visual Patent Portfolio License includes 29 patent owners
> contributing more than 900 patents that are essential for use of the
> MPEG-4 Visual (Part 2) Standard. Our AVC Patent Portfolio License
> includes 25 patent owners contributing more than 1,000 patents that are
> essential for use of AVC/H.264 Standard ("MPEG-4 Part 10").

My immediate question would be:

"Given that Microsoft and several other vendors have been hit for billions of dollars in patent infringements after they bought a license from MPEG-LA to use the MPEG-2 intellectual property, we will only buy a license from MPEG-LA if they guarantee that no intellectual property other than their own is infringed by the technology they're licensing, and they indemnify and promise to be liable for any lawsuit held against any company implementing the AVC/H.264 standard."

It's extremely hypocritical for MPEG LA and its members to cast aspersions on the possibility that Theora may be at risk of attack from submarine patents, and yet stand idly by while patent trolls attack companies that have licensed technology from MPEG LA. If you buy the license to implement the standard, you should be buying a license for <u>everything</u> that implements the standard. You shouldn't then be told "oh, sorry, you did it in this slightly different way, we don't cover that, hope you like paying lots of money to other patent trolls".

It just highlights the complete stupidity of trying to claim that ideas are property.

Microsoft MPEG-2 patent infringement lawsuit

Posted Feb 5, 2010 9:01 UTC (Fri) by DonDiego (guest, #24141) [Link] (1 responses)

Where did you get that information about Microsoft being hit by MPEG-2 patent infringement suits? I haven't heard about such a lawsuit before.

Microsoft MPEG-2 patent infringement lawsuit

Posted Feb 5, 2010 14:35 UTC (Fri) by pboddie (guest, #50784) [Link]

They may have been thinking of this:

http://en.wikipedia.org/wiki/Alcatel-Lucent_v._Microsoft

gstreamer decoders

Posted Jan 28, 2010 11:30 UTC (Thu) by thomasvs (guest, #36955) [Link] (20 responses)

"Fluendo also offers an alternative H.264 decoder that hooks into gstreamer. In exchange for money they take away your freedom. It's tasteless."

Why do we take away your freedom? Feel free not to buy our codecs. No one is forcing you to give us money. I don't see how offering an option for those people that want a legal properly licensed codec takes away freedom. It's hollow rhetoric.

gstreamer decoders

Posted Jan 28, 2010 12:46 UTC (Thu) by DonDiego (guest, #24141) [Link] (19 responses)

> > Fluendo also offers an alternative H.264 decoder that hooks into
> > gstreamer. In exchange for money they take away your freedom.
> > It's tasteless."

> Why do we take away your freedom? Feel free not to buy our codecs. No one
> is forcing you to give us money. I don't see how offering an option for
> those people that want a legal properly licensed codec takes away freedom.
> It's hollow rhetoric.

There you're doing it again. Insinuating that the only way to get a "legal properly licensed" codec is by forfeiting software freedom and giving you money. By corollary you're also saying that free software implementing those same codecs is somehow illegal and should be avoided in favor of your proprietary software. This is tasteless and insulting.

gstreamer decoders

Posted Feb 3, 2010 11:10 UTC (Wed) by thomasvs (guest, #36955) [Link] (18 responses)

I don't like exagerated rhetoric. In no way am I saying FFmpeg is illegal. Our reading of the GPL and LGPL, which are licenses governing the distribution of software, you need to give the same rights to your recipients as you have, and they need to be able to redistribute with the same rights as well.

In our reading this conflicts with the combination of patents and their usage license when they are volume-based instead of one-time fee. If I distribute the code, I'm not going to pay the end user license for everyone that gets my software; I don't even know how you would be able to track that.

In the case of mp3, since there was a one-time fee, we did exactly that.

Of course, this reasoning a) assumes that patents and patent licensing are legally valid (which for example is the case in the US) and b) is our (and our lawyer's) interpretation of the situation.

Diego, feel free to disagree with this; in the end what we saw is a practical situation (no distro feels legally safe to ship ffmpeg/xine/vlc/mplayer).

But don't blow up the discussion with insinuations that we think ffmpeg is illegal, or that we try to take away anyone's freedom. That's just intentionally polarizing the discussion. Your arguments are stronger when you don't put words in the mouth of the other.

gstreamer decoders

Posted Feb 3, 2010 13:37 UTC (Wed) by paulj (subscriber, #341) [Link] (3 responses)

If you are not restricted by the patent (e.g. never signed a deal with the
licensor, not subject court injunction), then you can
distribute just fine without compromising the free software licence on the
code. This is true regardless of whether or not the code is subject to patents,
for you are in the same position as the recipient, which is all the GPL licence
requires.

If you choose not to distribute a codec because you know it is patented, then
you do so because you are protecting *yourself* from legal risk - not because
the licence requires it. It is a misunderstanding to claim the licence is the
barrier, as you could happily distribute away and not violate any free software
licences, given the above.

I think the above may be what Don Diego is trying to communicate, and it fits
in with my understanding of the GPL and patent issues (IANAL, etc).

If you come to an agreement with the patent holder, then obviously you
must secure a blanket agreement that covers all your down stream users. If
the patent only applies in certain countries, then note that the GPL allows
code to be distributed with geographic exceptions set by the rights holder,
while (it seems, but am not certain) remaining GPL compatible.

The next question, which I think you or others in the Mozilla camp (and
perhaps the FSF?) have tried to raise is the question of whether patent
encumbered technologies should be resisted by promoting other, less
encumbered technologies. This is an interesting one, but it is implied per se
by licensing obstacles to distribution on the code.

gstreamer decoders

Posted Feb 3, 2010 13:46 UTC (Wed) by paulj (subscriber, #341) [Link]

Last sentence makes little sense. Basically I meant that the idea of resisting
patented tech does not rest on there being any immediate licensing problems
with implementations of such software.

gstreamer decoders

Posted Feb 3, 2010 18:13 UTC (Wed) by DonDiego (guest, #24141) [Link] (1 responses)

Patented software is indeed distributed all the time, just take Linux, Samba, Firefox as high-profile examples. Their license is not compromised by the fact that somebody somewhere claims some patent.

But you are not portraying my stance correctly, see my other posts for reference.

gstreamer decoders

Posted Feb 3, 2010 21:29 UTC (Wed) by paulj (subscriber, #341) [Link]

Yes, I see my mistake. I thought originally you were referring to FFmpeg and
other unlicensed practitioners of patents distributing potentially patented
code.

Re the patent licence case, after digging relatively carefully through the GPL
v2 and v3 text to find the precise text that contradicts you, I find you may
well be right. I.e. I can no longer support this earlier paragraph of mine:

"If you come to an agreement with the patent holder, then obviously you
must secure a blanket agreement that covers all your down stream users. If
the patent only applies in certain countries, then note that the GPL allows
code to be distributed with geographic exceptions set by the rights holder,
while (it seems, but am not certain) remaining GPL compatible."

It seems the *actual* obligations imposed by the GPL do not go that far.
Rather it seems that, as you say, it only affects licensees who promise the
patent holder to try restrict those they distribute to. Which, it appears, is not
the case for the MPEG-LA agreement.

I'm starting to think you're right.

gstreamer decoders

Posted Feb 3, 2010 13:42 UTC (Wed) by DonDiego (guest, #24141) [Link] (13 responses)

> Our reading of the GPL and LGPL, which are licenses governing the
> distribution of software, you need to give the same rights to your
> recipients as you have, and they need to be able to redistribute with
> the same rights as well.

False. You need to give recipients the same rights that you received when getting the software. You received FFmpeg as (L)GPL from us, you have to pass it along as (L)GPL again. The (L)GPL says nothing about a contract with the MPEG LA.

I'll give you another example: The original author has the right to publish the software under any license. This right is *not* passed along with GPL software. I could also sell you some FFmpeg code I wrote under a proprietary license. Then you have the right to use that code under said proprietary license, but you do *not* pass that right along when you redistribute FFmpeg. You have the right, but you need not pass it along, you are not even allowed to pass it along.

> in the end what we saw is a practical situation (no distro feels
> legally safe to ship ffmpeg/xine/vlc/mplayer).

FALSE !!!

Do you really believe what you were saying there? Just scroll up and read a bit of the discussion above or verify such statements before making them.

> But don't blow up the discussion with insinuations that we think
> ffmpeg is illegal, or that we try to take away anyone's freedom.

You profit from making people think that you are the only "legal" way to run multimedia software under Linux. Some people are easily scared and gullible and believe what you write. These people then run your proprietary software instead of free software to do the same job at least as good. These people are thus deprived from their software freedom and you have profited.

There is no way around these facts. If you were putting all the money you earn with that stuff into a big fund to sponsor free software or if you donated it, then fine, I would believe you. Or if there was a note in your shop that said "no private person has ever needed this, you can use free software X instead also". But you do no such thing.

Which is fine, be that way if you want, I would welcome you to act differently, but I do not condemn you. However, please be honest about what you do. You sell proprietary software like any other company and are in no way special.

> That's just intentionally polarizing the discussion. Your arguments
> are stronger when you don't put words in the mouth of the other.

I have heard "FFmpeg is illegal.", "Playing DVDs under Linux is illegal.", "Someone will end up in jail." more times than I can count. Just try to spend a day at an FFmpeg/MPlayer booth for a day during LinuxTag or some other event.

This discussion is already polarized and lopsided in one direction. I intend to balance the scales a bit by countering the FUD and anticipatory obedience that has become the hallmark of parts of our community.

gstreamer decoders

Posted Feb 3, 2010 14:38 UTC (Wed) by mjw (subscriber, #16740) [Link] (12 responses)

> > Our reading of the GPL and LGPL, which are licenses governing the
> > distribution of software, you need to give the same rights to your
> > recipients as you have, and they need to be able to redistribute with
> > the same rights as well.

> False. You need to give recipients the same rights that you received when
> getting the software. You received FFmpeg as (L)GPL from us, you have to
> pass it along as (L)GPL again. The (L)GPL says nothing about a contract
> with the MPEG LA.

Actually the LGPL does if such contracts are about patent licenses (quotes from GPLv2.1, but other versions have similar obligations):

Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license.
[...]
If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.

gstreamer decoders

Posted Feb 3, 2010 15:08 UTC (Wed) by paulj (subscriber, #341) [Link]

Don Diego is talking about the case where you distribute GPLed code where
you have *no* agreement with any patent licensors. This is perfectly
acceptable, at least wrt the licence.

It is a fallacy to say that every distributor of GPLed software must ensure they
have blanket downstream licences to all potentially applicable patents. The only
thing refusing to distribute protects against is legal risk to the *distributor*, and
a lesser risk to the recipient from the *patent holder* - not the licensor of the
GPL software!

See also my other reply, an uncle of sorts to this one.

(L)GPL vs. patents

Posted Feb 3, 2010 15:28 UTC (Wed) by DonDiego (guest, #24141) [Link] (10 responses)

> Actually the LGPL does if such contracts are about patent licenses
> (quotes from GPLv2.1, but other versions have similar obligations):

> Finally, software patents pose a constant threat [...]
> [.. continue quote from the preamble..]

This is from the preamble of the LGPL. As it has no effect on the license itself and is in no way legally binding, it is best ignored.

> If you cannot distribute so as to satisfy simultaneously your
> obligations under this License and any other pertinent obligations,
> then as a consequence you may not distribute the Library at all. For
> example, if a patent license would not permit royalty-free
> redistribution of the Library by all those who receive copies directly
> or indirectly through you, then the only way you could satisfy both it
> and this License would be to refrain entirely from distribution of the
> Library.

This just means that other contracts do not excuse you from the obligations of the LGPL. Any downstream recipient must continue to receive the full LGPL rights, the redistributor is not allowed to restrict them, no matter what other obligations say.

If somebody has a contract with the devil that claims a limb for each redistribution of FFmpeg then that person will quickly run out of limbs and then have a serious problem with the devil, but with nobody else.

Downstream recipients are not affected. They have no contract with the devil, they need not fear for their limbs, they just need to abide by the terms of the LGPL.

(L)GPL vs. patents

Posted Feb 3, 2010 15:48 UTC (Wed) by mjw (subscriber, #16740) [Link] (6 responses)

> This is from the preamble of the LGPL. As it has no effect on the license itself and is in no way legally binding, it is best ignored.

Of course it is not smart to ignore the text of the license. The preamble makes clear what the intent is of the legal clauses. In case their is any doubt how to interpret a particular clause one looks at the intent to see that "any patent license obtained for a version of the library must be consistent with the full freedom of use".

> > if a patent license would not permit royalty-free
> > redistribution of the Library by all those who receive copies directly
> > or indirectly through you, then the only way you could satisfy both it
> > and this License would be to refrain entirely from distribution of the
> > Library.
>
> This just means that other contracts do not excuse you from the obligations of the LGPL. [...] Downstream recipients are not affected.

Yes, but it does affect the (re)distributor. If they get a patent license, then they have to make sure that it covers not only themselves, but also all the recipients of any copies of the library. You might think that is the problem of those who take out such a patent license, and that they would be foolish to get into a contract with something like the MPEG LA. (And you might be right about that.) But it is still a real problem for such companies that do.

(L)GPL vs. patents

Posted Feb 3, 2010 16:02 UTC (Wed) by DonDiego (guest, #24141) [Link] (5 responses)

> > This is from the preamble of the LGPL. As it has no effect on the license itself and is in no way legally binding, it is best ignored.

>Of course it is not smart to ignore the text of the license. The preamble makes clear what the intent is of the legal clauses. In case their is any doubt how to interpret a particular clause one looks at the intent to see that "any patent license obtained for a version of the library must be consistent with the full freedom of use".

Sure? OK, let's try:

PREAMBLE

The book club is a non-profit, for-good, honest, no-nonsense organization that strives to bring its members peace, prosperity, happiness and easy access to their favorite books with absolutely no hooks attached

CONTRACT

666. (f) If you have read this far, we will now inform you that we will send you a few books per week at not exactly premium conditions. They will be a random choice of the old stuff we could not sell otherwise. You may not give them back and pay within three days.

Construct a slightly less contrived example if you wish, but still the fact remains: the preamble is not legally binding.

> > This just means that other contracts do not excuse you from the obligations of the LGPL. [...] Downstream recipients are not affected.

> Yes, but it does affect the (re)distributor. If they get a patent license, then they have to make sure that it covers not only themselves, but also all the recipients of any copies of the library.

No. BTW, the SFLC agrees with us.

(L)GPL vs. patents

Posted Feb 3, 2010 16:49 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

Can you provide a reference to SFLC's interpretation? I haven't
seen it

(L)GPL vs. patents

Posted Feb 3, 2010 17:53 UTC (Wed) by DonDiego (guest, #24141) [Link] (3 responses)

I can see if I get something in writing, it's all from talks with one of our devs that also lives in New York so far.

Much more importantly, this is the official interpretation of FFmpeg. Since we are the copyright owners, our interpretation is the one that matters. We still need to put that in writing.

(L)GPL vs. patents

Posted Feb 4, 2010 16:00 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

If you want your claims to be taken seriously it needs to be in writing If
you are repeatedly going to refer to claims about SFLC's interpretation it
would be beneficial to get it in writing as well

(L)GPL vs. patents

Posted Feb 4, 2010 16:07 UTC (Thu) by DonDiego (guest, #24141) [Link] (1 responses)

I am an FFmpeg copyright holder, so you already have a statement from me. We shall try to make something more official and put it on our website.

I would like you to provide me with the contrary interpretation in writing as well. You claim that the FSF has made statements to a different effect, but I never saw such a thing.

(L)GPL vs. patents

Posted Feb 4, 2010 16:27 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

Collectively a group making a statement is quite different from a single
copyright holder and I made no claims about FSF's interpretations You are
confusing me with someone else

(L)GPL vs. patents

Posted Feb 3, 2010 15:59 UTC (Wed) by paulj (subscriber, #341) [Link] (2 responses)

Are you saying that a patent licensor can continue to distribute a GPLed work
implementing that patent even when the licence is not passed on? That
doesn't seem to in concordance with the GPL.. Though I can't tell if you're
claiming that, or if you're just talking about the rights of the downstreams.

Where you seemed to be saying that non-licensees were unaffected (other
than risk from patent holder) and able to distribute just fine, I agree with you.

(L)GPL vs. patents

Posted Feb 3, 2010 15:59 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

a patent licen/see/. Grr.

(L)GPL vs. patents

Posted Feb 3, 2010 17:58 UTC (Wed) by DonDiego (guest, #24141) [Link]

That's exactly what I'm saying. A patent licensee can continue distributing FFmpeg under the LGPL no matter what other side deals are in effect.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 26, 2010 21:38 UTC (Tue) by roc (subscriber, #30627) [Link]

I was specifically refuting the accusation that lack of H.264 is an "antifeature". I was at Benjamin Mako Hill's LCA talk last week, and he defined it as a restriction of capability which takes additional work to implement. Therefore, lack of support for DirectShow or Quicktime codecs is not an antifeature, since it's easier to not support them than to support them.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 28, 2010 20:31 UTC (Thu) by DonDiego (guest, #24141) [Link]

> > Making it difficult for users to add H.264 support is a antifeature. They
> > are intentionally making their program do things most people don't want
> > it to do in order to forward a specific political viewpoint.

> Not at all. Integrating an H.264 codec, or integrating support for various
> system codec frameworks, are features that we have chosen to not add,
> features that would require major engineering effort to create and
> support, given we need faithful adherence to the HTML5 spec. If you don't
> believe this, you can take the Firefox source and show us how easy it is.

But you are already working on a gstreamer backend for fennec (embedded Firefox)

https://bugzilla.mozilla.org/show_bug.cgi?id=422540

What gives?

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 26, 2010 8:53 UTC (Tue) by paulj (subscriber, #341) [Link] (8 responses)

They're orthogonal arguments though. In one dimension you have a video
embedding technology, HTML5 vs Flash. In the other dimension you have the
video codec, H.264 v Ogg Theora.

At present the world is Flash / H.264. Surely replacing Flash with HTML5 is a
win, regardless of the codec dimension?

Further, the dimensions are not completely independent, for Flash intrinsically
supports H.264, whereas it does not support Ogg Theora. The video codecs
which Flash is deemed to support is determined solely by one
vendor, for all practical purposes[1]. So in a world where Flash is the dominant
video embedding technology you will struggle to get the codec changed.
Whereas with HTML5 you have a greater number of vendors who can offer
more codec support, including a very well established open-source effort.

Therefore if you can encourage the adoption of HTML5 over Flash, regardless
of codec, you will get more freedom to change the world in the other
dimension (the codec dimension).

Basically, this is how you change the world:

Flash + H.264
-> HTML5 + H.264
-> HTML5 + H.264 + Ogg Theora
-> HTML5 + Ogg Theora

You stand far less chance of making the world a more free place by spurning
HTML5, as that just keeps Flash in place, which keeps the codec dimensions
'stuck' to the H.264 pole.

(and yes, I know Ogg Theora is a container format itself, I don't know the
name of the free video codec it uses - VP3?)

1. they have the ability to ensure any free re-implementations are always
kept well behind.

Ogg vs. Theora

Posted Jan 26, 2010 10:23 UTC (Tue) by DonDiego (guest, #24141) [Link] (7 responses)

> (and yes, I know Ogg Theora is a container format itself, I don't
> know the name of the free video codec it uses - VP3?)

Ogg is the container, Theora is the codec. Theora is derived from the VP3 codec originally created by On2.

Ogg is a deeply flawed container format, for details see

http://hardwarebug.org/2008/11/17/ogg-timestamps-explored/

Ogg vs. Theora

Posted Jan 26, 2010 10:41 UTC (Tue) by paulj (subscriber, #341) [Link] (6 responses)

Very interesting thanks!

So perhaps replace Ogg with Avi? E.g. replace "Ogg Theora" in my comment
above with "Avi Theora"?

Ogg vs. Theora

Posted Jan 26, 2010 13:02 UTC (Tue) by __alex (guest, #38036) [Link] (5 responses)

Avi and Vorbis audio do not work very well together. I'm not sure if there are
even any DirectShow filters other than ffmpeg that support it and even that
has trouble keeping the audio in sync.

Ogg vs. Theora

Posted Jan 26, 2010 21:38 UTC (Tue) by Trelane (subscriber, #56877) [Link] (1 responses)

http://xiph.org/downloads/

Xiph has them. Dunno if they're perhaps ffmpeg-based, but it seems unlikely.

Ogg vs. Theora

Posted Jan 27, 2010 11:40 UTC (Wed) by DonDiego (guest, #24141) [Link]

They are not based on FFmpeg.

Ogg vs. Theora

Posted Feb 1, 2010 14:45 UTC (Mon) by nye (subscriber, #51576) [Link] (2 responses)

Matroska is probably the way forward.

Ogg vs. Theora

Posted Feb 4, 2010 1:13 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

Does it just show that I don't watch much video, or that I don't watch
much (any) pirated video, that I've never actually seen anything in a
Matroska container? (At least, not knowingly. I've never encountered an
odd-looking video file and run file(1) or similar tool on it and been
told, hey, this is Matroska.)

Ogg vs. Theora

Posted Feb 4, 2010 23:30 UTC (Thu) by DonDiego (guest, #24141) [Link]

The answer is yes ;-)

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 25, 2010 21:56 UTC (Mon) by rfunk (subscriber, #4054) [Link]

"Currently the options for consuming/publishing video on web pages are Flash
plugin, Java plugin or HTML5 video."

There's one other option: Silverlight. Which has its own complications, and
as far as I can tell video-capable Silverlight just is not playable on Linux
(Moonlight doesn't get to implement those closed codecs). Netflix is the
major user of Silverlight video, but I've run into a couple others in the
wild too.

I'm concerned that this HTML5 video dispute may somehow help Silverlight.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 26, 2010 2:12 UTC (Tue) by roc (subscriber, #30627) [Link]

Mozilla has often made decisions that favour what we see as "the good of the Web" over the immediate convenience of our users. For example, we resisted supporting ActiveX, which is a good thing since if we hadn't there would be no Web browsing on any platform but Windows now. See
http://weblogs.mozillazine.org/roc/archives/2010/01/activ...

Access to third-party codecs doesn't solve any problem for most of our users, since Windows XP and Vista don't include an H.264 codec.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 26, 2010 21:52 UTC (Tue) by MisterIO (guest, #36192) [Link] (4 responses)

The solution is very simple: make a better video codec! If you can, that is.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 26, 2010 22:15 UTC (Tue) by Trelane (subscriber, #56877) [Link] (3 responses)

Dirac is underway. Doesn't mean that the MPEG-LA cabal won't shoot you down anyway, since they stand to lose their profits and ability to bully others.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 27, 2010 0:05 UTC (Wed) by coriordan (guest, #7544) [Link]

When I looked into it a few years ago, I heard that Dirac wasn't a viable replacment for mpeg/h264/ogg and never will be because that's not it's goal. It was designed to make high-quality copies of videos for archiving. This was the reason the BBC's own (DRM'd) online movie player doesn't use Dirac.

(Maybe things have changed. I think it was 2008 when I read that.)

Dirac

Posted Jan 30, 2010 16:06 UTC (Sat) by DonDiego (guest, #24141) [Link] (1 responses)

Dirac development appears stalled. There are no new releases and activity on their CVS repositories has stopped.

Dirac

Posted Jan 30, 2010 16:19 UTC (Sat) by DonDiego (guest, #24141) [Link]

After a bit more investigation it appears that libschroedinger has switched to git and there is some activity on the git repository. Whether libdirac also switched, I don't know.

http://diracvideo.org/

is completely useless and provides little information unfortunately...

Software patents don't exist in most of the world

Posted Jan 27, 2010 14:37 UTC (Wed) by dion (guest, #2764) [Link] (3 responses)

Remember back in the bad old days when another kind of math was illegal in some countries, back then there were "international" versions of many packages with all the crypto features and restricted versions for the US.

I wonder why Mozilla doesn't simply make an International build available that has h264 and and a gulag build without h264 for the poor, oppressed masses in the US and Japan.

Web site operators would need to either stream their video from The Free world or use Ogg Theora and stream from the US, but users behind the lawsuit-curtain could probably get their hands on a Free version of Firefox via Samizdat.

Software patents don't exist in most of the world

Posted Jan 27, 2010 15:29 UTC (Wed) by pboddie (guest, #50784) [Link]

Remember back in the bad old days when another kind of math was illegal in some countries, back then there were "international" versions of many packages with all the crypto features and restricted versions for the US.

You're mixing up a number of issues here:

  • Actual prohibition of encryption
  • Export restrictions
  • Patent claims

In fact, as I recall, the US versions of programs like Netscape Navigator/Communicator had "full-strength" encryption employing the patent-encumbered RSA technologies; most other countries got the "export-strength" encryption; countries like France had special encryption-free versions. I imagine that there may well have been programs used widely outside the US that would not have been tolerated in the US, but that would quite likely have more to do with patent claims than the other factors.

Yes, it's tempting to say "to hell" with the patent cartels, but doing so in their backyard while proliferating their technologies (and thus drawing vendors into having to support those technologies, thus funding those cartels still further) cannot be regarded as the most prudent strategy for an outfit like Mozilla.

Software patents don't exist in most of the world

Posted Jan 28, 2010 0:02 UTC (Thu) by roc (subscriber, #30627) [Link] (1 responses)

The assumption that H.264 is not patented outside the USA is wrong.
http://weblogs.mozillazine.org/bz/archives/020400.html

Maybe all the non-US patents are noneforceable, but that's at best unproven.

Software patents don't exist in most of the world

Posted Jan 28, 2010 14:53 UTC (Thu) by dion (guest, #2764) [Link]

Well, as the linked page says software patents are thankfully still illegal around here, but that's no reason not to avoid H.264, hardware vendors are still in as much of a jam as the US ones.

MPEG LA AVC/H.264 patent license text

Posted Jan 28, 2010 15:42 UTC (Thu) by DonDiego (guest, #24141) [Link] (4 responses)

Go to

http://apps.shareholder.com/sec/viewerContent.aspx?compan...

and look for the exhibits at the bottom

AVC PATENT PORTFOLIO LICENSE
MPEG-4 VISUAL PATENT PORTFOLIO LICENSE

That should provide for interesting reading.

MPEG LA AVC/H.264 patent license text

Posted Feb 2, 2010 16:17 UTC (Tue) by DonDiego (guest, #24141) [Link] (3 responses)

I extracted the AVC patent portfolio license and put it online for easy reference:

http://www1.mplayerhq.hu/~diego/avc_license.html

MPEG LA AVC/H.264 patent license text

Posted Feb 2, 2010 16:43 UTC (Tue) by Trelane (subscriber, #56877) [Link]

Thanks for the digging. Yay facts! :)

MPEG LA AVC/H.264 patent license text

Posted Feb 2, 2010 16:49 UTC (Tue) by Trelane (subscriber, #56877) [Link] (1 responses)

Pretty much backs up the assertion above that it's based on units, not sales for codecs.

MPEG LA AVC/H.264 patent license text

Posted Feb 3, 2010 10:39 UTC (Wed) by DonDiego (guest, #24141) [Link]

Also see the section about minimum volume and minimal fees, i.e. 0.

H.264 vs. Theora vs. Dirac comparison

Posted Jan 28, 2010 22:31 UTC (Thu) by DonDiego (guest, #24141) [Link]

Here is a professionally done codec comparison between H.264 (x264), Theora (libtheora) and Dirac (libschroedinger):

http://codecism.blogspot.com/2010/01/theora-vs-x264-vs-sc...

Let me quote the result:

Conclusion

PSNR and SSIM don't perfectly correlate to perceived quality. But they're close, and if anything the conclusion that Theora needs at least twice the bitrate to match H.264 in terms of objective quality measurements understates the effect of x264's psychovisual optimizations.

Blizzard: HTML5 video and H.264 - what history tells us and why we're standing with the web

Posted Jan 31, 2010 16:04 UTC (Sun) by sandifop (guest, #63283) [Link]

Geez guyz, it depends: I think the egg was first but it depends on your definition of chicken.

Theora patents

Posted Feb 3, 2010 1:34 UTC (Wed) by DonDiego (guest, #24141) [Link] (13 responses)

Theora patents

Posted Feb 3, 2010 20:27 UTC (Wed) by michael_ock (guest, #63333) [Link]

The latter two weren't filed until the time of release (or significantly after) VP3 (what Theora is based on) was released as open source, so there's your prior art.

Theora patents

Posted Feb 4, 2010 8:02 UTC (Thu) by silviapfeiffer (guest, #63354) [Link] (10 responses)

Just posting links to patents isn't actually proving anything - I could post a billion links and defending each one would be a futile effort. Let's be constructive with such discussions. If you really think these patents are being infringed by Theora, you should care to explain why you think so. Since everything about Theora is public, it's possible to have such a technical discussion publicly.

Theora patents

Posted Feb 4, 2010 15:11 UTC (Thu) by DonDiego (guest, #24141) [Link] (9 responses)

I'm being constructive and doing this in the open. Everybody else claims that "No patents apply, just *trust* us.", which is disingenuous. Why has nobody published the results of their patent investigations?

Theora patents

Posted Feb 4, 2010 16:07 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (8 responses)

You doing it openly has no value at all really You need lawyers to analyze
your claims and you will find that its hard to get lawyers to say anything
in public about this sort of analysis in general

Theora patents

Posted Feb 4, 2010 23:01 UTC (Thu) by DonDiego (guest, #24141) [Link] (5 responses)

> You doing it openly has no value at all really

Yes, it should really be done behind closed doors, just like software development and science. After that, when you have concluded your research, you tell nobody about it and just demand that everybody trust you. After all, why should they ever doubt your word.

> You need lawyers to analyze your claims

You want a lawyer to analyze whether or not Theora implements the technique described in the patent? What would qualify a lawyer to do that? Do you go see a lawyer when you feel a pain in your chest?

> and you will find that its hard to get lawyers to say anything in public about this sort of analysis in general

This is not specific to lawyers, it applies to all people that have something to hide.

Theora patents

Posted Feb 5, 2010 5:52 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

I wouldn't trust any "open analysis" of chest pain from you (especially there
is no analysis at all other than a bunch of links) either I would not trust
anyone not trained to do the work to get good results and your try if it was
actually one is ample proof of that If you want anyone to take you seriously
substantiate why these links mean anything at all or get someone like SFLC to
verify your claims

The reasons for lawyers not usually willing to talk about patent claims in
specific details in public is because their analysis can be used as a weapon
against the case they are trying to make and I am sure you will find out more
when you try and get SFLC to publish their interpretations if it is actually
specific

Theora patents

Posted Feb 5, 2010 9:07 UTC (Fri) by DonDiego (guest, #24141) [Link] (3 responses)

I haven't done any sort of analysis, nor did I claim to have done so. I just posted a bunch of links that we stumbled upon after a quick search. It shows that there are plenty of patents out there that are potentially infringed and that saying "Just trust us." is not enough. You'll have to come up with something better than an unsubstantiated promise.

If the patent analysis can be used as a weapon it's because patents are being infringed.

Theora patents

Posted Feb 5, 2010 16:27 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

You throwing a bunch of links really serves no purpose other than
unsubstantiated FUD Anybody can throw such links and if you make a claim
that a technology is patent encumbered the burden of proof is on you and not
on anyone else

There are lots of people including Xiph and Mozilla which have done such
analysis and their actions on distributing the codec is enough to show their
decision and your claim that the only reason not to publish it because there
is infringement is plain wrong and shows zero understanding of the issues
involved

Refer http://lwn.net/Articles/373094/

Theora patents

Posted Feb 5, 2010 22:54 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

I notice that you don't seem to be describing any of these 'issues
involved', only alluding to them. (Also, your . key has apparently failed
in the last few days. Sentences are much easier to read with the
occasional one in.)

Theora patents

Posted Feb 6, 2010 5:06 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

Yes indeed my keyboard has some issues and I need to get it replaced and
for now a few important keys are not working The issues involved were
described in the link and you could read that without having me repeat it

Theora patents

Posted Feb 5, 2010 21:21 UTC (Fri) by paulj (subscriber, #341) [Link] (1 responses)

But the organisations who have had their lawyers do this research and gotten
an opinion could publish it, no?

Part of the problem perhaps is that the waters between licence issues due to
patents risks and patent risks to distributors are not quite clear (it seems from
this discussion anyway). E.g. a possible issue here, I wonder, is that publishing
such legal opinion might help clarify risk generally, but not be helpful to the risks
faced by the publishing organisation?

Theora patents

Posted Feb 6, 2010 5:16 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

Any lawyer you consult with likely ask you not to publish their legal
opinions especially when the issue is patents If the other party knows the
arguments you are making then you are putting all your cards on the table
and they can make their counter arguments much more stronger and sometimes
twist your arguments against you

As a general case lawyers would advise their clients to never talk to the
police as well and it is not because you have something to hide

http://video.google.com/videoplay?docid=-4097602514885833865

Christopher Blizzard's reply

Posted Feb 19, 2010 20:05 UTC (Fri) by JoeBuck (subscriber, #2330) [Link]

Christopher Blizzard of Mozilla has posted a response. If he has his facts right, there is nothing to worry about.

Mike Melanson on HTML 5 video

Posted Feb 4, 2010 16:01 UTC (Thu) by DonDiego (guest, #24141) [Link] (1 responses)

I cannot help but post Mike Melanson's take on HTML 5 Video, the codecs used therein and how it competes with Flash. Humorous quote:
Another aspect I have to appreciate about the debate surrounding HTML5 video is the way that it brings out the positive spirit in people. Online discussions are normally overwhelmingly negative. But advocates of the HTML5/Xiph approach truly believe this could all work out: If Apple decides to adopt the Xiph stack, and if some benevolent hardware company would churn out custom ASICs for decoding Xiph codecs, and if those ASICs were adopted in next quarter’s array of mobile computing devices and netbooks, and if Google transcodes their zillobytes of YouTube videos to the Xiph stack, and if Google throws the switch and forces the 60% of IE-using stragglers to either change browsers or go without YouTube, and if Google thereby forgoes many opportunities to monetize their videos, then absolutely! HTML5 video could totally unseat Flash video.
Ironically Mike is both the main person working on the Linux port of Adobe Flash and the original author of the VP3 spec on which Theora was based. He always had a weak spot in his heart for fringe multimedia formats, but he surely had no idea what kind of genie he was letting out of the bottle there...

Mike Melanson on HTML 5 video

Posted Feb 8, 2010 11:29 UTC (Mon) by bawjaws (guest, #56952) [Link]

That's interesting, so when people are throwing around insults about how Theora
was based on an no good, brain-dead format that On2 only open sourced
because no-one would pay money for it, they're actually insulting the main guy
doing Flash on Linux. Funny how these thing go.

Strangely he doesn't seem very keen on the IETF working together with Skype,
Broadcom and Xiph to create a royalty-free audio codec standard for internet
applications either:

http://multimedia.cx/eggs/ietf-request-for-codec/

Possibly he's just developed a generalised dislike for hippy freeloaders from
his experiences developing Flash for Linux?


Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds