[FFmpeg-devel] Reintroducing FFmpeg to Debian

Fri Aug 8 18:06:08 UTC 2014

Hi Reinhard,

On 08.08.2014 14:29, Reinhard Tartler wrote:
> On Fri, Aug 8, 2014 at 7:13 AM, Matthias Urlichs <matthias at urlichs.de> wrote:
> I intended to come up with a more timely full response, but I just
> didn't get to it so far.

Thanks for explaining your point of view here.

> For now, please refer to http://lwn.net/Articles/607662/,

Have a look at: http://lwn.net/Articles/608040/

I was not there, when the FFmpeg/Libav split happened and I don't want 
to judge, whether it was a good thing or not. But it clearly caused a 
lot of bad blood between the developers involved, which in my opinion 
hurts the development of the multimedia framework in recent times.

> http://codecs.multimedia.cx/?p=370 (rather old, but still true), and

If these features weren't used, they wouldn't have been developed.
And many new features have been added to FFmpeg after that post.

> http://codecs.multimedia.cx/?p=674 (recent update on that matter)

Let me quote from there:
"But that’s not what kills the fun, “security holes” do.

With an advance of automatic fuzz tools it’s easy to generate millions 
of damaged files that crash your decoder and yet there are no tools for 
generating correct patches. Fixing those crashes is tedious, requires a 
lot of thinking (should I disable it? will it affect decoding correct 
files? etc.) and in other words not fun at all."

That seems as if he doesn't want to continue Libav development, because 
fixing security issues is tedious work.
It has basically nothing to do with whether FFmpeg is of good quality 
security wise or not, or a good or bad competitor against Libav.

> Regarding Marco's argument that libav had few friends, well, let me
> point to https://medium.com/libre-parole/libav-is-beautiful-4c1a2c886948
> for instance.

One person thinking that the code is 'beautiful' is no convincing 
argument. The number of people expressing their interest in having 
FFmpeg back in Debian is a lot more convincing.

>> IMHO the best idea at this point would be to toss out libav, and rebuild
>> the rdeps with ffmpeg. Now, before it's too late for jessie.
>
> I think that is totally out of question: Uploading FFmpeg to our
> archive will break the Debian archive so hard that it will take months
> to get everything back to testing, if it works at all.

Let me repeat what I wrote in my initial mail in this thread:
Having FFmpeg in the Debian archive breaks absolutely *nothing*, but it 
gives developers and users a choice between the two.

Even if Libav were to be removed, a transition to FFmpeg could be rather 
smooth, as all the necessary patches already exist.
But you're right that the time to test the resulting packages is getting 
rather short for the coming freeze.

Still it can make sense for packages that are tested with FFmpeg 
upstream and have known issues with Libav.

So if you and the other Libav maintainers were to support the idea of 
having both, the security and release teams could perhaps be convinced 
to allow that. This has been my goal from the beginning and I hoped that 
would be appreciated.

> To the best of my knowledge, there are only two high-profile projects
> that play hardball to require FFmpeg: Mplayer and mythtv. Neither of
> those do that (again to the best of my knowledge) mainly because of
> technical but rather very political reasons. The case of mplayer has
> been elaborated extensively in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159#79 (see the
> following "discussion" with Reimar - my conclusion from that is while
> technically possible, nobody wants to make mplayer work with Libav -
> and that's why it was removed, not because of the FFmpeg dependency).
> For Mythtv I can only say that they didn't even bother engaging any
> discussion.

That FFmpeg has more features is a rather technical argument.

Note that also many other projects are developed mainly with FFmpeg, 
they just happen to not break completely when compiled against Libav.

For example, mpv prefers FFmpeg for good reasons:
"Although mpv attempts to work well with both FFmpeg and Libav, FFmpeg 
is preferred in general. This is simply because FFmpeg merges from 
Libav, and seems to have more features and fewer bugs than Libav." [1]

These features are actually requested by users, see e.g. [2].

> (All) other high-profile downstream projects, including VLC or XBMC
> (now Kodi) work demonstrably just fine with Libav. Sure, FFmpeg may

Just fine? Did you see the bugs I mentioned in my initial mail?

And how does it come that XBMC needs the '--enable-libav-compat' 
configure option, which then uses code from lib/xbmc-libav-hacks, to 
build against Libav?

> provide them with extra features, but why on earth would anyone want 3
> different implementations of a ProRes encoder (seriously, and FFmpeg
> seems to claim to provide "security support" for each of them), or
> support for fringe codecs such as Wing Command 3 (yes, you can decode
> the videos from that video game).

One of those ProRes encoders comes from Libav and is provided in FFmpeg 
for compatibility with Libav. Supporting both encoders provides the user 
with additional choice.
Also security issues in an encoder are less likely, given that it
_encodes_ bitmaps into a bitstream and doesn't have to do complicated
parsing of attacker provided bitstreams into bitmaps like a decoder.

If FFmpeg wouldn't care so much about compatibility with Libav, a lot 
less programs could be built with both.

> There are a number of legitimate requested backports, such as for some
> of FFmpeg's additional filters in libavfilter, and similar. All of
> them are rather easy to backport, and this is done on a regular basis.
>
> However, with the due diligence and attention such a widely used and
> high-profile library requires.

I'm not sure such ports to Libav would be easy, as I'm under the 
impression that many filters in FFmpeg use features not available in Libav.

As far as I can tell, only 3 filters have been ported in the last two 
years, including one submission by an external developer. Keeping in 
mind that more than 100 additional filters have been added to FFmpeg 
this is only a very small number.

The external submission came from a developer of a music player who uses 
Debian/Ubuntu and therefore has to use Libav.
"I went with libav simply because it is what is in the Debian and Ubuntu 
package managers, and one of my goals is to get this music player 
backend into their package managers.
[...]
In order to have this functionality, I ported the "compand" audio filter 
from ffmpeg." [3]

> Which brings me to my next point: Release frequency. FFmpeg has an
> insane frequency of releases, and still seems to "support" (at least
> providing updates) to all of them,

Generally FFmpeg supports all releases still widely used.

> including 0.5 which is currently in
> oldstable (needless to say none of these patches made it to
> oldstable-security, why is still a mystery to me).

It was a mystery to me, but I assumed you would know the reasons [4]:
ffmpeg (4:0.5.6-1) stable-security; urgency=low
[...]
   * Note while the source package name reads 'ffmpeg', this is actually
     the libav-0.5.6 release.

  -- Reinhard Tartler <siretart at tauware.de>  Mon, 26 Dec 2011 00:14:25 +0100

So even if the package in oldstable is called ffmpeg, it is actually 
Libav and thus only got the security updates provided by Libav.

Nothing prevents you from uploading ffmpeg-0.5.14 to squeeze-lts.

> The effect of that
> is that downstream projects have a hard time to choose what version of
> FFmpeg they want to support.

What do you mean?
Every distribution includes the latest possible version and upstream 
tracks how long they need to be supported [5].

> This brings effectively back to the
> situation I was in when I took over maintenance of the package many
> years ago: Back then, Michael Niedermeyer strongly recommended all
> downstreams to avoid shared libraries and just link statically against
> libavcodec.a to avoid problems regarding "incompatible" library
> versions. I see exactly this problem arising again: Both mythtv and
> mplayer upstream (btw, xbmc as well) bundle some copy of ffmpeg in
> their sources and recommend everyone to just use the internal copy to
> avoid problems.
>
> Needless to say that this is not acceptable for use in Debian.

Both MPlayer and XBMC can be built against a system version of FFmpeg.

> Yes, I agree that this situation is a mess. A big mess. My fear is
> that switching to FFmpeg will bring us back to the mess we where 8
> years ago, and I worked on for years.

How can switching to FFmpeg undo the development of the last 8 years?
Especially since commits from Libav get merged on a daily basis.

> Libav is far from being perfect. That's true. I don't know why exactly
> FFmpeg seems to have more manpower, but it's not all black or white.
> For instance, there are a number of developers that actively
> contribute to both projects and are essential in keeping both projects
> in good health.

Indirectly all Libav contributors also contribute to FFmpeg, because 
changes in Libav get merged into FFmpeg.

> Also I don't really buy the security argument. True,
> FFmpeg has more security updates, but backporting them to Libav turned
> out to be difficult because many if not most of them turn out to be
> either incomplete, invalid or require further clarification. Libav
> developers prefer to go the unpleasant road of fully understanding the
> issue, which takes extra time.

If that extra time is about a year or more (CVE-2011-3946, 
CVE-2013-0851, CVE-2013-0852, CVE-2013-0868) [6], I think it is clearly 
far too long.

> For all these reasons, I do not see the
> necessity to do any drastic and dangerous steps right now.
> I now seriously wonder if the last 45 minutes in which I wrote this
> email wouldn't have been better spent with preparing the next upload
> for stable-security. YMMV.

It would be nice, if you could also spent some time thinking about the 
possibility of having both FFmpeg and Libav in Debian.

Best regards,
Andreas

1: https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav
2: http://lwn.net/Articles/608012/
3: http://andrewkelley.me/post/quest-build-ultimate-music-player.html
4: https://tracker.debian.org/media/packages/f/ffmpeg/changelog-4%3A0.5.10-1
5: https://trac.ffmpeg.org/wiki/Downstreams
6: https://tracker.debian.org/media/packages/liba/libav/changelog-6%3A10.3-1