[FFmpeg-devel] Reintroducing FFmpeg to Debian

[Kieran Kunhya]

> Most forks cause additional work which, in the long term, is better spent
> elsewhere. The ffmpeg/libav split is ample proof of that; in an ideal
> world, you wouldn't need the mythtv fork either.
>
> Debian's position is that we _really_ want to avoid having multiple copies
> of essentially the same code in the archive; it's additional work for the
> security team (if they even know about the copies), needlessly eats memory
> when the two are in use simultaneously, and causes no end of trouble when a
> plug-in is linked against copy A while the main code (or another plugin)
> uses copy B (unless everybody is very careful WRT symbol versioning).

The reality is that in the current state of affairs static linking is
the *only* way you are guaranteed to have the features you expect and
avoid ABI mismatches. It's very complicated when your users complain
about bugs in an underlying library that is either too old on a system
or the wrong flavour of the fork. Then your users have to rebuild a
massive dependency chain to fix that bug or hope for the best in the
future.

We also use a fork specifically to work around very wasteful
calculations in libswscale during 10-bit chroma conversion that
involve multiplying a pixel by a 2^n value with 32-bit precision and
then shifting that value down by n back to 16-bit precision (achieving
nothing). The fix breaks other codepaths that we don't use but the
performance gain is big enough to warrant a fork.

FWIW I think debian should also enable libavresample. This code has
been proven to be more robust internally and was designed by a larger
group instead of libswresample which was basically one person (and
literally appeared in git out of nowhere).

Kieran