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

Carl Eugen Hoyos ceffmpeg at gmail.com
Wed Jul 18 01:37:13 EEST 2018


2018-07-18 0:22 GMT+02:00, Hendrik Leppkes <h.leppkes at gmail.com>:
> 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?

Which other options exist?

> 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?

The exact same guarantees as for any other buffer FFmpeg
provides?

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

And such files do not exist or what exactly do you claim?

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

But that only works if that's how the encoder did it, no?

> This doesn't change how the format is stored, just when cropping is applied.

Then I wonder what exactly this patch fixes (if nothing is changed).

Carl Eugen


More information about the ffmpeg-devel mailing list