[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