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 1DFF444452 for ; Sat, 10 Sep 2022 17:00:12 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2963168BB25; Sat, 10 Sep 2022 20:00:09 +0300 (EEST) Received: from mail.overt.org (mail.overt.org [157.230.92.47]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 64B8268B8EC for ; Sat, 10 Sep 2022 20:00:02 +0300 (EEST) Received: from authenticated-user (mail.overt.org [157.230.92.47]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mail.overt.org (Postfix) with ESMTPSA id 0101C3F1EB for ; Sat, 10 Sep 2022 11:59:59 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=overt.org; s=mail; t=1662829200; bh=+P5Qv3jtko8OtX3GQAbgWxNU2mWM6A/njyT1dVdHUqM=; h=Date:From:To:Subject:In-Reply-To:References:From; b=t6k2eGoCUetj0u+fAStVMPAIkx2EJyQ3VDtrlw9fBbRvNPM0wRKBhgQtg0bnOji49 vIBxfUM8aA5Z3+CgPGEkGAlRxe+h7JjMFW16pabc8lNp1AyZQqNFEtSg74gczBJoak RZkqG7pgxj7+Cvv5w8xPentULNpYVgypM6DFgKc3GpwBzFP/DZCsdflBnAhg39f6Et bbCSZMfDGTF81/Lzmr66mgXc/1bogozj8o4erit6sJ46iywXJd7mt1uO+dB12jfk7H js9XtXjvvIxpyz6547DlBuUvKiG8bIzkf8pQ6b9POeZQVE+TLOGDpZl/6J+hw12VcZ eL77rBYs/0qLg== Date: Sat, 10 Sep 2022 09:59:54 -0700 From: Philip Langdale To: ffmpeg-devel@ffmpeg.org Message-ID: <20220910095954.62c8fcd1@fido7> In-Reply-To: <20220910150432.GH2088045@pb2> References: <20220909034611.390710-1-philipl@overt.org> <20220910150432.GH2088045@pb2> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] lavu/pixdesc: favour formats where bit depth exactly matches 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Sat, 10 Sep 2022 17:04:32 +0200 Michael Niedermayer wrote: > > > > diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c > > index d7c6ebfdc4..412e257a30 100644 > > --- a/libavutil/pixdesc.c > > +++ b/libavutil/pixdesc.c > > @@ -3004,6 +3004,11 @@ static int get_pix_fmt_score(enum > > AVPixelFormat dst_pix_fmt, if ((ret = > > get_pix_fmt_depth(&dst_min_depth, &dst_max_depth, dst_pix_fmt)) < > > 0) return -3; > > + // Favour formats where bit depth exactly matches. If all > > other scoring is > > + // equal, we'd rather use a lower bit depth that matches the > > source. > > + if (src_min_depth != dst_min_depth || src_max_depth != > > dst_max_depth) > > + score -= 64; > > This adds a penalty for decreasing the depth, that is under > FF_LOSS_DEPTH > > more so if we decreas depth from 16 to 15 bit, that gives a penalty > of 2 but increasing from 15 to 16 a penalty of 64. This needs an > adjustment also are we intentionally treating a increase from 14 to > 15 like 14 to 16 ? or do we want to prefer the closer ? > > a FF_LOSS_EQUAL_DEPTH / DIFFERENT_DEPTH could be added to keep this > more in line with existing code Good point. I was thinking about this in binary terms, but you are right that the penalty should scale with the divergence, in the same way that it does for other mismatches. > > > + > > src_color = get_color_type(src_desc); > > dst_color = get_color_type(dst_desc); > > if (dst_pix_fmt == AV_PIX_FMT_PAL8) > > @@ -3020,14 +3025,21 @@ static int get_pix_fmt_score(enum > > AVPixelFormat dst_pix_fmt, } > > > > if (consider & FF_LOSS_RESOLUTION) { > > + // Apply a large penalty if there's a loss of resolution, > > but also apply > > + // a small penalty of the dst resolution is higher so that > > we favour > > + // exactly matching formats. > > if (dst_desc->log2_chroma_w > src_desc->log2_chroma_w) { > > loss |= FF_LOSS_RESOLUTION; > > score -= 256 << dst_desc->log2_chroma_w; > > - } > > + } else if (dst_desc->log2_chroma_w < > > src_desc->log2_chroma_w) > > + score -= 32; > > + > > if (dst_desc->log2_chroma_h > src_desc->log2_chroma_h) { > > loss |= FF_LOSS_RESOLUTION; > > score -= 256 << dst_desc->log2_chroma_h; > > - } > > + } else if (dst_desc->log2_chroma_h < > > src_desc->log2_chroma_h) > > + score -= 32; > > this would favor 410 -> 411 over 410 -> 420, i dont think that choice > is correct in that specific case True. I'll need to make it scale here as well. > i do agree though with the basic idea behind this patch Thanks for taking a look! --phil _______________________________________________ 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".