[FFmpeg-devel] [PATCH] Add HDR dynamic metadata struct (for SPMTE 2094-40) to libavutil.
moh.izadi at gmail.com
Tue Dec 18 06:58:12 EET 2018
As Jan mentioned, we need to specify the kind of the HDR metadata. Here are
AVSMPTE2094App4 (Application 4 is HDR10+ while Dolby is application 1)
Which one do you prefer?
On Mon, Dec 17, 2018 at 3:07 PM Jan Ekström <jeebjp at gmail.com> wrote:
> On Tue, Dec 18, 2018 at 12:58 AM Vittorio Giovara
> <vittorio.giovara at gmail.com> wrote:
> > On Mon, Dec 17, 2018 at 5:53 PM Jan Ekström <jeebjp at gmail.com> wrote:
> > > On Tue, Dec 18, 2018 at 12:41 AM Vittorio Giovara
> > > <vittorio.giovara at 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
> > > > 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
> > > 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.
> > 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
> 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)
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel