| Message ID | 20181210191659.11884-1-moh.izadi@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
On Mon, Dec 10, 2018 at 2:50 PM Mohammad Izadi <moh.izadi@gmail.com> wrote: > From: Mohammad Izadi <izadi@google.com> > > The dynamic metadata contains data for color volume transform - > application 4 of SPMTE 2094-40:2016 standard. The data comes from HEVC in > the SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35. > > I'll add support to HEVC in a follow-up. > --- > libavutil/Makefile | 2 + > libavutil/frame.c | 1 + > libavutil/frame.h | 7 + > libavutil/hdr_dynamic_metadata.c | 40 ++++ > libavutil/hdr_dynamic_metadata.h | 344 +++++++++++++++++++++++++++++++ > libavutil/version.h | 2 +- > 6 files changed, 395 insertions(+), 1 deletion(-) > create mode 100644 libavutil/hdr_dynamic_metadata.c > create mode 100644 libavutil/hdr_dynamic_metadata.h > > diff --git a/libavutil/Makefile b/libavutil/Makefile > index caddc7e155..7dcb92b06b 100644 > --- a/libavutil/Makefile > +++ b/libavutil/Makefile > @@ -31,6 +31,7 @@ HEADERS = adler32.h > \ > file.h \ > frame.h \ > hash.h \ > + hdr_dynamic_metadata.h \ > There > hmac.h \ > hwcontext.h \ > hwcontext_cuda.h \ > @@ -119,6 +120,7 @@ OBJS = adler32.o > \ > fixed_dsp.o \ > frame.o \ > hash.o \ > + hdr_dynamic_metadata.o \ > hmac.o \ > hwcontext.o \ > imgutils.o \ > diff --git a/libavutil/frame.c b/libavutil/frame.c > index 9b3fb13e68..c5f30b6847 100644 > --- a/libavutil/frame.c > +++ b/libavutil/frame.c > @@ -840,6 +840,7 @@ const char *av_frame_side_data_name(enum > AVFrameSideDataType type) > case AV_FRAME_DATA_QP_TABLE_PROPERTIES: return "QP table > properties"; > case AV_FRAME_DATA_QP_TABLE_DATA: return "QP table > data"; > #endif > + case AV_FRAME_DATA_HDR_DYNAMIC_METADATA_SMPTE2094_40: return "HDR > Dynamic Metadata SMPTE2094-40"; > 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 > } > return NULL; > } > diff --git a/libavutil/hdr_dynamic_metadata.c > b/libavutil/hdr_dynamic_metadata.c > new file mode 100644 > index 0000000000..59dfcc84e4 > --- /dev/null > +++ b/libavutil/hdr_dynamic_metadata.c > @@ -0,0 +1,40 @@ > + > +#include "hdr_dynamic_metadata.h" > +#include "mem.h" > + > +AVDynamicMetadataSMPTE2094_40 > *av_dynamic_metadata_smpte2094_40_alloc(void) > you need to return the size of allocation back to the caller, see spherical.h as example (especially since you document that "its size is not a part of the public ABI.") +/** > + * Option for overlapping elliptical pixel selectors in an image. > + */ > +enum AVOverlapProcessOption { > + AV_OVERLAP_PROCESS_WEIGHTED_AVERAGING = 0, > + AV_OVERLAP_PROCESS_LAYERING = 1, > +}; > I'm not a fan of these names, but i've bikeshed enough > + > +/** > + * Percentile represents the percentile at a specific percentage in > + * a distribution. > + */ > +typedef struct AVPercentile { > + /** > + * The percentage value corresponding to a spesific percentile > linearized > typo 'spesific' + * RGB value in the processing window in the scene. The value shall be > in > + * the range of 0 to100, inclusive. > + */ > + uint8_t percentage; > + /** > + * The linearized maxRGB value at a specific percentile in the > processing > + * window in the scene. The value shall be in the range of 0 to 1, > inclusive > + * and in multiples of 0.00001. > + */ > + AVRational percentile; > +} AVPercentile; > + >
On Tue, Dec 18, 2018 at 12:41 AM Vittorio Giovara <vittorio.giovara@gmail.com> wrote: > > On Mon, Dec 10, 2018 at 2:50 PM Mohammad Izadi <moh.izadi@gmail.com> wrote: > > > From: Mohammad Izadi <izadi@google.com> > > > > The dynamic metadata contains data for color volume transform - > > application 4 of SPMTE 2094-40:2016 standard. The data comes from HEVC in > > the SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35. > > > > I'll add support to HEVC in a follow-up. > > > --- > > libavutil/Makefile | 2 + > > libavutil/frame.c | 1 + > > libavutil/frame.h | 7 + > > libavutil/hdr_dynamic_metadata.c | 40 ++++ > > libavutil/hdr_dynamic_metadata.h | 344 +++++++++++++++++++++++++++++++ > > libavutil/version.h | 2 +- > > 6 files changed, 395 insertions(+), 1 deletion(-) > > create mode 100644 libavutil/hdr_dynamic_metadata.c > > create mode 100644 libavutil/hdr_dynamic_metadata.h > > > > diff --git a/libavutil/Makefile b/libavutil/Makefile > > index caddc7e155..7dcb92b06b 100644 > > --- a/libavutil/Makefile > > +++ b/libavutil/Makefile > > @@ -31,6 +31,7 @@ HEADERS = adler32.h > > \ > > file.h \ > > frame.h \ > > hash.h \ > > + hdr_dynamic_metadata.h \ > > > > There > > > hmac.h \ > > hwcontext.h \ > > hwcontext_cuda.h \ > > @@ -119,6 +120,7 @@ OBJS = adler32.o > > \ > > fixed_dsp.o \ > > frame.o \ > > hash.o \ > > + hdr_dynamic_metadata.o \ > > hmac.o \ > > hwcontext.o \ > > imgutils.o \ > > diff --git a/libavutil/frame.c b/libavutil/frame.c > > index 9b3fb13e68..c5f30b6847 100644 > > --- a/libavutil/frame.c > > +++ b/libavutil/frame.c > > @@ -840,6 +840,7 @@ const char *av_frame_side_data_name(enum > > AVFrameSideDataType type) > > case AV_FRAME_DATA_QP_TABLE_PROPERTIES: return "QP table > > properties"; > > case AV_FRAME_DATA_QP_TABLE_DATA: return "QP table > > data"; > > #endif > > + case AV_FRAME_DATA_HDR_DYNAMIC_METADATA_SMPTE2094_40: return "HDR > > Dynamic Metadata SMPTE2094-40"; > > > > 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). Just my 20 cents. Jan
On Mon, Dec 17, 2018 at 5:53 PM Jan Ekström <jeebjp@gmail.com> wrote: > On Tue, Dec 18, 2018 at 12:41 AM Vittorio Giovara > <vittorio.giovara@gmail.com> wrote: > > > > On Mon, Dec 10, 2018 at 2:50 PM Mohammad Izadi <moh.izadi@gmail.com> > wrote: > > > > > From: Mohammad Izadi <izadi@google.com> > > > > > > The dynamic metadata contains data for color volume transform - > > > application 4 of SPMTE 2094-40:2016 standard. The data comes from HEVC > in > > > the SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35. > > > > > > I'll add support to HEVC in a follow-up. > > > > > > diff --git a/libavutil/frame.c b/libavutil/frame.c > > > index 9b3fb13e68..c5f30b6847 100644 > > > --- a/libavutil/frame.c > > > +++ b/libavutil/frame.c > > > @@ -840,6 +840,7 @@ const char *av_frame_side_data_name(enum > > > AVFrameSideDataType type) > > > case AV_FRAME_DATA_QP_TABLE_PROPERTIES: return "QP table > > > properties"; > > > case AV_FRAME_DATA_QP_TABLE_DATA: return "QP table > > > data"; > > > #endif > > > + case AV_FRAME_DATA_HDR_DYNAMIC_METADATA_SMPTE2094_40: return "HDR > > > Dynamic Metadata SMPTE2094-40"; > > > > > > > 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? > Just my 20 cents. > > Jan > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
On Tue, Dec 18, 2018 at 12:58 AM Vittorio Giovara <vittorio.giovara@gmail.com> wrote: > > On Mon, Dec 17, 2018 at 5:53 PM Jan Ekström <jeebjp@gmail.com> wrote: > > > On Tue, Dec 18, 2018 at 12:41 AM Vittorio Giovara > > <vittorio.giovara@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
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 <jeebjp@gmail.com> wrote: > On Tue, Dec 18, 2018 at 12:58 AM Vittorio Giovara > <vittorio.giovara@gmail.com> wrote: > > > > On Mon, Dec 17, 2018 at 5:53 PM Jan Ekström <jeebjp@gmail.com> wrote: > > > > > On Tue, Dec 18, 2018 at 12:41 AM Vittorio Giovara > > > <vittorio.giovara@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 >
On Tue, Dec 18, 2018 at 12:04 AM Mohammad Izadi <moh.izadi@gmail.com> wrote: > 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? IMO AVDynamicHDRPlus or AVHDRPlusMetadata. Thanks, Vittorio > -- > Best, > Mohammad > > > On Mon, Dec 17, 2018 at 3:07 PM Jan Ekström <jeebjp@gmail.com> wrote: >
diff --git a/libavutil/Makefile b/libavutil/Makefile index caddc7e155..7dcb92b06b 100644 --- a/libavutil/Makefile +++ b/libavutil/Makefile @@ -31,6 +31,7 @@ HEADERS = adler32.h \ file.h \ frame.h \ hash.h \ + hdr_dynamic_metadata.h \ hmac.h \ hwcontext.h \ hwcontext_cuda.h \ @@ -119,6 +120,7 @@ OBJS = adler32.o \ fixed_dsp.o \ frame.o \ hash.o \ + hdr_dynamic_metadata.o \ hmac.o \ hwcontext.o \ imgutils.o \ diff --git a/libavutil/frame.c b/libavutil/frame.c index 9b3fb13e68..c5f30b6847 100644 --- a/libavutil/frame.c +++ b/libavutil/frame.c @@ -840,6 +840,7 @@ const char *av_frame_side_data_name(enum AVFrameSideDataType type) case AV_FRAME_DATA_QP_TABLE_PROPERTIES: return "QP table properties"; case AV_FRAME_DATA_QP_TABLE_DATA: return "QP table data"; #endif + case AV_FRAME_DATA_HDR_DYNAMIC_METADATA_SMPTE2094_40: return "HDR Dynamic Metadata SMPTE2094-40"; } return NULL; } diff --git a/libavutil/frame.h b/libavutil/frame.h index 66f27f44bd..1b65a34ab3 100644 --- a/libavutil/frame.h +++ b/libavutil/frame.h @@ -166,6 +166,13 @@ enum AVFrameSideDataType { * function in libavutil/timecode.c. */ AV_FRAME_DATA_S12M_TIMECODE, + + /** + * HDR dynamic metadata associated with a video frame. The payload is + * an AVDynamicMetadataSMPTE2094_40 type and contains information for color + * volume transform - application 4 of SPMTE 2094-40:2016 standard. + */ + AV_FRAME_DATA_HDR_DYNAMIC_METADATA_SMPTE2094_40, }; enum AVActiveFormatDescription { diff --git a/libavutil/hdr_dynamic_metadata.c b/libavutil/hdr_dynamic_metadata.c new file mode 100644 index 0000000000..59dfcc84e4 --- /dev/null +++ b/libavutil/hdr_dynamic_metadata.c @@ -0,0 +1,40 @@ +/** + * Copyright (c) 2018 Mohammad Izadi <moh.izadi@gmail.com> + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "hdr_dynamic_metadata.h" +#include "mem.h" + +AVDynamicMetadataSMPTE2094_40 *av_dynamic_metadata_smpte2094_40_alloc(void) +{ + return av_mallocz(sizeof(AVDynamicMetadataSMPTE2094_40)); +} + +AVDynamicMetadataSMPTE2094_40 *av_dynamic_metadata_smpte2094_40_create_side_data(AVFrame *frame) +{ + AVFrameSideData *side_data = av_frame_new_side_data(frame, + AV_FRAME_DATA_HDR_DYNAMIC_METADATA_SMPTE2094_40, + sizeof(AVDynamicMetadataSMPTE2094_40)); + if (!side_data) + return NULL; + + memset(side_data->data, 0, sizeof(AVDynamicMetadataSMPTE2094_40)); + + return (AVDynamicMetadataSMPTE2094_40 *)side_data->data; +} diff --git a/libavutil/hdr_dynamic_metadata.h b/libavutil/hdr_dynamic_metadata.h new file mode 100644 index 0000000000..35c38454c3 --- /dev/null +++ b/libavutil/hdr_dynamic_metadata.h @@ -0,0 +1,344 @@ +/* + * Copyright (c) 2018 Mohammad Izadi <moh.izadi@gmail.com> + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef AVUTIL_HDR_DYNAMIC_METADATA_H +#define AVUTIL_HDR_DYNAMIC_METADATA_H + +#include "frame.h" +#include "rational.h" + +/** + * Option for overlapping elliptical pixel selectors in an image. + */ +enum AVOverlapProcessOption { + AV_OVERLAP_PROCESS_WEIGHTED_AVERAGING = 0, + AV_OVERLAP_PROCESS_LAYERING = 1, +}; + +/** + * Percentile represents the percentile at a specific percentage in + * a distribution. + */ +typedef struct AVPercentile { + /** + * The percentage value corresponding to a spesific percentile linearized + * RGB value in the processing window in the scene. The value shall be in + * the range of 0 to100, inclusive. + */ + uint8_t percentage; + /** + * The linearized maxRGB value at a specific percentile in the processing + * window in the scene. The value shall be in the range of 0 to 1, inclusive + * and in multiples of 0.00001. + */ + AVRational percentile; +} AVPercentile; + +/** + * Color transform parameters at a processing window in a dynamic metadata for + * SPMTE 2094-40. + */ +typedef struct AVSMPTE2094_40ColorTransformParams { + /** + * The relative x coordinate of the top left pixel of the processing + * window. The value shall be in the range of 0 and 1, inclusive and + * in multiples of 1/(width of Picture – 1). The value 1 corresponds + * to the absolute coordinate of width of Picture – 1. The value for + * first processing window shall be 0. + */ + AVRational window_upper_left_corner_x; + + /** + * The relative y coordinate of the top left pixel of the processing + * window. The value shall be in the range of 0 and 1, inclusive and + * in multiples of 1/(height of Picture – 1). The value 1 corresponds + * to the absolute coordinate of height of Picture – 1. The value for + * first processing window shall be 0. + */ + AVRational window_upper_left_corner_y; + + /** + * The relative x coordinate of the bottom right pixel of the processing + * window. The value shall be in the range of 0 and 1, inclusive and + * in multiples of 1/(width of Picture – 1). The value 1 corresponds + * to the absolute coordinate of width of Picture – 1. The value for + * first processing window shall be 1. + */ + AVRational window_lower_right_corner_x; + + /** + * The relative y coordinate of the bottom right pixel of the processing + * window. The value shall be in the range of 0 and 1, inclusive and + * in multiples of 1/(height of Picture – 1). The value 1 corresponds + * to the absolute coordinate of height of Picture – 1. The value for + * first processing window shall be 1. + */ + AVRational window_lower_right_corner_y; + + /** + * The x coordinate of the center position of the concentric internal and + * external ellipses of the elliptical pixel selector in the processing + * window. The value shall be in the range of 0 to (width of Picture – 1), + * inclusive and in multiples of 1 pixel. + */ + uint16_t center_of_ellipse_x; + + /** + * The y coordinate of the center position of the concentric internal and + * external ellipses of the elliptical pixel selector in the processing + * window. The value shall be in the range of 0 to (height of Picture – 1), + * inclusive and in multiples of 1 pixel. + */ + uint16_t center_of_ellipse_y; + + /** + * The clockwise rotation angle in degree of arc with respect to the + * positive direction of the x-axis of the concentric internal and external + * ellipses of the elliptical pixel selector in the processing window. The + * value shall be in the range of 0 to 180, inclusive and in multiples of 1. + */ + uint8_t rotation_angle; + + /** + * The semi-major axis value of the internal ellipse of the elliptical pixel + * selector in amount of pixels in the processing window. The value shall be + * in the range of 1 to 65535, inclusive and in multiples of 1 pixel. + */ + uint16_t semimajor_axis_internal_ellipse; + + /** + * The semi-major axis value of the external ellipse of the elliptical pixel + * selector in amount of pixels in the processing window. The value + * shall not be less than semimajor_axis_internal_ellipse of the current + * processing window. The value shall be in the range of 1 to 65535, + * inclusive and in multiples of 1 pixel. + */ + uint16_t semimajor_axis_external_ellipse; + + /** + * The semi-minor axis value of the external ellipse of the elliptical pixel + * selector in amount of pixels in the processing window. The value shall be + * in the range of 1 to 65535, inclusive and in multiples of 1 pixel. + */ + uint16_t semiminor_axis_external_ellipse; + + /** + * Overlap process option indicates one of the two methods of combining + * rendered pixels in the processing window in an image with at least one + * elliptical pixel selector. For overlapping elliptical pixel selectors + * in an image, overlap_process_option shall have the same value. + */ + enum AVOverlapProcessOption overlap_process_option; + + /** + * The maximum of the color components of linearized RGB values in the + * processing window in the scene. The values should be in the range of 0 to + * 1, inclusive and in multiples of 0.00001. maxscl[ 0 ], maxscl[ 1 ], and + * maxscl[ 2 ] are corresponding to R, G, B color components respectively. + */ + AVRational maxscl[3]; + + /** + * The average of linearized maxRGB values in the processing window in the + * scene. The value should be in the range of 0 to 1, inclusive and in + * multiples of 0.00001. + */ + AVRational average_maxrgb; + + /** + * The number of linearized maxRGB values at given percentiles in the + * processing window in the scene. The maximum value shall be 15. + */ + uint8_t num_distribution_maxrgb_percentiles; + + /** + * The linearized maxRGB values at given percentiles in the + * processing window in the scene. + */ + AVPercentile distribution_maxrgb[15]; + + /** + * The fraction of selected pixels in the image that contains the brightest + * pixel in the scene. The value shall be in the range of 0 to 1, inclusive + * and in multiples of 0.001. + */ + AVRational fraction_bright_pixels; + + /** + * This flag indicates that the metadata for the tone mapping function in + * the processing window is present (for value of 1). + */ + uint8_t tone_mapping_flag; + + /** + * The x coordinate of the separation point between the linear part and the + * curved part of the tone mapping function. The value shall be in the range + * of 0 to 1, excluding 0 and in multiples of 1/4095. + */ + AVRational knee_point_x; + + /** + * The y coordinate of the separation point between the linear part and the + * curved part of the tone mapping function. The value shall be in the range + * of 0 to 1, excluding 0 and in multiples of 1/4095. + */ + AVRational knee_point_y; + + /** + * The number of the intermediate anchor parameters of the tone mapping + * function in the processing window. The maximum value shall be 15. + */ + uint8_t num_bezier_curve_anchors; + + /** + * The intermediate anchor parameters of the tone mapping function in the + * processing window in the scene. The values should be in the range of 0 + * to 1, inclusive and in multiples of 1/1023. + */ + AVRational bezier_curve_anchors[15]; + + /** + * This flag shall be equal to 0 in bitstreams conforming to this version of + * this Specification. Other values are reserved for future use. + */ + uint8_t color_saturation_mapping_flag; + + /** + * The color saturation gain in the processing window in the scene. The + * value shall be in the range of 0 to 63/8, inclusive and in multiples of + * 1/8. The default value shall be 1. + */ + AVRational color_saturation_weight; +} AVSMPTE2094_40ColorTransformParams; + +/** + * This struct represents dynamic metadata for color volume transform - + * application 4 of SPMTE 2094-40:2016 standard. + * + * To be used as payload of a AVFrameSideData or AVPacketSideData with the + * appropriate type. + * + * @note The struct should be allocated with + * av_dynamic_metadata_smpte2094_40_alloc() and its size is not a part of + * the public ABI. + */ +typedef struct AVDynamicMetadataSMPTE2094_40 { + /** + * Country code by Rec. ITU-T T.35 Annex A. The value shall be 0xB5. + */ + uint8_t itu_t_t35_country_code; + + /** + * Application version in the application defining document in ST-2094 + * suite. The value shall be set to 0. + */ + uint8_t application_version; + + /** + * The number of processing windows. The value shall be in the range + * of 1 to 3, inclusive. + */ + uint8_t num_windows; + + /** + * The color transform parameters for every processing window. + */ + AVSMPTE2094_40ColorTransformParams params[3]; + + /** + * The nominal maximum display luminance of the targeted system display, + * in units of 0.0001 candelas per square metre. The value shall be in + * the range of 0 to 10000, inclusive. + */ + AVRational targeted_system_display_maximum_luminance; + + /** + * This flag shall be equal to 0 in bit streams conforming to this version + * of this Specification. The value 1 is reserved for future use. + */ + uint8_t targeted_system_display_actual_peak_luminance_flag; + + /** + * The number of rows in the targeted system_display_actual_peak_luminance + * array. The value shall be in the range of 2 to 25, inclusive. + */ + uint8_t num_rows_targeted_system_display_actual_peak_luminance; + + /** + * The number of columns in the + * targeted_system_display_actual_peak_luminance array. The value shall be + * in the range of 2 to 25, inclusive. + */ + uint8_t num_cols_targeted_system_display_actual_peak_luminance; + + /** + * The normalized actual peak luminance of the targeted system display. The + * values should be in the range of 0 to 1, inclusive and in multiples of + * 1/15. + */ + AVRational targeted_system_display_actual_peak_luminance[25][25]; + + /** + * This flag shall be equal to 0 in bitstreams conforming to this version of + * this Specification. The value 1 is reserved for future use. + */ + uint8_t mastering_display_actual_peak_luminance_flag; + + /** + * The number of rows in the mastering_display_actual_peak_luminance array. + * The value shall be in the range of 2 to 25, inclusive. + */ + uint8_t num_rows_mastering_display_actual_peak_luminance; + + /** + * The number of columns in the mastering_display_actual_peak_luminance + * array. The value shall be in the range of 2 to 25, inclusive. + */ + uint8_t num_cols_mastering_display_actual_peak_luminance; + + /** + * The normalized actual peak luminance of the mastering display used for + * mastering the image essence. The values should be in the range of 0 to 1, + * inclusive and in multiples of 1/15. + */ + AVRational mastering_display_actual_peak_luminance[25][25]; + +} AVDynamicMetadataSMPTE2094_40; + +/** + * Allocate an AVDynamicMetadataSMPTE2094_40 structure and set its fields to + * default values. The resulting struct can be freed using av_freep(). + * + * @return An AVDynamicMetadataSMPTE2094_40 filled with default values or NULL + * on failure. + */ +AVDynamicMetadataSMPTE2094_40 *av_dynamic_metadata_smpte2094_40_alloc(void); + +/** + * Allocate a complete AVDynamicMetadataSMPTE2094_40 and add it to the frame. + * + * @param frame The frame which side data is added to. + * + * @return The AVDynamicMetadataSMPTE2094_40 structure to be filled by caller. + */ +AVDynamicMetadataSMPTE2094_40 * +av_dynamic_metadata_smpte2094_40_create_side_data(AVFrame *frame); + +#endif /* AVUTIL_HDR_DYNAMIC_METADATA_H */ diff --git a/libavutil/version.h b/libavutil/version.h index 62112a6049..6aea82c609 100644 --- a/libavutil/version.h +++ b/libavutil/version.h @@ -79,7 +79,7 @@ */ #define LIBAVUTIL_VERSION_MAJOR 56 -#define LIBAVUTIL_VERSION_MINOR 24 +#define LIBAVUTIL_VERSION_MINOR 25 #define LIBAVUTIL_VERSION_MICRO 101 #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
From: Mohammad Izadi <izadi@google.com> The dynamic metadata contains data for color volume transform - application 4 of SPMTE 2094-40:2016 standard. The data comes from HEVC in the SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35. I'll add support to HEVC in a follow-up. --- libavutil/Makefile | 2 + libavutil/frame.c | 1 + libavutil/frame.h | 7 + libavutil/hdr_dynamic_metadata.c | 40 ++++ libavutil/hdr_dynamic_metadata.h | 344 +++++++++++++++++++++++++++++++ libavutil/version.h | 2 +- 6 files changed, 395 insertions(+), 1 deletion(-) create mode 100644 libavutil/hdr_dynamic_metadata.c create mode 100644 libavutil/hdr_dynamic_metadata.h