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

[Paul B Mahol]

On 2/24/20, Anton Khirnov <anton at khirnov.net> wrote:
> 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.

There is lot of hate here, so I'm refrain from posting further.
Do as you and technical committee wish. I'm out of the game.

>
> --
> Anton Khirnov
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".