[FFmpeg-devel] [PATCH 1/4] configure: add fftw3 detection

[Reimar Döffinger]

On Fri, Mar 25, 2016 at 07:50:22AM -0700, Ganesh Ajjanagadde wrote:
> On Fri, Mar 25, 2016 at 2:32 AM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de> wrote:
> >> Big NO from me. Please refrain from doing such silly things.
> >> Either improve our implementation or do nothing.
> >
> > I don't disagree with the basic objections, but
> > I'd appreciate more diplomacy and kindness (and
> > space for people to explain there motivations)
> > in the responses.
> 
> To see if I understand the objections a bit better, how is this for a
> one line summary:
> FFmpeg does not like external libs, no matter how good or bad they are
> relative to its own code, when it has internal code that does roughly
> the same thing.

Short: It's probably not that far off. Though I think we simply
don't like external libraries in general :)

Much longer:
At least for me it is mostly
1) Improving our code is the top priority
2) external libs always add maintenance effort, so there
must be a relevant enough advantage. We are not too
consistent in what we require, but often it is things
like that it's too complex for us to do, or it is new
and it will take some time to get it done ourselves
or it is there for us to be able to compare in a shared
environment (can make debugging/testing easier).

x264 is an example of code that was good enough to win
simply on being "too good" so "no matter how good or bad"
is not true.

But there's a lot of external projects we sometimes
with effort, sometimes easily managed to be (much) better.

Also, nobody reviews external libraries, and quite
a few of them have horrible portability or code quality
issues. Nothing obvious on FFTW, but check major libraries
like (not relevant to us) libLLVM, not offering a stable API
is one thing I can excuse, but they export symbols like
ConvertUTF8toUTF16 and isLegalUTF8String (!!!).
If compiler guys don't manage to follow basic best
practices, what do you think what kind of crap you can find
in most other random libs?
What about boost for example, knowingly including files
licensed under an incompatible license or not at all
in a tarball claiming to be licensed under the boost license?
Or the lagarith "lossless" codec relying on bitexact
x87 FPU operations so it can't decode unless compiled
for 32 bit x86 with specific compiler options?
Also always a question:  Will the upstream project be able to
handle security issues in a timely manner?
It's easy to be negatively surprised by libraries,
and it leaves a mark.
Which circles back to "no matter how good the code
of the external library". I don't know if the FFTW
code is in fact good, and it is not easy to find
out that kind of thing.

Not that we don't have enough issues with our code,
but it's at least our code and we deserve the blame
we get from it :)

> > I am in the habit of liking to call things silly
> > myself, but honestly almost all patches here
> > exist for a good reason, even if including
> > them is not a good idea, and I don't want to
> > discourage people from sending in interesting
> > but "silly" things just because they might be derided.
> 
> BTW, in case you want to know for e.g improving communication, this is
> not the first time. This has happened on multiple occassions before. I

Oh, I know it is quite common. I'm not the list policeman,
I just sometimes think it might be a good idea to complain a bit.

> actually very much appreciate Paul's and Clement's responses here.
> Unlike others here, they actually point out their fundamental
> objections at the beginning instead of showing some "fake interest",

No time to read the example and it sure happens, but
1) I don't mean to say people should pretend to agree, it's quite
possible to be firm and polite (but I'm not really angry with people
if they aren't, I just want to push things a bit).
2) "fake interest" might just be a case of it taking time.
If FFTW made some codec (not just the FFT part) 2x faster and
implementing the same optimizations in FFmpeg would mean adding
2000 lines of code I'd probably be in favour. Though based on
nothing I assume it's not even remotely like that.