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.

Video
ID                                       : 1
Format                                   : RGB
Codec ID                                 : r210
Codec ID/Hint                            : Blackmagic Design
Bit rate mode                            : Constant
Bit rate                                 : 6 636 Mb/s
Width                                    : 3 840 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 25.000 FPS
Color space                              : YUV
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 32.000
Stream size                              : 1.76 GiB (100%)
Language                                 : English
Encoded date                             : UTC 2021-04-15 10:51:44
Tagged date                              : UTC 2021-04-15 10:51:44
Color primaries                          : BT.2020
Transfer characteristics                 : HLG
Matrix coefficients                      : BT.2020 non-constant

Are there any uptades on the dolby synch audio problem?

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 :

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)

Quote from HiassofT

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 )

Hello Hias,

And which nightly do I need for rpi4?

There are so much versions when I look at the nightly list.

Thanks

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?

Quote from Phoskam

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?

Quote from HiassofT

If you are in the mood for some experimental testing here's a new testbuild to try:

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

Kodi and video driver now signal BT.2020 colorspace, my LG C8 now shows BT.2020 in status info (which it didn't before).

Conversion matrix in video driver is unchanged so whitepoint most certainly isn't right. 10/12bit output is still missing as well, but hopefully we're one step closer to correct HDR output.

The build also contains current WIP HEVC optimizations and latest kodi Matrix changes. High-bitrate and 50/60fps HEVC videos should perform better now but beware, there might still be bugs

so long,

Hias

Display More

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

Quote from harun-cuk17

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

Display More

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)

Quote from noggin

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.

Display More

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.

Thanks

Quote from noggin

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.