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 configurations > > like Ticket 5548 > > > > 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. > > 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 > > Wouldn't it easier for spec and maths to keep the previous behavior for luma > 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 part > more explicit while considering the patch as a bug fix rather than a spec > change. >
> 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 things and would become the default in future versions Any future compression between luma and chroma planes may benefit from slices being less odd in their chroma vs luma coordinates. But noone is working on this AFAIK. Its just hypothetical thx [...] -- 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.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
