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
_______________________________________________
ffmpeg-devel mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
