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

Soft Works softworkz at hotmail.com
Mon Feb 24 19:04:17 EET 2020



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Paul B Mahol
> Sent: Monday, February 24, 2020 5:39 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp
> 
> On 2/24/20, Soft Works <softworkz at hotmail.com> wrote:
> >> -----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.
> >
> 
> Please write such a list, I'm interested.

Excellent trap, but I won't step in ;-)

I'm not even advocating to start some kind of deprecation cycle. All I
meant to say is that _if_ there's something to be removed, it might
possibly be a good idea to have some kind of "soft-" or "2-stage-"removal
which would provide an opportunity for users to accommodate 
or complain.

softworkz




More information about the ffmpeg-devel mailing list