Log in

View Full Version : HDR metadata questions


DarkZeros
5th September 2018, 22:58
I recently came across a content with HDR10. And I started to play around with it, to see if my TV can decode it properly and also weather I should start considering HDR for the future.

The content has:

Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.708000 y=0.292000, G: x=0.170000 y=0.797000, B: x=0.131000 y=0.046000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0050 cd/m2, max: 1000.0000 cd/m2
Maximum Content Light Level : 777 cd/m2
Maximum Frame-Average Light Level : 370 cd/m2


And no matter how I play it it looks washed out. (Q6F samsung TV, desktop with HDR10 support)
However, looking at the metadata, makes sense, since the TV has 1000 cd/m2 and the content states that 777 cd/m2 is the maximum.

Is this correct? Can anyone provide me with a sample test HDR10 content I can test?

And in case the content I have is garbage, can it be fixed somehow? Converting to 8bit leads to a washed out as well in x265.

rekweom
6th September 2018, 21:51
Your TV should play it just fine. You can also use MadVR to passthrough HDR.

Lyris
7th September 2018, 00:43
Does playing it back on your TV not trigger the HDR display mode? How are you getting it to your display?

Converting to 8bit leads to a washed out as well in x265.
Why would you want to convert it to 8 bit? Very bad idea for HDR.

Cary Knoop
7th September 2018, 03:46
Right, HDR10 is 10 (or 12) bits by definition.

DarkZeros
9th September 2018, 15:31
Ok, I managed to do more testing today.
The TV does indeed accept HDR, and it shows HDR icon.
Another content in 10 bits HDR works ok, but the other content has 1000 cd/m2.

However, this content has 777 cd/m2 and looks like the brightness is low on the TV while showing the content.
Any way I can correct this?
Maybe the TV is not picking up properly the metadata.

Lyris
20th September 2018, 00:03
Right, HDR10 is 10 (or 12) bits by definition.

In theory there's nothing to stop you applying the PQ EOTF to 8-bit or even less footage. Just not a good idea to spread 230-ish levels across 4000 cd/m2 or more of real-world light output levels...

benwaggoner
26th September 2018, 00:37
In theory there's nothing to stop you applying the PQ EOTF to 8-bit or even less footage. Just not a good idea to spread 230-ish levels across 4000 cd/m2 or more of real-world light output levels...
I've seen a couple variants of HDR in 8-bit. In YUV with just dropping the least significant bits, there is terrible banding and weird chroma issues.

In another, rendering to 0-255 RGB 4:4:4 with very good dithering, it actually looked pretty good.

Blue_MiSfit
28th September 2018, 05:45
@benwaggoner, do you think a more conservative HDR grade (e.g. with maxcll / maxfall under 1000 as most studios are doing these days) would be more suitable for a hypothetical 8 bit HDR system than say for example something hypothetically pushing 4000?

The brightest I've ever seen is around 1500 I think.

Cary Knoop
28th September 2018, 06:29
I think that 8-bit HDR is some kind of a misnomer and reduces the standard even before it is mainstream.
For HDR you need the higher bitrate.

foxyshadis
28th September 2018, 07:26
@benwaggoner, do you think a more conservative HDR grade (e.g. with maxcll / maxfall under 1000 as most studios are doing these days) would be more suitable for a hypothetical 8 bit HDR system than say for example something hypothetically pushing 4000?

The brightest I've ever seen is around 1500 I think.

Mapping 1000 on to the typical 100 cd/m2 of 709 would be a hard sell; it's impossible not to wash something out. Of course, the fewer steps you have to compress into a limited range the better, but HLG definitely sounds like a useful automatic solution at that point.

mparade
26th October 2018, 17:55
Hello there,

The basis HDR10 layer, after being separated from the additional Dolby Vision video layer + additional metadata, can be reencoded as "static" HDR10 then merged back again with the Dynamic Dolby Layer within a container?Should this work theoretically?

Help would be appreciated.

benwaggoner
30th October 2018, 16:58
Hello there,

The basis HDR10 layer, after being separated from the additional Dolby Vision video layer + additional metadata, can be reencoded as "static" HDR10 then merged back again with the Dynamic Dolby Layer within a container?Should this work theoretically?

Help would be appreciated.
Normal Dolby Vision Profile 5 has a non-backwards compatible base layer in Y'CtCp color space that dynamically varies the mapping of code values to PQ to optimize dynamic range.

Are you talking about some way to convert from Profile 5 to Profile 8.1 (which is a HDR10 backwards compatible stream)? So far Profile 8.1 has only been used for live events, and I'm not sure how much of that has been available to customers versus testing.

mparade
26th December 2018, 12:11
Thank you for the info. I just meant if it is possible to reencode the HDR10 layer as static using x265 just by ignoring the Dolby Vision extension layer.

asarian
30th December 2018, 21:03
I've seen a couple variants of HDR in 8-bit. In YUV with just dropping the least significant bits, there is terrible banding and weird chroma issues.

In another, rendering to 0-255 RGB 4:4:4 with very good dithering, it actually looked pretty good.

I'm having good results with DGHDRtoSDR. My TV can't show HDR anyway, so re-encode to 8-bit it is. :)

I haven't noticed any (extra, 'terrible') banding, though. What filter are you using for your 4:4:4 encoding, please? I'd like to give that a try too.

asarian
30th December 2018, 21:08
Normal Dolby Vision Profile 5 has a non-backwards compatible base layer in Y'CtCp color space that dynamically varies the mapping of code values to PQ to optimize dynamic range.

Are you talking about some way to convert from Profile 5 to Profile 8.1 (which is a HDR10 backwards compatible stream)? So far Profile 8.1 has only been used for live events, and I'm not sure how much of that has been available to customers versus testing.

Btw, is there way/filter to apply the Dolby Vision Enhancement Layer (like in VapourSynth), to get the intended SDR color again? It looks like a 1920x1080p extra stream.

SeeMoreDigital
30th December 2018, 22:51
Have you guys seen the following Dolby Vision in MP4 post? https://forum.doom9.org/showthread.php?p=1861421#post1861421


Cheers

kolak
1st January 2019, 15:54
Btw, is there way/filter to apply the Dolby Vision Enhancement Layer (like in VapourSynth), to get the intended SDR color again? It looks like a 1920x1080p extra stream.

Base layer should be SDR image, no?
It's for backward compatibility.
Then if you have hardware with DV then 2nd layer is added to create an HDR "final" image. This "mixing" both layers is a secret and you need to license it from Dolby. This what happens in DV capable processors inside players/TVs etc.

gonca
1st January 2019, 16:28
Base Layer is HDR10
The enhancement (second) layer is the DV metadata 1920x1080
Backward compatibility in DV terms means that 4K HDR only equipment can play DV video as HDR10

asarian
1st January 2019, 21:54
Base layer should be SDR image, no?
It's for backward compatibility.
Then if you have hardware with DV then 2nd layer is added to create an HDR "final" image. This "mixing" both layers is a secret and you need to license it from Dolby. This what happens in DV capable processors inside players/TVs etc.

Thanks. Too bad the 'mixing' is a secret, but it answers my question as to whether maybe a VapourSynth filter could do the mixing itself.

benwaggoner
3rd January 2019, 20:27
Base layer should be SDR image, no?
It's for backward compatibility.
Then if you have hardware with DV then 2nd layer is added to create an HDR "final" image. This "mixing" both layers is a secret and you need to license it from Dolby. This what happens in DV capable processors inside players/TVs etc.
Base layer in SDR is Profile 3 IIRC. That was popular in the very first wave of DoVi content. But it is substantially less efficient to encode and more computationally expensive to decode than Profile 5, which is why everyone is getting away from having two layers of video content. Instead there is a base layer and then a metadata layer.