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

[Michael Niedermayer]

On Wed, Jul 18, 2018 at 12:22:21AM +0200, Hendrik Leppkes wrote:
> 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?

This is a good question.
I would argue that logic gurantees this, because without the chroma plane
being large enough you would have vissible areas with luma samples but
no chroma samples.
But besides logic, i think all of our code works this way, FFmpeg itself
would overead if this wasnt true


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

But this is not really true. There are many files that have mod2 != 0
with 420. For example this is common in jpegs.
gimp for example will happily create such files you just crop or scale
and you have a 50% chance to get that on export


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180718/b4e66fb4/attachment.sig>