Google’s YouTube Uses FFmpeg | Hacker News Reader

Google’s YouTube Uses FFmpeg

multimedia.cx

92 pointsnaryad40 comments

I don't want to be snarky in response to an ffmpeg developer, because I love ffmpeg and respect his contributions, but still, this is not exactly news. The explosion of the entire category of "video sharing sites based on Flash" happened right after ffmpeg added FLV support.

That was the missing piece -- before that, you could only convert videos to FLV using Adobe's proprietary (and expensive and crappy and GUI-based, not command-line) tools. ffmpeg provided the missing chunk of the pipeline, and a lot of people had the exact same "aha!" moment, and within a short time a bunch of sites like launched (or converted to a Flash video player from a crappy "Click here for WMV, Click here for QT, now wait a good long time" experience).

ffmpeg didn't just help YouTube, it helped make the entire category of video-sharing websites go big.

This is great!

I think the bigger story is how much popular web applications are dependant on open source operating systems, libraries and programs.

Probably any that you've seen accept uploaded video from their users. My company's software is dependent on ffmpeg and a few other open source tools for converting and dealing with video. I don't accept uploaded video but I do a lot of transcoding and ffmpeg is excellent for that. I also use mp4box and handbrake if anyone is curious.

We use ffmpeg at Yahoo, and we used it at Associated Content to convert user's videos into FLV. ffmpeg + upload scripts is able to replace almost all of the manual time and 3 different Windows apps that editors used to do just to get a random video on the web.

Well... I also use FFmpeg to encode all the video that's presented on th iG (a large Brazilian portal+ISP) channel in Sony and LG internet-enabled TVs. It works really well.

If any FFmpeg developer is reading this, thank you for making our product possible. If you ever come to Brazil, the beer is on us.

I recommend Skol.

To me this illustrates that if you want to ensure that improvements to your code are shared back, you'd better use the AGPL license (http://www.gnu.org/licenses/agpl.html) instead of GPL.

Quote from the AGPL preamble:

It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.

edit: according to a comment below, Google is already sharing their improvements without being obliged to do so. Nice! You can't always count on goodwill though, so my point stands.

Chris Dibona has already co-ordinated the release of Google's patches to the FFmpeg community.

On the other hand, many companies avoid using AGPL code altogether. Code that isn't used can't be improved.

If they avoid it, it's because they are not ready to share the code. Thus their using the code is pretty much useless in the first place...

There are two kinds of enhancements to consider: Enhancements that are specific to your product and enhancements that are general to the library you're incorporating.

If Rails had been AGPL, every single webapp based on Rails would have to have its source code released. Now, Rails is not AGPL, does that mean that anybody using Rails (and not making their entire project open source) are "useless"? The vibrancy of the Rails community seems to disagree with that assessment.

> 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.

> 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.

> If they avoid it, it's because they are not ready to share the code.

Maybe they only can or want to share some of the code, not all of it. The AGPL prevents this.

That's the same argument people make against the GPL for normal desktop apps. And yet, GPLed software has been quite successful.

Google won't touch or integrate anything that is GPL licensed into their own products - especially AGPL. the linux kernel in android is the only GPL code you will find from Google, and even then they got a lot of criticism from FSF folks for deciding to license modules under a more liberal license

So if you are a developer and want to see your own library and code used by corporates such as Google and many others, a more liberal license is the only way to go.

If it is a javascript library or a web application, again, a more liberal license is the way to go since the FSF insist that a script include means your entire app must be GPL.

Using copyright law to force corporations and developers to become contributors and active participants in your software project is, to me, a ridiculous notion.

It seems like a personal choice to me. If you want companies to use your code internally, and are okay with the fact that they might make improvements that they don't release back (or think that voluntary releases will be sufficient), then GPL or BSD/MIT is fine. If you don't want to allow for proprietary forks of stuff used in webapp backends, then AGPL is a better choice. If you have a different set of preferences about how people use your code than either of those, you can keep it proprietary and just negotiate custom licenses with potential users.

AGPL seems like a particularly reasonable choice if you're running a SaaS and want to release your code, but also want to make sure no competitor can use your code as a starting point from which to leapfrog you without releasing the improvements back for your own use. That's the approach gitorious takes, for example. Of course, the other way to keep competitors from leapfrogging you with your own code is not to release it at all, or release it with a proprietary license--- the approach github and Dropbox and many other SaaS take. From that perspective, AGPL is at least more liberal a license than the "no code release" license.

> Google won't touch or integrate anything that is GPL licensed into their own products

ffmpeg is GPL, and it is being used in youtube. Isn't that the story here?

> Using copyright law to force corporations and developers to become contributors and active participants in your software project is, to me, a ridiculous notion.

So the fact that so many companies contribute to the Linux kernel has nothing to do with its GPL license?

Without the GPL there would be a "tragedy of the commons" situation: it would be best for the common good to share and avoid duplicated efforts, but it would be advantageous for individual companies to use the code but not share their improvements. The GPL fixes that by enforcing cooperation.

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.

> Using copyright law to force corporations and developers to become contributors and active participants in your software project is, to me, a ridiculous notion.

I don't really understand this sentence. No one is forcing anyone to do anything. There is code, and it has a license, and if you don't like the terms of the license, you don't use the code. Is it also ridiculous that that most software/movie/music/book creators use copyright law to "force" consumers to pay for their output?

This is absurd. We use Mercurial and Dulwich code in the project hosting site, and those are both GPL. We're very careful about where we allow GPL'd code, but we do use it quite a bit. Obviously, we're more paranoid about AGPL, but that's really a different license because of the extra restrictions.

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.

Yes I agree. What else could they possibly be using? And you're supposed to use it to convert videos ... what's the story?

MEncoder

Doesn't mplayer/mencoder also use libavcodec (i.e. ffmpeg) for many codecs?

GStreamer is another option. While support for some formats is provided in GStreamer by using ffmpeg, it has independent implementations for many formats and a very different architecture.

You can script Sorenson Squeeze through a command line but that's expensive software and was probably not available in the form that exists today when YouTube launched.

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.

I was under the impression (though I may be wrong) most standard video types are converted by some in-house closed source software developed by Google, but then if it's an odd/obscure format their software can't process they fall back on FFMPEG. Even if they do use FFMPEG I'd guess it's heavily modified to suit their needs/infastructure

Why would google want to reengineer and build closed sourced video converters? Especially when you need to pay multimillion dollar licensing fees to mpegla et al to even try to do such a thing.

If you touch a patented codec (in a country where software patents apply), you need to pay for patent license regardless whether you wrote the code yourself or not. Google must be paying for H.264 encoding already.

> Why would google want to reengineer and build closed sourced video converters?

To adapt them for their infrastructure and trade-offs. They are transcoding a lot of video. Zencoder for example modified their transcoders to encode multiple formats from a single decoded stream (I presume with ffmpeg you'd end up decoding same video multiple time during transcode into multiple formats).

I think you can use ffmpeg to decode to a buffer (memory or disk as needed), and the re-encode from that buffer into various sizes/formats. don't think you actually need a different encoder/decoder to do that. I may be horribly wrong though :)

My comment is somewhat off-topic.

Google is also using Aspose[1] for their Google Docs' Documents. You can see it's Aspose.Words for Java, if you read the source of the documents you download from Google Docs.

I've checked only for RTF and DOC formats though.

[1] http://www.aspose.com/

Anyone else want to see the ffmpeg command lines used for various conversions? I've looked before for them, but had no luck.

VLC is able to playback RoQ as well apparently. It was not able to skip through the video though. Also the film is 27 seconds but VLC displayed it as 1:46.

In any case, VLC can handle stuff like RoQ and that is why I love it.

VLC uses libavcodec from ffmpeg for many of its codecs.

Reply on news.ycombinator.com