Issue 21318  being fixed would allow for a pluggable libffmpegsumo.

Thought I should mention that Opera also belongs in the list of data points:
http://my.opera.com/core/blog/2009/12/31/re-introducing-video

I agree, it would be nice if not every program tries to implement video playback 
capabilities from ground zero, but reuse some already existing architecture. I am still 
using MPlayer (as an ex-developer of it) to watch movies, but I can say, that choosing 
gstreamer is still better solution than other, and at least a typical desktop can 
benefit from the multimedia capabilities need to be implemented only once. Just imagine 
how "funny" to "teach" a system for a new codec, if you need to modify/hack (and or 
install codec package) for every single softwares using their own solutions. Brrrr ;)

An important reason to use platform media frameworks (gstreamer on linux) is that
they will take advantage of hardware decoders - which may be essential on netbooks.

Another data point is TANDBERG Movi, which is a professional video conferencing 
product supporting HD video and Echo Cancellation:
http://en.wikipedia.org/wiki/Tandberg_Movi

This would be great! 

And just out of curiosity, would it be possible to use webkit-gtk? 

It would be nice to share the media player between Chromium and WebKitGTK+ yes ;)

Hey everyone,

Thanks for sharing your concerns.  I understand that support for pluggable codecs would be very cool, but it's in direct conflict with Chrome's 
security sandbox and goals.  Dynamically loading and executing codecs at run-time is something the sandbox explicitly disallows.  The alternative 
of loading all gstreamer codecs at start time hurts new tab/startup performance too much.  Finally, support for gstreamer on Mac/Windows isn't 
quite at the level as it is on Linux, and writing three separate backends (DirectShow, QuickTime, gstreamer) would further complicate the 
implementation and provide inconsistent results across operating systems.

In summary, we really wanted Chrome to behave and run the same on all platforms and have all media playback happen inside the sandbox.

Scherkus, you're talking about Chrome, but this bug is filed against Chromium.  If you 
take off your Chrome hat, I'm not sure the same arguments have the same weight.

Hmm, switching Chromium's Linux backend should not require writing new backends for OS 
X and Windows. Also, do you consider gstreamer to be an attack vector for the sandbox?

Scherkus: GStreamer is not that heavy-weight, since libgtk is already loaded in the 
process the main library GStreamer brings in is around 300k-400k stripped without 
debug info. The codecs and wrappers are already present in ffmpeg so they should be 
of no concern. 

From a Linux point of view, GStreamer would give chrome/chromium many advantages such 
as proper integration with all kind of audio hardware (pulseaudio), video 
acceleration (vaapi etc), third-party legally licensed codecs (from fluendo) and a 
legal way to ship chromium on Linux distributions and still be able to support patent 
encumbered codecs on demand such as H264.

Both Opera and Songbird are using GStreamer on both Windows and MacOSX, so it should 
be mature enough for the use cases Chromium needs.

Sandboxing is not at all about guaranteeing safety *within* the sandbox per se, it's 
about containing security exploits so their reach is limited *across* the sandbox 
boundary -- in fact the sandbox philosophy is "distrust everything by default, from 
the point of everything else".  If the video player is a potential security hazard 
that should be separated from the renderer and/or rest of the browser, it just needs 
to be put in its own sandbox (like all plugins will eventually have to be).

I believe that currently the Flash plugin is not even sandboxed on Linux (maybe I'm 
wrong? It is supposed to be sandboxed on Windows..) -- or at least it seems to be 
able to crash the renderer process, which a sandboxed plugin should not be able to 
do.  This really implies that the current situation is no worse than adding Gstreamer 
to Chromium -- and if the situation has to be (and can be) fixed for Flash / Java / 
totem / vlc / other plugins, then it can be fixed for Gstreamer too, even if 
Gstreamer doesn't run as a plugin but somewhere in the core.  It just has to be 
treated the same way as any other part of Chrom{e|ium} security-wise: untrusted by 
default.

PS I don't understand the comments about having multiple platform-dependent backends 
being a problem either -- there are so many parts of Chromium that are platform-
dependent currently that could/should be based on portable code, pushing the platform 
dependencies down to a lower level.

I am really not an expert about chrome/chromium, but flash player for example also a 
dangerous stuff, maybe even more dangerous, since we can't know what is inside it. So 
in the spirit of flash plugin, isn't it possible to run the "video play" part as a 
well separated process? then no more threats than with flash, and even if gstreamer 
has exploitable bugs, it can't affect the other parts of the browser, since the 
process level separation. Or something like this. The world moves into HD content, 
more codecs, even 3D soon video soon :), so it will be extremly difficult soon to 
support all features without some centralized infrastructure. Also what about the hw 
acceleration? Chromium wants to implement all of these alone?

Before this misconception becomes too widespread, please know that FFmpeg has
hardware acceleration infrastructure (HwAccel) and support (vaapi, vdpau, xvmc, dxva).

I love how well ffmpeg works and don't have any emotional attachment to Gstreamer -- 
the only reason I personally voted for this bug is I want there to be an easy way to 
get HTML5 video working in Chromium on Fedora using RPM repositories.  Currently for 
Gstreamer apps that would entail just having to add one of the rpmfusion repos to get 
the patented codec support into Gstreamer.  However as long as someone re-builds 
Chromium with ffmpeg support and adds it to rpmfusion, then it will be just as easy 
to install as Gstreamer codecs.

I have heard that the ffmpeg codebase and upstream community are not super easy to 
work with, and it's a huge codebase, so I would still be concerned about ffmpeg being 
in core if it's not properly sandboxed -- whether or not it has any sort of plugin 
infrastructure.

>> However as long as someone re-builds Chromium with ffmpeg support 
>> and adds it to rpmfusion, then it will be just as easy to install 
>> as Gstreamer codecs.

I disagree. For one, we should really have *the* best browser available in the 
official Fedora repo - an not just a version with all video functionality removed. 
Some 3rd party rebuilds (lagging behind some days etc) won't satisfy most users.

There's always another solution: going the Mozilla route and not supporting H.264 etc 
in Chromium as well as Chrome...

@rsbultje yes, but can chromium use it really now while playing some video presented 
with html5 video tag? I meant that, at least I can't see any HD with flash, so slow. 
Native video with chromium is a _bit_ better, but MPlayer simply so much more resource 
effective, even if it's used ffmpeg codec there too, and I played through the network 
in my "test" too.

The fact that flash cannot be sandboxed is no excuse to have html5 <video> operating 
outside the sandbox.

It is also important to understand the spirit of the <video> and <audio> tag. It 
should just work, like <img> tag and not be subject the installed codecs. 

We also understand the h264 vs others issue which is unfortunate but from the 
chromium we are just developers and we need to cope.

If the problems are - and are only - technical ones. Could we please have a description of what exactly would be necessary for 
GStreamer to be used within a sandbox.

Limiting the plugins that get loaded would probably be one, but I'm not sure whether you wouldn't end up with the same sort of 
problems with ffmpeg if you start hitting hardware, for either sound or video decoding.

Having a list of the necessary changes is probably a good goal to work towards for other browsers and GStreamer users as 
well. And I'm sure it would interest the 67 people that subscribed to this issue.

Thanks

>> It is also important to understand the spirit of the
>> <video> and <audio> tag. It  should just work, like
>> <img> tag and not be subject the installed codecs.

This is only achievable if <video> and <audio> imply some particular codec.  Sadly, 
they do not, so this cannot happen.  No browser vendor is going to ship support for 
every possible codec.

The best way, then, to achieve "just work" status on the <video> and <audio> tags is 
to support the ability for the user to supply their own codecs in the case where the 
browser vendor cannot.

Lastly, since we're talking about Linux users here, the idea of having something 
"just work" is relative.  ;-)

@hadessuk: the general approach when you want to sandbox a piece of software is to 
split it in two parts, the one inside the sandbox touches the bits delivered by the 
network and decodes + validates the complex format, then the data is converted in the 
simplest format it can be used. This format is send over shared memory to the trusted 
piece which operates on this format and can touch the hardware.

If the case of video, a good candidate for the shared format is unscaled YUV, then 
the trusted piece will use the GPU to do the scaling + toRGB + present part.

I know that is not the ideal workload split bettween CPU and GPU but it is a solid 
start, works for many platforms and gives you a good deal of acceleration.

As a Linux user I'm actually used to video playback "just working" which I can't say 
is true when I'm stuck on Windows or MacOS. When I was at Songbird we invested a lot 
of time and money getting GStreamer working well on Mac and Windows so that other 
platforms could have the same kind of seamless media support we've come to expect on 
Linux.

So could we achieve proper sandboxing by limiting the inner part to just demuxers and 
decoders? (And a special sink that sends the data to the other part for processing and 
displaying?)

Maybe someone could do a feature request for sandboxing in the Gstreamer bugtracker, 
they might consider implementing it in a cross-platform way for increased security in 
all Gstreamer apps.

I don't think such a model would work for all apps. Running decoder and renderer in 
two separate processes includes additional latency as you have to keep at least a 
minimal buffer on both ends not to run into problems when the other process becomes 
IO-bound for example. Let's concentrate on getting a proper list of Chromium's 
requirements.

Having bought Fluendo Codecs this would be great. 

Opera is going this route too see http://my.opera.com/core/blog/2009/12/31/re-
introducing-video. Cross-platform support does not seem to be far away.

BTW, for those asking about RPM support, the Google Chrome RPMs support h264 natively.

http://www.google.com/chrome/eula.html?platform=linux

Yes well, the problem is that chromium can't be included in any US based distribution 
because ffmpeg has quite a few legal issues.

I would much rather have Chromium included in the distribution repositories, but unless 
the HTML5 <video> and <audio> backend issue is solved, Chromium builds for distros like 
Fedora are going to be crippled.

Gentoo? *BSD? OpenSolaris? Arch Linux? All with h264? Packaged following FHS with 
system libraries (where appropriate) which get security updates. On ubuntu I wouldn't 
dare to recommend installing packages of the website above, use the ppa instead it's 
better for you. Not sure how good the rpm's are but deb's will make any package 
maintainer faint.

The only way you can get proper support on linux/unix distros is to get distros on 
board to do the packaging. Which gives you a lot of developers, support and QA on 
board.

Please someone comment how good rpm's from packaging point of view.

Oh and the binary blobs on that page do not have source code, and the branding is not 
free either.

Do you want the market share of Fedora & Ubuntu? This distributions are the type that 
can potentially switch to Chromium as default browser. Wouldn't they significantly 
increase your market penetration on the desktop? Even if you don't use this feature 
on Android, ChromiumOS, Mac and Windows. All of which can do GStreamer.

"and writing three separate backends (DirectShow, QuickTime, gstreamer)" you can 
strip the gstreamer plugins and plugin only gstreamer-ffmpeg and sandbox plugin codec 
for h264 separetly.

"it's in direct conflict with Chrome's security sandbox and goals"

And it has been offered to modify gstreamer/* to fit your needs just tell us what 
those are. You wouldn't want us to break into those forcefully, do you?

what i have to say is that i've tried out chrome on windows and i hate it, i've tried 
chromium on linux and i love it. now, if chromium is like an opensource derivate of 
chrome why not allowing the community to develop and improve it? 
having the requirements for a process to be sandboxed should be just fine, and on top 
of that i expect that not only gstreamer but also xine and vlc would provide their 
sandboxed implementations.
as for the gstreamer not being equelly developed on the different systems, then check 
out vlc backend: it's working very well, and with a lot of people using it on linux, 
windows and osx. it also seems to be the fastest player/backend on windows, very fast 
on osx (i have friends using it often and they're saying that it's faster than 
quicktime) and on linux is well developed. vlc is also present in boxee and xbmc and 
this would permit chromium to be delivered also on multimedia boxes as default 
browser. so if i were to consider a backend that is more or less equelly developed 
and working on the 3 main oses, instead of directly using ffmpeg i'd consider vlc 
instead of gstreamer. 
another big problem of using directly ffmpeg is that it's often updated and many 
times it breaks the old api, so using it directly inside chrome would put developers 
in a condition in which their effort to maintain the api breakage would increase 
leaving them with either just provide an old, maybe insecure, ffmpeg version or an 
additional effort to fix this api breakage. in this case removing the direct dep on 
ffmpeg would allow the browser to not care about this api breakage as long as the 
backend would not expose it, and this would be a great gain in the browser 
development.

@givemesugarr VLC, XBMC, and Boxee all use ffmpeg for their codec implementations.

And all of them cannot be included in distros because they use ffmpeg. Chromium is a 
great web browser. It should not be restricted from distros or crippled when included 
in distros because of the codec engine for HTML5.

@dmitrij.ledkov: See comment #23 for the general requirement you ask. I you want more 
details feel free to look at the source code. The integration ffmpeg and chrome is 
clean and understandable. There is no master "needs" list.
 
>>"You wouldn't want us to break into those forcefully, do you?"
... I don't know what to make of this. Maybe my joke processing unit is broken.

@sandfordarmstrong: vlc uses ffmpeg libraries, as happens also for gstreamer, xine 
and most of the backends in linux, but vlc is not limited to the ffmpeg codec use as 
far as know. this means that if you have other codecs, like the win32codecs used to 
be, you can add them to the vlc codecs. also for what i can recall about vlc, from 
ffmpeg it mainly uses the muxers and demuxers. 
boxee has an inhouse player, derivating from the xmbc player, using ffmpeg, but it 
can have vlc installed and it does also support mpeg-2 via libmpeg2 and dts via 
libac3/liba52 and libdca/libdts. 
xbmc *doesn't* use directly ffmpeg, but uses mplayer for playing, which uses ffmpeg 
engine.
so, since, almost everyone in linux is using an implementation of the ffmpeg 
mux/demuxers and codecs, it's pretty true saying that vlc, xbmc and boxee are using 
ffmpeg codec implentation... but it's also true for gstreamer, xine-lib and all other 
backend projects in linux.

@ngompa13 ffmpeg doesn't only implement closed source codecs. distros just compile it 
with the support they want and are permitted to deploy and then everything is solved. 
if i remember well, on suse and fedora, ffmpeg and xine are provided with only free 
codecs, and then there's the availability of full featured versions of these packages 
in packman or other semiofficial repositories.
the same approach could be used for chromium: compile chromium against a stripped 
down version of ffmpeg and provide a full featured version on a semiofficial 
repository.
what i cannot understand is why, when i build chromium from source it seems like i'm 
not using the system ffmpeg library, but a stripped down one. i have all codec 
support in ffmpeg but when o compile chromium from source it seems that it's 
compiling against a different libavcodec version which is built without h264 support.

givemesugarr:

Disabling codecs in distro builds and telling people they can always use illegal 
sources (external repos that ignore the patents and licenses and recompile with h264 
enabled) is not a solution.

Installing Chrome/Chromium from Google's repositories is also not a solution as it 
(1) does not work on all distros and (2) is likely to break your future upgrades. 
Especially as their packaging-fu is weak.

Please refrain at any and all cost from calling FFmpeg sources illegal.

Aren't we all on the same side?!

rsbultje:

It seems you fail to differentiate between sources and distribution of a binary made 
from those very sources. In countries where almost all parts of h264 are patented 
(luckily not here in Poland) you are not legally allowed to distribute binaries that 
use ffmpeg with h264 support enabled. Google is paying the license costs so they're 
fine with using ffmpeg in Chrome. Distros are not able to pay such licenses so we're 
obviously not fine with the current state of things. For us it's either no Chromium 
or Chromium with no h264.

Fluendo codecs came with my Ubuntu Dell... and my mom's.

@patrys: very succinctly put.  I couldn't agree more: your point reinforces the 
argument in bug report.  I personally also think that using gstreamer as a backend
would allow the maximum flexibility as it could provide the codecs that are available
on the client machine without reinventing the wheel and introducing direct
dependencies on patent-encumbered codecs.  I really hope that you chromium guys
reconsider your position, this along could well prove to be major stumbling blocks
for an uncrippled chromium being widely available in the major distros' repositories.

@patrys: i'm not by *any* mean saying that the sources are illegal!! it's illegal, in 
some states and countries, to distribute binary patented packages. the packaman repo, 
for example, is distributing the rpm for the countries where there aren't patent 
problems. this is different from saying that they're illegal packages. the source 
code of ffmpeg and of all the other codecs are legal and protected by the gpl/mit/ecc 
licenses. the distribution of binary of these packages in some countries is not 
royalty free, though. 
anyway, even in the countries where you cannot distribute binary packages, nobody 
prevents you from manually compiling ffmpeg from source and then recompile chromium 
for example to have a full working multimedia environment and still not violate the 
law, as long as you're not distributing the binaries you've compiled.

givemesugarr:

So in short your proposition is to force the user to recompile the browser with each 
and every release? Would you tell your grandfather to compile himself a fresh git 
master? Are you serious?

patrys:
There is no need to compile a fresh git master. You can always compile a stable 
release. And this is exactly what Gentoo does. And that is only if you live in a 
country that recognizes software patents. European grandfathers won't have to compile 
themselves.

givemesugarr:

Fedora can't do that. With software patents, both source and binaries can get you sued. 
That's why the ffmpeg source code is stripped out for Chromium builds by the Fedora 
guy.

I want a Silverlight-style community pledge from the H264 patent owners that they will 
never sue the distributors or users of any open source or Free Software decoder for 
H264.

That will never happen. The MPEG-LA's only method of making money is through the 
patents it has on all the codecs it developed a decade or so ago.

They stand to make a TON of money off the people _encoding_ media if it becomes the 
unchallenged standard for HTML5 video, so I don't see why not.

>> They stand to make a TON of money off the people _encoding_ media

Sorry, but this is even _worse_. And let's try to stay on topic.

> so in short your proposition is to force the user to recompile the browser with 
each 
> and every release? Would you tell your grandfather to compile himself a fresh git 
> master? Are you serious?

no. first of all i don't think that my grandpa would try to install stuff... i would 
have the system updated for him myself once every 2 weeks. it would take about 2-3 
hours once every 2 weeks to keep it updated and clean and he would just use it. your 
example is not a good one since i don't think that there are so many old users using 
linux, and about them o don't think that would be able to install every stuff... to 
not think about the damage they could do to the system if i were to give them the 
root password...
also git master is only for bleeding edge system and development testing. you should 
only recompile stable releases of the browser and eventually recompile old releases 
after a new backend/ffmpeg release. gentoo stable tree does this: usually in about a 
week you shouldn't have more than 2-3 stable packages to compile and the compilation 
system is foolproof and sandboxed.

>Fedora can't do that. With software patents, both source and binaries can get you 
>sued. 
>That's why the ffmpeg source code is stripped out for Chromium builds by the Fedora 
>guy.

well, this is true, but if they sue the source packages, they'd be suing the project 
and not fedora, so the project would fix the issues, if the judges issues them to do 
so. so the sources aren't really a danger and the main problem with patents for 
distros *would be* the distribution of binary packages in certain countries which are 
usual to enforce patents. 
now, i'd really like to know this: does really chrome pay for being able to 
distribute it's software with the patented ffmpeg h264 decoder/demuxer in every 
country where it's required to do so?! well, if so, then it's ok. if not, why do 
google hasn't instead chose to put videos in a free codec so that he shouldn't be 
paying anything? if i recall correctly the w3c has standardized theora, which is 
patent free, and not the *non free* patented h264. so why not using free standardized 
codecs but closed source ones? but maybe i'm not so well informed on the matter.... 
so, returning to the original topic, in my opinion, for a lot of reasons, 
chrom{e|ium} it should be implemented not directly on the ffmpeg codecs, but on a 
backend, that has different codecs since it would not only relieve developers from a 
bigger burden (they'd just need to call upon the backend exposed interfaces, instead 
of reimplementing them) and users from a difficult configuration and setup process.

>no. first of all i don't think that my grandpa would try to install stuff...
>(snip)

Pardon me, givemesugar, but I think it's obvious that the majority of people here
(and in FLOSS) in general desire this utopia about achieving the "year of the
Linux/FLOSS/you-name-it desktop" to come true eventually, and this cannot happen if
we need a chromium-developer/linux-semi-expert/you-name-it administering every linux
box out there. We need to get (keep) installation of programs easy.

>now, i'd really like to know this: does really chrome pay for being able to
>distribute it's software with the patented ffmpeg h264 decoder/demuxer in every
>country where it's required to do so?! well, if so, then it's ok. if not, why do
>(snip)

Well AFAIK On2 owns these patents and AFAIK Google has acquired this company (or has
intention to) so they have either stopped paying or will eventually...

Furthermore, according to some sources[1], it seems Google ditches free codecs such
as theora in favor of H264 because of performance (which is somewhat logical given
their acquisition/intention).

[1] http://robert.accettura.com/blog/2009/07/06/debating-ogg-theora-and-h-264/

s/performance/quality

On2 doesn't hold patents for H.264. They hold patents for the VP* codec series. Theora 
itself is originally based on On2's VP3 codec. Flash itself supports the VP6 codec. 
Their newest codec is the VP8 codec. 

The reason why Theora is considered safe is because On2 released a RAND royalty free 
license for the usage of VP3 and contributed the VP3 codec code to Xiph. That is the 
basis of Theora.

This is the licensing I can find for the Chrome browser installed on Ubuntu Hardy is
at /usr/share/doc/chromium-browser/copyright.

These packages (including h264 support) are available from 
deb http://ppa.launchpad.net/chromium-daily/ppa/ubuntu hardy main
deb-src http://ppa.launchpad.net/chromium-daily/ppa/ubuntu hardy main

Unless I'm missing something (it's a big file) source code filenames that refer to
h264 are all licensed under the LGPL. 

1. Apologies if this is a dumb question but: how is shipping (or making available for
download) binaries of an LGPL-licensed implementation of h264 compatible with a
patented technology?

2. There is no mention of MPEGLA at all in this file.  My understanding was that
licensed distribution of h264 also requires distribution of a particular mandatory
statement from MPEGLA?

3. People seem to be saying that shipping ffmpeg with h264 support in a distro is
fraught with possible legal issues but that making ffmpeg with h264 support available
for download is not.  I don't understand that.  What is happening here, are these
binaries being hosted in some country where h264 is not patented?

@wdef200:

1. It isn't. Patent licenses are normally independent of software licenses.

2. You are correct.

3. In the case of Ubuntu, Canonical is a UK company, which has different laws. The 
reason ffmpeg is such a legal gray area is because some countries declare it illegal, 
and others don't. In the case of Fedora, a distribution sponsored by US company Red 
Hat, Inc., ffmpeg is damn near impossible to include in the distribution, because the 
United States unfortunately currently upholds software patents.

@ngompa13: thanks

Re (1):  since the LGPL is copyleft, it is not possible to restrict this distribution
of an LGPL-licensed implementation of H.264 which means it is in direct conflict with
the patent holder's fee-based licensing. Correct?

If this is the case, and considering (2), I'd say Google do not appear to be paying
royalties to MPEGLA for the distribution of H.264-enabled ffmpeg (or rather
libffmegsumo).  Would MPEGLA even go along with distribution of an LGPL'd implementation?

>Pardon me, givemesugar, but I think it's obvious that the majority of people here
>(and in FLOSS) in general desire this utopia about achieving the "year of the
>Linux/FLOSS/you-name-it desktop" to come true eventually, and this cannot happen if
>we need a chromium-developer/linux-semi-expert/you-name-it administering every linux
>box out there. We need to get (keep) installation of programs easy.

i agree with this utopia, but what would think about someone who downloads and
installs a browser that is meant to have some functionality and then discover that it
doesn't has them?! i think that this is another reason why to strip out the codec
part from the browser itself and use an interface to the backends. i really think
that doing this would increase distros' interest in packaging chrom{e|ium} in their
repos. this leads me to a consideration i've seen past the years: software developers
don't always collaborate with distibutions' packagers and this is a bad thing. i
think that packagers would agree to help out with identifying everything they would
need to help developers package at best their software and so the user experience
would be much more impressive, since the packaging of a program would not be
delegated to developers but to the distributions' packagers. there are too many
different distros around, with too many different libs installed and trying to
package something that would run on *a lot* of different distros, which use a lot of
different gcc flags and other custimizations, would mean loosing too much time and
resources in doing it, and would provide a less than optimal product. 
but this at the moment can't be done since the patent issues still blocks various
distros. so delegating it to the distros, by using one of their standard player
backend would permit a much more penetration for chrom{e|ium} in linux environments. 

Please stop accusing Google, they do pay the license fees and they are allowed to 
distribute h264 decoders along with their products. It does not matter if the decoder 
is LGPL or not since the license is non-transferable and if you recompile the sources 
you need to buy a separate license.

The problem is not about accusing of Google breaking some law, it's about letting 
distros distribute Chromium without breaking the law.

@wdef200: MPEG LA doesn't really care what license the implementation is under as
long as they get their license fee. What is more in question is if Google violates
the LGPL by distributing LGPL code and at the same time pay a patent fee for the
methods in that code. Most software licensing lawyers would say they are, but in some
sense that doesn't matter as long as the ffmpeg developers are not complaining. Of
course someone downstream could test out the strenght of the LGPL by trying to get
google to also pay the patent fees for their use of libffmpegsumo. Would be
interesting if that happened.

@patrys: right, my apologies, I jumped to conclusions.  So Google have said they are
paying an h.264 royalty to MPEGLA for every download of Chrome from their servers, or
they have some sort of unlimited distribution license?

@christian.schaller:  mmmm .. have to digest that.

Thanks - personally I'm not in favor of sw patents but I am trying to understand
these issues with regard to Chrome.

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.