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 2B1BF41A2B for ; Sat, 17 Sep 2022 19:13:48 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 59B2268BB36; Sat, 17 Sep 2022 22:13:45 +0300 (EEST) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3E1C968BB1A for ; Sat, 17 Sep 2022 22:13:39 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id 1106D240003 for ; Sat, 17 Sep 2022 19:13:37 +0000 (UTC) Date: Sat, 17 Sep 2022 21:13:37 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20220917191337.GH2088045@pb2> References: <20220917014406.43508-1-philipl@overt.org> MIME-Version: 1.0 In-Reply-To: <20220917014406.43508-1-philipl@overt.org> Subject: Re: [FFmpeg-devel] [PATCH v4] lavu/pixdesc: favour formats where depth and subsampling exactly match 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="===============2906758563668502382==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============2906758563668502382== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SpMheJ0pkkhZNj51" Content-Disposition: inline --SpMheJ0pkkhZNj51 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 16, 2022 at 06:44:06PM -0700, Philip Langdale wrote: > Since introducing the various packed formats used by VAAPI (and p012), > we've noticed that there's actually a gap in how > av_find_best_pix_fmt_of_2 works. It doesn't actually assign any value > to having the same bit depth as the source format, when comparing > against formats with a higher bit depth. This usually doesn't matter, > because av_get_padded_bits_per_pixel() will account for it. >=20 > However, as many of these formats use padding internally, we find that > av_get_padded_bits_per_pixel() actually returns the same value for the > 10 bit, 12 bit, 16 bit flavours, etc. In these tied situations, we end > up just picking the first of the two provided formats, even if the > second one should be preferred because it matches the actual bit depth. >=20 > This bug already existed if you tried to compare yuv420p10 against p016 > and p010, for example, but it simply hadn't come up before so we never > noticed. >=20 > But now, we actually got a situation in the VAAPI VP9 decoder where it > offers both p010 and p012 because Profile 3 could be either depth and > ends up picking p012 for 10 bit content due to the ordering of the > testing. >=20 > In addition, in the process of testing the fix, I realised we have the > same gap when it comes to chroma subsampling - we do not favour a > format that has exactly the same subsampling vs one with less > subsampling when all else is equal. >=20 > To fix this, I'm introducing a small score penalty if the bit depth or > subsampling doesn't exactly match the source format. This will break > the tie in favour of the format with the exact match, but not offset > any of the other scoring penalties we already have. >=20 > I have added a set of tests around these formats which will fail > without this fix. >=20 > v2: Rework penalty system to scale penalty based on how different the > two formats are, and add new loss categories for them. >=20 > v3: Remove leftover bits of v1. > Remove bit depth penalty scaling to avoid the value being too large > in extreme cases (1 bit vs 16 bit). >=20 > v4: Reduce subsampling penalty to avoid situations where a loss of > bit dpeth will have a smaller penalty than having greater than > needed chroma resolution. >=20 > Signed-off-by: Philip Langdale > --- > libavutil/pixdesc.c | 31 +++++++- > libavutil/pixdesc.h | 15 ++-- > libavutil/tests/pixfmt_best.c | 129 +++++++++++++++++++++++++++++----- > tests/ref/fate/pixfmt_best | 2 +- > 4 files changed, 150 insertions(+), 27 deletions(-) should be ok thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. --SpMheJ0pkkhZNj51 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYyYcXQAKCRBhHseHBAsP q23EAJ442OMuzDggqYjkVFgFQlOGdwhw7ACcDP/Xk2uTfHsiQYQBbfbhbD9wpiE= =5i9t -----END PGP SIGNATURE----- --SpMheJ0pkkhZNj51-- --===============2906758563668502382== 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". --===============2906758563668502382==--