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

[Nicolas George]

L'octidi 18 brumaire, an CCXXVI, Hendrik Leppkes a écrit :
> I don't. We've done a lot of work to remove fields from generic data
> structures which are used by single codecs on semi-obscure cases. The
> fact alone that after years of avcodec and a PNG decoder this field
> wasn't asked for regularly alone speaks to me that its not generic
> enough to warrant inclusion in AVFrame.
> 
> Certainly it would make for nicer code if you could access every field
> directly, but if we do that for every piece of data provided by all
> random single decoders, we have a nightmare of a frame structure, with
> hundreds of fields that only ever are applicable in a minority of
> cases.

This is a "slippery slope" kind of argument, and they are rarely valid.
Right now, we have only 16 frame side data types, and the conditions to
accept them were less stringent that they would be for fields in the
frame. Your "hundreds of fields" is quite an exaggeration.

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.

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.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171108/874f0f01/attachment.sig>