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

Anton Khirnov anton at khirnov.net
Tue Feb 25 12:28:45 EET 2020


Quoting Thilo Borgmann (2020-02-24 23:07:48)
> 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.

I disagree with that. Keeping code around is not free, as Vittorio
already said - it is a burden in many ways. So I believe all code needs
continued justification for its existence - not just "it was added in
the past so it stays in forever". Note that I'm not saying it needs to
be mainstream or very popular - I am fine with obscure features that
are only useful to a few people in highly special cases (given they are
not unduly intrusive and those people are willing to maintain them). But
so far in this thread, there has been no actual use presented for
exporting and passing around QP tables. None whatsoever.

Most objections here are like yours - it's a) a feature and b) someone
somewhere sometime might conceivably want to use it, so it must not be
removed. Michael's reponse is the only one that comes close to having a
use case, but even he says that he's unsure of the usefulness of the
actual QP tables and that it's largely theoretical.

I believe I did more structural changes to the libraries than most
people and in my experience these obsolete features from mplayer days
are a MASSIVE maintenance pain. The amount of effort required to keep
them working is simply not justified when essentially nobody uses them.

IMO these demands that they all be preserved forever is endangering the
project. If making changes becomes too hard, people stop making them.
They move to other places that are less hostile to change. We are at
risk of turning into a repository of obscure old codecs and filters and
getting overtaken by leaner projects like dav1d (yes it's supposed to be
AV1-only, but that can change).

> 
> 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?

The patch in your link is not using this API. Precisely because this API
is inadequate for anything newer than MPEG4 ASP. If anything, it's an
additional argument in favor of my patches.

> 
> 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.

WTF? What shame?
I am sending patches, in good faith, that I believe will improve the
project. People may (and do) object to them. As long as the discussion
is civil, constructive and in good faith (so far it mostly is), I see no
reason for any shame.

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list