On Wed, Jul 18, 2018 at 10:01 AM, Vittorio Giovara <vittorio.giov...@gmail.com> wrote: >> this does not follow from what you write below. But more so this is not >> how pixel formats were implemented in FFmpeg. >> Where does this idea come from ? > > I found the following description of this pixel format pretty accurate: > https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/pixfmt-yuv410.html > > I am not sure how non-mod4 sizes work, but probably codecs within ffmpeg > take into account more alignment than necessary and make things work
To expand on this (and other replies): The behavior in FFmpeg is very unexpected for an API user who may wish to actually use the returned yuv410p data with an application or other library that is *not* from FFmpeg, such as a renderer, or external encoder lib, resizer, etc. Everything else on the planet assumes that if you have a buffer of a specific chroma subsampling type, you actually have enough data for it to be valid, with width/height that make it so. It's very surprising when you get back a set of buffers/width/height that don't make sense for a given pixel format, and is little to no documentation about why/how. I don't think "logic guarantees the buffer is mod4/aligned" is a reasonable thing to tell an API user in lieu of documentation for unexpected behavior. Cheers, - Derek _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel