On 3/6/2017 8:20 PM, Rostislav Pehlivanov wrote: > 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.
Yes, the library we disable by default but that some downstream projects enable to easily support both projects without a massive amount of custom codepaths or ifdeffery. > > >> >> 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. You seem to have forgotten the very long years where Debian shipped libav and not ffmpeg. Had we not merged that library and dropped API/ABI support from the get go, who knows what would have happened. > I'll write a shim just to keep people like you happy. I'd very much like if every other of your emails could stop being so aggressive when it's completely unjustifiable. You seem to be reacting to some old frustration with this code (or code you dislike in general) rather than to an email by "people like me" where I'm simply expressing the need to not disrupt downstream projects too much unless necessary. > > >> 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. My concerns are very valid, and i ask you again to drop the aggressiveness. You'll write a shim? That's great. Just don't be a dick when you're informing me about it. And for that matter, if the general consensus is to drop all pretenses of API compatibility then i have no issues with all this. You wouldn't even need to write a shim in that case. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
