On Fri, Mar 25, 2016 at 9:23 AM, Reimar Döffinger <reimar.doeffin...@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.doeffin...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
