RPi4 testbuild with HDR support

are we getting any closer?:)

I'm interested in developing the RPi 4 into an open-source test pattern generator, particularly for use with HDR displays. It seems like a lot of what is needed overlaps with the effort to get HDR working in Kodi/LibreELEC.

Where is the work that popcornmix has done on the video driver to enable HDR output? Is it in the mainline Linux kernel somewhere?

I'm particularly interested in understanding the various registers that the GPU/HDMI peripheral exposes for setting the color format, bit depth, AVI info frames, etc. Are these documented anywhere?

Thanks!

ErikSwan https://github.com/raspberrypi/linux/ <= everything is there. There will be differences between upstream mainline kernel and the downstream Pi kernel, but there's a pleasing-to-see continual upstreaming effort so the differences are not so big. Note that you also need to combine this with Pi firmware and the latest ffmpeg version; not specifically for HDR (which is more of a DRM thing) but to ensure you have the latest playback fixes. FFMpeg changes are still being hoarded downstream; the focus is still on features/fixes before that effort will start in earnest.

HDR signalling is upstream. e.g. here.

RPI4B

LG OLED TV

Marantz SR55000 AVR

I see HDR is working on the Nightlies. Well done.

An observation.

1. The control panel overlay is also in HD while video is playing. Accessible by pressing ESCAPE.

The glare from the overlay makes is undesirable. I have an OLED screen and am wary of staying on this screen for more than a few seconds in case it burns in. Is this something that can be controlled or avoided.

2. Nice logo by the way.

3. How does one disable HDR

chook

1. Known and cannot currently be changed. Some kind of tonemapping to mute it might be possible in the future.

2. ??

3. Also not possible, but Kodi only switches to HDR during playback .. so just don't play HDR media if you don't want HDR

Nothing unexpected. I was surprised when playing a video I have for years played in HDR. Never mind I've seen it.

Thanks for your tireless efforts.

chook

Quote from HiassofT

There's a draft PR to allow RGB/YCC selection via another connector property https://github.com/raspberrypi/linux/pull/4201 but ATM it's a bit unclear if it will be implemented that way or if it should be handled internally in the video driver (eg 4kp60 can't output 12bit 4:4:4 due to bandwidth limitations, auto-switching to 4:2:2 may be desirable in that case).

so long,

Hias

I guess there are issues where there are HDMI output modes that are not supported (e.g. RGB or 4:4:4 YCbCr >8-bit at 2160p50 and higher) because they are out of spec, but there are also issues where you may wish to select from multiple supported options - such as 4:2:2 YCbCr 12-bit or 4:2:0 YCbCr 8-bit, 10-bit or 12-bit when both are supported on a given platform (a moot point on the Pi 4B as it only supports RGB, 4:4:4 YCbCr and 4:2:2 YCbCr and doesn't support 4:2:0 YCbCr)

This isn't relevant on the Pi 4B where 4:2:2 YCbCr 12-bit is the only supported HDMI output format that will support UHD HDR at 10-bit or higher bit depth for 2160p50 and higher frame rates - but it is relevant to other platforms that may share the same framework - where 4:2:0 YCbCr 10-bit and 12-bit and 4:2:2 YCbCr 12-bit may both be valid options for 2160p50 and higher output. (The former being lower bandwidth than the latter)

(Many UHD TVs will support 4:2:0 10-bit and higher at 2160p50 and higher on all their HDMI inputs, but only support 4:2:2 12-bit 2160p50 and higher on their 'Enhanced HDMI' inputs - and this also has to be enabled in menus. It often also has to be enabled on AVRs too. On my Sony UHD HDR TV only HDMI 2 and 3 support 4:2:2 12-bit at 2160p50 when enabled, and my Denon AVR also needs this to be explicitly enabled, otherwise it's 4:2:0 only for 10-bit and higher 2160p50 and higher)

(NB people may wonder why I don't mention 4:2:2 10-bit - but that's because it's not a valid HDMI output format - 4:2:2 YCbCr is only supported at 12-bit on 2160p50 and higher modes - there are no other bit depth options. 10-bit HDR10 and HLG video is padded to 12-bit - ideally with 00s in the LSBs)

Oooooh!

On it!

Let's see if I can notice a beautiful difference or if it's all waster on poor me...

Nico

I'm guessing that you have done your own set of testing before giving us this build, so I'm not too scared (already running LE11/K20 nightlies too).

What sort of breakage should we be on the lookout for?

How do we verify the output data/quality/level?

OK, so I'll do a general functionality test rather than a full HDR test.

My Sony TV, quite recent, always told me HDR10 or HLG and BT.2020, for ages

Grrrr.... I'm leaving tomorrow and I will be away from my system for 4 week. I won't be able to look at this much. Sorry!

The System Info in settings announces no HDR capability.

The TV is a recent Sony XH90.

Oh, also, I have a saved/fixed EDID. Will I need to update it for any reason?

Here is the decode of, I believe, relevant data:

  Vendor-Specific Video Data Block (Dolby), OUI 00-D0-46:
    Version: 2 (12 bytes)
    DM Version: 3.x
    Backlt Min Luma: 100 cd/m^2
    Interface: Standard + Low-Latency
    Supports 10b 12b 444: Not supported
    Target Min PQ v2: 0
    Target Max PQ v2: 2965
    Unique Rx, Ry: 0.67968750, 0.32031250
    Unique Gx, Gy: 0.26562500, 0.69140625
    Unique Bx, By: 0.14843750, 0.05859375
  Video Capability Data Block:
    YCbCr quantization: Selectable (via AVI YQ)
    RGB quantization: Selectable (via AVI Q)
    PT scan behavior: Supports both over- and underscan
    IT scan behavior: Always Underscanned
    CE scan behavior: Always Overscanned
  Colorimetry Data Block:
    xvYCC601
    xvYCC709
    sYCC601
    opYCC601
    opRGB
    BT2020YCC
    BT2020RGB
  YCbCr 4:2:0 Video Data Block:
    VIC  96:  3840x2160   50.000 Hz  16:9    56.250 kHz 297.000 MHz
    VIC  97:  3840x2160   60.000 Hz  16:9    67.500 kHz 297.000 MHz
    VIC 101:  4096x2160   50.000 Hz 256:135  56.250 kHz 297.000 MHz
    VIC 102:  4096x2160   60.000 Hz 256:135  67.500 kHz 297.000 MHz
  HDR Static Metadata Data Block:
    Electro optical transfer functions:
      Traditional gamma - SDR luminance range
      SMPTE ST2084
      Hybrid Log-Gamma
    Supported static metadata descriptors:
      Static metadata type 1

Quote from HiassofT

If you are in the mood for some experimental testing here's a first LE11 testbuild with 10/12bit output support

Does this mean we’ll see LE11 HDR testbuilds for generic (Intel) versions soon too?

Quote from HiassofT

If you are in the mood for some experimental testing here's a first LE11 testbuild with 10/12bit output support

https://www.horus.com/~hias/tmp/libr…118-cdca5e3.tar

If you play a 10bit video file the video driver should select the best mode supported by the display: RGB 12bit is preferred, then YCbCr 4:2:2 12bit, then RGB 10bit and if none of that is supported by the display RGB 8bit is used (as before).

Note: this is a LE11 testbuild with kodi Nexus so better install it on a separate SD card if you're running LE10 and don't want to trash that installation.

so long,

Hias

Display More

Will have a play with this over the weekend. Have an HD Fury Vertex HDMI analyser so can see precisely what is being output in video terms.

Great work!

I guess the following is how the preferences work ?

2160p30 and below : RGB 12-bit, YCbCr 4:2:2 12-bit, RGB 10-bit, RGB 8-bit

2160p50 and above : YCbCr 4:2:2 12-bit, RGB 8-bit.

(There are no 4:4:4/RGB modes at >8 bit supported in 2160p50 and above in HDMI 2.0, and 4:2:2 YCbCr is supported at 12-bit only)

4:2:2 12-bit YCbCr at 2160p50/60 is often only supported by some (not all) HDMI inputs on some TVs (like my Sony XF9005 - which won't support this format on HDMI 1 and 4, only 2 and 3) and has to be enabled in TV menus. Similarly my Denon AVR has to have support for 4:2:2 12-bit enabled in its menus too. It's often called 'Enhanced HDMI' or similar. It also requires higher performance HDMI cables to work reliably as the bandwidth is pushing the limits of the HDMI 2.0a spec.