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 6B3EB44BE2 for ; Sat, 7 Oct 2023 17:11:42 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B92FD68C889; Sat, 7 Oct 2023 20:11:39 +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 78C08680016 for ; Sat, 7 Oct 2023 20:11:33 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 60504240003 for ; Sat, 7 Oct 2023 17:11:31 +0000 (UTC) Date: Sat, 7 Oct 2023 19:11:30 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20231007171130.GR3543730@pb2> References: <20231007001444.31861-1-michael@niedermayer.cc> <20231007001444.31861-3-michael@niedermayer.cc> <63f89695-1a25-41fa-900d-650e4da6f43f@mediaarea.net> MIME-Version: 1.0 In-Reply-To: <63f89695-1a25-41fa-900d-650e4da6f43f@mediaarea.net> X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH 3/3] [RFC] avcodec/ffv1: Better rounding for slice positions 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="===============1754100248556663213==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============1754100248556663213== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4TSNxiJ5t2iBNdYs" Content-Disposition: inline --4TSNxiJ5t2iBNdYs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 07, 2023 at 06:52:07AM +0200, Jerome Martinez wrote: > On 07/10/2023 02:14, Michael Niedermayer wrote: > > This fixes green lines in some odd dimensions with some slice configura= tions > > like Ticket 5548 > >=20 > > This also changes the encoder and whats encoded, and would require an > > update to the specification. This change attempts to limit the change > > to configurations that have missing lines currently. >=20 > It changes a lot the count of pixels per slice, and , e.g. with 4:2:2 and= 4 slices per direction (16 slices in total), 13 pixel width: > before: 3/3/3/4 for luma, 2/2/2/2 for chroma (so 1 chroma too much) > after: 4/4/2/3 for luma, 2/2/1/2 for chroma >=20 > Wouldn't it easier for spec and maths to keep the previous behavior for l= uma and consider extra chroma as to be not encoded? > Something like 3/3/3/4 for luma, 2/2/2/1 for chroma > Actually maybe not really a change for spec in that case, more making a p= art more explicit while considering the patch as a bug fix rather than a sp= ec change. >=20 > Or did I miss another issue? I'll check more a bit later. The existing thing has a few odd behaviors in corner cases 1. sometimes its not encoding the rightmost & bottommost chroma (leaving a = green line) 2. sometimes its encoding chroma columns/rows in more than one slice (which= is a waste of bits) iam not sure if the chrome that gets encoded in each slice is entirely expected, i guess it depends on what one expects The new code tries to keep slices size a multiple of the chroma subsampling factor. That way the left top coordinate of every 4:2:0 slice would always = be even for example and only the last ones could have right / bottom odd when = the whole image has odd width/height But this is a RFC for exactly the reasons that you mention, it changes thin= gs and would become the default in future versions Any future compression between luma and chroma planes may benefit from slic= es being less odd in their chroma vs luma coordinates. But noone is working on this AFAIK. Its just hypothetical thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Some people wanted to paint the bikeshed green, some blue and some pink. People argued and fought, when they finally agreed, only rust was left. --4TSNxiJ5t2iBNdYs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZSGRPgAKCRBhHseHBAsP q8R4AJ9HjHJmFShtNyrsD9g8zNSiQVBTEgCeNttE9+G9pLn6clybpGurzm+AKBM= =MmvB -----END PGP SIGNATURE----- --4TSNxiJ5t2iBNdYs-- --===============1754100248556663213== 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". --===============1754100248556663213==--