[FFmpeg-devel] Reintroducing FFmpeg to Debian
andreas.cadhalpun at googlemail.com
Sat Aug 9 20:25:09 CEST 2014
On 09.08.2014 19:26, Kieran Kunhya wrote:
> 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
I can understand that statically linking is easier from an upstream
point of view, but it has important disadvantages for a distribution
such as Debian and thus should be avoided if possible.
It is also the responsibility of a distribution to make sure that there
are no ABI mismatches or similar problems.
> 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.
Can you provide a commit/diff/link for reference?
The way you describe it makes it appear as if these calculations are
needed sometimes, but not always. If so, there should be away to teach
libswscale to only do these calculations if they are necessary.
> 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).
FWIW I already enabled libavresample in the Debian FFmpeg package for
compatibility reasons .
Still I would be interested in any proof of libavresample being 'more
More information about the ffmpeg-devel