[FFmpeg-devel] [PATCH 1/4] lavfi: remove af_resample

James Almer jamrial at gmail.com
Tue Mar 7 01:58:53 EET 2017


On 3/6/2017 8:20 PM, Rostislav Pehlivanov wrote:
> On 6 March 2017 at 22:45, James Almer <jamrial at 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.



More information about the ffmpeg-devel mailing list