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

[Anton Khirnov]

Quoting Paul B Mahol (2020-02-24 18:07:26)
> On 2/24/20, Anton Khirnov <anton at khirnov.net> wrote:
> > Quoting Paul B Mahol (2020-02-24 17:02:52)
> >> On 2/24/20, James Almer <jamrial at gmail.com> wrote:
> >> > On Monday, February 24, 2020, Carl Eugen Hoyos <ceffmpeg at gmail.com>
> >> > wrote:
> >> >>
> >> >>
> >> >>
> >> >>> Am 24.02.2020 um 15:54 schrieb Anton Khirnov <anton at khirnov.net>:
> >> >>>
> >> >>> 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.
> >> >>
> >> >> In this case your patch set is not acceptable: I strongly suggest you
> >> > work on something that improves FFmpeg instead of removing features.
> >> >>
> >> >> Carl Eugen
> >> >
> >> > Anton argued why it should be removed. You should do the same about why
> >> > it
> >> > should not. Simply saying you are against removing features other
> >> > developers consider useless is not enough.
> >>
> >> Filter as is was simply never marked for deprecation, same applies for
> >> removed features to other filters in this set.
> >
> > So what? It produced deprecation warnings on every build for five years.
> >
> > Are you claiming you have a use case for it? Or know about someone who
> > does?
> 
> I believe there are still usecases for this filter and other filters.

Elaborate please. What use cases? Actual or theoretical?

> 
> What about other filters and other deprecation warnings?
> Are filters gonna be removed because of single deprecation warning in file?

This is sophistry, the filter is not being dropped because of a minor
deprecation warning in it. The fundamental functionality which it is
built around is to be removed.

> 
> I think it was mistake to set qp side data as deprecated right after
> its addition.

This is not an an accurate description of what happened. Exporting QP
tables wasn't deprecated at that point. Rather the preexisting
functionality for exporting QP tables (as plain points to avcodec
internal buffers) was converted to newly added side data API to keep
things working for a while and see if anyone wants to keep this. Five
years passed and nobody did. Therefore it should be removed.

> 
> It is hurting our reputation when users look how we removed items
> after few years
> of usage or when we deprecate items right in same commit that added them.

I believe it hurts our reputation a lot more when our feature list reads
like state of the art from 2002, but necessary infrastructure
maintenance cannot be done because of the burden of all these
"features".

Users hate us a lot more for confusing inconsistent poorly documented
APIs which are hard to use correctly than for deprecating obsolete
filters.

-- 
Anton Khirnov