HDMI Black level - Raspberry 4 - Librelelc 10.0.2 - Limited out of the box ?

It's really important to separate HDR and SDR in this discussion - as the same titles mastered/graded for the two different dynamic ranges can appear very different, and any HDR->SDR tone mapping (squeezing an HDR source into an SDR signal) conversion will always have side-effects.

Most HDR displays also have different black level, contrast, brightness etc. settings for SDR and HDR10/HLG formats and thus you need to calibrate separately for both - often on an input-by-input basis. (However Dolby Vision content often inhibits/overrides some of these controls)

I've seen no evidence on my Pi4B LibreElec install that AVC/h.264 and HEVC/h.265 Rec 709 HD SDR content is replayed with any difference in black levels, white levels etc. (I master content in both formats in standard video levels (aka 'Limited') from broadcast quality masters, which are by default limited range, for personal use)

There is clearly a difference between the same title mastered in HD Rec 709 SDR h.264 and UHD Rec 2020 HDR10 h.265 - but this is to do with the colour gamut (Rec 709 vs Rec 2020) and the SDR or HDR EOTF (SDR/BT.1886 vs HDR10's PQ ST.2084), not the codec. In some cases where the mastering has taken place with different colourists or the same colourist doing two separate grades, rather than a tone mapped down conversion, different decisions will be taken artistically between the SDR and HDR 'looks'.

It's important to remember that HDR10's PQ EOTF (the bit that makes it 'HDR') explicitly defines an absolute 1:1 mapping between video levels and output light level from the display, whereas the SDR standard used for regular HD (and some non-HDR UHD) content has no such explicit link and is a relative standard. This difference can often make UHD HDR content look 'dim' or 'dark' compared to the same title mastered for HD viewing in SDR.

(PQ = Perceptive Quantisation, Colour Gamut = the definition of what actual colour the red, green and blue primaries are in the real world, EOTF = Electro Optical Transfer Function = The relationship between the video levels in the signal and the output levels you see on a display. Tonemapping is the conversion between a wider colour gamut and/or dynamic range and a narrower gamut and/or dynamic range. It's the process that decides what you throw away and how you make the SDR signal either reflect the original scene or how you make it reflect the experience of viewing the HDR mastering on an SDR display - which are two very different approaches)

The “Samsung Travel With My Pet HDR UHD 4K Demo.ts” is darker on the colums at 1:19, compared with same video played on Nvidia Shield using same version of Kodi, LG TV infos says both playbacks are 4K UHD bt.2020.

Quote from giannia

The “Samsung Travel With My Pet HDR UHD 4K Demo.ts” is darker on the colums at 1:19, compared with same video played on Nvidia Shield using same version of Kodi, LG TV infos says both playbacks are 4K UHD bt.2020.

I'll see if my HD Fury Vertex reports the same static HDR 10 metadata being sent via both platforms - can you link to the content if it's in the public domain and not copyright?

I have an RPi 4B and an nVidia Shield TV Pro 2019.

It's important also to remember that some TVs will do an internal tone map to reflect the capabilities of the display - and this will be informed by the MaxCLL (Maximum Content Light Level) and MaxFALL (Maximum Frame Average Light Level) static metadata sent, which is part of the HDR10 standard (and carried by the HEVC codec, and in some cases additionally by the wrapper I believe) (This is assuming no HDR10+ is in play)

Some platforms don't passthrough MaxCLL and MaxFALL metadata - and this situation is informally referred to as PQ10 rather than HDR10 (as are TVs that ignore the static metadata - though that wouldn't be relevant to this discussion)

Yes, it’s on 4kmedia.org

Thinking about it, if I can find the time, I should be able to capture the 4K output from the two boxes using a BlackMagic 4K HDMI capture solution I have, and look at the content (alongside the original file) in Davinci Resolve Studio to compare the digital outputs with the source file.

mathmath51 can you test with hdmi_enable_4kp60=1 in config.txt (you also need to enable HDMI Ultra HD Deep Color support in your TV's setting - this is usually HDMI-port specific) on LE 10.0.2?

LE10.0.2 supports outputting at 10 and 12bit, LE10.0.1 only sent 8bit HDMI.

So on LE10.0.1 your 4kp23.97 file is transmitted as RGB 4:4:4 8bit, 10.0.2 without 4kp60 enabled transmits at YCbCr 4:2:2 12bit, with 4kp60 enabled it transmits RGB 4:4:4 12bit - all that could make a difference.

so long,

Hias

Ah, and another thing: your edid shows you've connected the RPi to a Denon AVR.

Please also test with a direct connection from the RPi to the TV to rule out issues from the AVR (Denon AVRs have some history of doing strange things...).

so long,

Hias

Can you please also test with the latest LE10 nightly? https://test.libreelec.tv/10.0/RPi/RPi4/

Would be good to know if it's fixed there, too.

so long,

Hias

Thanks for confirming!

I guess enabling 4kp60 might help on 10.0.2 but better keep using the latest LE10 nightly - it contains a couple more important fixes.

Just checked: The issue was caused by a bug in the video driver that was fixed after the 10.0.2 release - seems it didn't handle YCbCr limited properly... https://github.com/raspberrypi/li…b3a04238134aace

so long,

Hias

Quote from HiassofT

mathmath51 can you test with hdmi_enable_4kp60=1 in config.txt (you also need to enable HDMI Ultra HD Deep Color support in your TV's setting - this is usually HDMI-port specific) on LE 10.0.2?

LE10.0.2 supports outputting at 10 and 12bit, LE10.0.1 only sent 8bit HDMI.

So on LE10.0.1 your 4kp23.97 file is transmitted as RGB 4:4:4 8bit, 10.0.2 without 4kp60 enabled transmits at YCbCr 4:2:2 12bit, with 4kp60 enabled it transmits RGB 4:4:4 12bit - all that could make a difference.

so long,

Hias

What is the logic in the latest LE for 2160p 10-bit HEVC SDR/HDR10/HLG replay and YCbCr 4:2:2 vs RGB / YCbCr 4:4:4 at 30fps and lower and 50fps and higher?

• 4:2:2 12-bit is the only >8-bit format supported at all 2160p frame rates isn't it? This format often requires additional settings to be enabled in TVs and/or AVRs. (There is no 4:2:2 10-bit option in HDMI 2.0)
• RGB/4:4:4 YCbCr >8-bit is only supported at 30fps and below (and 8-bit at 2160p50 and above) but normally works OOTB on TVs and AVRs.
• 4:2:0 is supported only at 2160p50 and greater and on some TVs is the only >8-bit format supported at 2160p50 and above (and worked OOTB). However it's not supported by the Pi 4B?

For 10bit content the driver will check in the order RGB 4:4:4 12 bit -> YCbCr 4:2:2 12bit -> RGB 4:4:4 10bit -> RGB 4:4:4 8bit if both the sink and the RPi support that format.

It takes max TMDS bandwidth, YCbCr 4:2:2 and 10/12 (30/36) bit flags from EDID and also max TMDS rate from RPi into account (4kp60 / 600MHz TMDS is opt-in in config.txt) and picks the first supported format.

so long,

Hias

Quote from HiassofT

For 10bit content the driver will check in the order RGB 4:4:4 12 bit -> YCbCr 4:2:2 12bit -> RGB 4:4:4 10bit -> RGB 4:4:4 8bit if both the sink and the RPi support that format.

It takes max TMDS bandwidth, YCbCr 4:2:2 and 10/12 (30/36) bit flags from EDID and also max TMDS rate from RPi into account (4kp60 / 600MHz TMDS is opt-in in config.txt) and picks the first supported format.

so long,

Hias

Ah - so on every format change it checks for support of the various flavours - so on most modern UHD HDR displays it will be :

2160p30 and below - RGB 12 bit

2160p50 and above - YCbCr 4:2:2 12 bit, or it has to fall back to RGB 8-bit (as there is no support for RGB 10-bit at 2160p50 and above, and the Pi doesn't support YCbCr 4:2:0)?

Does the Pi ever output YCbCr 4:4:4 ?

The summary you posted is correct.

While there's some support for YCC4:4:4 in the video driver (I noticed a function checking if it'd be valid), it doesn't make use of it.

The linux drm subsystem is a bit limited in that regard, there's no connector property that would let you force eg RGB or YCC - it's all up to the driver.

The only drm connector property we can play with is the max_bpc which let's us limit component depth to max 8/10/12 bits per channel.

max_bpc defaults to 8 (so that on desktops you'll get RGB instead of falling down YCC 4:2:2, sharp text is usually more important there than 12bit which might not even be used by the software running on the desktop) and in LE/kodi on the RPi we lift that to 12bit in case of 10bit video content so we can make use of the higher output bit-depth (which is more important here than potential loss in chroma resolution - subtitles and GUI are usually up-scaled from 1080p anyways).

so long,

Hias

My Yamaha RX-V6A AVR reports this compatibility table. The default setting is mode “4K Mode 1” and for this mode the best compatibility in the range 4K 60-24Hz is YCbCr 4:2:2

YCbCr

Image YCbCr hosted in ImgBB

ibb.co