On 6 March 2017 at 22:45, James Almer <jamr...@gmail.com> wrote: > On 3/5/2017 11:46 PM, Rostislav Pehlivanov wrote: > > af_aresample does the same thing better and doesn't depend on > > libavresample > > But it depends on libswresample. What about the builds that are using > lavr but nor lswr? >
You mean that library which is disabled by default? We tell people to use the actual stuff we support rather than the stuff we've let in "for convenience", like we've done for the past 5 bloody years. > > Is the purpose of this set to pave the way for a lavr removal? Because > one thing is dropping ABI compatibility with libav since it was being a > pain in the ass and probably not even working, but another is dropping > whole modules or being increasingly API incompatible. > > So what if it is? I'm not interested if it take 1 month, 6 months, a year, 2 years, that crap is getting out of our code. If you ask me it should never have been merged. I'll write a shim just to keep people like you happy. > If it gets in the way of some addition or refactoring then sure, I'm ok > with an eventual removal, but if it's just "Redundant filter/library I > don't want around" then not so much, because said redundancy was accepted > in the first place to make downstream projects' and users' lives easier. > > And who's going to maintain it once their project dies? We? We already have a better resampling library in our code. We won't need it. As I said before I'll write a fucking API shim when I submit the patches to kill that thing. Even if its half working it'll still work just about as well as that thing's idea of "resampling". Anyway I'm pushing this patch in a few days unless someone objects validly. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
