[FFmpeg-devel] Reintroducing FFmpeg to Debian

Fri Aug 8 14:47:43 UTC 2014

On 8 August 2014 13:29, Reinhard Tartler <siretart at gmail.com> wrote:
> 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.
>

So in ubuntu, at the time we were doing libav9 transition we also
still had mplayer and pleora of packages inheritance from
deb-multimedia or some such repositories. I was very reluctant to
remove mplayer and all the reverse-deps, as I felt it is valuable to
ship mplayer. I believe it was based on unreleased experimental
packaging in git and other bits [1] Later Colin Watson also provided
minimal port to make it build on arm64. Unfortunately libav10
transition got entangled in too many ways and we didn't manager to
port mplayer to libav10. This was attempted based on top of mplayer
trunk snapshot / last stable tarball, patches from gentoo and own
porting efforts from myself and sil2100/robru but albeit
unsuccessfully. Under pressing wait of too many things stuck in
proposed migration (britney migration) we did remove mplayer and
reverse dependencies and pointed / filed bugs to port to mplayer2 or
just libav-tools where appropriate. I did ponder about compiling
mplayer with an embedded copy of libav9 statically linked, but
ultimately decided that it's unnecessary evil and majority of
use-cases are served by the current libav stack. Either of ffmpeg and
libav is a big security maintenance burden, simply from nature of
inherently handling complex and large streams of untrusted data. So in
trusty, I did work to unsplit the packages such that libav moved from
main to universe, and can be synced from debian unmodified to minimize
net-total maintenance burden as now updates and packaging can be fully
shared. I see moving to mplayer2 as a net positive benefit for Debian.
MythTV alone, whilst important package, I don't see as special enough
to grant use of an embedded copy or forcing an uncertain cost of
switching back to ffmpeg. If we need to port that project, then in
Debian/Ubuntu/UbuntuStudio there are enough interested people to get
it done.

[1] https://launchpad.net/ubuntu/+source/mplayer/2:1.1+dfsg1-0ubuntu1

Regards,

Dimitri.

> (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
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST at lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster at lists.debian.org
> Archive: https://lists.debian.org/CAJ0cceaon=Trrde-VCTOC83cjh1sH_jtrfKkonza6C+UJAyCxg@mail.gmail.com
>

-- 
Regards,

Dimitri.