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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
