RPi4 testbuild with HDR support

  • OK - for some reason I had to capture in 10-bit RGB Uncompressed rather than 10-bit YCbCr... Anyway - first glance suggests that the 75% Rec 2020 bars are in the right place on Da Vinci Resolve's vector scope (i.e. in the 75% RGBYCM squares). I'm not a DaVinci Resolve expert by any means - but with a Rec 2020 timeline, and a capture that is correctly flagged as Rec 2020 in Media Info, then I think this is looking good.

    On the luminance ramp below the 4 sets of colour bars you can clearly see truncation to 8-bits from the 10-bit source.

  • Update - just compared the captured bars from the Pi 4B, playing back an h.265 conversion of the source file from the EBU, along with the native bars from the EBU test file in Resolve and they appear identical. I think this suggests that things are good.

    I transcoded the EBU v210 source to h.265 using libx265 with the following ffmpeg command, played it on the Pi 4B and captured the result in RGB 10-bit uncompressed :

    Code
    ffmpeg -i "EBU_HDR_COLOUR_BARS_2160p_v210.mov" -filter_complex loop=loop=20:size=100 -codec:v libx265 -crf 15 -pix_fmt yuv420p10le -color_primaries bt2020 -colorspace bt2020_ncl -color_trc arib-std-b67 "EBU_HDR_COLOUR_BARS_2160p_v210.2020hlg.mov"

    (You have to tell ffmpeg the colour space and EOTF to flag on the output - but those flags don't process the video, they just add metadata AIUI)

  • Update - just compared the captured bars from the Pi 4B with the native bars from the EBU test file in Resolve and they appear identical. I think this suggests that things are good.

    Awesome, this is really good news! Huge thanks for going through all the effort and checking this!

    so long,

    Hias

  • Awesome, this is really good news! Huge thanks for going through all the effort and checking this!

    so long,

    Hias

    No problem. I'm not a Resolve Expert - but things do look good.

    Next step - 10-bit RGB (2160p30 and below) and/or YCbCr 4:2:2 12-bit so we can have HDR (and SDR 10-bit) at all frame rates :)

    (Interesting that some OTT providers are now using h.265 10-bit SDR for some content - SVT Play in Sweden are - as a route to higher quality SDR with far less banding than 8-bit SDR. 10-bit isn't restricted to HDR these days - it has benefits for SDR too )

    Edited once, last by noggin (April 15, 2021 at 12:41 PM).

  • Are there any uptades on the dolby synch audio problem?

    If you mean DolbyDigital+/E-AC3 then no, this is a kodi issue.

    If it's important to you then just subscribe to the kodi issue on GitHub Garbled sound with DD+/EAC3 passthrough and official Dolby DD+ 7.1 sample · Issue #19182 · xbmc/xbmc · GitHub to get notifications when something changes (but I don't expect this to be fixed any time soon TBH).

    so long,

    Hias

  • FYI: The BT.2020 HDR fixes have been merged into our master branch and are included in the latest nightly build - so you can switch back to using nightlies instead of the test builds from this thread.

    so long,

    Hias

  • Working for me now, my Sony 65XE9305 switches to hdr, but only thing is that in hdr the overall image looks pretty dark.

    Is there a way to up the brightness in libreelec/kodi somewhere in the settings?

    Edited 2 times, last by Phoskam (April 17, 2021 at 11:40 AM).

  • Working for me now, my Sony 65XE9305 switches to hdr, but only thing is that in hdr the overall image looks pretty dark.

    Is there a way to up the brightness in libreelec/kodi somewhere in the settings?

    Have you watched the same content in HDR via alternate sources such as a UHD HDR Blu-ray player? Is that brighter?

    If not - then chances are you're just seeing the normally reported issue with HDR10 from people who have HDR TVs but normally watch SDR on them.

    Most people with HDR displays are watching SDR content with the SDR peak brightness pushed well into the HDR range of brightness levels. The SDR range in HDR10 (and other specs) is officially 0-100nits (i.e. anything over 100nits is reserved for HDR speculars, detail in bright areas etc.). However this feels really dim to many people watching in regular light level rooms, and the reality is that most people watching SDR will have their peak SDR well over 100nits on an HDR TV.

    As a result HDR stuff (which will keep most of the detail in the SDR range of 0-100nits) often looks a lot darker than people are expecting (particularly as many people think HDR = brighter picture, rather than more detail in highlights)

    This is also somewhat complicated by HDR10 officially using PQ (Perceptive Quantisation) where the ST.2084 EOTF (video level - > display light level conversion) according to the standard is fixed to a 1:1 mapping - rather than relative (like SDR and HLG HDR) - so in theory you shouldn't be able to make an HDR picture brighter or darker with user controls (as that stops it being properly compliant with the HDR10 spec). (*)

    Of course you will often find this can be overridden on many TVs - though it does mean that you are then likely to be clipping/squeezing more and more HDR detail (reducing the benefits of the HDR source), as the brighter you make the SDR picture, the less dynamic range you have left for the HDR elements.

    Dolby Vision modes on TVs often go one step further and specifically stop you altering the display brightness levels at all.

    (*) Arguably this is why HLG HDR makes a tonne more sense for domestic viewing (particularly as it has ambient light compensation built into the standard - rather than bolted on as a bolted-on afterthought like Dolby Vision IQ)

    Changing the brightness/contrast of an image should really be a display function not a Kodi function?

  • First I make a new fresh install of:

    LibreELEC-RPi4.arm-10.0-nightly-20210417-e3f1165.img

    After that I put your file:

    LibreELEC-RPi4.arm-10.0-devel-20210409193846-98e0bda

    in the UPDATE folder to update

    But When open HDR video the colors are still dark I think. Maybe it is the video itself. Do you have any tips to change in the settings or do you have a sample file that I could test?

    So long

    Edited 2 times, last by harun-cuk17 (April 17, 2021 at 1:27 PM).

  • Do you have the same video on an original source - comparing an HDR10 UHD Blu-ray played on a UHD Blu-ray player, compared with the same disc ripped as a file (without remastering/transcoding) and played back on the Pi 4B would be the obvious route.

    What I can say is that the video levels leaving the Pi 4B are what is expected within the standard, and the EOTF is being correctly flagged.

    I haven't checked what the MaxCLL and MaxFALL and mastering metadata situation is - but I wouldn't expect that to change the replay level (though it may change how highlights are treated)

    (As I've said above - HDR content is often accused of being too dark when it follows the official HDR10 specs, largely because the specs are based on the SDR range - 0-100nits - being unrealistically low for domestic settings, and the reality is that people watch SDR content at far brighter levels than the spec is based on, meaning they watch SDR pushed well into the HDR10 HDR range of >100 nits)

    Properly mastered SDR will keep almost all content but highlights and speculars in the 0-100nit range - so HDR often appears dark as a result (particularly HDR10 content that has a set-in-stone video level to light level mapping, unlike HLG)

  • The other hdr stuff I watch is mostly dolby vision on Netflix or hdr movies on YouTube.

    Both of these look much brighter, especially dolby vision.

    Tonight were going to watch a movie, then the living room is also much darker.

  • How the Pi 4B performs the HDR to SDR tone mapping ? I got 1080p projector and 4K monitor, both are SDR.

    It doesn't. Tone mapping requires a quite powerful GPU (or fast processor) which the RPi4 doesn't have and also this isn't implemented in Kodi yet. Mapping 720p or maybe 1080p might be possible but 4k most certainly is way above the RPi4's capabilities.

    So, stay away from HDR media if you only have SDR displays or recode it with tone mapping on a PC.

    so long,

    Hias

  • Do you have the same video on an original source - comparing an HDR10 UHD Blu-ray played on a UHD Blu-ray player, compared with the same disc ripped as a file (without remastering/transcoding) and played back on the Pi 4B would be the obvious route.

    What I can say is that the video levels leaving the Pi 4B are what is expected within the standard, and the EOTF is being correctly flagged.

    I haven't checked what the MaxCLL and MaxFALL and mastering metadata situation is - but I wouldn't expect that to change the replay level (though it may change how highlights are treated)

    (As I've said above - HDR content is often accused of being too dark when it follows the official HDR10 specs, largely because the specs are based on the SDR range - 0-100nits - being unrealistically low for domestic settings, and the reality is that people watch SDR content at far brighter levels than the spec is based on, meaning they watch SDR pushed well into the HDR10 HDR range of >100 nits)

    Properly mastered SDR will keep almost all content but highlights and speculars in the 0-100nit range - so HDR often appears dark as a result (particularly HDR10 content that has a set-in-stone video level to light level mapping, unlike HLG)

    No I dont have the same movie on uhd disc. Maybe somebody got a file which I can download and put it on a usb stick and then play it on the rpi4 to test it.

    Thanks for the information buddy.