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 0F8CD4301C for ; Thu, 15 Sep 2022 21:26:05 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id A5C2C68BBC0; Fri, 16 Sep 2022 00:26:02 +0300 (EEST) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E258368BB95 for ; Fri, 16 Sep 2022 00:25:55 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id EEAC6FF802 for ; Thu, 15 Sep 2022 21:25:54 +0000 (UTC) Date: Thu, 15 Sep 2022 23:25:54 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20220915212554.GS2088045@pb2> References: <20220914232002.325160-1-philipl@overt.org> MIME-Version: 1.0 In-Reply-To: <20220914232002.325160-1-philipl@overt.org> Subject: Re: [FFmpeg-devel] [PATCH] v3: 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="===============1462771136303723255==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============1462771136303723255== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xZUUYh/FQdxVAVy5" Content-Disposition: inline --xZUUYh/FQdxVAVy5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 14, 2022 at 04:20:02PM -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 > Signed-off-by: Philip Langdale > --- > libavutil/pixdesc.c | 31 +++++++++- > libavutil/pixdesc.h | 15 +++-- > libavutil/tests/pixfmt_best.c | 111 ++++++++++++++++++++++++++++------ > tests/ref/fate/pixfmt_best | 2 +- > 4 files changed, 132 insertions(+), 27 deletions(-) >=20 > diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c > index d7c6ebfdc4..6377224c64 100644 > --- a/libavutil/pixdesc.c > +++ b/libavutil/pixdesc.c > @@ -3013,9 +3013,16 @@ static int get_pix_fmt_score(enum AVPixelFormat ds= t_pix_fmt, > =20 > for (i =3D 0; i < nb_components; i++) { > int depth_minus1 =3D (dst_pix_fmt =3D=3D AV_PIX_FMT_PAL8) ? 7/nb= _components : (dst_desc->comp[i].depth - 1); > - if (src_desc->comp[i].depth - 1 > depth_minus1 && (consider & FF= _LOSS_DEPTH)) { > + int depth_delta =3D src_desc->comp[i].depth - 1 - depth_minus1; > + if (depth_delta > 0 && (consider & FF_LOSS_DEPTH)) { > loss |=3D FF_LOSS_DEPTH; > score -=3D 65536 >> depth_minus1; > + } else if (depth_delta < 0 && (consider & FF_LOSS_EXCESS_DEPTH))= { > + // Favour formats where bit depth exactly matches. If all ot= her > + // scoring is equal, we'd rather use the bit depth that most= closely > + // matches the source. > + loss |=3D FF_LOSS_EXCESS_DEPTH; > + score +=3D depth_delta; > } > } > =20 > @@ -3035,6 +3042,28 @@ static int get_pix_fmt_score(enum AVPixelFormat ds= t_pix_fmt, > } > } > =20 > + if (consider & FF_LOSS_EXCESS_RESOLUTION) { > + // Favour formats where chroma subsampling exactly matches. If a= ll other > + // scoring is equal, we'd rather use the subsampling that most c= losely > + // matches the source. > + if (dst_desc->log2_chroma_w < src_desc->log2_chroma_w) { > + loss |=3D FF_LOSS_EXCESS_RESOLUTION; > + score -=3D 32 << (src_desc->log2_chroma_w - dst_desc->log2_c= hroma_w); > + } > + > + if (dst_desc->log2_chroma_h < src_desc->log2_chroma_h) { > + loss |=3D FF_LOSS_EXCESS_RESOLUTION; > + score -=3D 32 << (src_desc->log2_chroma_h - dst_desc->log2_c= hroma_h); > + } with 16bit 4:2:0=20 to 14bit 4:2:0 vs. 16bit 4:4:4 more data is preserved in the later but the 420->444 would have a loss of 64 i think and 16->14 i think 8. I didnt try this just reading the code so i m= ay be missing something but i think the code would favor the lower bitdepth That may be unexpected thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact --xZUUYh/FQdxVAVy5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYyOYXQAKCRBhHseHBAsP q5gbAJ4uxQRbjpDOlp6RHaYa8Fqc83v/aQCcDOOrWgTscxCugPVwScPg7tzZCkU= =61gw -----END PGP SIGNATURE----- --xZUUYh/FQdxVAVy5-- --===============1462771136303723255== 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". --===============1462771136303723255==--