On Wed, Jul 18, 2018 at 12:13 AM Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > > 2018-07-17 23:58 GMT+02:00, Hendrik Leppkes <h.lepp...@gmail.com>: > > On Tue, Jul 17, 2018 at 11:54 PM Carl Eugen Hoyos <ceffm...@gmail.com> > > wrote: > >> > >> 2018-07-17 21:39 GMT+02:00, Vittorio Giovara <vittorio.giov...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
