Select provider of libav* libraries

[Bálint Réczey]

Hi Reinhard,

2014-10-04 19:47 GMT+02:00 Reinhard Tartler <siretart at gmail.com>:
> On Sat, Oct 4, 2014 at 11:46 AM, Bálint Réczey <balint at balintreczey.hu> wrote:
>
>> I would also like to add that since Libav and FFmpeg offer different
>> features they are different enough to consider them as alternates
>> which have the place in Debian on their own right.
>
> This is the part that makes me very uneasy, because that is a
> statement that neither FFmpeg nor Libav upstream hold (Libav largely
> ignores what FFmpeg says or does, and FFmpeg claims to have all
> features of Libav because of the daily merges).
AFAIK FFmpeg also claims to have features which are not present in
Libav which makes a difference here.

>
> I think it is fair to say that both ffmpeg and libav share a large set
> of common functionality. This can be seen by the fact that both
> provide a set of competing shared libraries. I am not really convinced
> that this sort of competition is helpful to Debian. In fact, I see it
> rather harmful, as it fragments our archive in packages in two camps.
I see a competition here fruitful rather than harmful. There is an mpv
and an xbmc package using ffmpeg in experimental and if there are two
camps I'm in both. I try to pick the library which works better for
the package in question. I also maintain forked-daapd which I don't
plan switching to ffmpeg because I see no advantage of doing so.

>
> I claim that the majority of packages involved in the last two
> libavformat/libavcodec library transitions do not care what package
> provides libavformat.so/libavcodec.so (and their dependencies). In
> what way does the choice between the libavcodec.so provide help them?
> I see a great potential for confusion here, for rather little gain.
I would let the maintainers of those packages comment on this part.

On thing I can see as a gain is that people will probably prefer Debian's
ffmpeg packages over dmo's ones creating less invalid bugs in the BTS.

I also expect the features of FFmpeg and Libav to converge since Libav
would become more motivated in providing the features already
present/still present in FFmpeg. I think the healthy competition
created by having both libraries in Debian will create both forks more
productive.

>
> I would rather see people help with improving Libav, which provides a
> cleaner and leaner codebase and is supported by an upstream with a
> much more responsible development process. Just take the recent
> shellshock drama as an example for what happens if you integrate
> questionable (or simply too much) functionality in a widely used piece
> of software.
I would not make big claims here because Libav's security track record
is not known to be way better than FFmpeg's. I think there has been
great progress lately, the security tracker in Debian shows no open
issues for libav now.

>
> I do understand that VDPAU doesn't work with XBMC when using libav.
> Note that this seems to be specific to XBMC, because both mpv and vlc
> seem to use libav's VDPAU capabilities just fine. I've raised this on
> IRC a few hours ago and it is being looked at. For the future, VDPAU
> is currently being overhauled in libav/master. I think it is fair to
> say that this issue is being taken seriously, although the reaction
> could definitely be more rapid.
Thank you for raising the issue. I'm testing the patch right now.

Cheers,
Balint

>
>
>> PS: I would like to see the Libav and FFmpeg forks merging under any
>> name they pick, but this is unlikely to happen before Jessie's freeze.
>> Maybe before Jessie+1...
>
> I fully agree here, and would love to help on making that happen. But
> before that can happen, both projects need to sort out the outstanding
> trust issues, and agree on a common development process. At least
> that's my take-away from the most recent discussion threads on
> debian-devel@ and elsewhere.
I think both projects should work on getting closer to the other's
position and I see this stalled at the moment...

>
> --
> regards,
>     Reinhard