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

wm4 nfxjfg at googlemail.com
Tue Mar 7 08:37:20 EET 2017


On Mon, 6 Mar 2017 20:58:53 -0300
James Almer <jamrial at gmail.com> wrote:

> 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.

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.)


More information about the ffmpeg-devel mailing list