Select provider of libav* libraries

[Andreas Cadhalpun]

Hi Reinhard,

On 30.05.2015 23:54, Reinhard Tartler wrote:
> On Fri, May 29, 2015 at 9:16 AM, Bálint Réczey <balint at balintreczey.hu> wrote:
>> 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's correct.

> That seems overly complicated to me,

I think this renaming is a rather mechanical change.

> and would rather propose to just rename the current "libav" source
> package to "ffmpeg" and package the latest ffmpeg source tarball.

Then that ffmpeg source package would take over the binary package
names as well. If you think it's not necessary to preserve the
development packages from src:libav, my proposal becomes even simpler:
Just rename lib*-ffmeg-dev to lib*-dev in the current ffmpeg source
package. That'd work, because src:ffmpeg has a higher epoch.

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

I had considered producing optimized flavors, but I came to the conclusion
that it would complicate debian/rules without much benefit, because
the flavors are mostly unnecessary:
 * On i386 all the SSE etc. optimizations are guarded by runtime
   CPU detection, so that even when compiled with SSE the libraries work
   fine on CPUs without SSE.
   The only optimization were this doesn't apply are the i686 optimizations,
   which currently amount to a dozen assembler lines. So I don't think
   this justifies shipping two flavors.
 * The situation for arm*, where the neon/vfp optimizations are runtime
   guarded, is similar.
 * Sparc is on it's way out, possibly going to be replaced by sparc64.
   So building a sparc64 flavor on sparc isn't really useful.
 * This leaves powerpc, where configure would enable '-maltivec'
   together with the hand-written altivec optimizations, which are guarded
   by runtime CPU detection. This causes gcc to add some altivec
   instructions, which are not guarded and thus cause SIGILL.
   Looking into fixing this in the configure script is on my TODO list.

Are there good reasons to produce these optimized flavors?

> Andreas, would that approach be acceptable to you?

I'd rather continue with the packaging of the current ffmpeg source
package, because the one from src:libav uses a pre-dh7 debian/rules,
and a quite complicated one at that.

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

I already did a mass-rebuild for my proposal and the results can be
found in my mail [1] mentioned above.
The blender and paraview FTBFS bugs have been resolved and the new mpd
version is now in sid, so unless new, unrelated FTBFS bugs were
introduced, only 7 packages would fail to build.
Three of those FTBFS already (dvswitch has a patch in #747868,
gstreamer0.10-ffmpeg should be removed and jitsi is fixed in NEW
since 8 months).
Two (gpac and xbmc) would require changes for the next Libav version
as well, because they use private API, which was changed.
The hardcoded sonames in taoframework have to be updated, like in every
Libav transition. (Maybe someone can fix taoframework to use the sonames
present in the build environment?)
So only gst-libav1.0 needs a FFmpeg specific change, which is an additional
build-dependency on libavresample-dev, because it currently relies on
libavcodec-dev to bring this indirectly, but FFmpeg's libavcodec uses
libswresample instead of libavresample.

> If that number seems acceptable, then first upload it to
> experimental, and then coordinate with the release team to get a
> transition slot.

That's a sensible plan, similar to what I had in mind.

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

The whole FFmpeg/Libav user base is in an uncomfortable situation
since the split.

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

I guess "new" depends on the timescale of comparison, but FFmpeg 0.5
has been maintained during the past five years.
Also I'm not sure what you mean with "without the competition from Libav".
Do you expect Libav to vanish suddenly?

> What makes me most uncomfortable about this move is that it is rather
> impossible to reverse - there is no going back.

Why that? We're currently discussing to revert the move from FFmpeg to
Libav. Similarly, if at some point in the future another fork becomes
more useful for Debian, we could move to it.

> 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

I'd claim it's not harder to maintain than the Libav codebase, unless
you can provide some evidence for this.

> competing (i.e., multiple) implementations for encoders and decoders,

Libav also has multiple implementations for encoders (e.g. ac3/ac3_fixed)
and decoders (e.g. mp3/mp3float). It just has fewer de-/encoders in total.

> and so on.

What else?

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

I still don't see what about the Libav codebase should be cleaner or
easier to understand than the FFmpeg codebase.

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

That Libav still contains many security issues fixed in FFmpeg is very
convincing.

> neither of them has been around when the things escalated
> and Libav forked from FFmpeg after all.

I consider myself lucky that I had not been involved in that escalation,
which must have been painful for everyone involved.

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

Aside from such a redesign being a major undertaking, choosing a language
like Rust has another problem: Many more developers can write C than Rust,
so the barrier for contribution would be much higher for most.

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

Finding and fixing the remaining security problems is another option,
which is currently worked on.

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

Your allegation that FFmpeg was a "one man show" is highly disrespectful
to all other FFmpeg contributors, including the Libav developers, whose
improvements are merged by Michael.

Anyway, let me try to convince you again:
FFmpeg 2.4 was released around the same time as Libav 11 in September 2014.
Let's look at the number of commits since then:
Libav:
$ git shortlog -ns --no-merges v11..HEAD | head -n15
   294	Vittorio Giovara
   253	Martin Storsjö
   206	Anton Khirnov
   131	Luca Barbato
    72	Diego Biurrun
    46	Michael Niedermayer
    32	Rémi Denis-Courmont
    21	Andreas Cadhalpun
    17	Hendrik Leppkes
    16	Gabriel Dume
    16	Himangi Saraogi
    16	wm4
    14	Federico Tomassetti
    12	Peter Meerwald
    11	Janne Grunau

FFmpeg:
$ git shortlog -ns --no-merges n2.4..HEAD | head -n15
  1831	Michael Niedermayer
   294	Vittorio Giovara
   252	Martin Storsjö
   197	Anton Khirnov
   179	Clément Bœsch
   155	James Almer
   150	Carl Eugen Hoyos
   114	Andreas Cadhalpun
   113	Luca Barbato
    98	Lukasz Marek
    93	Paul B Mahol
    85	Ronald S. Bultje
    83	wm4
    66	Christophe Gisquet
    48	Benoit Fouet

So while Michael is clearly the most active FFmpeg developer, it is not
at all a "one man show".
Claiming that is a bit like claiming that Linux development was a
"one man show", because Linus is the most important developer.

Regarding API stability, you already mentioned the upstream tracker, so I
don't know what further evidence you'd like to see that FFmpeg takes API
stability 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?

I'd also be interested in the current opinion of the people mentioned
above.

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

I hope you enjoyed your journey.

Best regards,
Andreas