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

Thilo Borgmann thilo.borgmann at mail.de
Tue Feb 25 00:07:48 EET 2020


Am 24.02.20 um 22:41 schrieb Lou Logan:
> On Mon, Feb 24, 2020, at 3:37 AM, Anton Khirnov wrote:
>> 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.
>> ---
>>  doc/filters.texi            |  32 -------
>>  libavfilter/Makefile        |   1 -
>>  libavfilter/allfilters.c    |   1 -
>>  libavfilter/vf_qp.c         | 183 ------------------------------------
>>  tests/fate/filter-video.mak |   7 +-
>>  tests/ref/fate/filter-pp2   |   1 -
>>  tests/ref/fate/filter-pp3   |   1 -
>>  7 files changed, 1 insertion(+), 225 deletions(-)
>>  delete mode 100644 libavfilter/vf_qp.c
>>  delete mode 100644 tests/ref/fate/filter-pp2
>>  delete mode 100644 tests/ref/fate/filter-pp3
> 
> Fine with me. I've never seen it used by anyone.

I'm not fine with it. Declaring it's {use | use case} not existent is no arguments whatsoever in reality.

Also, removing some functionality needs an argument - it is not keeping some functionality needs an argument.

Nobody technically elaborates Paul's statement that it should go into side data. WTF? The compromise isn't even considered?

Let's dig some trenches, shall we?

And how come some obvious "use cases" / "needs" like [1] come into play? Or do we declare not continued discussions non-existent now, too?

And how comes, if Michael's investigation, that all of this is based on use of _a function_ that is deprecated instead of direct access of AVFrame's fields is the cause of all of this?

Shame on all of us.

-Thilo

[1] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-August/247401.html


More information about the ffmpeg-devel mailing list