[FFmpeg-devel] [RFC/PATCH] fftools/ffmpeg: stop printing PSNR information in status report

[Anton Khirnov]

Quoting Michael Niedermayer (2023-04-19 22:53:02)
> On Wed, Apr 19, 2023 at 09:48:32PM +0200, Anton Khirnov wrote:
> > When an encoder exports sum-of-squared-differences information in
> > encoded packets, print_report() will print PSNR information in the
> > status line. However,
> 
> > * the code computing PSNR assumes 8bit 420 video and prints incorrect
> >   values otherwise; there are no issues on trac about this
> 
> Are the values in the "otherwise" case maybe good enough so they
> worked for people with noone noticing ?

While working on this with a 10bit sample I was suprised this code and
vf_psnr showed significantly different values (IIRC not even the first
digit was accurate) and it took me a while to realize the scaling made
the assumptions it did.

> > * only a few encoders (namely aom, vpx, mpegvideo, snow) export this
> >   information; other often-used encoders such as libx26[45] do not
> >   export this, even though they could
> > 
> > This suggests that this feature is not useful and it is better to remove
> > it rather than spend effort on fixing it.
> > ---
> > I needed to resolve this code's interaction with encoders as a part of
> > my multithreading work and spent a few hours on it. Making it work
> > correctly in all cases seems nontrivial and duplicates a lot of the
> > logic from vf_psnr.
> 
> Can anything missing in vf_psnr be added into it and then vf_psnr used ?
> I agree that duplicating PSNR code and logic is bad

Nothing is missing in vf_psnr AFAIK, the difference is that these values
are produced directly by the encoder, so you don't need a
decoding+filtering pass to obtain the numbers.

The question more broadly is - what is this supposed to be useful for?
PSNR is a highly flawed metric and AFAIU state of the art moved several
generations away from it. And for a quick-and-dirty quality estimate,
the bitrate and QP might be more informative for most users, and are
supported by more encoders. So what is the point of printing this
information?

-- 
Anton Khirnov