ffmpeg 和 libav的故事

The FFmpeg/Libav situation
One year and a half ago, an important part of FFmpeg developers decided to change the way the project was managed. This led to some kind of takeover, mainly to get rid of the old maintainer dictatorship, but also to change development methods, redefine objectives, etc. Then, for various reasons I will quickly explain, these people made a new project called Libav.

I will try first to summarize the most objectively as I can what was the situation, why it led to the current one, and basically how things are linked together. In a second time though, I will try to explain why, as a FFmpeg/Libav war child, I finally chose one side, and what it means daily.

How are MPlayer, FFmpeg, VLC, libav*, etc connected?
To understand well what's going on, let's do a quick summary of the tools and communities.

MPlayer and FFmpeg projects are originally two very close communities; both projects started around the same time (year 2000), and still share a lot of commons things (MPlayer uses FFmpeg API, a lot of developers were working on both projects, they were hosted on the same server, and more).

The FFmpeg project provides a few libraries to convert, play, stream, process audio and video (more information on the ffmpeg libraries here), and a few tools (ffmpeg for transcoding, ffplay for playback, etc), all of them making obviously use of these libraries.

MPlayer is basically a GPL video player, with its own demuxers, decoders, filters, etc. but at some point it made use of FFmpeg to lighten the burden of too much code maintenance.

I don't know the VLC project very much, though I know enough to say that they make use of the libav* libraries like MPlayer does, especially the codecs one (libavcodec). While MPlayer community is very small, VLC seems to have enough developers to afford for example the cost of writing a better© support for some formats than libavformat from FFmpeg.

Many other projects make use of these libraries (XBMC, Chromium, ...), you get the point.

How was FFmpeg development driven?
The FFmpeg development model was fairly simple: the biggest FFmpeg contributor (Michael Niedermayer, see stats) was the "self-proclaimed" maintainer, and basically had the last word in technical decisions, mainly because he's been the top contributor of the project. A bunch of other folks had write access to the repository, sent patches for review on a mailing-list (or not if it's trivial enough), and pushed it upstream.

What went wrong?
Like in many other FLOSS communities, there are a lot of strong personalities, huge egos, technical religions, etc. The multimedia community is not an exception, far from that.

As previously said, I started getting interested into FFmpeg around that time, so I can't comment on the exactness of the statements, but the main complaints I saw mentioned and remember from that time were about the project leader. It was all about "I do and commit whatever I want to", "I don't care about cosmetics", "I don't want to discuss with you in real life, mails are good enough", eventually discouraging newcomers, and his general attitude towards other developers (note: he was of course not an exception).

For more details, see Libav history.

Then, since a lot of active developers wanted to put an end to this, they decided to change the situation, not by forking to avoid the current state we are in, but thus, by removing Michael's and the other developers from the project who were not part of the new team. I let you imagine the problems it caused: some developers didn't understand, or understood very well and got angry and aggressive, but also a lot of people not being part of the team started to give their opinion for one side or another, insult each other, and basically a civil war started.

To make things simple, after trying to find a compromise, Michael and the remaining people in the FFmpeg team later decided to restore ffmpeg.org DNS and the Libav folks were "forced" to fork to have it their way. Things didn't go well, there were a lot of inflamed private exchanges I wasn't part of, with various threats.

After the fork, things actually got a bit more peaceful; no less hatred, but developers were busy bitching and trolling on their side, and then it likely became a messy and irrecoverable situation everyone finally somehow accepted.

Note that a lot of circumstances are not depicted here, the article would get way too long, but feel free to read the threads.

Sexy Libav
At first, even though I disagreed with the method used, I was actually pretty appealed by what could come out of this. I wasn't an FFmpeg developer at that time, just a MPlayer one, and a small FFmpeg contributor. And to be honest, being mostly detached from the project, it was actually pretty funny to see them acting like children, even though the situation was kind of serious.

The fork resulted in a real activity burst on Libav, while FFmpeg's future was not clear.

The development policy is different in Libav: no leader, every single commit must be reviewed and approved by a member of the team (even the most trivial one), with a serious desire of making things perfect. I was sending patches at that time, because it was worth giving it a try, there was some activity, people were nice, etc.

Being more active, I tried to stay neutral (actually, that's not that hard when you have no opinion on the matter) and sent some patches to both mailing-lists (mostly depending on the people being able to review my stuff).

What happened on FFmpeg?
While Libav left with the server, bug tracker, etc., the FFmpeg project was restoring itself, with the help of some VideoLAN people (the FFmpeg sources are now hosted on git.videolan.org). Michael also started to merge the Libav changes back into FFmpeg every 1-2 day, with a lot of forgotten, previously rejected, sometimes controversial features, or in stand-by such as ffmpeg-mt.

The main point here is that the fork stimulated the competition, and FFmpeg became a way better (IMHO) and more complete project. Also, I must say the leader's attitude completely changed, in a very good way. This is certainly one of the most positive thing that came out of that war.

Technically speaking, what's wrong with Libav?
I'm going to be a bit harsh here, sorry about that but I feel it's important to express it at least once.

I recommend by the way to read Why FFmpeg is “better” than Libav by Numbers but not in Reality which is a bit outdated but gives an opposite opinion from what's being said here. If I remember correctly some other Libav developers and contributors also expressed their opinion on this, but I can't find the links. Anyway, let's give mine, this is what blogging is all about anyway.

Libav is totally ignoring FFmpeg since the beginning (almost 2 years of development now). And this is of course not only related to features, they also don't give a damn about regressions they introduce, security issues (look for "j00ru" in the FFmpeg history for instance), and overall bug fixes. This is not 3-4 patches, there are hundreds of them.

At times, you can see them picking random stuff from FFmpeg, but they often re-fix them in their own way, taking the privilege to take the full authorship, suggesting it's trivial enough (this might be true, but looking for the bug is a contribution by itself, and implies recognition since it's sometimes harder than fixing the bug). Here are the last examples I spotted:
?ffmpeg:781fb46c5 and libav:12d42cd7a8
?ffmpeg:a9011623e and libav:0426c69310
?ffmpeg:788a60d9d and libav:e58b75f7ff
?ffmpeg:e3c267053 and libav:15358ade15

There is basically no recognition at all for FFmpeg, and they rewrite everything. Let's give some examples:

?ffprobe outputs: last year, Stefano and I worked on a way of improving ffprobe by making it output something else than the weird INI/XML by default. So we developed a simple writer system and provided a JSON output. At the same time, the feature was proposed as a hack on libav (they just hardcoded crappy printf calls all over the code). Of course, I suggested to just pick the commits in FFmpeg, but I was likely ignored (the hack patch as well). We then worked on adding XML, CSV, flat and various other outputs, most of them customizable through options. People started to use them, and obviously requested to the Libav folks the feature. The sane choice would have been to just pick what was already done. Instead, they decided to rewrite this from scratch, with the argument: "I don't like it". And by the way, they broke the default output "because it's evil and it sucks", and so breaking users scripts (without any version bump or anything). They also didn't even care to keep the same option names with FFmpeg so users could switch between tools easily (FFmpeg added the -of alias for compatibility).

?libswresample and libavresample: end of 2011, Michael wrote an audio library to do any sample rate, formats, layout, packing conversions he dubbed libswresample. Later on a few people contributed to it, for example to document or expose the API properly to the user. It was then integrated to the whole project (tools, filters), and greatly improved the audio support in FFmpeg. As usual, Libav completely ignored this for one year, and then decided to pay a developer (with the money of the FFmtech foundation) to rewrite completely a library for the exact same purpose. They tried to justify this. This obviously pissed off the users. Since FFmpeg has a much better policy toward satisfying the users, we also provide the libavresample API.

?Audio filtering: during this year FFmpeg integrated a lot of filters, especially audio ones. We were a handful of developers focusing on the filtering, so we wrote quite a bunch of useful filters. Nevertheless, they started to get interested in libavfilter as well, and between one or two rewrite-from-scratch trolls, they finally decided to just improve the API instead (smart move for once). Improving the API obviously meant ignoring FFmpeg and breaking the API several times. OK, I'm a bit dishonest since Libav actually brought some really good things in the process, but what I condemn here is their NIH syndrome (see for instance af_amix + af_join, and af_pan + af_amerge) which hurts everyone.

...and certainly more: I only mentioned things I was directly concerned here, but it is likely other developers can raise some similar issues.

The main problem is that external projects who want to support both FFmpeg and Libav are just fucked, and this only because Libav doesn't care a second about their users.

I think this is more a pride issue than anything else. They just don't want to consider FFmpeg and they want it to disappear. If you want something in Libav, you have to submit them directly: with FFmpeg's daily merges and most developers not wanting to do the work twice, they can afford to just ignore everything and still have some contributions…

If you want an overview of the amount of things FFmpeg getting in, it's pretty easy: since most of work done on FFmpeg is ignored from Libav, it's safe to say that the commits listed below are most likely not in Libav:
?Carl Eugen Hoyos commits
?Marton Balint commits
?Michael Niedermayer commits
?Nicolas George commits
?Paul B Mahol commits
?Stefano Sabatini commits
?mine...
?...and many others.

Colors preferences
Also, overall, I don't agree with the development methods of Libav, but this is mostly a taste issue. To make it simple, I believe the process of sending a patch for everything like fixing a trailing whitespace is a complete nonsense. And this is actually discouraging developers you trusted with a write access to the repository, and treating them like children. This is not efficient. And I tend to think that when you maintain some code, it's good to be able to fix things quickly without bikeshedding.

How come Libav is so widely spread then?
I have a few ideas in mind, the main ones being:

The Debian/Ubuntu packager is on Libav side (see by the way the distribution status on their site), and obviously they distribute Libav packages. But they are also using this to spread a very destructive lie:

ffmpeg version 0.8.3-6:0.8.3-4, Copyright (c) 2000-2012 the Libav developers
  built on Jun 26 2012 09:26:41 with gcc 4.7.1
*** THIS PROGRAM IS DEPRECATED ***
This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.
[...]

This is obviously false, and even more wrong in the sense that they are still using the "ffmpeg" name for the package. It looks like it's been "fixed" on Ubuntu but it's still present on Debian here.

This propaganda certainly hurts the FFmpeg project a lot.

Note: FFmpeg is providing ff* tools, fully compatible with the av* tools from Libav (avconv, avplay, ...), with additional features, bug fixes, but also backward compatibility for some options Libav decided to remove.

The fork doesn't exist
I believe the fork is not a bad thing, of course assuming Libav accepts being one. But Libav is presenting itself as a FFmpeg replacement, or rename and not a fork. Basically, the spirit can be summarized with:
?"Libav is the upstream"
?"Libav is doing all the work"
?"Everyone is on Libav"
?"Who cares about FFmpeg? It's a downstream fork with no important work"

(Of course, FFmpeg has 1k+ post per month on ffmpeg-devel mailing list, for patches and miscellaneous development discussions).

This attitude makes the users believe FFmpeg is not that an important project in comparison to Libav.

Real-life meetings
The group behind the takeover is basically composed of kinfolks, knowing each other very well, and actively participating to various "commercial" or developers meetings. They also believe talking in real life is the way of solving every human and technical problems (but also like to ignore the mails and IRC talks they don't like).

Thus, they are widely known by the mainstream, since the social dimension is an important thing for some users.

So what comes next?
I'm unfortunately not yet able to predict the future, but concerning myself, I'll just continue to do the best I can to make FFmpeg a better project, but of course still following closely all the great things Libav developers are able to produce.

A project reunification is clearly difficult to reach soon. FFmpeg made choices Libav will never accept (such as the MPlayer filters wrapper in FFmpeg). On the other hand I think both projects could be kept in sync somehow (if Libav wakes up someday), with different methods of development, and even different goals: FFmpeg can be trying to support even more crazy exotic formats while Libav could decide to drop some because it is a "maintenance burden". It's a good thing to affirm these differences for both sides ("we support everything" vs "we have less crap"), what isn't is their contemptuous behaviour towards developers and users.

[原文链接] http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html