[FFmpeg-devel] Reintroducing FFmpeg to Debian

[wm4]

On Sat, 09 Aug 2014 20:25:09 +0200
Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> wrote:

> 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].

That's pretty nice! Maybe now people don't have to deal with two
extremely similar yet slightly different resampling libraries. It
really takes the cake when you try making your software work with both
FFmpeg and Libav.

Unfortunately, FFmpeg vehemently resists against enabling lavr by
default.

> 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
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel