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. 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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
