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 ?


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


> 
> Given that nobody ever noticed that it's broken for everything other
> than YUV420P, or bothered adding support in libx264 strongly suggests to
> me that nobody cares about this and it can be safely dropped.
> 
> Anyone against?

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

No snowflake in an avalanche ever feels responsible. -- Voltaire