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

[henryperu77]

I have this World Cup sample in 4k HEVC 4:2:0 HLG 10bits and i want to convert it to 4k HEVC 8bits HLG/HDR using ffmpeg but maintaining the correct colors

https://transfer.pcloud.com/download.html?code=5ZzR5f7ZTbdQywOFwo4ZF4SbZOMq0cOPWlJF62I3TCb5VnyMDbagV

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

ffmpeg -i "d:\Descargas\NPO1 UHD.ts"
-c:a copy
-c:v libx265
-tag:v hvc1 -crf 22
-pix_fmt yuv420p10le
-x265-params "colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc" "d:\Descargas\NPO1_UHD_mkv.mkv"

Any help is appreciated...:thanks:

[videoh]

Why do you think it is HDR HLG? It doesn't look like it to me. Looks like plain old UHD.

[henryperu77]

Why do you think it is HDR HLG? It doesn't look like it to me. Looks like plain old UHD.

Video
ID : 511 (0x1FF)
Menu ID : 20901 (0x51A5)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@Main
Codec ID : 36
Duration : 53 s 280 ms
Bit rate : 24.4 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 50.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.059
Stream size : 155 MiB (93%)
Encryption : TPS-Crypt or Viaccess
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : HLG / BT.2020 (10-bit)
Matrix coefficients : BT.2020 non-constant

[videoh]

Assuming that is MediaInfo output, I'll have to look into how it detects HLG (there is no metadata for HLG). It may just be 2020 UHD, as the "HLG / BT.2020" could be ambiguous with the "/" meaning "or" rather than "and". If I decode this as simple UHD, then it looks fine. Investigating...

[nevcairiel]

If I decode this as simple UHD, then it looks fine. Investigating...

Thats one of the "features" of HLG, if you ignore it, it still looks mostly fine.

HLG-encoded streams usually have one extra SEI message that tells the player that the stream is HLG, but if you ignore that SEI message then it would just look like ordinary BT.2020 SDR.

For the OP, you should definitely not set the transfer to 2084 since thats not HLG but HDR10/PQ. I don't know if x265 can properly set the double transfer characteristics that HLG uses (ie. BT.2020 in main header, HLG in SEI header).

[henryperu77]

Thats one of the "features" of HLG, if you ignore it, it still looks mostly fine.

HLG-encoded streams usually have one extra SEI message that tells the player that the stream is HLG, but if you ignore that SEI message then it would just look like ordinary BT.2020 SDR.

For the OP, you should definitely not set the transfer to 2084 since thats not HLG but HDR10/PQ. I don't know if x265 can properly set the double transfer characteristics that HLG uses (ie. BT.2020 in main header, HLG in SEI header).

So what do you suggest i can use?

[videoh]

HLG-encoded streams usually have one extra SEI message that tells the player that the stream is HLG Interesting! Can you tell me the details on the SEI message, or point to a spec? Thank you.

[videoh]

Found this:

HEVC HDR UHDTV Bitstreams using HLG10 shall also contain the alternative_transfer_characteristics SEI message. The alternative_transfer_characteristics SEI message shall be inserted on the HEVC DVB_RAP, and preferred_transfer_characteristics shall be set equal to “18”, indicating Recommendation ITU-R BT. 2100 [45] HLG system.

[MGarret]

So what do you suggest i can use?

I don't have a clue about HDR but in x265 docs there is this:

--atc-sei <integer>

Emit the alternative transfer characteristics SEI message where the integer is the preferred transfer characteristics. Required for HLG (Hybrid Log Gamma) signalling. Not signalled by default.

I encoded your sample to elementary stream with the command you posted but added atc-sei=18 and mediainfo reports HLG / BT.2020 for transfer. However I don't know if this is correct output or if it's possible to encode it like this to 8bit.

[videoh]

I will add HLG support to DGDecNV and DGHDRtoSDR.

[henryperu77]

I don't have a clue about HDR but in x265 docs there is this:



I encoded your sample to elementary stream with the command you posted but added atc-sei=18 and mediainfo reports HLG / BT.2020 for transfer. However I don't know if this is correct output or if it's possible to encode it like this to 8bit.

Please upload it, to check it out!
thanks

[henryperu77]

I will add HLG support to DGHDRtoSDR.

What is that??

[MGarret]

Please upload it, to check it out!
thanks

Why don't you try it yourself?

Here
https://www.mediafire.com/file/z7y5lqczufsqbxn/NPO_TEST_x265.hevc

It's only few seconds

[videoh]

What is that?? It's an Avisynth filter for converting HDR10 to SDR. It runs at 100fps+ for 2160p on a recent nVidia card. It also can run in software mode but is very slow that way. Don't look to download it right now as I have it in the shop for changes. Will be available again in a few days. I will also add the HLG SEI detection to DGDecNV.

[excellentswordfight]

I have this World Cup sample in 4k HEVC 4:2:0 HLG 10bits and i want to convert it to 4k HEVC 8bits HLG/HDR using ffmpeg but maintaining the correct colors

https://transfer.pcloud.com/download.html?code=5ZzR5f7ZTbdQywOFwo4ZF4SbZOMq0cOPWlJF62I3TCb5VnyMDbagV

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

ffmpeg -i "d:\Descargas\NPO1 UHD.ts"
-c:a copy
-c:v libx265
-tag:v hvc1 -crf 22
-pix_fmt yuv420p10le
-x265-params "colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc" "d:\Descargas\NPO1_UHD_mkv.mkv"

Any help is appreciated...:thanks:
Ideally you wanna use the "alternative_transfer_characteristics" but its not supported by x265, but this mostly to keep fallback compatibility with SDR devices. But the transfer function you are after is arib-std-b67 (its the same transfer as used by HLG so it also uses 18 as value).

With that said, I cant see any reason for the 8bit transcode, that is out of the HLG specc. What should be done is to convert it to SDR, then transcode it.

[henryperu77]

Ideally you wanna use the "alternative_transfer_characteristics" but its not supported by x265, but this mostly to keep fallback compatibility with SDR devices. But the transfer function you are after is arib-std-b67 (its the same transfer as used by HLG so it also uses 18 as value).

With that said, I cant see any reason for the 8bit transcode, that is out of the HLG specc. What should be done is to convert it to SDR, then transcode it.

Ok what i need to convert it to SDR adding the color changes

[excellentswordfight]

Ok what i need to convert it to SDR adding the color changes
What is the target for the encode? Cause first you asked to keep the HDR intact, but I cant I imagine a decoder that can handle HDR but not 10bit.

When I looked at this the last time the options were limited and I ended up doing it with ffmpeg and a LUT with acceptable results (but definitely not great). Cant share the LUT though so cant help you with that unfortunately. Maybe someone else here know of another solution.

I've seen some people doing the convert with just ffmpeg (without a lut), I guess that it would look something like this:

"ffmpeg.exe" -i "input.ts" -vf zscale=tin=arib-std-b67:min=bt2020nc:pin=bt2020:rin=tv:t=arib-std-b67:m=bt2020nc:p=bt2020:r=tv,zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv,format=yuv420p -an -c:v libx265 -preset slow -x265-params level=51:crf=22:keyint=500:min-keyint=50:rc-lookahead=50:bframes=8:no-sao=1:colorprim="bt709":transfer="bt709":colormatrix="bt709":range="limited" "out"

Dont have any HLG samples atm to test with, but I guess that you can start with that, but be prepaird to tweak it.

[Revan654]

Video
ID : 511 (0x1FF)
Menu ID : 20901 (0x51A5)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@Main
Codec ID : 36
Duration : 53 s 280 ms
Bit rate : 24.4 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 50.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.059
Stream size : 155 MiB (93%)
Encryption : TPS-Crypt or Viaccess
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : HLG / BT.2020 (10-bit)
Matrix coefficients : BT.2020 non-constant

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'm a little fuzzy when it comes to HLG, shouldn't the transfer be something other then BT.2020? HDR10 uses ST.2084, I would think HLG uses ARIB STD-B67.

https://i.imgur.com/3drdJ4nl.jpg

[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.

[videoh]

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

[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]

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

...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]

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]

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]

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]

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.