As Jan mentioned, we need to specify the kind of the HDR metadata. Here are some alternatives:
AVDynamicHDRPlus AVSMPTE2094App4 (Application 4 is HDR10+ while Dolby is application 1) AVHDRPlusMetadata Which one do you prefer? -- Best, Mohammad On Mon, Dec 17, 2018 at 3:07 PM Jan Ekström <jee...@gmail.com> wrote: > On Tue, Dec 18, 2018 at 12:58 AM Vittorio Giovara > <vittorio.giov...@gmail.com> wrote: > > > > On Mon, Dec 17, 2018 at 5:53 PM Jan Ekström <jee...@gmail.com> wrote: > > > > > On Tue, Dec 18, 2018 at 12:41 AM Vittorio Giovara > > > <vittorio.giov...@gmail.com> wrote: > > > > > > > > I like > > > VeryLongJavaLikeNamingForFunctionsAndDataTypesAsWellAsEnumsOfCourse > > > > as much as the next guy, but this is overly too long and the related > > > > structure name (AVDynamicMetadataSMPTE2094_40) is inconsistent with > the > > > > public type naming present in this project. > > > > > > > > If I may suggest, please use the following names: > > > > - AV_FRAME_DATA_DYNAMIC_HDR for frame data type: it is obviously > > > metadata, > > > > and the fact that is based on SMPTE2094-40 should not be hardcoded > in the > > > > name > > > > - dynamic_hdr.h as header name: again the fact that it's metadata > does > > > not > > > > be carried everywhere > > > > - AVDynamicHDR as structure name: short and to the point, and without > > > spec > > > > numbers or underscores > > > > > > > > > > I don't think SMPTE ST.2094-XX utilized the same fields? > > > > > > I think SMPTE ST.2094-40 is Samsung's dynamic metadata which is effect > > > usually called "HDR10+" ? Not just calling it AVDynamicHDR could come > > > up useful if we plan on adding support for SMPTE ST.2094-10 which is > > > one part of what's called "Dolby Vision" (even though it is just > > > dynamic metadata - because of course you have to stick everything > > > under a single marketing name). > > > > > > > It's still technically dynamic metadata but I get your point. > > It could maybe be stored in dynamic_hdr.h header, and call it > > AVDynamicHDRPlus to differenciate it from the future AVDolbyVisionHDR. > What > > do you think? > > > > The other alternative would have been to make sure that the structure > can take the values that are "essential" from those separate > specifications. > > I do not have a heavy opinion one way or another (separate structure > per spec or single with all the required data), but just had to > mention it because it would have otherwise been a singular "dynamic > HDR metadata" entity while it unfortunately seems that these things > have splintered into multiple competing alternatives... (of which > Samsung's and Dolby's things seem to be those getting most use) > > Jan > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel