[FFmpeg-devel] [PATCH 2/2] ffv1dec: Ensure that pixel format constraints are respected

[Hendrik Leppkes]

On Wed, Jul 18, 2018 at 12:13 AM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>
> 2018-07-17 23:58 GMT+02:00, Hendrik Leppkes <h.leppkes at gmail.com>:
> > On Tue, Jul 17, 2018 at 11:54 PM Carl Eugen Hoyos <ceffmpeg at gmail.com>
> > wrote:
> >>
> >> 2018-07-17 21:39 GMT+02:00, Vittorio Giovara <vittorio.giovara at gmail.com>:
> >> > YUV410P requires that sizes are divisible by 4.
> >>
> >> Do you mean that AV_PIX_FMT_YUV410P requires it?
> >> Where is this documented?
> >
> > Its a consequence of the subsampling factor. 4:1:0 is one-fourth the
> > horizontal resolution and half the vertical resolution, as such the
> > width has to be a multiple of 4 for that to result in a valid chroma
> > dimension.
>
> (Apart from the fact that it appears to work here and is needed to
> archive some multimedia files.)
> Why wouldn't the chroma dimension be rounded up?
>

Where is it ever specified that this would be the case?
If I'm an API user, and I get an odd image size with such a
subsampling factor, what guarantees do I have that the chroma plane is
big enough to be rounded up, and I don't overread the buffer, or
process garbage information?

Its the same with 4:2:0 images, non-mod2 images using 4:2:0 are just
flat out invalid, or non-mod4 if they are interlaced even.

Thats why cropping info exists. You can store odd-sized images like
that if you really want to by padding it, but you need to crop it
after converting it to RGB or another format without such limitations.
This doesn't change how the format is stored, just when cropping is applied.

- Hendrik