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

Quote from giannia

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

https://ibb.co/vYWb7RQ

Yes.

4K Mode 2 = 'Enhanced HDMI Mode support' on some platforms. This allows the higher bandwidth HDMI 2.0 modes to be used that allow HDR support at >4:2:0 subsampling with >8 bit depth.

4K Mode 1 only supports the lower bandwidth HDMI 2.0 modes that are based around 4:2:0 at 2160p50 and above for >8 bit depth.

My Sony UHD TV, with the enhanced modes enabled, is equivalent to 4K Mode 2 on HDMIs 2 and 3, but 4K Mode 1 on HDMIs 1 and 4. My Denon AVR required enhanced modes to be enabled too, to pass through 2160p50 and above 4:2:2 12 bit inputs.

(4:2:0 was initially added to the HDMI 2.0 spec to allow HDMI 1.4 physical hardware in TVs etc. to support 2160p50 and above modes as it squeezed into an HDMI 1.4 bandwidth signal. ISTR nVidia and Sony both added support for 4:2:0 2160p50 and above modes as upgrades to hardware that was otherwise limited to HDMI 1.4)

Quote from HiassofT

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

Display More

Thanks - that all makes sense - and totally understand why desktops would favour RGB over a subsampled 4:2:2 or 4:2:0 mode to avoid chroma smearing on fine detail (whereas video is already encoded in 4:2:0 usually so it's a moot point for video replay)

Out of interest is bit-depth checked irrespective of EOTFs - i.e. does a 1080p50 10-bit HEVC SDR Rec 709 file get output in a 10-bit or 12-bit mode?

Quote from noggin

Out of interest is bit-depth checked irrespective of EOTFs - i.e. does a 1080p50 10-bit HEVC SDR Rec 709 file get output in a 10-bit or 12-bit mode?

Yes, this is done independently.

The logic inside kodi is quite simple:

If the video driver supports the colorspace property it'll set it to "BT2020" for BT2020 videos or "Default" (i.e. usually BT709) for other content.

HDR metadata is handled in a similar way (set if driver supports it and we have it, unset or untouched otherwise).

If the video bit depth is higher than 8bit and the video driver supports the max_bpc property it'll set it to 12 - so you'll usually get 12bit RGB or YCbCr 4:2:2 both for SDR and HDR 10bit content.

By default (eg in GUI) max_bpc is set to 8 so we get 8bit RGB output (YCbCr 4:2:2 won't be considered by the RPi video driver as it's a 12bpc mode).

The Kodi PR that adds this logic is in LE RPi builds but still under discussion at Kodi side - see https://github.com/xbmc/xbmc/pull/20006 - so there might be changes or extensions in the future.

The various video drivers work slightly differently or don't support all combinations (eg due to hardware limitations/bugs).

For example Intel doesn't support YCbCr 4:2:2, only RGB, YCbCr 4:4:4 and YCbCr 4:2:0 so it might be an option to set max_bpc to 10 to get 10bit output or don't set it at all (IIRC Intel defaults to 12) to let the driver choose some supported format.

Or, eg on RPi, maybe an option to always keep it at 12 to avoid mode switches between GUI and 10bit video playback.

I guess in the end we might see some config setting to control behavior, similar to "adjust refreshrate on playback".

so long,

Hias

Quote from HiassofT

Yes, this is done independently.

The logic inside kodi is quite simple:

If the video driver supports the colorspace property it'll set it to "BT2020" for BT2020 videos or "Default" (i.e. usually BT709) for other content.

HDR metadata is handled in a similar way (set if driver supports it and we have it, unset or untouched otherwise).

If the video bit depth is higher than 8bit and the video driver supports the max_bpc property it'll set it to 12 - so you'll usually get 12bit RGB or YCbCr 4:2:2 both for SDR and HDR 10bit content.

By default (eg in GUI) max_bpc is set to 8 so we get 8bit RGB output (YCbCr 4:2:2 won't be considered by the RPi video driver as it's a 12bpc mode).

The Kodi PR that adds this logic is in LE RPi builds but still under discussion at Kodi side - see https://github.com/xbmc/xbmc/pull/20006 - so there might be changes or extensions in the future.

The various video drivers work slightly differently or don't support all combinations (eg due to hardware limitations/bugs).

For example Intel doesn't support YCbCr 4:2:2, only RGB, YCbCr 4:4:4 and YCbCr 4:2:0 so it might be an option to set max_bpc to 10 to get 10bit output or don't set it at all (IIRC Intel defaults to 12) to let the driver choose some supported format.

Or, eg on RPi, maybe an option to always keep it at 12 to avoid mode switches between GUI and 10bit video playback.

I guess in the end we might see some config setting to control behavior, similar to "adjust refreshrate on playback".

so long,

Hias

Display More

That's now made me question how Rec 601 output is handled (given the very different RGB<->YCbCr matrices that Rec 709 and Rec 601 have) wrt 'default'?

Quote from noggin

That's now made me question how Rec 601 output is handled (given the very different RGB<->YCbCr matrices that Rec 709 and Rec 601 have) wrt 'default'?

Phew, that's indeed a tricky question. Maybe popcornmix can give some more detailed info (or correct me)?

If I understood CTA-861 correctly "default" (i.e. C0 and C1 both zero) means SMPTE 170M/BT.601 for SD and BT.709 for HD resolutions. But I'm not sure what exactly happens when RPi upscales SD video to HD - the SD video probably would be BT.601 but the output then HD BT.709.

The video plane usually is in YCC but internally it gets converted to RGB before it's being mixed with other planes (eg overlay), then an output conversion can get applied (eg to again convert it to YCC).

Dave fixed the various conversion matrices in this commit https://github.com/raspberrypi/li…b3a04238134aace PR discussion is here https://github.com/raspberrypi/linux/pull/4932 but it doesn't seem to mention BT.601 and SD->HD upscaling so I can't tell if this is handled properly (my guess is outputting SD content at SD resolution should work).

so long,

Hias

On a second thought BT.601/709 handling should be fine:

For YCbCr planes kodi sets the COLOR_ENCODING (601/709/2020) and COLOR_RANGE (limited/full) properties so the YCbCr conversion to internal RGB (where plane composition is performed) should be correct.

If the output connector Colorspace prop is set to Default the driver chooses the RGB->BT.709 matrix if YCbCr output is enabled. This can happen with 10bit 1080p output on a HD TV.

Usually we'll output RGB though so no conversion will be applied at the output stage and C0=0, C1=0 correctly indicate the RGB colorimetry (C0=1 or C1=1 would be invalid for RGB output)

We might have a theoretical problem though if we would output YCbCr at an SD resolution (where HDMI default is BT.601 but the driver would apply the BT.709 matrix) but that would be a rather rare corner case:

You need to play 10bit SDR content and have the display resolution set to SD in combination with a TV/monitor that doesn't support 12bit RGB so the driver chooses YCbCr 4:2:2.

so long,

Hias