On 9/20/2017 12:58 PM, Vittorio Giovara wrote:
>> * In my opinion we should not add new fields to structures that map 1:1 to
> *>* something defined elsewhere (with the exception of booleans).
> *>* I think this should be a separate side data and type, ie AVGammaResponse,
> *>* that can of course reside in the same header.
> *>* --
> *>* Vittorio
> *>* _______________________________________________
> *>* ffmpeg-devel mailing list
> *>* ffmpeg-devel at ffmpeg.org 
> <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
> *>* http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
> *>
> Why? I don't see anything special about the struct. And this value fits in
> exactly to what the struct is all about.
> 
> 
> "mastering display" is a specification defined in several standards,
> including h264 and h265. It groups two kind of properties, the mastering
> display primaries (with its whitepoint) and the screen min and max
> luminance. AVMasteringDisplayMetadata is modelled after this specification
> and designed to expose the same kind of information; setters and getter
> will expect to use all the information contained in it.
> 
> Adding a field that is missing from the original specification to that
> structure is, in my opinion, semantically wrong, not only because
> AVMasteringDisplayMetadata won't be strictly mapped to a the "mastering
> display" any more, but also because the setters and getters of the
> "mastering display" users will not need the new field at all.
> 
> There is a precedent to this: AVColorVolume. Its field are, in practice,

Did you mean AVContentLightMetadata? I can't find any reference to
AVColorVolume in the tree.

> tied to mastering display, but they are stored in a separate structure, and
> not squashed in the main AVMasteringDisplayMetadata structure. I think we
> should continue this trend so that we can easily map structures with known
> specifications and not overload them with unnecessary fields.
> 

PS: Please fix your mail client. You're creating new threads with each
reply as they don't have an in-reply-to header field.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to