Distributions

Reconsidering ffmpeg in Debian

For better or for worse, forks are a part of the free software landscape. Often a fork will result in a reinvigorated development community and the removal of unneeded roadblocks. But not all forks work out well. What is a distributor to do if, at some point, it concludes that it chose wrongly when it followed a fork of an important project? Going back to the original may not always be an easy thing to do, even if there appears to be a consensus for that move. The presence of security concerns can make such a change even harder to contemplate. The recent discussion on welcoming ffmpeg back into Debian illustrates the potential hazards nicely.

FFmpeg is a set of libraries for the handling of files (and streams) containing audio and video data. With its extensive format support, it has long been the definitive library for application developers wanting to work with multimedia streams. It has also, at times, had a history of discord within its development community. Back in early 2011, strong disagreements within this project led to a hostile fork which, eventually, picked up the name libav. Initially the two projects worked with nearly identical code, but they have drifted apart over time.

The Debian distribution chose early on to drop ffmpeg and go with libav. This decision was made in typical Debian style; the Debian developer who maintained ffmpeg was part of the group that created the fork, so he naturally pulled the distribution along for the ride. For the most part, Debian users have not really noticed the change; things generally just work, though, recently, the mplayer video player application has run into trouble due to its being primarily written and tested for ffmpeg rather than libav. Other programs, too, occasionally show signs of their developers paying more attention to working with ffmpeg.

Recently, Andreas Cadhalpun proposed a plan to bring the ffmpeg system back into the Debian distribution. He had a number of reasons for wanting to have ffmpeg in the repository, including compatibility problems between libav and programs like mplayer and the XBMC media center system. There are, he said, a number of features in ffmpeg that have not found their way into libav; these include the "deshake" image stabilization filter and a number of codecs. He also mentioned ffmpeg's active developer community, implying by omission that libav's community is less so. The plan for bringing back ffmpeg has been carefully designed to avoid breaking programs that currently depend on libav. FFmpeg would be carefully installed so that it could live alongside libav and applications could be built against either.

The discussion that ensued made it clear that a number of Debian developers would like to see ffmpeg as part of the distribution again. Indeed, defenders of libav were mostly conspicuous in their absence. It would seem that, in the three years and some since the fork, libav has lost a lot of its charm, at least in the Debian community. Given Debian's tendency toward including almost anything if a developer wants to maintain it, one would think that putting ffmpeg back would be uncontroversial. In the reality, though, it is still not clear that ffmpeg will be returning in the near future.

The sticking point would appear to be security support. FFmpeg is seen by many as having rather more than its share of security problems; as a result, the Debian security team is nervous about adding ffmpeg support to their workload. It is worth noting that nobody has said that libav is better in this respect; indeed, Debian security team member Moritz Muhlenhoff stated that he thinks ffmpeg is more responsive to security issues than libav. The point is that either package brings in a fair number of problems to be solved, so doubling the load is not welcome. As Moritz put it last February: "for libav/ffmpeg this simply isn't manageable at all due to the huge stream of security issues trickling in".

There are a number of reasons why a project like ffmpeg (or libav) will have more than the average number of security-related problems. The library is directly exposed to potentially hostile data in the form of audio and video streams controlled by others. The number of formats to be supported is huge, and many codecs are written by developers who may not have security at the top of their list of concerns. Performance requirements can lead to hardware-specific code, sometimes done in assembly. Multimedia libraries find their way into a wide range of other applications, so a vulnerability can show up in unexpected places. It is thus not entirely surprising that a project like ffmpeg would have a relatively large number of security issues.

Even so, one might argue that the number is too large, and that the project should be doing better. The answer here is that, with some help from Google, both ffmpeg and libav are indeed trying to do better. In particular, the fuzzing work done at Google has led to over 1,000 separate bugs being fixed in ffmpeg. Many of those were security-related, of course; that, too, will increase the number of security fixes released by the project.

So ffmpeg should be getting better, and, by most accounts, libav is trying to follow the same path. That fact may calm some worries about accepting ffmpeg back into Debian in general, but it still is unlikely to make the security team feel better about its increased workload. So if ffmpeg comes in, it may well have to be at the expense of libav, a change that was not part of the posted plan for restoring ffmpeg.

If the debian-devel discussion is a proper guide, there will be few tears shed if ffmpeg edges libav out of the distribution. But, of course, there is a hitch here: the freeze date for the upcoming "jessie" release is a mere three months away. That is not a long time to replace a core library depended on by a large number of applications. If this replacement is to happen, it needs to start right away. If it does not happen soon, libav is likely to be the only option in Debian for another two years or so.

As of this writing, no clear resolution is in sight. There have been suggestions that this issue should be referred to the Debian technical committee, even though it cannot honestly be said that the requisite efforts to achieve consensus within the development community have been made.

Forks, if done right, can bring extensive benefits to both developers and users. The X.org fork of XFree86, for example, jump-started the development community and led to a rapid modernization of the code and increase in functionality. Three years later, it is not at all clear that the libav fork has succeeded in this way. Instead, it presents distributors with an unpleasant choice: either try to pick a winner or double up on an already extensive security update stream. Regardless of how it chooses, Debian is going to have a fair amount of work to do as it straightens out its short- and long-term plans regarding multimedia support.

Comments (55 posted)

Distribution quotes of the week

-- Eric "Sparks" Christensen

-- Harald Sitter

Comments (1 posted)

CyanogenMod 11.0 M9 Released

CyanogenMod 11.0 M9 has been released. "This release marks the first ever (non-nightly) release for the Xperia Z2 ‘sirius’, Xperia Z2 Tablets ‘castor’ and the HTC One ‘m8′ – kudos to their maintainers and all the other maintainers that bring you these releases every month!"

Comments (none posted)

Red Hat Enterprise Linux OpenStack Platform 3.0 Retirement Notice

Support for Red Hat Enterprise Linux OpenStack Platform 3.0 has reached its end. Users are encouraged to upgrade to RHEL OpenStack Platform 4.0.

Full Story (comments: none)

Distribution newsletters

• Debian Misc Developer News (#36) (July 31)
• DistroWatch Weekly, Issue 570 (August 4)
• 5 things in Fedora this week (July 29)
• 5 things in Fedora this week (August 5)
• Ubuntu Weekly Newsletter, Issue 377 (August 3)

Comments (none posted)