Select provider of libav* libraries

[Bálint Réczey]

2015-05-30 23:54 GMT+02:00 Reinhard Tartler <siretart at gmail.com>:
...
> 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).
IMO merging the mentioned and other useful parts to ffmpeg:src and a
switch would be better than switching libav's upstream again. It would
be less confusing for everyone. Why should I always explain that yes,
it is FFmpeg but we call it the libav source package and yes, there is
a Libav upstream project which is not tracked by any package in Debian
anymore. :-)

...
> 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.
I have explained my professional opinion regarding the situation but I
summarize it briefly adding the project management perspective:
If Michael stops contributing to FFmpeg, there will be enough people
around to continue development from that point in the ffmpeg tree.
Forking in advance is a waste of time, but improving and understanding
ffmpeg's codebase would be valuable even without considering the bus
factor.

Libav is full of known secholes while ffmpeg is fuzz-free which calls
for an immediate switch.

Libav  lacks manpower and nothing seems to change it in the near nor
the far future.

I was not around when Newton discovered gravity, but it worked for me
pretty reliably so far. :-)

Cheers,
Balint

PS: Stretch without FFmpeg means Stretch without Kodi almost certainly.