[FFmpeg-devel] [PATCH v3] lavu: add an AV_FRAME_DATA_GAMMA side data type

[Hendrik Leppkes]

On Wed, Nov 8, 2017 at 10:30 PM, Nicolas George <george at nsup.org> wrote:
>
> The question we should be asking is: does it make sense, in general, for
> any frame (or any video frame, or...)? For this field, I would argue
> that the answer is yes: the gamma value is needed to make a few
> operations on frames really correct. You can for example observe that
> libswscale can do gamma-correct scaling, but it hardcodes 2.2.
>

Gamma might sound useful of a property to have, but there is no actual
technical evidence to really support that. As said in an earlier mail,
we've gone for years without it and no-one missed it, and even now its
only being added for one decoder, and even there its apparently only
used for obscure files ("joke images", as the author called it).
In fact, for videos, the gamme is usually defined through the transfer
function, which has the color_trc field already.

> Furthermore, I am quite doubtful about another side of the argument: you
> complain about "hundreds of fields" that make the AVFrame structure a
> "nightmare", but please explain to me how it is worse a nightmare than
> having "hundreds of" side data types defined in the big enum just a few
> lines above AVFrame. The only difference I can see is the size of the
> structure. I grant you that for really hundreds of fields it would
> indeed be a concern. But not for sixteen. Apart from that, the problem
> is about the number of features that a developers needs to know, and a
> side data type counts for that exactly as much as a field in AVFrame.

I actually think that the separation into "core" data and "side" data
helps clarity. The AVFrame contains fields that most people should
probably look at, so they can read the struct and figure out what
fields may need handling. If that list includes all sorts of
properties with marginal value and rare/special usage, its easy to get
"lost" in there.

- Hendrik