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

[Michael Niedermayer]

On Wed, Jul 18, 2018 at 11:03:47AM -0400, Derek Buitenhuis wrote:
> 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 think i see what you mean.
But iam not sure i understand how the proposed changes would be the ideal
solution.

For example:
lets assume we have a 3x3 image of 420 or 410 (be that from a jpeg or whatever)

If we want to use this with software that that does support odd resolutions
then it should just work. Theres no 4th column or row in the logic image that
could be used.

OTOH if we want to use this with softwate that does not support odd resolutions
then its not going to work with a 3x3 (as odd) or 2x2 (looses a column and row)
or a 4x4 (which has a column and a row that is uninitialized or black)

what i mean is that the API by which one exports the width and height doesnt
really affect this. To get from a 3x3 to something that actually works with
external code which only supports even resolutions, something somewhere has
to make it even and either scale, crop or fill in.

More specifically, saying that this 3x3 is a 4x4 image with crop is not really
true as theres not neccesarily any data in the last column and row. And a
filter or encoder using that anyway could produce bad output


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

just posted a small patch to document this

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin
-------------- 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/1645e75e/attachment.sig>