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

[Derek Buitenhuis]

On Wed, Jul 18, 2018 at 10:01 AM, Vittorio Giovara
<vittorio.giovara at 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