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

[Michael Niedermayer]

On Mon, Feb 24, 2020 at 03:54:45PM +0100, Anton Khirnov wrote:
> 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.

your reasoning only works if there is a problem that requires a fix.

Your reasoning here seems
BIG problem in A && noone fixes it -> noone cares about A

My view is
whoever sees a problem in A (i do not really) should fix it.

Maybe iam missing something and there is in fact a big problem in the
code. But if that is the case iam not aware of the problem and thats
why i did nothing for years "fixing" it. Its not that i do not care.

So what is really the issue here ?
if i build vf_qp.o i get
./libavutil/frame.h:719:1: note: 'av_frame_get_qp_table' has been explicitly marked deprecated here
attribute_deprecated

./libavutil/frame.h:721:1: note: 'av_frame_set_qp_table' has been explicitly marked deprecated here
attribute_deprecated

if i look at git history these where deprecated in
commit 7df37dd319f2d9d3e1becd5d433884e3ccfa1ee2
Author: James Almer <jamrial at gmail.com>
Date:   Mon Oct 23 11:10:48 2017 -0300

    avutil/frame: deprecate getters and setters for AVFrame fields
    
    The fields can be accessed directly, so these are not needed anymore.

This says the field can be accessed directly, so certainly its not
deprecated in favor of the side data API.    

and in fact av_frame_get_qp_table / av_frame_set_qp_table do use the 
side data API already so none of this makes sense really.
And the whole argument about five years also isnt correct as
october 2017 is not 5 years ago


> 
> Furthermore, I believe this filter (and all the associated
> "postprocessing" ones) are anachronistic relics of the DivX era. They
> were in fashion around ~2005 (though I doubt they were actually
> improving anything even then) but nobody with a clue has used them since
> H.264 took over.

well, for old videos (which still exist today) and i mean the stuff
that used 8x8 dct based codecs mpeg1 to mpeg4, divx, msmpeg4, realvideo
also jpeg and that use not very high bitrate. (very high bitrate of course
doesnt have much to improve toward)

There is a quite noticable quality improvment when using postprocessing
with the right parameters both subjective and objective (PSNR IIRC)
And at the rare but not noneexisting occurance where i do want to watch
such a video i always use one of these filters.
In realty that has often been the spp filter but thats probably not
important.
In general if you can see 8x8 blocks without the filter, these filters
will make the video simply look better.

if passing QP helps for the above usecase probably depends on how
variable QP is in the video one wants to watch or if a single fixed
hand tuned QP works well (it often does indeed)

Another usecase for passing QP was lossless re-encoding.
I do not know how common this has been used (iam not using it and its not
my idea originally), this of course also requires a encoder which
can accept motion vectors and MB types on input or intra only

Yet another use case is maintaining the input encoders choices
for quantization / quality when converting to another format.
in principle one could even have one encoder provide quantization
information to a second encoder

            -> encoder1
           /       v
raw input         QP
           \       v
            -> encoder2
           
why? i dont know, maybe for art or fun, duplicate some bad QP choices or good
QP choices, or edit QP choices ina specific area.

but i would not call the ability to pass the QP array around and
to modify it useless.

Also last but not least, if you think there really is an issue that
MUST be fixed otherwise the code must be removed. Why not ask the 
people listed in authors & copyright to look into it ?
Iam listed in the copyright it seems and unless i forgot it noone
asked me to fix some major issue in vf_qp

Thanks


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200224/5fd30107/attachment.sig>