The FFmpeg/Libav scenario

One yr and a half in the past, an essential a part of FFmpeg builders determined to
change the best way the mission was managed. This led to some sort of
takeover, primarily to eliminate the previous maintainer dictatorship,
but in addition to vary improvement strategies, redefine goals, and so on. Then, for
numerous causes I’ll shortly clarify, these individuals made a brand new mission known as
Libav.

I’ll strive first to summarize probably the most objectively as I can what was the
scenario, why it led to the present one, and mainly how issues are linked
collectively. In a second time although, I’ll attempt to clarify why, as a FFmpeg/Libav
warfare youngster, I lastly selected one aspect, and what it means each day.

How are MPlayer, FFmpeg, VLC, libav*, and so on linked?

To know effectively what is going on on, let’s do a fast abstract of the instruments and
communities.

MPlayer and FFmpeg initiatives are initially two
very shut communities; each initiatives began across the similar time (yr 2000),
and nonetheless share quite a lot of commons issues (MPlayer makes use of FFmpeg API, quite a lot of
builders had been engaged on each initiatives, they had been hosted on the identical server,
and extra).

The FFmpeg mission supplies a couple of libraries to transform, play, stream, course of
audio and video (extra info on the ffmpeg libraries here),
and some instruments (ffmpeg for transcoding, ffplay for playback, and so on), all of
them making clearly use of those libraries.

MPlayer is mainly a GPL video participant, with its personal demuxers, decoders,
filters, and so on. however in some unspecified time in the future it made use of FFmpeg to lighten the burden of
an excessive amount of code upkeep.

I do not know the VLC mission very a lot, although I do know sufficient to say that they
make use of the libav* libraries like MPlayer does, particularly the codecs one
(libavcodec). Whereas MPlayer neighborhood could be very small, VLC appears to have sufficient
builders to afford for instance the price of writing a greater© assist for some
codecs than libavformat from FFmpeg.

Many different initiatives make use of those libraries (XBMC, Chromium, …), you get
the purpose.

How was FFmpeg improvement pushed?

The FFmpeg improvement mannequin was pretty easy: the biggest FFmpeg
contributor (Michael Niedermayer, see stats) was
the “self-proclaimed” maintainer, and mainly had the final phrase in technical
selections, primarily as a result of he is been the highest contributor of the mission. A bunch
of people had write entry to the repository, despatched patches for evaluation on a
mailing-list (or not if it is trivial sufficient), and pushed it upstream.

What went incorrect?

Like in lots of different FLOSS communities, there are quite a lot of robust personalities,
enormous egos, technical religions, and so on. The multimedia neighborhood will not be an
exception, removed from that.

As beforehand mentioned, I began getting into FFmpeg round that point,
so I am unable to touch upon the exactness of the statements, however the principle complaints
I noticed talked about and keep in mind from that point had been concerning the mission chief. It
was all about “I do and commit no matter I need to”, “I do not care about
cosmetics”, “I do not need to focus on with you in actual life, mails are good
sufficient”, finally discouraging newcomers, and his normal perspective in direction of
different builders (observe: he was after all not an exception).

For extra particulars, see Libav history.

Then, since quite a lot of energetic builders wished to place an finish to this, they
determined to vary the scenario, not by forking to keep away from the present state we
are in, however thus, by removing Michael’s and the other developers from the
project who weren’t a part of the brand new staff. I allow you to think about
the issues it precipitated: some builders did not perceive, or understood very
effectively and received offended and aggressive, but in addition lots of people not being a part of
the staff began to offer their opinion for one aspect or one other, insult every
different, and mainly a civil war started.

To make issues easy, after looking for a compromise, Michael and the
remaining individuals within the FFmpeg staff later determined to revive ffmpeg.org DNS and
the Libav people had been “compelled” to fork to have it their method. Issues did not go
effectively, there have been quite a lot of infected non-public exchanges I wasn’t a part of, with
numerous threats.

After the fork, issues truly received a bit extra peaceable; no much less hatred, however
builders had been busy bitching and trolling on their aspect, after which it probably
grew to become a messy and irrecoverable scenario everybody lastly in some way accepted.

Notice that quite a lot of circumstances should not depicted right here, the article would get
method too lengthy, however be at liberty to learn the threads.

Attractive Libav

At first, regardless that I disagreed with the strategy used, I used to be truly fairly
appealed by what might come out of this. I wasn’t an FFmpeg developer at that
time, only a MPlayer one, and a small FFmpeg contributor. And to be sincere,
being largely indifferent from the mission, it was truly fairly humorous to see
them appearing like youngsters, regardless that the scenario was sort of severe.

The fork resulted in an actual activity burst on Libav, whereas
FFmpeg’s future was not clear.

The event coverage is completely different in Libav: no chief, each single commit
should be reviewed and accepted by a member of the staff (even probably the most trivial
one), with a severe need of creating issues excellent. I used to be sending patches at
that point, as a result of it was value giving it a strive, there was some exercise, individuals
had been good, and so on.

Being extra energetic, I attempted to remain impartial (truly, that is not that tough when
you haven’t any opinion on the matter) and despatched some patches to each mailing-lists
(largely relying on the individuals having the ability to evaluation my stuff).

What occurred on FFmpeg?

Whereas Libav left with the server, bug tracker, and so on., the FFmpeg mission was
restoring itself, with the assistance of some VideoLAN individuals (the
FFmpeg sources are now hosted on git.videolan.org). Michael additionally
began to merge the Libav modifications again into FFmpeg each 1-2 day, with a
lot of forgotten, beforehand rejected, typically controversial options, or in
stand-by comparable to ffmpeg-mt.

The principle level right here is that the fork stimulated the competitors, and FFmpeg
grew to become a method higher (IMHO) and extra full mission. Additionally, I have to say the
chief’s perspective fully modified, in an excellent method. That is actually one
of probably the most optimistic factor that got here out of that warfare.

Technically talking, what’s incorrect with Libav?

I will be a bit harsh right here, sorry about that however I really feel it is essential to
specific it at the least as soon as.

I like to recommend by the best way to learn Why FFmpeg is “better” than Libav by Numbers
but not in Reality which is a bit outdated however provides an
reverse opinion from what’s being mentioned right here. If I keep in mind appropriately some
different Libav builders and contributors additionally expressed their opinion on this,
however I am unable to discover the hyperlinks. Anyway, let’s give mine, that is what running a blog is
all about anyway.

Libav is totally ignoring FFmpeg because the starting (nearly 2
years of improvement now). And that is after all not solely associated to options,
in addition they do not give a rattling about regressions they introduce, safety
points (search for “j00ru” within the FFmpeg historical past for example), and general
bug fixes. This isn’t 3-4 patches, there are lots of of them.

At occasions, you may see them choosing random stuff from FFmpeg, however they typically
re-fix them in their very own method, taking the privilege to take the total authorship,
suggesting it is trivial sufficient (this could be true, however searching for the bug is a
contribution by itself, and implies recognition because it’s typically more durable than
fixing the bug). Listed below are the final examples I noticed:

There’s mainly no recognition in any respect for FFmpeg, and so they rewrite
every thing. Let’s give some examples:

• ffprobe outputs: final yr, Stefano and I labored on a method of bettering
  ffprobe by making it output one thing else than the bizarre INI/XML by
  default. So we developed a easy author system and supplied a JSON
  output. On the similar time, the function was proposed as a hack
  on libav (they only hardcoded crappy printf calls all
  over the code). After all, I prompt to simply decide the commits in FFmpeg,
  however I used to be probably ignored (the hack patch as effectively). We then labored on including
  XML, CSV, flat and numerous
  different outputs, most of them customizable through options.
  Folks began to make use of them, and clearly requested to the Libav people the
  function. The sane alternative would have been to simply decide what was already performed.
  As a substitute, they determined to rewrite this from scratch, with the argument: “I
  do not prefer it”. And by the best way, they broke the default output “as a result of it is
  evil and it sucks”, and so breaking customers scripts (with none model bump
  or something). Additionally they did not even care to maintain the identical possibility names with
  FFmpeg so customers might change between instruments simply (FFmpeg added the -of
  alias for compatibility).
• libswresample and libavresample: finish of 2011, Michael wrote an audio
  library to do any sample rate, formats, layout, packing conversions he dubbed
  libswresample. In a while a couple of individuals contributed to it, for instance
  to doc or expose the API correctly to the person. It was then built-in to
  the entire mission (instruments, filters), and significantly improved the audio assist in
  FFmpeg. As regular, Libav fully ignored this for one yr, after which
  determined to pay a developer (with the cash of the FFmtech basis) to
  rewrite fully a library for the very same goal. They tried to
  justify this. This clearly pissed off the customers. Since
  FFmpeg has a significantly better coverage towards satisfying the customers, we additionally provide
  the libavresample API.
• Audio filtering: throughout this yr FFmpeg built-in quite a lot of filters,
  particularly audio ones. We had been a handful of builders specializing in the
  filtering, so we wrote fairly a bunch of helpful filters. Nonetheless, they
  began to get fascinated about libavfilter as effectively, and between one or two
  rewrite-from-scratch trolls, they lastly determined to simply enhance the API
  as a substitute (good transfer for as soon as). Bettering the API clearly meant ignoring
  FFmpeg and breaking the API several times. OK, I am a bit
  dishonest since Libav truly introduced some actually good issues within the
  course of, however what I condemn right here is their NIH syndrome (see
  for example af_amix + af_join, and af_pan + af_amerge) which hurts everybody.

…and positively extra: I solely talked about issues I used to be immediately involved right here,
however it’s probably different builders can elevate some related points.

The principle downside is that exterior initiatives who need to assist each FFmpeg and
Libav are simply fucked, and this solely as a result of Libav does not care a second about
their customers.

I believe that is extra a delight difficulty than the rest. They only do not need to
take into account FFmpeg and so they need it to vanish. If you’d like one thing in Libav,
it’s a must to submit them immediately: with FFmpeg’s each day merges and most
builders not desirous to do the work twice, they’ll afford to simply ignore
every thing and nonetheless have some contributions…

If you’d like an outline of the quantity of issues FFmpeg getting in, it is fairly
straightforward: since most of labor performed on FFmpeg is ignored from Libav, it is secure to say
that the commits listed under are most definitely not in Libav:

See Also

French cheese beneath menace | CNRS Information

Colours preferences

Additionally, general, I do not agree with the event strategies of Libav, however that is
largely a style difficulty. To make it easy, I consider the method of sending a
patch for every thing like fixing a trailing whitespace is an entire nonsense.
And that is truly discouraging builders you trusted with a write entry to
the repository, and treating them like youngsters. This isn’t environment friendly. And I
are inclined to suppose that while you keep some code, it is good to have the ability to repair
issues shortly with out bikeshedding.

How come Libav is so extensively unfold then?

I’ve a couple of concepts in thoughts, the principle ones being:

Packaging

The Debian/Ubuntu packager is on Libav aspect (see by the best way the distribution
status on their website), and clearly they distribute Libav
packages. However they’re additionally utilizing this to unfold a really damaging lie:

ffmpeg model 0.8.3-6:0.8.3-4, Copyright (c) 2000-2012 the Libav builders
  constructed on Jun 26 2012 09:26:41 with gcc 4.7.1
*** THIS PROGRAM IS DEPRECATED ***
This program is simply supplied for compatibility and shall be eliminated in a future launch. Please use avconv as a substitute.
[...]

That is clearly false, and much more incorrect within the sense that they’re nonetheless
utilizing the “ffmpeg” identify for the bundle. It looks like it’s been “fixed” on
Ubuntu however it’s nonetheless current on Debian right here.

This propaganda actually hurts the FFmpeg mission quite a bit.

Notice: FFmpeg is offering ff* instruments, totally suitable with the av* instruments
from Libav (avconv, avplay, …), with extra options, bug fixes, however
additionally backward compatibility for some choices Libav determined to take away.

The fork does not exist

I consider the fork will not be a nasty factor, after all assuming Libav accepts being
one. However Libav is presenting itself as a FFmpeg alternative, or rename and
not a fork. Principally, the spirit might be summarized with:

• “Libav is the upstream”
• “Libav is doing all of the work”
• “Everyone seems to be on Libav”
• “Who cares about FFmpeg? It is a downstream fork with no essential work”

(After all, FFmpeg has 1k+ submit per 30 days on ffmpeg-devel mailing
list, for patches and miscellaneous improvement discussions).

This perspective makes the customers consider FFmpeg will not be that an essential mission in
comparability to Libav.

Actual-life conferences

The group behind the takeover is mainly composed of kinfolks, figuring out every
different very effectively, and actively taking part to numerous “business” or
builders conferences. Additionally they consider speaking in actual life is the best way of
fixing each human and technical issues (but in addition wish to ignore the mails
and IRC talks they do not like).

Thus, they’re extensively recognized by the mainstream, because the social dimension is an
essential factor for some customers.

So what comes subsequent?

I am sadly not but capable of predict the longer term, however regarding myself,
I will simply proceed to do the very best I can to make FFmpeg a greater mission, however of
course nonetheless following carefully all the nice issues Libav builders are capable of
produce.

A mission reunification is clearly tough to achieve quickly. FFmpeg made selections
Libav won’t ever settle for (such because the MPlayer filters wrapper in FFmpeg). On the
different hand I believe each initiatives could possibly be stored in sync in some way (if Libav wakes
up sometime), with completely different strategies of improvement, and even completely different objectives:
FFmpeg might be making an attempt to support even more crazy exotic formats
whereas Libav might resolve to drop some because it is a “maintenance
burden”. It is a good factor to affirm these variations for each
sides (“we assist every thing” vs “now we have much less crap”), what is not is their
contemptuous behaviour in direction of builders and customers.