Select provider of libav* libraries

Reinhard Tartler siretart at gmail.com
Sat May 30 21:54:46 UTC 2015


On Fri, May 29, 2015 at 9:16 AM, Bálint Réczey <balint at balintreczey.hu> wrote:
> Hi Dmitry,
>
> 2015-05-29 12:22 GMT+02:00 Dmitry Smirnov <onlyjob at debian.org>:
>> Thanks for insight into upstream security situation, Balint.
>>
>> So what would be the next step? Mass bug filings? Shall we draft a template
>> here?
> Andeas already proposed a transition plan [1] and already submitted
> several bugs.
> If we decide to switch to ffmpeg, I think this is the best proposal so far.
>
> [1] http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/043980.html

That mail proposes to make changes to the "libav" source package so
that the "ffmpeg" source package can "take over" binary package names
currently produced by "libav". That seems overly complicated to me,
and would rather propose to just rename the current "libav" source
package to "ffmpeg" and package the latest ffmpeg source tarball.

I'd rather keep the packaging of the package that is currently called
"libav", because on many architectures, it compiles multiple "flavors"
with hardware optimized flavors (on i386 for instance, there is a
flavor without latest SEE, etc).

Andreas, would that approach be acceptable to you?

If so, then I'd propose to get a test package ready in Git, and I'd
then do a mass-rebuild on my amd64 box to see how many packages fail
to build. If that number seems acceptable, then first upload it to
experimental, and then coordinate with the release team to get a
transition slot.

Regarding the actual decision whether or not to abandon Libav in favor
of FFmpeg: After thinking about this very hard for a couple of weeks,
I find we are in a very uncomfortable situation. Neither of the two
competing projects is really ideal, but the reality is that there is
no one in Debian who has the capacity to significantly contribute to
either of those projects - we are effectively dependent on the
upstream project to provide a product that we can integrate and
redistribute. I have been doing that during the jessie's development,
but things have changed in my life and I'm no longer able to keep up
with that commitment. Libav has served us very well for years, but the
project lost much of its drive from its inception, which is very
unfortunate.

FFmpeg clearly provides more functionality and has definitely more
manpower available that provides also updates for earlier releases.
The drive for maintaining release branches is something rather new for
FFmpeg, and it remains to be seen if that enthusiasm can be held up
even without the competition from Libav.

What makes me most uncomfortable about this move is that it is rather
impossible to reverse - there is no going back. I certainly do hope
that we do not open pandora's box - at least
http://upstream-tracker.org/versions/ffmpeg.html looks promising, but
then FFmpeg comes with a codebase that is hard to maintain, has
competing (i.e., multiple) implementations for encoders and decoders,
and so on.

Bottom line: I still have some concerns with this move, but I can't
claim Libav to be superior to FFmpeg at this point. From the provided
product, I still do believe that Libav is the more promising code-base
for integrating into a large-scale distribution such as Debian because
it has a cleaner code-base that is easier to understand and extend.
>From the development communities, Libav clearly can't keep up with
FFmpeg, who has a defacto full-time developer doing an outstanding
amount of work. There is, however, a significant risk in form of a
bus-factor: Is Michael replaceable? He has been working on FFmpeg for
over 15 years more or less full-time, but is this going to continue
like that forever? Most likely not; so is the risk for that acceptable
for Debian? - It appears that Balint, Allesandro and Andreas think it
clearly is - and I'm not sure why they appear to be so convinced on
this point; neither of them has been around when the things escalated
and Libav forked from FFmpeg after all.

For me, that is a par - and I think I stand with my rather neutral position.

On a personal note: I think the FFmpeg code base stems for a time
where performance was the top-priority - long-term maintainability and
security against malicious sources was clearly not. These new
requirements are best addressed with a general redesign - ideally in a
safer language such as Rust (http://www.rust-lang.org/), or similar.
Unfortunately, such a project is not currently in sight, so the best
option media playback applications have right now to provide secure
and versatile playback capabilities is to sandbox the decoding process
like the Chromium browser. This is challenging to implement and
not-portable, which is however a stated goal of both Libav and FFmpeg.

Also, I would feel much more comfortable if someone could convince me
that FFmpeg is really not a one man show, and is taking maintenance of
both internal and external APIs seriously.

Because of the significance of this issue (this move is rather
impossible to revert), I'd also like to hear the positions of others
who have recently worked on the Libav package:

- Fabian, you were counted as in favor of switching to FFmpeg. In the
light of the most recent posting from Andreas, the mails that Balint
kindly forwarded, and my thoughts, would you approve and support
moving Debian from Libav in favor of FFmpeg?

 - Sebastian, you made the most recent uploads of the Libav package
where I handed off upstream releases to you, but I don't recall you
participating in this thread. I also know that you have been
interacting with Libav upstream in the past. I'd be very curious to
hear your thoughts on this issue, would you mind sharing them?

- Rico, you also worked on the package in the past, and I do remember
that you also hung out on #libav-devel at some point in the past. What
do you think on this matter?

- Jonas & Allessio, Balint counted both of you as in favor of Libav.
Did your opinion/impression change in the last couple of weeks? Can
you think of criteria or assessments that would help with finding a
decision on this matter?

Thank you all for bearing with my rather slow responses. I've been
traveling for the last four weeks and am finally back home now.

-- 
regards,
    Reinhard



More information about the pkg-multimedia-maintainers mailing list