Inserting/replacing HDR metadata without re-encoding

[mariner]

Greetings.
Is there as way to insert/modify/strip HDR metadata such as transfer_characteristics in a file without re-encoding?
Many thanks and best regards,

[Selur]

YouTube-Matroska Colour Metadata Ingestion Utility (https://github.com/youtubehdr/hdr_metadata) might work for HDR-10. (haven't tested)

[mariner]

YouTube-Matroska Colour Metadata Ingestion Utility (https://github.com/youtubehdr/hdr_metadata) might work for HDR-10. (haven't tested)

Thanks for the kind reply, Selur.

1. Is the info written to the raw video stream? Or just the mkv container?
2. What argument to use for writing metadata transfer_characteristic HDR10+ etc?
3. How to remove transfer_characteristics_Origina : BT.2020 (10-bit)?
4. I also tired the "ffmpeg -color_trc" command but was unable to get rid of the transfer_characteristics_Origina : BT.2020 (10-bit). What is the correct syntax?
5. Can't seem to get the ffmpeg command to write metadata to mp4 file. Any help?


ffmpeg -i "IN" -c copy -color_trc arib-std-b67 "OUT"

....
colour_primaries : BT.2020
transfer_characteristics : HLG
transfer_characteristics_Origina : BT.2020 (10-bit)
matrix_coefficients : BT.2020 non-constant
VARIANT_BITRATE : 15872000
.....

Many thanks and best regards,

[Selur]

Is the info written to the raw video stream? Or just the mkv container?
No clue, haven't tried the tool, like I wrote. -> you could have tried yourself

What argument to use for writing metadata transfer_characteristic HDR10+ etc?
In general the syntax is:
--colour-transfer-characteristics TID:n see: https://mkvtoolnix.download/doc/mkvmerge.html (2.8)
There is no 'transfer_characteristic HDR10+', mkvtoolnix and the tool mentioned above should support:
0: reserved, 1: ITU-R BT.709, 2: unspecified, 3: reserved, 4: gamma 2.2 curve, 5: gamma 2.8 curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: linear, 9: log, 10: log sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.1361 extended colour gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, 17: SMPTE ST 428-1; 18: ARIB STD-B67 (HLG)

How to remove transfer_characteristics_Origina : BT.2020 (10-bit)?
The 'original' part is usually added by MediaInfo whenever the container and stream info differ. The stream info is then shown as 'original'.
-> you would need to overwrite the flag in the stream

4. I also tired the "ffmpeg -color_trc" command but was unable to get rid of the transfer_characteristics_Origina : BT.2020 (10-bit). What is the correct syntax?
I don't think normal ffmpeg doesn't support this, and https://forum.doom9.org/showthread.php?t=152419 has a different syntax and only supports H.264 not H.265 content.
-> are you even sure the tool you choose supports what you want?

Can't seem to get the ffmpeg command to write metadata to mp4 file. Any help?
I doubt that ffmpeg can do what you want without reencoding the video.

[sneaker_ger]

From what I can see that tool is basically just a modded, deprecated mkvtoolnix. Since the "vanilla" version now has the same features (+more) it isn't needed anymore. Both the mod as well as vanilla only work on the Matroska headers, not the bitstream itself. Since these values are fixed for a given track there is no equivalent for HDR10+, only HDR10.


Removing the bitstream data should be possible with ffmpeg's bitstream filter (for HEVC): https://ffmpeg.org/ffmpeg-bitstream-filters.html#filter_005funits
But I don't think it's a good idea to just randomly "play" with any color flags, be it bitstream or container. Result will be b0rked files.

[mariner]

1.
In general the syntax is:
--colour-transfer-characteristics TID:n see:
https://mkvtoolnix.download/doc/mkvmerge.html (2.8)
There is no 'transfer_characteristic HDR10+',
mkvtoolnix and the tool mentioned above should support:
0: reserved, 1: ITU-R BT.709, 2: unspecified, 3: reserved, 4: gamma 2.2 curve, 5: gamma 2.8 curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: linear, 9: log, 10: log sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.1361 extended colour gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, 17: SMPTE ST 428-1; 18: ARIB STD-B67 (HLG)

Thanks.

2.
How to remove transfer_characteristics_Origina : BT.2020 (10-bit)?
The 'original' part is usually added by MediaInfo whenever the container and stream info differ. The stream info is then shown as 'original'.
-> you would need to overwrite the flag in the stream
Appreciate if you could kindly explain how to do it.

3.
I don't think normal ffmpeg doesn't support this, and https://forum.doom9.org/showthread.php?t=152419 has a different syntax and only supports H.264 not H.265 content.
-> are you even sure the tool you choose supports what you want?
I suspect the "ffmpeg -color_trc" command only works on the mkv container?

4.
I doubt that ffmpeg can do what you want without reencoding the video.
Appreciate if you could kindly explain how to do it.

Many thanks and best regards,

[mariner]

From what I can see that tool is basically just a modded, deprecated mkvtoolnix. Since the "vanilla" version now has the same features (+more) it isn't needed anymore. Both the mod as well as vanilla only work on the Matroska headers, not the bitstream itself. Since these values are fixed for a given track there is no equivalent for HDR10+, only HDR10.


Removing the bitstream data should be possible with ffmpeg's bitstream filter (for HEVC): https://ffmpeg.org/ffmpeg-bitstream-filters.html#filter_005funits
But I don't think it's a good idea to just randomly "play" with any color flags, be it bitstream or container. Result will be b0rked files.
Thanks for the kind reply, sneaker.
2.13 hevc_metadata refers to a h265 section where presumably all transfer_characteristics are defined, but I was not able to locate the page. Can you help?
Also appreciate any help with the command line synax.
Many thanks and best regards,

[sneaker_ger]

I linked to "filter_units (https://ffmpeg.org/ffmpeg-bitstream-filters.html#filter_005funits)" bitstream filter. Try
ffmpeg -i INPUT -c:v copy -bsf:v filter_units=remove_types=39 OUTPUT
to remove the dynamic data ("PREFIX_SEI_NUT" SEIs. Not sure about type 40 = "SUFFIX_SEI_NUT").
Use "hevc_metadata (https://ffmpeg.org/ffmpeg-bitstream-filters.html#hevc_005fmetadata)" filter if you (also) want to change the static base data, e.g. change colormatrix BT709.

But again: these are only flags. Removing or changing them from correct files will only result in b0rked files.

[kolak]

Do you know where I can find reference for those unit types (numbers vs. what they mean)?

[sneaker_ger]

H.265 spec Table 7-1
https://www.itu.int/rec/T-REC-H.265

[kolak]

:thanks:

[mariner]

I linked to "filter_units (https://ffmpeg.org/ffmpeg-bitstream-filters.html#filter_005funits)" bitstream filter. Try
ffmpeg -i INPUT -c:v copy -bsf:v filter_units=remove_types=39 OUTPUT
to remove the dynamic data ("PREFIX_SEI_NUT" SEIs. Not sure about type 40 = "SUFFIX_SEI_NUT").
Use "hevc_metadata (https://ffmpeg.org/ffmpeg-bitstream-filters.html#hevc_005fmetadata)" filter if you (also) want to change the static base data, e.g. change colormatrix BT709.

But again: these are only flags. Removing or changing them from correct files will only result in b0rked files.

Thanks for the kind reply sneaker.
Transfer_characteristic stays at BT2020 after running the command. What's the command to change it to HLG/PQ?
Many thanks and best regards,

[ReciprocalUniverse]

Thanks for the kind reply sneaker.
Transfer_characteristic stays at BT2020 after running the command. What's the command to change it to HLG/PQ?
Many thanks and best regards,

I got the clue here I needed, thanks everyone, so here is the answer to you for changing to PQ/HLG.

ffmpeg -i input -c copy -bsf:v hevc_metadata=colour_primaries=9:transfer_characteristics=16:matrix_coefficients=9 output

The 16 is for PQ. For HLG just change the 16 to 18.

[ReciprocalUniverse]

Does anyone know the ffmpeg parameter names for max-cll and max-fall ?

[Blue_MiSfit]

in x265-params add max-cll=<maxcll,maxfall>

[ReciprocalUniverse]

in x265-params add max-cll=<maxcll,maxfall>

Thanks, but the only reason I'm adding back in ffmpeg HDR metadata to an h.265 encoded stream is because in this instance I'm not using x265. Resolve will output h.265 but not include HDR metadata. The advantage is speed. The disadvantage is the HDR metadata has to be added in after the encoding is finished, and the quality is bad. I don't think I can use it. If I use x265, then yes, --max-cll "1419,520" goes in at the beginning, and a beautiful encode :)

Mkvmerge will add it to the container but since bt709 transfer is already embedded in the h.265 stream that Resolve outputs, it wins. It's an interesting phenomenon because mediainfo will show all the HDR metadata is there but it won't play in HDR. Ffmpeg will copy the metadata to the stream and cause HDR playback but the quality I can't accept. The recording originates from the camera as 16 bit linear raw, and only x265 rendered from a DNxHR HQX intermediate retains player quality that respects the source file.

So I'm still looking for the ffmpeg nomenclature, but in the big scheme the h.265 encoder Resolve uses is so bad I will only use it for a draft, in which case looks like maxcll/maxfall is just lipstick for a pig.

[benwaggoner]

So I'm still looking for the ffmpeg nomenclature, but in the big scheme the h.265 encoder Resolve uses is so bad I will only use it for a draft, in which case looks like maxcll/maxfall is just lipstick for a pig.
I just pipe ffmpeg output into x265.exe, and set my parameters there. Life's too short to do complex encoding INSIDE ffmpeg :)! You don't use a swiss army knife when you need a katana.

[ReciprocalUniverse]

I just pipe ffmpeg output into x265.exe, and set my parameters there. Life's too short to do complex encoding INSIDE ffmpeg :)! You don't use a swiss army knife when you need a katana.

Yes, yet when using the ffmpeg hevc_metadata command, you are not encoding video, just inserting metadata which is very fast. The video output was already rendered prior by Resolve; its h.265 encoder just doesn't have addressable hdr metadata, it just flags your PQ content as regular 709.

If the quality was better, it would be worth running the command because with Nvidia it renders at about 21 frames/sec average.

[benwaggoner]

Yes, yet when using the ffmpeg hevc_metadata command, you are not encoding video, just inserting metadata which is very fast. The video output was already rendered prior by Resolve; its h.265 encoder just doesn't have addressable hdr metadata, it just flags your PQ content as regular 709.

If the quality was better, it would be worth running the command because with Nvidia it renders at about 21 frames/sec average.
Would that let you add/replace metadata to an already encoded elementary stream without reencoding the stream?

[ReciprocalUniverse]

Would that let you add/replace metadata to an already encoded elementary stream without reencoding the stream?

Absolutely! Just overwrites the old parameter values with new. -bsf = bitstream filter command for hevc_metadata instruction.

Not sure if I mentioned here or elsewhere, but I found it interesting that I could have a video file that would report correct HDR metadata (mkvmerge) to MediaInfo yet not trigger HDR mode in the display device. Well, if the h.265 stream carries the metadata also, it overrides what could be reported in the VUI. The process above fixes that.

That's how the YouTube HDR content creator's process is based, h.264 which doesn't or didn't support ST2084 metadata could instead rely on HDR metadata put into an mkv container to tell the YouTube servers to process the undefined h264 video stream as PQ transfer.

Hopefully, the days of these workarounds will be behind us.

Tom

[mariner]

I got the clue here I needed, thanks everyone, so here is the answer to you for changing to PQ/HLG.

ffmpeg -i input -c copy -bsf:v hevc_metadata=colour_primaries=9:transfer_characteristics=16:matrix_coefficients=9 output

The 16 is for PQ. For HLG just change the 16 to 18.

Greetings ReciprocalUniverse, you're a genius.:thanks:
Initial testing with ub820/x700 has been encouraging, both players responding to the modified flags. It is interesting to note that the players behave differently with some of the files, and it seems that other flags also play a part in affecting the playback. Would you be kind enough to share the links/documentations how these flags are defined and the arguments used? In particular the following:
Transfer_characteristic: bt2020 and bt709,
colour_range,
colour_primaries,
matrix_coefficients,

Would you be able to help with doing the same for h264 files? It seems some of these can benefit from changing the flags, but the ub820 ignore these changes.

Many thanks and best regards,

[ReciprocalUniverse]

Initial testing with ub820/x700 has been encouraging, both players responding to the modified flags. It is interesting to note that the players behave differently with some of the files, and it seems that other flags also play a part in affecting the playback. Would you be kind enough to share the links/documentations how these flags are defined and the arguments used? In particular the following:
Transfer_characteristic: bt2020 and bt709,
colour_range,
colour_primaries,
matrix_coefficients,

Would you be able to help with doing the same for h264 files? It seems some of these can benefit from changing the flags, but the ub820 ignore these changes.

Many thanks and best regards,

The command syntax usage for x264 and x265 varies between applications and even within versions in some cases, <ST2084, ST.2084, "ST-2084," "PQ">; ffmpeg and mkvmerge, x264, x265 all have unique syntax. Keeping track of all of that across platforms is difficult and picky, but the integers representing each argument seem to be the same for all of them. In other words, x264 might call range = "tv" or "pc," x265 might use "limited" or "full," but they are consistent that using the integer 1 for "tv" or 2 for "pc" is the same.

So if you read-the-docs for x265, x264 or mkvmerge; for transfer you will see the textual syntax for st-2084 identified in slightly different ways but it will always be integer 16, HLG always 18, bt2020 primaries always 9, bt2020nc matrix always 9, bt2020c is 10. So just use the integers!

As far as x264 it works that way as well except last I checked it didn't support st2084 so no matter what metadata you give it, you won't get PQ EOTF from it.

I haven't figured out nor seen the syntax for ffmpeg to report mastering display properties for RGB coordinates and white point, nor maxcll/maxfall. Hopefully they are supported in the HEVC_Metadata instruction.

[mariner]

The command syntax usage for x264 and x265 varies between applications and even within versions in some cases, <ST2084, ST.2084, "ST-2084," "PQ">; ffmpeg and mkvmerge, x264, x265 all have unique syntax. Keeping track of all of that across platforms is difficult and picky, but the integers representing each argument seem to be the same for all of them. In other words, x264 might call range = "tv" or "pc," x265 might use "limited" or "full," but they are consistent that using the integer 1 for "tv" or 2 for "pc" is the same.

So if you read-the-docs for x265, x264 or mkvmerge; for transfer you will see the textual syntax for st-2084 identified in slightly different ways but it will always be integer 16, HLG always 18, bt2020 primaries always 9, bt2020nc matrix always 9, bt2020c is 10. So just use the integers!

As far as x264 it works that way as well except last I checked it didn't support st2084 so no matter what metadata you give it, you won't get PQ EOTF from it.

I haven't figured out nor seen the syntax for ffmpeg to report mastering display properties for RGB coordinates and white point, nor maxcll/maxfall. Hopefully they are supported in the HEVC_Metadata instruction.
Thanks again, ReciprocalUniverse.

1. The list you have provided has been most useful. Would you be kind enough to give the numbers used for the other flags?

Transfer_characteristic:
st-2084=16
HLG=18

Colour_range:
Limited (tv)=1
Full (pc)=2

Colour_primaries:
BT2020=9

Matrix_coefficients:
BT2020nc=9
BT2020c=10

Need:
Transfer_characteristic: BT2020 and BT709,
Colour_primaries: BT709 and DCI-P3

2. What's the difference between bt2020nc and bt2020c?

3. Regarding h264, the x700 does respond to the modified flags.
This is what I'm trying to figure out:
When the x700 plays a sdr/709 video with the DolbyVision switch on, it produces a more appealing image on the non-DV projector compared to the same when the DV switch is off.. Any idea what could be happening here?

Many thanks and best regards,

[ReciprocalUniverse]

Thanks again, ReciprocalUniverse.

1. The list you have provided has been most useful. Would you be kind enough to give the numbers used for the other flags?

Need:
Transfer_characteristic: BT2020 and BT709,
Colour_primaries: BT709 and DCI-P3BT709 always =1 and you can refer to the linked documents below for others.
Color primaries for BT709=1; for BT2020=9.
Color matrix for BT2020NC=9; for BT2020C=10;
Color primaries as with color matrix; for DCI-P3 these never existed but should have. It's a problem when SMPTE elected BT2020 which few devices can reproduce the full gamut of while quite a few or even most can now support 90% or better of DCI-P3 gamut.
Color transfer characteristic refers to gamma or EOTF, so it's 16 for PQ and 18 for HLG.

2. What's the difference between bt2020nc and bt2020c?

BT2020NC was the broadcast standard most applicable but it was discovered a small amount of chroma crosstalk made its way into the luma channel, thus BT2020C is more precise. You probably don't have control of this within your NLE and should therefore use BT2020NC as your default. Changing the color matrix metadata will not change the actual output, only the way it is reported and interpreted, so it's more important to set it to the way it is likely created.

3. Regarding h264, the x700 does respond to the modified flags.
This is what I'm trying to figure out:
When the x700 plays a sdr/709 video with the DolbyVision switch on, it produces a more appealing image on the non-DV projector compared to the same when the DV switch is off.. Any idea what could be happening here?

I'm sorry, I don't know what an x700 is but if it is a tv display device or related that looks better with DV setting=on, I could guess tv device is receiving actual BT2020 color gamut all the time but thinks it's 709. It sounds counter intuitive, but when actual 2020 is played back on a device expecting 709 it ends up looking a bit flat, undersaturated. The DV=ON setting could be setting the color primaries param to BT2020 in which case the device now properly decodes the YUV info.

The Dolby Vision base layer is PQ + 2020. The enhancement layer is just metadata that tone maps the base layer to the smaller color space of SDR/601/709.

Somebody who knows what they are talking about should answer that. I should have left it alone, sorry.

Tom

https://www.matroska.org/technical/specs/index.html
https://x265.readthedocs.io/en/default/
https://pastebin.com/g3fZSMZN
https://pastebin.com/qNj96hb7
http://manpages.org/x264
https://gist.github.com/nolanlum/762034
x264 --fullhelp

[mariner]

Greetings Tom, thanks fro the kind reply.

x700 is the entry level uhd player from sony costing a third of the panasonic ub820. When playing sdr/709 h264 video, especially 2k ones, it seems to produce a image of better colour/contrast if the DV switch is turned on. One possible explanation, as you have pointed out, could be the insertion of some flags into the output stream that engages an different eotf in the projector. If that's the case, would you give some suggestions what may be the possible candidates?

By the way, is h264_metadata the correct filter to use in this case?

Below is list of transfer_characteristic flags, courtesy of selur, for those who may wish to do some testing.

Thanks and best regards,


Colour_range:
Limited (tv)=1
Full (pc)=2

Colour_primaries:
BT2020=9
BT709=1
DCI-P3=?

Matrix_coefficients:
BT2020nc=9
BT2020c=10
BT709=1

Transfer_characteristic:
HLG=18
st-2084=16
BT2020(10)=14
BT709=1

0: reserved,
1: ITU-R BT.709,
2: unspecified,
3: reserved,
4: gamma 2.2 curve,
5: gamma 2.8 curve,
6: SMPTE 170M,
7: SMPTE 240M,
8: linear,
9: log,
10: log sqrt,
11: IEC 61966-2-4,
12: ITU-R BT.1361 extended colour gamut,
13: IEC 61966-2-1,
14: ITU-R BT.2020 10 bit,
15: ITU-R BT.2020 12 bit,
16: SMPTE ST 2084,
17: SMPTE ST 428-1;
18: ARIB STD-B67 (HLG)

[kolak]

If your source is HDR10 then same as for h265: 9-16-9.
All what you need to do is set headers to values which describe actual video content (so you don't have situation that video is HDR, but headers say Rec.709).
All good players/HDR TVs follow headers singling, so it has to be set according to actual video nature.

There is no setting for P3 gamut. Use Rec.2020 and then in display mastering info: P3.

[ReciprocalUniverse]

If your source is HDR10 then same as for h265: 9-16-9.
All what you need to do is set headers to values which describe actual video content (so you don't have situation that video is HDR, but headers say Rec.709).
All good players/HDR TVs follow headers singling, so it has to be set according to actual video nature.

There is no setting for P3 gamut. Use Rec.2020 and then in display mastering info: P3.

This is good; now let's discuss in the context of the thread topic, which is how do you after-the-fact insert the display mastering info with ffmpeg, or without re-encoding?

Is display mastering info even used? In Resolve using ACES, there is/was an option for Rec.2020 w/P3 clip which makes P3 a subset of 2020 which all HDR TV's will support. On the other hand, with Resolve Color Management we can use tone mapping and grade 2020 to the limits of the colors 709 can see, again just grading the 709 subset within 2020 but in both cases exporting the color primaries as full 2020.

I'm not sure if that is clear or not but display mastering metadata may not be used and could be obsolete. But if we *are* going to include it, how do you insert it into the stream headers after the fact without re-encoding? I guess I disagree that "all good players/HDR tv's follow the (container) headers singly." It appears to me the container headers can carry wrong flagging and the player still gets it right because it's using the HEVC private stream headers.

[mariner]

Need help with flags

Did some preliminary testing modifying the three flags of HEVC streams: Transfer_characteristic, Matrix_coefficients and Colour_primaries. This is how the players behave connected to a basic HDR projector:
Panasonic UB820: Not affected by changing Colour_primaries,
Sony x700: Not affected by changing Matrix_coefficients.
Appreciate if someone can help with some basic questions regarding these flags:

1. The flags displayed by mediainfo are part of the video stream, not the container?
2. Do they describe the source content? Or how the content is to be displayed?
3. What do these flags mean? What are the values and valid flag combinations?
4. Some flags appears problematic for players. For example, Transfer_characteristic=BT2020 seems to cause the ub820 and X700 into sending SDR output, and so does Matrix_coefficients=Identity for ub820. Are the players behaving correctly?

Many thanks and best regards,

[sneaker_ger]

1. MediaInfo may display either.
2. What's the difference?
3. See HEVC specs (https://www.itu.int/rec/T-REC-H.265).
4. "Transfer_characteristic=BT2020" is not a valid option for ffmpeg's hevc_metadata bitstream filter.

[ReciprocalUniverse]

1. MediaInfo may display either.
2. What's the difference?
3. See HEVC specs (https://www.itu.int/rec/T-REC-H.265).
4. "Transfer_characteristic=BT2020" is not a valid option for ffmpeg's hevc_metadata bitstream filter.

This is right, especially #4. BT2020 is a color gamut. In lieu of a specified transfer characteristic 16 (PQ) or 18 (HLG) to go with it, BT2020 will usually go with standard 2.2-2.4 gamma, exact same as BT709, BT1886.

Transfer characteristic as sneaker knows is a gamma or EOTF choice.

[ReciprocalUniverse]

Need help with flags

Did some preliminary testing modifying the three flags of HEVC streams: Transfer_characteristic, Matrix_coefficients and Colour_primaries. This is how the players behave connected to a basic HDR projector:
Panasonic UB820: Not affected by changing Colour_primaries,

Could just be hard to see, or not supported.

Sony x700: Not affected by changing Matrix_coefficients. Could just be hard to see, or not supported. It's only a small difference in calculation of luma between 2020NC and 2020C. There is also a 709, which could be default. I would not recommend obsessing over this. The essential ONE for HDR is transfer characteristics.

2. Do they describe the source content? Or how the content is to be displayed?

They describe the source content, and by extension becomes a recommendation for how it should be displayed by the device.

3. What do these flags mean? What are the values and valid flag combinations? If this were only SDR, you would not have to specify them, could leave them blank and the default values would be normal for SDR. It's when you are doing HDR with the PQ or HLG transfer that the "one" becomes essential to set the HDR mode on the display device so that it properly displays the contrast and brightness characteristic that was coded into the video.

4. Some flags appears problematic for players. For example, Transfer_characteristic=BT2020 seems to cause the ub820 and X700 into sending SDR output, and so does Matrix_coefficients=Identity for ub820. Are the players behaving correctly? BT2020 is WCG (wide color gamut), so if you use that for your transfer, it's the same as 709 so yes, it will be SDR. Only PQ (ST2084) and HLG (ARIB STD B67) are HDR modes.

[mariner]

Greetings Tom and sneaker, thanks for the detail explanations.
Lets see if I get this right:

1. EOTF
Are there are only 3 officially defined EOTF in use, namely:
1. SMPTE ST 2084, for HDR/BT2020 signal
2. ARIB STD-B67, for HLG/BT2020 signal
3. BT1886, for SDR/BT709 signal.

What about the gama 2.2 and 2.4 curves? Where do they fit in?

2. Conversion functions
Are there official definitions of the following conversion functions?
HDR/BT2020 to SDR/BT709
HLG/BT2020 to SDR/BT709
HLG/BT2020 to HDR/BT2020
SDR/BT709 to HDR/BT2020
SDR/BT709 to HLG/BT2020

3. Transfer_characteristic
Does the Transfer_characteristic flag specifying the EOTF to be used by the display device? If so, BT1886 and gama2.4 seems to be missing from the list?

1: ITU-R BT.709,
4: gamma 2.2 curve,
5: gamma 2.8 curve,
14: ITU-R BT.2020 10 bit,
15: ITU-R BT.2020 12 bit,
16: SMPTE ST 2084,
18: ARIB STD-B67 (HLG)

4. Dynamic range and Colour Space: SDR/BT2020
As there appears to be no provision for separate handling of dynamic range/colour space in the EOTF, is there an official definition of SDR/BT2020? How is it displayed?

The SDR/BT2020 output mode is a feature of the panasonic ub820 highly touted by the JVC users to compensate for the lack of brightness while retaining the WCG. That seems to require the ability to disable HDR and engage BT2020 at the same time. How is this done? Is there a flag combination that allows for this?

Or is the player performing some conversion? Does anyone know what the player outputs?

5. Transfer characteristics = BT.709
This nasa test clip was detected by ub820 as SDR/BT2020, but can't get it to look like the rest.
How does one deal with this correctly?

http://ff.de/nasa-8k-hdr-download/

Color primaries : BT.2020
Transfer characteristics : BT.709
Matrix coefficients : BT.2020 non-constant


6. Transfer characteristics = BT.2020 (10-bit)
This clip was meant for trouble shooting the nvidia graphics card. UB820 shows SDR/BT2020 but can't get it right.
Looking at the flags and comments by the clip provider, this is meant to be a SDR/BT2020 signal that should look like a 709 colour bar. How to display this?

Color primaries : BT.2020
Transfer characteristics : BT.2020 (10-bit)
Matrix coefficients : BT.2020 non-constant



https://forums.geforce.com/default/topic/1058957/shield-tv/problems-with-colors-once-hdmi-setting-set-to-2020/post/5824228/#5824228

Here are two SMPTE HD Color Bars.
One is the standard one,
the second one has been converted to BT.2020
as per BT.2087 recommendation preserving the BT.709 colors.
Play them on your TV's native media player.
All the bars should look exactly the same.
If they aren't, then you have a problem :)

SMPTE HD Color Bar
https://mega.nz/#!sVdhCIaL!lY9O2rdNAfrJuFnhHXZvyUrC3CuqxQFUY8nEG2N28D8

SMPTE HD Color Bar with BT.2020 mapping https://mega.nz/#!dBNX1Q6a!oB0NSHVy5fKXTnA22xBmaH8AmF_tc5TS8Nc3OiIrSe4
https://mega.nz/#!dBNX1Q6a!oB0NSHVy5fKXTnA22xBmaH8AmF_tc5TS8Nc3OiIrSe4


7. Matrix coefficients = Identity
This is a strange one, shown by ub820 as HDR/BT709.
The image produced is somewhat lacking in colour, and the
difference with x700 is quite noticeable.
What's the reason for the identity flag? And how to display this correctly?

Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : Identity

Many thanks and best regards,

[mariner]

Greetings.
Anyone had a chance to take a look?

[excellentswordfight]

Greetings.
Anyone had a chance to take a look?
I had a hard time following your questions. But some of the information looked a bit weird.

If you look at the VUI section of https://x265.readthedocs.io/en/default/cli.html they have a pretty good list of all the avalible flags.

And I think a bit of the confusion comes from that different names are used for pretty much the same thing. If you look at the Transfer characteristic flag you can see that 1 specifies BT709, that flag is also used for BT1886. As I understand it, BT1886 is an extension standard to specify the EOTF of 709, so they are used interchangeably, even though 1886 should be the correct "naming". 1886 specify a gamma 2.4.

"While the image capture process of Recommendation ITU-R BT.709 had an optical to electrical transfer function, there has never been an EOTF documented. This was due in part to the fact that display devices until recently were all CRT devices which had somewhat consistent characteristics device to device.

This Recommendation does NOT change any signal parameters defined in Recommendation ITU-R BT.709; legacy installations are not impacted."

https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.1886-0-201103-I!!PDF-E.pdf


And for SDR/2020 content (question 4,5,6), this is a bit of rabbit hole since its very hard to know what each device is doing, and if they are designed correctly. But this is content with a larger then 709 color gamut (WCG/2020) but is still produced with a normal SDR EOTF in mind (so usually 709 for 8bit and 2020 for 10bit) and not an PQ curve (hdr). For that testclip, do you have you tried deep color/WCG settings etc on your tv?

[Balling]

1) There is also sRGB EOTF and Adobe RGB EOTF, only the last one is perfect 2.2 gamma. 2.4 is actually BT.1886 on a perfect OLED display. On LCD garbage BT.1886 is almost sRGB.
2) Yes, see BT.2390 and all others.
3) No, it does not. That is OETF. For BT.2100 (i.e. HDR) EOTF is more or less just a reverse. For SDR, BT.2020 10 (12) bit /BT.709/BT.601 transfer (it is the same transfer) should be presented using BT.1886.
5) The BT.709 transfer is the same as in BT.2020, 10 bit. So see next question. But if serious you need to get to linear light and then color manage XYZ to XYZ of destination device also applying white point change if needed.
6) The mapping is defined in SMPTE RP 219-2, but the pattern for HDR is not the same, LOL. HDR is defined in BT.2111.
7) That is RGB, Identity matrix means it is either XYZ or some form of RGB, in this case it is RGB with BT.2020 primaries. It is HDR as it is PQ. As to how to display this, well, you just do not apply the YCBCR decoding. Simple.