[FFmpeg-devel] Reintroducing FFmpeg to Debian

[Reinhard Tartler]

On Fri, Aug 8, 2014 at 7:13 AM, Matthias Urlichs <matthias at urlichs.de> wrote:
> Hi,
>
> Andreas Cadhalpun:
>> Once FFmpeg is back in the archive, it'll be easy to reintroduce MPlayer. It
>> has been removed from sid, since it fails to build against Libav, but it
>> builds fine against FFmpeg.
>> (It uses some of the features only provided by FFmpeg.)
>>
> Yet another reason why solely depending on libav is a bad idea.
>
> That leaves the question of the "official" opinion of the libav
> maintainers (pkg-multimedia-maintainers at lists.alioth.debian.org).
> Did none of them write anything in "defense" of libav, or have I simply
> missed it?

I intended to come up with a more timely full response, but I just
didn't get to it so far.

For now, please refer to http://lwn.net/Articles/607662/,
http://codecs.multimedia.cx/?p=370 (rather old, but still true), and
http://codecs.multimedia.cx/?p=674 (recent update on that matter)

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.

> 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.

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.

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

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.

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, 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). The effect of that
is that downstream projects have a hard time to choose what version of
FFmpeg they want to support. 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.

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.

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. 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. 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.


-- 
regards,
    Reinhard