LibreELEC (Leia) 9.2 ALPHA1 with Raspberry Pi 4B Support

    Quote from Stereodude

    If it doesn't support YUV4:2:x it won't be able to do 10-bit 2160p60. If it can only do 8-bit RGB 2160p60 HDR playback is going to be gimped.

    However, I don't know if the Videocore VI is capable of decoding YUV video, leaving it in YUV color space, and rending the Kodi GUI/OSD either directly into YUV color space or rendering it to RGB and converting it to YUV for blending and output so that the video can be passed unmolested without two color space conversions.

    The Pi Devs have said 4:2:2 support is there - but it looked like they suggested the vertical subsampling for 4:2:0 meant that wasn't an option. If that is the case, then that means 4:2:2 12-bit will be the only HDR HDMI 2.0 output mode for 2160p50-60 supported I guess (as there is no 10-bit 4:2:2 defined for HDMI 2.0 - so 10-bit HDR HEVC content is output at 4:2:2 12-bit not 10-bit)

    For 2160p24-30 content you can run RGB or 444 and output HDR, without needing 4:2:2 (though 4:2:2 12-bit is valid at these frame rate resolution / combos as well, whilst there is no 4:2:0 support in HDMI 2.0 at <50p). For the bulk of HDR HEVC PQ content - which is 2160p23.976 movies an tv drama - RGB or 4:4:4 YCrCb output in 10-bit is a supported HDMI 2.0 mode and is fine.

    I guess if you render Kodi to YUV-space you'll need to have both Rec 709 and Rec 2020 RGB->YCrCb conversion implemented, unless you mind GUI rendered stuff being a bit out (are photos gui-rendered)

    Quote from noggin

    The Pi Devs have said 4:2:2 support is there - but it looked like they suggested the vertical subsampling for 4:2:0 meant that wasn't an option. If that is the case, then that means 4:2:2 12-bit will be the only HDR HDMI 2.0 output mode for 2160p50-60 supported I guess (as there is no 10-bit 4:2:2 defined for HDMI 2.0 - so 10-bit HDR HEVC content is output at 4:2:2 12-bit not 10-bit)

    For 2160p24-30 content you can run RGB or 444 and output HDR, without needing 4:2:2 (though 4:2:2 12-bit is valid at these frame rate resolution / combos as well, whilst there is no 4:2:0 support in HDMI 2.0 at <50p). For the bulk of HDR HEVC PQ content - which is 2160p23.976 movies an tv drama - RGB or 4:4:4 YCrCb output in 10-bit is a supported HDMI 2.0 mode and is fine.

    I guess if you render Kodi to YUV-space you'll need to have both Rec 709 and Rec 2020 RGB->YCrCb conversion implemented, unless you mind GUI rendered stuff being a bit out (are photos gui-rendered)

    Well, if the YUV 4:2:2 support on the Pi works anything like a PC everything will be done in RGB colorspace and then be converted to YCrCb right before it's output with a conversion of nebulous quality / correctness.

    Most BD & UHD-BD players output in YCrCb color space and play back YUV video content from files without a conversion to RGB and then back to YUV. It would be nice if the RPi 4 could do the same. Unfortunately the BD & UHD-BD players have all sorts of limitations on codecs and containers.

    Quote from Stereodude

    Well, if the YUV 4:2:2 support on the Pi works anything like a PC everything will be done in RGB colorspace and then be converted to YCrCb right before it's output with a conversion of nebulous quality / correctness.

    Most BD & UHD-BD players output in YCrCb color space and play back YUV video content from files without a conversion to RGB and then back to YUV. It would be nice if the RPi 4 could do the same. Unfortunately the BD & UHD-BD players have all sorts of limitations on codecs and containers.

    Yep - though I guess you're then in a world of Rec 601 vs Rec 709 vs Rec 2020 YCrCb conversions (as they are all different) if you play back a Rec 601 DVD and output it in Rec 709? (And that's ignoring gamut conversions - which you kind of can with 601/709 tolerably, but you can't with 709 vs 2020)

    Arguably taking stuff back to RGB rather than doing YCrCb.601 - > YCrCb.709 conversion in the YCrCb domain is a six and two threes?

    Quote from noggin

    Yep - though I guess you're then in a world of Rec 601 vs Rec 709 vs Rec 2020 YCrCb conversions (as they are all different) if you play back a Rec 601 DVD and output it in Rec 709? (And that's ignoring gamut conversions - which you kind of can with 601/709 tolerably, but you can't with 709 vs 2020)

    Arguably taking stuff back to RGB rather than doing YCrCb.601 - > YCrCb.709 conversion in the YCrCb domain is a six and two threes?

    My understanding is that for HDR content there are flags in the HDMI stream to indicate the color space. I think that takes care of 709 and 2020 for folks with a HDR capable display. The source doesn't have to do any conversions, just enable the right flags in the output. I'm not sure how 601 is handled.

    There's going to need to be a lot of LE work done if people are expecting the RPi 4 to play pretty much everything and get reasonably correct results on all display types. That will require handling just about about every possible color space conversion, HDR to SDR tone mapping, and who knows what else.

    Quote from Stereodude

    My understanding is that for HDR content there are flags in the HDMI stream to indicate the color space. I think that takes care of 709 and 2020 for folks with a HDR capable display. The source doesn't have to do any conversions, just enable the right flags in the output. I'm not sure how 601 is handled.

    There's going to need to be a lot of LE work done if people are expecting the RPi 4 to play pretty much everything and get reasonably correct results on all display types. That will require handling just about about every possible color space conversion, HDR to SDR tone mapping, and who knows what else.

    It's true about gamut flagging in HDMI Infoframes - but that doesn't alter the upstream requirement to ensure you use the right YCrCb relationships.

    Annoyingly YCrCb are different in all three ITU standards (601, 709 and 2020)

    In Rec 601 : Y = 0.299R + 0.587G + 0.114B

    In Rec 709 : Y = 0.2125R + 0.7152G + 0.0722B

    In Rec 2020 :Y = 0.2627R + 0.678G + 0.0593B

    As you can see - the YCrCb values for each standard are derived totally differently (ignoring the differences in their primaries and gamut). If you just leave YCrCb untouched you can cause carnage. SD content is expected to be in Rec 601, HD content is expected to be in Rec 709, UHD content is expected to be in SDR Rec 709, SDR Rec 2020 (rarer) or HDR Rec 2020 (widespread)

    Looking at the EDID dump shows that 60hz modes are 420. I also confirmed this w/ the manufacturer (Visio) who unsurprisingly suggested I buy a new TV. The max pixel clock of 300mhz doesn't seem to allow 60hz 422.

    On the topic of colorspace the Pi does playback HEVC HDR Rec2020 but the colors are very muted and the black level / gamut is wrong. There is significant frame dropping on high bitrate (~120mbps) files.


    Vizio m50 c1 edid

    LibreELECpi:~ # edidparser edid.dat

    Enabling fuzzy format match...

    Parsing edid.dat...

    HDMI:EDID version 1.3, 1 extensions, screen size 110x62 cm

    HDMI:EDID features - videodef 0x80 !standby !suspend active off; colour encoding:RGB444|YCbCr422; sRGB is not default colourspace; preferred format is native; does not support GTF

    HDMI:EDID found monitor name descriptor tag 0xfc

    HDMI:EDID monitor name is M50-C1

    HDMI:EDID found monitor range descriptor tag 0xfd

    HDMI:EDID monitor range offsets: V min=0, V max=0, H min=0, H max=0

    HDMI:EDID monitor range: vertical is 25-76 Hz, horizontal is 15-140 kHz, max pixel clock is 300 MHz

    HDMI:EDID monitor range does not support GTF

    HDMI:EDID found preferred CEA detail timing format: 3840x2160p @ 30 Hz (95)

    HDMI:EDID found CEA detail timing format: 1920x1080p @ 60 Hz (16)

    HDMI:EDID established timing I/II bytes are 20 00 00

    HDMI:EDID found DMT format: code 4, 640x480p @ 60 Hz in established timing I/II

    HDMI:EDID standard timings block x 8: 0xD1C0 D1FC 0101 0101 0101 0101 0101 0101

    HDMI:EDID found DMT format: code 82, 1920x1080p @ 60 Hz (16:9) in standard timing 0

    HDMI:EDID unknown standard timing 1920x1080 @ 120 Hz aspect ratio (16:9)

    HDMI:EDID parsing v3 CEA extension 0

    HDMI:EDID monitor support - underscan IT formats:no, basic audio:yes, yuv444:yes, yuv422:yes, #native DTD:1

    HDMI:EDID found CEA detail timing format: 1920x1080p @ 60 Hz (16)

    HDMI:EDID found CEA detail timing format: 1280x720p @ 60 Hz (4)

    HDMI:EDID found CEA format: code 2, 720x480p @ 60Hz

    HDMI:EDID found CEA format: code 3, 720x480p @ 60Hz

    HDMI:EDID found CEA format: code 5, 1920x1080i @ 60Hz

    HDMI:EDID found CEA format: code 16, 1920x1080p @ 60Hz (native)

    HDMI:EDID found CEA format: code 4, 1280x720p @ 60Hz

    HDMI:EDID found CEA format: code 32, 1920x1080p @ 24Hz

    HDMI:EDID found CEA format: code 63, 1920x1080p @ 120Hz

    HDMI:EDID found CEA format: code 93, 3840x2160p @ 24Hz

    HDMI:EDID found CEA format: code 95, 3840x2160p @ 30Hz

    HDMI:EDID found CEA format: code 100, 4096x2160p @ 30Hz

    HDMI:EDID found audio format 2 channels PCM, sample rate: 32|44|48 kHz, sample size: 16|20|24 bits

    HDMI:EDID found audio format 6 channels AC3, sample rate: 32|44|48 kHz, bitrate: 640 kbps

    HDMI:EDID found HDMI VSDB length 13

    HDMI:EDID HDMI VSDB has physical address 5.0.0.0

    HDMI:EDID HDMI VSDB supports AI:no, dual link DVI:no

    HDMI:EDID HDMI VSDB deep colour support - 48-bit:no 36-bit:yes 30-bit:yes DC_yuv444:yes

    HDMI:EDID HDMI VSDB max TMDS clock 300 MHz

    HDMI:EDID HDMI VSDB does not support content type

    HDMI:EDID HDMI VSDB supports extended resolutions 1,3,4

    HDMI:EDID extended data block tag YCbCr420VideoData - length 3

    HDMI:EDID Disabling mode 97 as YUV420 only

    HDMI:EDID Disabling mode 102 as YUV420 only

    HDMI:EDID adding mandatory support for CEA (1) 640x480p @ 60Hz

    HDMI:EDID filtering formats with pixel clock unlimited MHz or h. blanking unlimited

    HDMI:EDID best score mode initialised to CEA (1) 640x480p @ 60 Hz with pixel clock 25 MHz (score 0)

    HDMI:EDID best score mode is now CEA (1) 640x480p @ 60 Hz with pixel clock 25 MHz (score 61864)

    HDMI:EDID best score mode is now CEA (2) 720x480p @ 60 Hz with pixel clock 27 MHz (score 66472)

    HDMI:EDID CEA mode (3) 720x480p @ 60 Hz with pixel clock 27 MHz has a score of 66472

    HDMI:EDID best score mode is now CEA (4) 1280x720p @ 60 Hz with pixel clock 74 MHz (score 3635592)

    HDMI:EDID DMT mode (4) 640x480p @ 60 Hz with pixel clock 25 MHz has a score of 18432

    HDMI:EDID CEA mode (5) 1920x1080i @ 60 Hz with pixel clock 74 MHz has a score of 149416

    HDMI:EDID best score mode is now CEA (16) 1920x1080p @ 60 Hz with pixel clock 148 MHz (score 4898248)

    HDMI:EDID CEA mode (32) 1920x1080p @ 24 Hz with pixel clock 74 MHz has a score of 124532

    HDMI:EDID CEA mode (63) 1920x1080p @ 120 Hz with pixel clock 297 MHz has a score of 149416

    HDMI:EDID DMT mode (82) 1920x1080p @ 60 Hz with pixel clock 148 MHz has a score of 149416

    HDMI:EDID CEA mode (93) 3840x2160p @ 24 Hz with pixel clock 297 MHz has a score of 423130

    HDMI:EDID best score mode is now CEA (95) 3840x2160p @ 30 Hz with pixel clock 297 MHz (score 5771496)

    HDMI:EDID CEA mode (100) 4096x2160p @ 30 Hz with pixel clock 297 MHz has a score of 273831

    HDMI0:EDID preferred mode remained as CEA (95) 3840x2160p @ 30 Hz with pixel clock 297 MHz

    HDMI:EDID has HDMI support and audio support

    edidparser exited with code 0

    LibreELECpi:~ #

    Quote from doof

    Looking at the EDID dump shows that 60hz modes are 420. I also confirmed this w/ the manufacturer (Visio) who unsurprisingly suggested I buy a new TV. The max pixel clock of 300mhz doesn't seem to allow 60hz 422.

    On the topic of colorspace the Pi does playback HEVC HDR Rec2020 but the colors are very muted and the black level / gamut is wrong. There is significant frame dropping on high bitrate (~120mbps) files.

    Yes - there are a number of HDMI 2.0 displays that only support the lower bandwidth modes - which mean they are 4:2:0 only for 2160p50 and above. They aren't currently compatible with the Pi 4B (and I don't think the Pi developers were that hopeful about future 4:2:0 output support as it requires more processing)

    And yes - the Pi plays HEVC stuff fine. In playback terms - the HEVC is 4:2:0 YCrCb compressed video - the Rec 2020 vs Rec 709 doesn't alter how HEVC encoding and decoding work hugely - they are just metadata flags. HOWEVER if you play back HEVC Rec 2020 PQ HDR (i.e. HDR10 ST.2084) stuff flagged as Rec 709 and SDR (i.e. BT.1886 or 2.2-2.4 power law gamma) you will end up with incorrect RGB primaries (Rec 2020 is a wider colour gamut) and very 'flat' dynamic range (which will also desaturate more).

    I had a quick play with libreelec, and some 4k content.

    When it boots up, the resolution is 3840x2160 (which is fine for testing). However, when playing some sample 4k content downloaded from here (Sony: Swordsmith HDR UHD 4K Demo | 4K Media), it seems to be trying to play it back at 4096x2160.

    This has two side effects:

    • The video itself is over-scanned, so is cropped
    • When returning to the libreelec ui, it too is cropped - needs a restart to return to normal

    Is this a know issue? The TV is a panasonic oled, which is native 3840x2160

    Do we know if 4K 60 FPS will require overclocking for good (heat issues) or are there some firmware improvements coming for it to work without overclocking?

    Quote from lordvader

    I had a quick play with libreelec, and some 4k content.

    When it boots up, the resolution is 3840x2160 (which is fine for testing). However, when playing some sample 4k content downloaded from here (Sony: Swordsmith HDR UHD 4K Demo | 4K Media), it seems to be trying to play it back at 4096x2160.

    This has two side effects:

    • The video itself is over-scanned, so is cropped
    • When returning to the libreelec ui, it too is cropped - needs a restart to return to normal

    Is this a know issue? The TV is a panasonic oled, which is native 3840x2160

    Have you whitelisted just the 3840x2160 modes? I never whitelist the 4096x2160 modes.

    When I first booted LibreElec connected to my Sony UHD TV (which supports 4096x2160 and 3840x2160 inputs but is 3840x2160 native) it started in 4096x2160/24p mode (with a cropped UI - and slightly washed out picture) However once I whitelisted only 720p, 1080p and 3840x2160p modes, everything is OK.

    I have Libreelec running on a Pi4 with a DVB hat fitted. I enabled TV headend and from my desktop PC the channels are working fine.

    On the actual Pi I can see all the channels and the video is fine but the sound is out of sync. Any ideas please?

    PS thanks for all the great work on this :)

    Quote from ChrisCwmbran

    I have Libreelec running on a Pi4 with a DVB hat fitted. I enabled TV headend and from my desktop PC the channels are working fine.

    On the actual Pi I can see all the channels and the video is fine but the sound is out of sync. Any ideas please?

    PS thanks for all the great work on this :)

    I believe you need to apply this fix from Popcornmix:


    For the stuttering reports there is a fix. Either wait for the next LE update or grab firmware from here:

    start4.elf?raw=true

    fixup4.dat?raw=true

    rename and replace http://start.elf/fixup.dat on the FAT partition of sdcard.

    Thank you. Even though I wasn't seeing any stuttering that does seem to have fixed the issue.

    I also had the CEC crash on startup and as suggested swapping the cable to the other HDMI connector fixed it.

    Thank you!

    • Official Post
    Quote from ChrisCwmbran

    I have Libreelec running on a Pi4 with a DVB hat fitted. I enabled TV headend and from my desktop PC the channels are working fine.

    On the actual Pi I can see all the channels and the video is fine but the sound is out of sync. Any ideas please?

    PS thanks for all the great work on this :)

    Please create a new thread: in Forum

    Include country of origin and log files:

    Please provide a full debug log.

    How to post a log (wiki)

    1. Enable debugging in Settings>System Settings>Logging
    2. Restart Kodi
    3. Replicate the problem
    4. Generate a log URL (do not post/upload logs to the forum)

    use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link

    I did initial testing on a RPi4 with RPi DVB Hat and TVH and didn't see any issues.

    I think the default firmware shipping with the LibreElec alpha does have some issues with h.264 streams - but the revised firmware posted elsewhere in this thread fixed those for me.