On Mon, 6 Mar 2017 20:58:53 -0300 James Almer <jamr...@gmail.com> wrote:
> 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. I still think that it's moronic bullshit to disable lavr by default. How about you don't take your moronic fork drama bullshit out on your API users? > > > > > >> > >> 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 doubt anyone really made use of the ABI compat. (you needed a special configure flag to make fully use of it). > > 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. Who is talking about dropping API-compatibility? As long as there are aliases for these extremely similar filters, the level of potential breakages should be very minimal. I'm all for removing redundant code. (Patch 2/4 is potentially contentious, but if someone tried to use that in a portable way, he had to ifdef it between FFmpeg/Libav anyway, because the main use is changing the options of auto-inserted resamplers.) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
