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

[Ganesh Ajjanagadde]

On Fri, Mar 25, 2016 at 9:23 AM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> 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.

Very fair. I personally know people who worked with Matteo Frigo and
the FFTW project, as it grew out of MIT. This has likely influenced my
perceptions about what they do. I also know pretty big projects use
it, e.g the Julia language. I think it is fair to say it is above your
average library. How far above will be subjective.

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

Maybe not for codecs, but long length FFT's used for filters. Paul at
one point was interested in 2^17 length FFT's, for which assuming the
FFT is the bulk of the compute, FFmpeg's is > 2x slower.

Not saying that we should include FFTW or not, just pointing out possibilities.

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel