This page documents the position statement of those who think that Debian should switch from Libav to FFmpeg as provider of the libav* (and related) libraries.

Contents

  1. Why Debian should switch to FFmpeg
    1. Security considerations
    2. Bug handling
    3. Additional Features
    4. Upstream Contributors
    5. Choice of other Distributions
  2. How Debian should switch to FFmpeg
    1. The Library Transition
    2. The Command Line Tools Transition
    3. Implementing the Transition

Why Debian should switch to FFmpeg

FFmpeg should be chosen for Debian, because it is better than Libav in practically every way. Below you can find the most important points.

Security considerations

FFmpeg is clearly better at fixing security issues.

Most CVEs are fixed in FFmpeg significantly earlier than in Libav.

For example, it took more than two months until CVE-2014-9604 was fixed in Libav after being fixed in FFmpeg. On the other hand, FFmpeg merges most commits from Libav, including fixes for potential security issues, on a daily basis.

Issues without CVE number remain unfixed in Libav for years.

For example, an out of bounds read in the bink decoder was fixed in FFmpeg three years ago (2012-06-02), while Libav git master was still vulnerable on 2015-06-02. Thankfully this is now finally also fixed in Libav.

Mateusz "j00ru" Jurczyk and Gynvael Coldwind from the Google Security Team have been working hard on finding potential security issues in FFmpeg and Libav.

As Mateusz explains, all of their findings have been fixed in FFmpeg, while Libav remains vulnerable to many issues: 

We have been quite successful working on the above effort with FFmpeg
for the last ~3.5 years: every single issue we have found (even the
least severe ones) has been fixed in a timely manner. As a result, after
tens of fuzzing iterations, there are currently no bugs in FFmpeg that
we are able to find using our current input corpus and mutation
algorithms. The situation is entirely different with Libav, which is
still affected by hundreds of such bugs, even though we have provided
the developers with reproducing testcases a number of times in the past.
Therefore, the security posture of Libav as of today is much, much worse
than FFmpeg's, and this is the reason I support the transition to the
latter library.

Additionally FFmpeg generally supports release branches that are still widely in use. For example the latest release of the FFmpeg 0.5 series was 0.5.15 in November 2014, while the latest release of the Libav 0.5 series was 0.5.10 in February 2013, despite being used in Debian Squeeze LTS.

Libav even dropped support for version 0.8, which is used in Debian Wheezy, already: 

Special note: The 0.8 branch of libav is now more than 2 years old --
downstreams are recommended to update sooner rather than later as 0.8.17 will be
the final official release for this branch.

Moritz Mühlenhoff from the Debian Security Team also prefers having FFmpeg: 

Several of the recently fixed libav security issues were only fixed because I
contacted Michael Niedermeyer for the reproducers and reproduced them with
libav git. There's no special Chrome test harness, all you need to do is rebuild
libav with asan and exercise the reproducers.
libav doesn't do that on it's own which I find disappointing since ffmpeg is
obviously a fairly big part of their larger software ecosystem. This seems
to caused by two factors:
- lack of manpower in libav
- a general animosity

Another factor in favour of ffmpeg is the support maintenance. As Andreas quoted
the libav 0.8 branch we use in wheezy will be EOLed soon. ffmpeg in contrast
even made updates to the 0.5 branch in November (i.e. the version in squeeze)

So summarising my personal perspective from being in the security team: We could
live with either solution, but by now I personally have a preference towards ffmpeg
with the lack of manpower in libav being the decisive factor.

Bug handling

FFmpeg and Libav are large programs and thus inevitably contain bugs. Many bugs get fixed as part of the normal development process.

FFmpeg merges most changes from Libav, including such bug fixes, while Libav only rarely cherry-picks some patches from FFmpeg. Thus Libav contains bugs not present in FFmpeg. (See e.g. bug #692876, bug #753923 or bug #783616 for typical examples.)

The usual way for Debian to deal with such bugs in the upstream code is to forward them to the upstream bug tracker. However in the case of Libav this doesn't really help as Reinhard Tartler explained: 

What project is doing a better job with handling defect reports?
- I'd think FFmpeg, because the Libav bug tracking system is currently
dysfunctional. AFAIUI this is being worked on. I've worked around this for
quite some time by talking to individuals on IRC directly, but this clearly
doesn't scale.

Examplary for this is Libav bug 840, which has a sample and a command line crashing Libav, but no reply since 2 months. The same bug was also reported as FFmpeg trac ticket 4431 and a fix was committed within two days.

Additional Features

FFmpeg has many more features than Libav.

For these reasons many upstream developers of libav* reverse-dependencies build and test mainly (or only) with FFmpeg.

Upstream Contributors

FFmpeg has a big and active user and developer community, while the Libav community is smaller. One reason for this is that FFmpeg merges most commits from Libav so that all Libav contributors indirectly contribute to FFmpeg as well.

You can for example look at statistics about the past twelve month:

Essentially the same can be seen by looking at the repositories directly. FFmpeg 2.4 was released around the same time as Libav 11 in September 2014. Let's look at the number of commits since then:

Libav: 

$ git shortlog -ns --no-merges v11..fd11465 | head -n15
   318  Vittorio Giovara
   258  Martin Storsjö
   206  Anton Khirnov
   146  Luca Barbato
    72  Diego Biurrun
    48  Michael Niedermayer
    32  Rémi Denis-Courmont
    25  Andreas Cadhalpun
    19  Hendrik Leppkes
    16  Gabriel Dume
    16  Himangi Saraogi
    16  wm4
    14  Federico Tomassetti
    12  Peter Meerwald
    11  James Almer

FFmpeg: 

$ git shortlog -ns --no-merges n2.4..b70582e | head -n15
  1850  Michael Niedermayer
   318  Vittorio Giovara
   257  Martin Storsjö
   197  Anton Khirnov
   180  Clément Bœsch
   162  James Almer
   150  Carl Eugen Hoyos
   125  Luca Barbato
   118  Andreas Cadhalpun
    98  Lukasz Marek
    93  Paul B Mahol
    86  Ronald S. Bultje
    84  wm4
    66  Christophe Gisquet
    48  Benoit Fouet

For this reason FFmpeg can produce major releases more frequently and also provide more bugfix-only releases for the release branches. So it's better maintained upstream, which makes Debian maintenance easier.

Despite providing more releases, the API/ABI is similarly stable as Libav:

No API/ABI should ever change with bugfix releases, i.e. 2.6.* releases all have the same. With most new major upstream releases (i.e. 2.*) only new API is introduced and private API/ABI changed. So only buggy programs that use private API need to be fixed (see e.g. bug #783879).

With some new major upstream releases the soversions get increased, at which point we need a library transition. The upstream tracker gives a good overview about this. The last soversion bumps were:

So transitions would be about once every half year and if one doesn't count libavfilter, because it only has a handful of reverse-dependencies, it's more like once per year.

Choice of other Distributions

Many distributions continued to use FFmpeg after the split.

openSUSE provides FFmpeg packages, while the Libav packages are not available anymore.

Gentoo has Libav and FFmpeg packages.

Interestingly Gentoo recently switched to FFmpeg by default after conducting a survey. About 300 people participated in that survey and the outcome was rather clear:

How Debian should switch to FFmpeg

The transition consists of two parts: libraries and command line tools.

The Library Transition

Transitioning the libraries could be done by switching build-dependencies from lib*-dev (built from src:libav) to lib*-ffmpeg-dev (built from src:ffmpeg). But because this would require making source changes to all reverse build-dependencies, it would be better to rename the libraries from src:ffmpeg to lib*-dev. Then binNMUs would be sufficient for most reverse build-dependencies.

Two FTBFS issues will be introduced by this transition:

There are also a few unrelated FTBFS issues, but fixes are available:

Some packages build without ffmpeg support with the transition:

Two obsolete packages also FTBFS:

The Command Line Tools Transition

Transitioning from the libav-tools to the ffmpeg binary package has to be done for all packages depending on libav-tools. Adjusting recommends/suggests would also be good, but is not as important. To facilitate the transition, a libav-tools-links package, which 'Provides: libav-tools' and contains links from the av* to the ff* binaries is going to be built from src:ffmpeg.

Reverse dependencies of libav-tools:

Reverse recommends of libav-tools:

Reverse suggests of libav-tools:

Packages without dependency relation on libav-tools:

Other packages needing changes:

Implementing the Transition

The layout of the ffmpeg source packages should be changed to:

The src:libav and src:libpostproc should get removed from sid/stretch after the transition.

Uploads with these changes should first go to experimental and after passing NEW and getting a transition slot from the release team, to unstable. Once there, binNMUs for the reverse build-dependencies should be scheduled.

The actual library transition will then probably take about 5 days, which is the time after which britney propagates the binNMUs to testing.

The following ben file should be sufficient to track the transition: 

title = "ffmpeg";
is_affected = .depends ~ "libavcodec56|libavcodec-extra-56|libavdevice55|libavfilter5|libavformat56|libavresample2|libavutil54|libpostproc52|libswscale3" | .depends ~ "libavcodec-ffmpeg56|libavcodec-ffmpeg-extra56|libavdevice-ffmpeg56|libavfilter-ffmpeg5|libavformat-ffmpeg56|libavresample-ffmpeg2|libavutil-ffmpeg54|libpostproc-ffmpeg53|libswresample-ffmpeg1|libswscale-ffmpeg3";
is_good = .depends ~ "libavcodec-ffmpeg56|libavcodec-ffmpeg-extra56|libavdevice-ffmpeg56|libavfilter-ffmpeg5|libavformat-ffmpeg56|libavresample-ffmpeg2|libavutil-ffmpeg54|libpostproc-ffmpeg53|libswresample-ffmpeg1|libswscale-ffmpeg3";
is_bad = .depends ~ "libavcodec56|libavcodec-extra-56|libavdevice55|libavfilter5|libavformat56|libavresample2|libavutil54|libpostproc52|libswscale3";

Changing the dependencies/recommends/suggests from libav-tools to ffmpeg should be done before stretch is released.