[FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp

[Anton Khirnov]

Quoting Soft Works (2020-02-24 17:13:54)
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > Anton Khirnov
> > Sent: Monday, February 24, 2020 3:55 PM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel at ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp
> > 
> > Quoting Carl Eugen Hoyos (2020-02-24 13:50:57)
> > > Am Mo., 24. Feb. 2020 um 13:40 Uhr schrieb Anton Khirnov
> > <anton at khirnov.net>:
> > > >
> > > > It fundamentally depends on an API that has been deprecated for five
> > > > years, has seen no commits since that time and is of highly dubious
> > > > usefulness.
> > >
> > > Please explain how the removed functionality was replaced.
> > 
> > It was not, for the reasons mentioned in the commit message. In my view,
> > the fact that nobody fixed it in all that time proves that nobody cares about
> > this functionality and thus that there is no value in keeping it.
> > 
> > Furthermore, I believe this filter (and all the associated "postprocessing"
> > ones) are anachronistic relics of the DivX era. They were in fashion around
> > ~2005 (though I doubt they were actually improving anything even then) but
> > nobody with a clue has used them since
> 
> Following those or similar arguments in a consequent way, would quickly 
> constitute quite a list of ffmpeg features having "no value" anymore.

Yes, and all features with no value should be removed. They are a burden
for both developers and users. Keeping them is bad for the project and
not good for anyone.

> 
> Removing features from one day to another would appear to me as a bit
> too extreme, no matter how useless the feature might be.

It's not "from one day to another" though. This functionality has been
deprecated for five years. And in that entire time nobody ever had
enough interest to do anything about it.

> 
> Maybe it would make sense to introduce some kind of feature category
> like "legacy features" where those types of features can be 'parked'
> for a while before getting removed eventually. 

Git history is not going anywhere. If there is ever a use case for this
(which I strongly doubt, but could happen), people are free to take the
code from history and adapt it to whatever new API they come up with.

-- 
Anton Khirnov