RPi4 testbuild with HDR support

    Quote from silentsound

    Do you have any recommendations on that? I've only ever used Handbrake, not sure if it can strip HDR meta data off a file.

    Afraid it's not just stripping metadata off - it's a case of transcoding and tone mapping from Rec 2020 PQ (aka HDR1) to Rec 709 SDR at the same time.

    HDR10 content is almost always in a new, wider gamut, Rec 2020 colour-space (i.e. based around different Red, Green and Blue primary colours that are redder, greener and bluer), whereas most SDR UHD content is in the same colour space as HD (Rec 709), and HDR10 has a totally different way of handling video levels from black to the brightest whites to SDR (that's what gives it the HDR-ness). Because conversion of HDR Rec 2020 to SDR Rec 709 requires converting colours that can't be shown in Rec 709, it requires some reasonably complex processing to reduce the visibility of the lost content in the conversion process (so that hues don't change and highlights and lowlights don't get totally lost)

    This requires a process called Tone Mapping - which means the h265 UHD video needs to be decoded, tone mapped, and then re-encoded to h265 (the Pi 4B won't play UHD h264) for playback in UHD SDR on a Pi 4B.

    If your SDR UHD display supports Rec 2020 then you only need to convert the dynamic range (or EOTF) not the colour space - but I think most SDR UHD displays are usually also Rec 709 only.

    I believe ffmpeg includes some functionality that may help with this : https://forum.doom9.org/showthread.php?t=175125 is a thread detailing some approaches - I've not tried them.

    You'll need a pretty beefy CPU and/or hardware GPU acceleration on an x86 platform to do this transcoding at a reasonable speed I suspect.

    Thank you for the detailed write-up, this is far more complex than I imagined! My PC is nowhere near powerful enough for this to be done in a relatively decent amount of time.

    Currently I have my rpi4 connected via the soundbar which is 4K compatiable but not HDR. When I play 4K HDR files naturally HDR tag is not active but the BT.2020 one is. Is it fair to assume that the soundbar is passing over an accurate image?

    Quote from silentsound

    Thank you for the detailed write-up, this is far more complex than I imagined! My PC is nowhere near powerful enough for this to be done in a relatively decent amount of time.

    Currently I have my rpi4 connected via the soundbar which is 4K compatiable but not HDR. When I play 4K HDR files naturally HDR tag is not active but the BT.2020 one is. Is it fair to assume that the soundbar is passing over an accurate image?

    Two things :

    1. You can use the second HDMI output from your Pi to carry audio to your Soundbar, and the first HDMI output to carry the picture directly to your TV if you have a spare HDMI port on your TV (removing your sound bar from the video path)

    2. If you are watching an HDR10 video without your TV in HDR10 (aka PQ/ST.2084) HDR mode, and thus watching it in SDR (but still in Rec 2020) - you will see very nasty pictures indeed - and instantly know something is wrong.

    If you are watching an HLG HDR video in SDR mode but still Rec 2020 - you will notice no major differences until you get in to the highlights of the picture - which will just look less bright. However there is very little HLG out there (BBC iPlayer uses it, as does Sky Q)

    Quote from noggin

    Two things :

    1. You can use the second HDMI output from your Pi to carry audio to your Soundbar, and the first HDMI output to carry the picture directly to your TV if you have a spare HDMI port on your TV (removing your sound bar from the video path)

    2. If you are watching an HDR10 video without your TV in HDR10 (aka PQ/ST.2084) HDR mode, and thus watching it in SDR (but still in Rec 2020) - you will see very nasty pictures indeed - and instantly know something is wrong.

    If you are watching an HLG HDR video in SDR mode but still Rec 2020 - you will notice no major differences until you get in to the highlights of the picture - which will just look less bright. However there is very little HLG out there (BBC iPlayer uses it, as does Sky Q)

    1. That is what I have been doing but CEC is not working correctly when using both HDMI ports at once (10.0.2)

    2. I've re-encoded on film and compared the output: they dont seem to be very different to my eyes but it could just be the opening scene. The HDR one triggers to the TV to Rec 2020 mode, the redone one does not. The HDR one stutters a lot (bandwidth or perhaps HDR10+?) where as the other plays smoothly.

    Regardless, I've learnt a lot!

    Quote from noggin

    (*) Dolby Vision Single layer can use 0-1023 levels with IPTPQc2 instead of YCbCr - but I'm not sure how that interacts with HDMI LLDV interconnects. (And it's a non-issue for the Pi 4B)

    Any chance of LLDV decoding from Kodi on RPI4 (I read ffmpeg libplacebo can decode DV) and do HDR10 dynamic tonemapping like hdfury processor?

    My TV is a Samsung and it doesn't decode DV.

    Quote from wyup

    Any chance of LLDV decoding from Kodi on RPI4 (I read ffmpeg libplacebo can decode DV) and do HDR10 dynamic tonemapping like hdfury processor?

    My TV is a Samsung and it doesn't decode DV.

    I'd say no possibility for 4K video (neither cpu nor 3d hardware has performance for this).

    I don't know if 1080p would be possible.

    But most hdr content is 4k.

    Quote from wyup

    Well, at least decode DV to HDR10 with libplacebo open source library, provided as a vulkan-based video filter in FFmpeg?

    Is this ICtCp to YCbCr/YUV conversion for native DV HEVC stuff that uses the ICtCp style representation? (Used for the DV profiles commonly used by Netflix, Prime, Apple TV+ etc.) rather than just using the DV RPUs to generate new metadata for HDR10 YCbCr/YUV encodes? (Ignoring FEL - Full Enhancement Layer - DV streams that expand the HDR10 stuff to >10-bit?)