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.

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.

It supports more codecs, formats, devices and filters. In particular it has more than three times as many filters, even though users requested some of these for Libav, e.g. an image stabilization filter in bug #707476.

It also supports more command line options. For example the -show_frames option is missing from avprobe, but has been requested in bug #694616 more than two years ago.

Even more important, FFmpeg provides additional APIs not present in Libav. Thus some applications don't build against Libav, e.g. mplayer, which was therefore removed from Debian, or chromium, which uses an embedded copy.

Other programs like XBMC needed special hacks to work with Libav. This was so burdensome for the developers that they removed those hacks, when renaming the project to Kodi.

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:

Libav FFmpeg Contributors (Past 12 Months) 121 developers 302 developers Commits (Past 12 Months) 1,721 commits 8,705 commits Files Modified 1,365 files 3,055 files Lines Added 84,819 lines 300,144 lines Lines Removed 60,106 lines 185,224 lines Year-Over-Year Commits Decreasing Stable

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:

2.4 (2014-09-14)

2.2 (2014-03-24, only libavfilter)

2.0 (2013-07-10)

1.1 (2013-01-07)

1.0 (2012-09-28, only libavfilter)

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:

61% [ 189 ] "I prefer ffmpeg, and it should be the default."

04% [ 015 ] "I prefer libav, and it should be the default."

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:

gst-libav1.0: needs build-dependency on libavresample-dev #790356

taoframework: hardcoded sonames need to be updated, this is part of the planned transition (This is an 'Architecture: all' package, anyway.)

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

dvswitch: #747868 (with patch), not in testing and not in stable

freerdp: #788557 (fixed upstream)

jitsi: #789038 (fixed in NEW), not in testing and not in stable

sflphone: #787390 (with patch), not in testing

xmms2: #792493 (with patch)

Some packages build without ffmpeg support with the transition:

Two obsolete packages also FTBFS:

gstreamer0.10-ffmpeg: #720796, to be removed, replaced by gst-libav1.0, already broken for ~ a year

xbmc: FTBFS #787018, replaced by kodi, which uses FFmpeg already. Xbmc also FTBFS due to libcec and will be replaced with a dummy package to help the transition to kodi. This FTBFS does not block the transition to ffmpeg (rbalint).

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:

devede supports both dvd-slideshow drop ffmpeg-avconv.patch dvdwizard drop port-to-avconv.patch ffdiaporama supports both gerris drop 04_replace_ffmpeg_by_avconv.patch ifetch-tools no direct use (why the dependency?) kdenlive supports both miro drop 140_use_avconv.patch mps-youtube supports both (already has ffmpeg as first alternative) performous-tools drop use-avconv.patch python-satellites needs one-line patch for video.py: avconv -> ffmpeg python3-audioread drop avconv.patch tribler supports both videotrans drop 03-ffmpeg_to_avconv.patch winff-gtk2,winff-qt supports both (already has ffmpeg as alternative) zoneminder drop libav_path.patch zoomer needs one-line patch for zoomer: avconv -> ffmpeg

Reverse recommends of libav-tools:

blktrace supports both education-desktop-other no direct use kphotoalbum supports both multimedia-video no direct use pafy supports both (already has ffmpeg as first alternative) python-audioread drop avconv.patch (see python3-audioread) soundkonverter supports both vcmi no direct use xwax supports both (already has ffmpeg as alternative) youtube-dl supports both (already has ffmpeg as alternative)

Reverse suggests of libav-tools:

album no direct use beets uses only ffmpeg get-iplayer supports both (already has ffmpeg as first alternative) gvb no direct use mediathekview no direct use owncloud supports both view3dscene no direct use

Packages without dependency relation on libav-tools:

cantata supports both get-flash-videos supports both gpodder supports both imagemagick configure check for avconv, but no BD on libav-tools lives supports both marble supports both moc supports both synfig supports both

Other packages needing changes:

x264 avconv -> ffmpeg in debian/tests/encode-testimage imagination drop 30_avconv_port.patch transcode drop 07_libav9-preset.patch

Implementing the Transition

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

ffmpeg, ffmpeg-doc, ffmpeg-dbg, qt-faststart

lib*-ffmpegN

libavcodec-extra-ffmpegN (Provides: libavcodec-extra)

lib*-dev

libavcodec-extra

lib*-ffmpeg-dev (transitional, to be removed before stretch release)

libav-tools-links (transitional, to be removed after stretch release)

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.