Re: [FFmpeg-devel] [PATCH 3/3] [RFC] avcodec/ffv1: Better rounding for slice positions

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 2323 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".