From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 811BB45F78 for ; Wed, 19 Apr 2023 22:12:59 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2439768BEE9; Thu, 20 Apr 2023 01:12:57 +0300 (EEST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 960CA68A630 for ; Thu, 20 Apr 2023 01:12:50 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id ADAEA1C0004 for ; Wed, 19 Apr 2023 22:12:49 +0000 (UTC) Date: Thu, 20 Apr 2023 00:12:48 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230419221248.GV275832@pb2> References: <20230419194832.757-1-anton@khirnov.net> <20230419205302.GU275832@pb2> <168193836938.9711.9672747873724950733@lain.khirnov.net> MIME-Version: 1.0 In-Reply-To: <168193836938.9711.9672747873724950733@lain.khirnov.net> Subject: Re: [FFmpeg-devel] [RFC/PATCH] fftools/ffmpeg: stop printing PSNR information in status report X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============4360761803060011542==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============4360761803060011542== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="worL9B4ITIAQZ1FS" Content-Disposition: inline --worL9B4ITIAQZ1FS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 19, 2023 at 11:06:09PM +0200, Anton Khirnov wrote: > 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, > >=20 > > > * the code computing PSNR assumes 8bit 420 video and prints incorrect > > > values otherwise; there are no issues on trac about this > >=20 > > Are the values in the "otherwise" case maybe good enough so they > > worked for people with noone noticing ? >=20 > 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. >=20 > > > * 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 > > >=20 > > > This suggests that this feature is not useful and it is better to rem= ove > > > 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. > >=20 > > 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 >=20 > 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. That sounds like a missing feature. vf_psnr cannot use the encoder values, it always needs to recompute them. The encoder could export these values in metadata and vf_psnr could then check if the frame pairs already have their psnr computed and use that. >=20 > 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? The "problem" isnt psnr specific having a filter which could provide another metric and be able to use encoder supplied data when available or compute them from encoder input + decoded images in a way that is automatic would be useful It would mean a single syntax a user could use to get the metric he wants while using the optimal implementation thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. --worL9B4ITIAQZ1FS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZEBnWwAKCRBhHseHBAsP q6BNAJsH4crQ1hcfneffLOiEFb90rA7tSwCeJXH9U8he+kms2982+3zM5chk3dk= =RMih -----END PGP SIGNATURE----- --worL9B4ITIAQZ1FS-- --===============4360761803060011542== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". --===============4360761803060011542==--