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

[Clément Bœsch]

On Mon, Oct 21, 2013 at 05:47:56PM +0200, wm4 wrote:
> 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.
> 

I guess I was counting the debug symbols in.

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

First point is that we are not the cause of the mess so it's always with
bitterness that we have to fix the problem (did you even complain once
about this to the other project?), and second point is about trust in the
understanding of the code I guess.

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

What I'm trying to explain is that the consequences of such patch - as
small as it is - are not trivial for the project. We are not happy about
dropping swr for at least the reasons I mentioned above (and allow me to
repeat that dropping swr will be a consequence of enabling avr by
default).

I understand this is pain for the users, but so far it seems we are the
only ones making any effort in the compatibility (and right, not enough to
satisfy everyone it seems).

> Why do you even have libavresample in your source tree?
> 

For optional compatibility.

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

Compatibility is not a given; for real ABI compat you have a
--enable-incompatible-libav-abi flag as well. Are you suggesting we make
it the default as well?

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

Nevertheless, a technical discussion is always a progress in a flamewar
debate.

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

No I'm suggesting to make possible to have both Libav and FFmpeg available
on ubuntu/debian. That way, we can imagine a mpv-ffmpeg and mpv-libav,
both linking to the appropriate lib; in that case I'm assuming the
application supports both. If not, you would have only mpv-libav, or only
mpv-ffmpeg. I think debian already deals with such problem (gnutls vs
openssl).

[...]

Now of course Michael has the final word on this decision because he's the
author of libswresample, so you'd better argue with him directly.

-- 
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/3c8f75ba/attachment.asc>