Quoting Paul B Mahol (2020-02-24 18:07:26) > On 2/24/20, Anton Khirnov <an...@khirnov.net> wrote: > > Quoting Paul B Mahol (2020-02-24 17:02:52) > >> On 2/24/20, James Almer <jamr...@gmail.com> wrote: > >> > On Monday, February 24, 2020, Carl Eugen Hoyos <ceffm...@gmail.com> > >> > wrote: > >> >> > >> >> > >> >> > >> >>> Am 24.02.2020 um 15:54 schrieb Anton Khirnov <an...@khirnov.net>: > >> >>> > >> >>> Quoting Carl Eugen Hoyos (2020-02-24 13:50:57) > >> >>>>> Am Mo., 24. Feb. 2020 um 13:40 Uhr schrieb Anton Khirnov < > >> > an...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".