[FFmpeg-devel] Reintroducing FFmpeg to Debian

Sat Aug 9 09:38:54 UTC 2014

Hi,

2014-08-08 20:06 GMT+02:00 Andreas Cadhalpun <andreas.cadhalpun at googlemail.com>:
> 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?
Being the xbmc maintainer I feel being addressed and let me share my
POV regarding XBMC. :-)
XBMC works with Libav for most use-cases while it fails in the rest,
notably it can not use VDPAU acceleration which is being
(understandably) complained about very often (#742896). Another issue
is Libav crashing on bad input which makes XBMC/Libav unusable in PVR
configurations when signal is corrupted sometimes (#741170). Upstream
makes sure all their use-cases work well with FFmpeg and not
interested in Libav-related issues. I can't fix the problems because I
don't have any HW reproducing them, and I don't get help from Libav
upstream/maintainers either in fixing those issues.
Media requiring codecs not supported by Libav will not play with
Debian's pacakaged XBMC, but I have not seen any file encoded in such
way.

To overcome the situation I had to set up a "PPA" at
https://people.debian.org/~rbalint/ppa/xbmc-ffmpeg/ because I would
like to serve Debian users who would like to use VDPAU or PVR.
Maintaining this costs me extra time whenever I update XBMC in Debian
because I have to build and update those packages as well.

Regarding the '--enable-libav-compat' configure option and
lib/xbmc-libav-hacks they exist(ed) because XBMC's codebase is written
with FFmpeg API in mind and the compatibility with Libav 10 was
"hacked in" this way. I wrote "existed", because upstream removed the
support completely in their master branch. Most of my time spent to
XBMC packaging is spent on making sure that XBMC works with Libav and
many upstream developers oppose having XBMC packaged in Debian at all
because they want to see only fully functional XBMC builds everywhere.

I would like to have flawlessly working XBMC in Debian as well, but it
can't happen without fixing the Libav issues I mentioned above or
letting FFmpeg entering Debian.

IMO Andreas did a very good job and made re-introducing FFmpeg to
Debian as painless as possible. The package deserves to enter at least
experimental. Keeping it out of Debian just because and other
well-known fork is in Debian is totally unfair. We claim to create The
Universal Operating System not an App Store.

Cheers,
Balint

PS: I think Libav made a strategic mistake by not following Linux's
strategy of creating a "staging" area and not allowing less than
stellar code entering their codebase.

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