Convert HEVC 2160p 10 bits HLG to 2160p 8bits with HLG/HDR using ffmpeg

[hydra3333]

thank you, videoh.

[videoh]

You're welcome, hydra3333. I am also adding HLG support to DGHDRtoSDR. Current version (no HLG yet) is here:

http://rationalqm.us/misc/DGHDRtoSDR_1.4.rar

[SeeMoreDigital]

Originally Posted by Revan654

The sample you Uploaded is not HLG from what my editing software is reading out. Mediainfo been hit or miss when it comes to HDR content.

I can confirm the sample triggers the HLG HDR flag on my LG television

Originally Posted by henryperu77

...I tried this that i found on another site, but the color results are horrible...

Out of interest... Are you viewing HLG content on a screen that supports HLG decoding?

[excellentswordfight]

Originally Posted by videoh

That stream does contain the SEI message discussed. Next slipstream of DGDecNV will show it in the DGI file.

Are you sure, I think it does. If I make an encode with x265 with --atc-sei 18 --transfer bt2020 (it should be --transfer bt2020-10 though), I get the same readout in ffmpeg and mediainfo as OP:s ts file.

[hydra3333]

don't know if this is relevant, someone said
https://mrmc.tv/forum/viewtopic.php?t=3973#p16210

The transfer characteristics for true HDR10 content cannot be BT.2020 ( # 14). It has to be PQ/ST.2084 ( #16). BT.2020 transfer characteristic is the same as for BT.709 (BT.1886/SDR)

.

[benwaggoner]

Originally Posted by videoh

Interesting! Can you tell me the details on the SEI message, or point to a spec? Thank you.

You should hear broadcast guys FREAK OUT at the very mention of metadata! Because if you have it, that implies it could change with content, and broadcast infrastructure has no way to switch metadata when switching between sources, ads, etcetera. Nor do device specs really say what should happen when display metadata changes mid-stream. In the HDR-10 world, the assumption is that a piece of content has to have the same metadata during an entire playback session, and that changing it would only be honored if there is an HDMI reset or something.

[benwaggoner]

Originally Posted by nevcairiel

HLG uses a separate SEI element to indicate a secondary transfer function, which allows fallback to SDR with non-HLG aware players. So the main transfer function entry would be an SDR one, and the extra SEI element would indicate the HLG transfer. If your analyzer does not understand that separate SEI, then it would show as SDR.

Real-world, it's more that the HLG code values look okay when treated as SDR.

HLG is something that works in practice (decent HDR on supported devices, with decent SDR on legacy devices) but not in theory (same set of code values without metadata can deliver two different creative intents).

The challenge with HLG is that it gets optimized for SDR, HDR, or sort of in the middle. It's never going to be as accurate or "HDR" as well-graded HDR-10(+) or Dolby Vision.

But if you are a broadcaster limited by RF instead of IP, having one channel that can do SDR and HDR is very appealing.

[benwaggoner]

Oh, another thing I just recalled - HLG is supposed to always be 10-bit. Weird things might happen using it in 8-bit instead due to lack of precision and/or hardware support.

[Gser]

Originally Posted by benwaggoner

Oh, another thing I just recalled - HLG is supposed to always be 10-bit. Weird things might happen using it in 8-bit instead due to lack of precision and/or hardware support.

Yeah as is all HDR except Dolby Vision which is a 12-bit mess. 8-bits would limit the dynamic range i.e. cause banding in frames with large range, loss of detail in highs and lows etc.