[FFmpeg-devel] [PATCH] configure: enable libavresample by default

Clément Bœsch u at pkh.me
Mon Oct 21 17:17:43 CEST 2013

On Sun, Oct 20, 2013 at 07:23:23PM +0200, wm4 wrote:
> ---
> There are several reasons why we should do this:
> - It makes it easier to migrate from Libav to FFmpeg.
> - Reduces differences between Libav and FFmpeg, increases
>   interoperability, and reduces the change that software becomes
>   Libav or FFmpeg only (the latter would not be bad for FFmpeg, but
>   the latter definitely is - so interoperability is better for FFmpeg
>   as well).
> - Makes resampling and mixing behavior (performance and quality)
>   more predictable for software that has to run with both FFmpeg
>   and Libav.
> - Makes some Libav-only software run on FFmpeg (assuming there
>   is software which relies on libavresample being present).
> - Easier to maintain than a hypothetical API compatibility wrapper
>   around libswresample to make it look like libavresample.
> - Some audio filters in lavfi depend on it. They are disabled if
>   libavresample is disabled.
> - You shouldn't cause pain to your users just because you think
>   that libswresample is unambiguously better than libavresample.
> - It's in the source tree, so why not enable it?

And there are also reasons we should not, such as:
 - adds 500kb of duplicated code
 - completely kills the purpose of the library we maintain

Now I understand that it looks more probable to replace lswr with lavr
from FFmpeg side than lavr with lswr from the other, but unfortunately
it's not something easily acceptable for us either:
 - lswr was here in the first place
 - lswr is written by (one of?) the main author of the original resampling
   code on which lavr is also based
 - has a somehow simpler API *IMO* (see the linesizes redundancy in lavr)
 - it is feature equivalent so far AFAIK
 - we can make the API evolve easily in comparison to lavr.

And of course, let's be honest; this is a political/strategic choice. As I
said earlier, if we accept lavr to be a default, users will never use lswr
and it would mean the death of that library, and quite a pain for us to
make the switch to lavr, and would kill all the efforts put into it.

I don't have a good or simple solution for the problem you raise, but I
don't agree with that patch, because I find this reckless for the future
of the project.

Maybe you could make a technical comparison of both libraries
(performance, API usage, documentation, features, bugs, whatever), that
would help going in your direction. Of course, it's likely the results of
that research will lead to random improvements to lswr to make it more
competitive/fill the potential gaps.

The best bet in my opinion would be to make FFmpeg packaged on the only
distro where it isn't: ubuntu/debian. I'm not talking about replacing the
fork, I'm suggesting a way to access libswresample for every application.
This will solve your problem, and many others.


Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131021/f58881e1/attachment.asc>

More information about the ffmpeg-devel mailing list