[FFmpeg-devel] Reintroducing FFmpeg to Debian

Timothy Gu timothygu99 at gmail.com
Thu Aug 21 05:11:07 CEST 2014

Hi Attila,

I will do a small self-intro, as you most likely don't know me: I am a
high school student who mainly writes documentation for FFmpeg, but
sometimes do small code fixes and patch review (mainly related to
documentation), both for FFmpeg and Libav. I sent my first patch to
FFmpeg last year in March. I don't know much about the split, but I
have read the most important discussions on ffmpeg-devel on the split.

On Wed, Aug 20, 2014 at 6:52 PM, Attila Kinali <attila at kinali.ch> wrote:
> On Mon, 18 Aug 2014 13:42:36 +0200
> Nicolas George <george at nsup.org> wrote:
>> The reason for switching from FFmpeg to libav in the first place just after
>> the fork is much simpler than that.
> Yes, the reason was that Reinhard, who was the maintainer of the
> ffmpeg package back then, was on the libav side after the split.
> BTW: for those who do not know. Michael raised the issue of
> the ffmpeg -> libav switch at ubuntu back then [1]. The technical board
> decided to go with the decision of the package maintainer [2,3,4].
> I think most people will find [3] the most interesting, as it explains
> why Reinhard thought (and still thinks) that libav was the better choice.

Most, if not all of the reasons in [3] have been eliminated, so
bringing this up only causes more confusion.

Also, the discussion appeared during a time when FFmpeg had flamewars,
mainly from Libav developers. Because the split was just forming,
FFmpeg was not that different from Libav then. It is not fair
therefore to compare the two projects at that time. However, there are
technical advantages towards FFmpeg now.

Also, keep in mind that Debian cares about maintainable (and
maintained) code **now** more than how a project leader behaves (or
rather, behave_d_).

I will now quote and explain how Reinhard's mail does not apply to the
current FFmpeg/Libav situation.

Reinhard Tartler wrote
> On various occasions [Michael Niedermayer's] quite strict rules on code
> quality and reviews doesn't seem to apply to him

This has not been the case since the split (at least within the past
year, as I joined FFmpeg last year). There are still some post-commit
oopses, but not nearly to a level that brings a discussion among

> After the fork, Michael has insulted almost everyone involved with
> founding Libav at least once, used libel and death threats as 'jokes',

I don't mean that I don't believe your insulting story, but there is
no public mailing list archive or IRC log or anything that supports
this. Even if Michael did these terrible things, he is certainly not
doing it now. The only "insult" I can find is in the thread you
mentioned https://lists.ubuntu.com/archives/technical-board/2011-May/000900.html
, which is an insult from Mans Rullgard, a former Libav developer and
former former FFmpeg developer.

> but OTOH keeps merging the work done at Libav both with and without
> insults.

I am interested to see any evidences to back up this statement. Note
that Michael does sometimes express disagreement with Libav commits,
but that's only because of technical issues, at least within the past

Also from this quote Reinhard seems to not like the spirit of LGPL...

> Interestingly, his standards and attitude to external work have
> totally changed: He has committed his mplayer filter wrapper despite
> predominant rejections,

This is one of the most significant sources of new filters, and one of
the reasons users (like me) use FFmpeg.

> ffmpeg-mt has been merged (partially with wrong
> attribution!)

I can't comment on the mistake in attribution as I was not involved in
FFmpeg during that time, and I am sure it is fixed (besides Git
history, which is unfortunately unfixable). But the only people I have
seen stripping attribution is Libav during their "cleanups", and
Michael is actively restoring lost attribution:

See for example
among others.

> despite various tests still failing (when running them
> with more than one thread), just to name a few.

Well it doesn't fail anymore now, so this is not a viable argument now.

> Now he argues that the
> merged external branches make 'his' tree 'superior'.

Well, it is ;)

> If you look at the git commit statistics, you'll notice that
> the developers with most commits (both numbers of commits and lines of
> changed code) in the last year and three years before the fork are in
> the Libav camp now.

Look at http://lucy.pkh.me/ffstats/authors.html now. The following
list is sorted in number of commits.

Michael Niedermayer <-- FFmpeg
Diego Biurrun <-- Libav
Stefano Sabatini <-- FFmpeg
Anton Khirnov <-- Libav
Justin Ruggles <-- Libav
Baptiste Coudurier <-- inactive
Måns Rullgård <-- inactive
Martin Storsjö <-- Libav
Paul B Mahol <-- FFmpeg
Reimar Döffinger < FFmpeg
Ronald S. Bultje <-- FFmpeg turned to Libav turned back to FFmpeg
Clément Bœsch <-- FFmpeg
Carl Eugen Hoyos <-- FFmpeg
Mans Rullgard <-- inactive
Aurelien Jacobs <-- inactive
Vitor Sessak <-- inactive
Kostya Shishkov <-- Libav
Luca Barbato <-- Libav
Nicolas George <-- FFmpeg
Ramiro Polla <-- Inactive

FFmpeg: 8
Libav: 6

Note that at least Stefano Sabatini and Ronald Bultje sent patches to
Libav, but both are FFmpeg-only developers now. I do not know the
details of their switch, but I believe that they had good reasons to
do that.

Also, although the commit count for Michael includes merge commit
counts, he is still No. 1 committer even with merge commits

> Moreover, my experiences with discussing matters like symbol
> versioning and binary compatibility with him doesn't make me too
> enthusiastic about maintaining a package with him as upstream in Debian
> or Ubuntu. Libav on the other hand is a group of very nice developers
> that generally are very open to discuss issues with API and ABI.

>From my own experiences and several months reading Libav mailing list,
Reinhard and Luca are pretty nice, for a fact. I can't comment about

For FFmpeg, all of them are nice IMO.

Libav broke ABI without major bump for numerous times. The last
unintended ABI break (IIRC) is the LLS API, from a change originated
from Libav. FFmpeg (more specifically and ironically, Michael)
actively made a step to fix it, while Libav just ignored it:

> For instance, one of the first developments in Libav was a large API
> cleanup that resulted in a 'global' SONAME bump in order to clarify the
> line between public API and private internals. I expect that in the long
> run this will make Libav much more 'dev-friendly' and open for
> integration in the rest of the multimedia community.

Nice job Libav. Your contributions had made Libav _and_ FFmpeg much
better projects.

> Of course FFmpeg
> has merged most if not all of this work.

Is it only me, or does Reinhard really not like the spirit of open source?

> What I consider most important for Ubuntu is that Libav has me as active
> release manager that drives a) daily builds in ubuntu [libav:daily], b)
> beta releases that are also included in other distros such as Gentoo
> [libav-beta:Gentoo] and of course c) proper 'main' release
> branches.

Now FFmpeg has one too. For Gentoo, see FFmpeg Gentoo maintainer's
blog: http://aballier.wordpress.com/2013/01/18/ffmpeg-vs-libav-a-distribution-maintainer-point-of-view-almost-two-years-after-the-split/

> Michaels idea of always using the latest git master code OTOH
> just doesn't work in binary distros with long-term stable
> releases.

Michael formally maintains three most important release branches:

But he makes releases, sometimes regularly, for all the other releases
back to 0.5.

> FFmpeg on the other hand seems to me these days mainly as
> one-man-show.

See the Git stats. It is not anymore.

> While FFmpeg is clearly receiving more drive-by
> contributions,

True, but this is not a bad thing.

> ffmpeg-devel still contains a considerable amount of
> flamewars,

Not anymore.

> while libav-devel has way more technical reviews and
> generally seems to me the nicer group to work with.

Can't comment on "nice", but Libav is suffering from forced review,
while the FFmpeg policy is more flexible.


More information about the ffmpeg-devel mailing list