Hi Kieran,
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
future.
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 [1].
Still I would be interested in any proof of libavresample being 'more
robust internally'.
Best regards,
Andreas
1:
https://anonscm.debian.org/cgit/collab-maint/ffmpeg.git/commit/?id=e6d32135ec5ada648465aba8d4daad58b86ff8d0
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e66785.4020...@googlemail.com
