RPi4 testbuild with HDR support

  • opjenexus please remove all banned addons and repositories - best do a clean installation - you won't get any support here with these addons/repository installed. After that upload a log file where you reproduced the issue.


    so long,


    Hias

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

  • ErikSwan the RPi4 HDMI driver exposes standard DRM connector properties to set HDR metadata and colorimetry (BT709/2020) info, like eg Intel and AMD drivers do it, too. This is included in current upstream kernels (since 5.14) and in the downstream 5.10 RPi kernel - I haven't checked with the upstream kernel though.


    The driver also exposes a max_bpc connector property to switch from 8bit to 10 or 12bit output, but YCC output (4:4:4 or 4:2:2) selection isn't implemented yet - the driver always outputs in RGB 4:4:4 ATM.


    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

  • 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

  • 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)

    Edited 3 times, last by noggin ().

  • 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/libreelec/LibreELEC-RPi4.arm-11.0-devel-20211216212118-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

  • 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?

  • Yes, we tested it, and I missed that deinterlace is broken - just noticed it now :) We're already working on it.


    To verify output mode you could check if your TV/display has some kind of diagnostics / info menu. My LG C8 is unfortunately a bit too old and only tells me resolution and refresh rate - newer models should also report color format and bit depth.


    popcornmix checked with his HDMI analyzer and we both checked dmesg - with drm.debug=0x02 you'll see the mode and bit depth buried in tons of other logs, eg

    Code
    [   73.507849] vc4-drm gpu: [drm:vc4_hdmi_encoder_atomic_check] Mode 3840x2160 @ 60Hz: Found configuration: bpc: 12, fmt: YUV 4:2:2, clock: 593407000

    or

    Code
    [  152.031004] vc4-drm gpu: [drm:vc4_hdmi_encoder_atomic_check] Mode 3840x2160 @ 24Hz: Found configuration: bpc: 12, fmt: RGB, clock: 445054500


    so long,


    Hias

  • 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:


  • 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?

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

    Edited once, last by noggin ().

  • camelreef the important bits in the edid are that it contains support for YCbCr 4:2:2 support in the CTA extension block (pretty much any HDMI TV should support that):

    Code
    Block 1, CTA-861 Extension Block:
      Revision: 3
      Underscans IT Video Formats by default
      Basic audio support
      Supports YCbCr 4:4:4
      Supports YCbCr 4:2:2

    And for deep color (10/12bit RGB 4:4:4) the DC_30bit and/or DC_36bit bits should be contained in the HDMI vendor block:

    Code
      Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
        Source physical address: 4.0.0.0
        Supports_AI
        DC_36bit
        DC_30bit
        DC_Y444

    In addition to that the edid also should contain an HDMI Forum vendor block which announces support for TMDS rates up to 600MHz to get RGB 4:4:4 at 4kp30 with 10/12 bit or YCbCr 4:2:2 12bit at 4kp60 - at 300MHz TMDS rate the max is 1920x1080p30 at YCbCr 4:2:2. eg:

    Code
      Vendor-Specific Data Block (HDMI Forum), OUI C4-5D-D8:
        Version: 1
        Maximum TMDS Character Rate: 600 MHz
        SCDC Present

    so long,


    Hias

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

    Sorry, no idea if additional changes might be needed for Generic.


    We added the kernel patches to add support for 10/12bit video output in the driver and a small kodi patch that signals the driver to outut 12 bit, if possible (via the max_bpc DRM property which is also present on Intel and other video drivers).


    Here's my current dev branch with all changes (kodi patches are only applied for RPi but colourspace and max_bpc patches should work on Intel, too): https://github.com/HiassofT/LibreELEC.tv/commits/le11-test


    so long,


    Hias