Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google’s YouTube Uses FFmpeg

multimedia.cx

Post reply on HN
Print view View original

41–45 of 45 posts

Re: Google’s YouTube Uses FFmpeg

#41

Post by sovande »

dman wrote: post #36
Lol_Lolovici wrote: post #22

Earlier quoted context omitted.

FFmpeg can also be compiled with an LGPL license so it can be linked in commercial products. Also executing an external GPL library/binary from a commercial product (no direct linking) is not in direct contradiction with GPL terms (although it's a gray area where most companies would probably not want to go).

Can you elaborate on the gray area bit?

See the GPL FAQ http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

The last paragraph describe the gray area; i.e. if a proprietary program depends on- and combine a GPL program to perform its functionality it can be argued that the two parts are a combined work and hence the whole work must be licensed under the GPL.

Re: Google’s YouTube Uses FFmpeg

#42

Post by beagle3 »

mseebach wrote: post #26
wcoenen wrote: post #21

Earlier quoted context omitted.

> If Rails had been AGPL, every single webapp based on Rails would have to have its source code released. Platforms are a special case, where it is usually desirable to distinguish between the platform itself and stuff on top of it. That's why we have the classpath exception for Java: http://en.wikipedia.org/wiki/Classpath_exception#The_classpa...

I'd argue that ffmpeg belongs to the platform in a YouTube like usage scenario. Compare with ActiveRecord in Rails: Everything single thing your apps does depends heavily on it, yet, it's still just a piece of infrastructure.

It boils down to interpretation of what constitutes a "derivative product". I think it would be better if whoever used Rails and made changes to Active Record _had_ to share these changes (a-la AGPL), without having to share the app they built on top.

Similarly, it's better if ffmpeg users who offer a service based on ffmpeg were required by the license to share their ffmpeg modifications (the way Google already does without being required to) without a need to share the rest of the webapp.

Re: Google’s YouTube Uses FFmpeg

#43

Post by jon_dahl »

Andrex wrote: post #2

What else would it use? (Genuinely curious, what else is viable?) Although I think it uses libvpx for WebM, but who knows, they may have migrated to FFmpeg 0.6.

Tools like mencoder, On2 Flix Engine, and GStreamer are alternatives, but they share a lot of code with ffmpeg (including the ubiquitous libavcodec).

If you want to avoid this altogether, you have a few options, though none of them are as strong as ffmpeg, like Quicktime, Microsoft (Expression Encoder etc.?), and enterprise software or hardware (Rhozet, Inlet, etc.). But I wouldn't be surprised if enterprise appliances even incorporate libavcodec today.

Re: Google’s YouTube Uses FFmpeg

#44

Post by mseebach »

beagle3 wrote: post #42
mseebach wrote: post #26

Earlier quoted context omitted.

I'd argue that ffmpeg belongs to the platform in a YouTube like usage scenario. Compare with ActiveRecord in Rails: Everything single thing your apps does depends heavily on it, yet, it's still just a piece of infrastructure.

It boils down to interpretation of what constitutes a "derivative product". I think it would be better if whoever used Rails and made changes to Active Record _had_ to share these changes (a-la AGPL), without having to share the app they built on top. Similarly, it's better if ffmpeg users who offer a service based on ffmpeg were required by the license to share their ffmpeg modifications (the way Google already does…

> I think it would be better if whoever used Rails and made changes to Active Record[...]

But doesn't it at this point boil down to an academic argument? Surely Rails benefits massively from being popular, and draconian (which I consider AGPL) licenses might hamper its popularity. I doubt that Rails misses out on significant contributions just because they are not required. Contributing to open source looks good on a CV/employer branding page.

Post reply on HN