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

[wm4]

On Mon, 21 Oct 2013 17:17:43 +0200
Clément Bœsch <u at pkh.me> wrote:

> 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

On my system, libavresample.a is 169KB.

> 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

And that matters how?

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

Yes, it's a political choice. You'd rather let all your users suffer in
pain (and maybe you use that to "convince" users to drop support for
Libav altogether?) than accept an essentially 1-line patch and just
enable the library. It also looks like the advantages of libswresample
over libavresample are so marginal that you have to use force to make
your users use it! It's a fucking joke.

Why do you even have libavresample in your source tree?

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

I really find this funny. Look at all the crappy ABI hacks Michael is
adding to all libav* libraries just to be ABI compatible to Libav, and
all the API fallout it's causing. But just _enabling_ libavresample by
default goes too far?

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

No, it's a political issue.

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

You suggest to make everyone on these systems to use Libav plus
libswresample? You know this is not a reasonable solution. There's no
way anyone would mish-mash these libraries in this way, if it even
works from a technical point of view.