Posts by noggin

    Looking at that last post, I have a question. Is this the same as the official firmware that is supposed to lower the voltage and temps of the pie?


    I think this is where people are getting confused.


    The above is the firmware for the VideoCore I believe - the same type of firmware as was used by previous Pis. This firmware is loaded on boot every time and handles a lot of the Pi's configuration and operation - specifically for the SoC.


    The firmware that is being discussed that reduces temperatures a little (by reducing the temperature of the PCI-E->USB3.0 bridge) is firmware specifically for the USB 3.0 bridge device - and this is stored in separate EEPROM (I think) and not loaded each boot.


    This is just firmware for the VL805 PCI-E->USB 3.0 bridge isn't it? This is reported to reduce average idle temps by ~3C.


    However there are reports that it reduces compatibility with some USB 3.0 devices - so it's worth being aware of that.


    (The reason I make the point about it being USB3.0 firmware only is because there is another 'firmware' for the PI 4B - similar to the previous firmwares - that is loaded to the VideoCore before fully booting, which has also been updated to resolve frame drops on video content that played fine on previous Pi models - such as 1080p and 1080i h.264)


    It's not just high bitrate h.265/HEVC stuff that is stuttering.


    The 36Mbs Wimbledon 2160p50 h.265/HEVC iPlayer stream is dropping frames continuously (according to the CTRL+SHIFT+O overlay). 36Mbs is a reasonably modest bitrate for 4K50 stuff - but I guess with twice as many frames to process each second, 2160p50 is going to be more challenging than 2160p23.976 (which is what 4K movies will be running at)


    The 17Mbs 1440p50 h.265/HEVC iPlayer stream seems to be pretty solid.

    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.

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

    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)

    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?

    Neither 4:2:2 nor 10-bit h.264 video are supported with hardware decode on the Pi (or any other ARM SoC AFAIK (*)), and as they are a very rare formats (4:2:2 is pro-territory only) even software support (which it's unlikely the Pi 3B/3B+ will have the grunt to achieve) is unlikely to be be successful.



    (*) Surprisingly the newer Rockchips support 4:2:0 10-bit h.264 hardware decode - but I don't think 4:2:2 support is there.

    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)


    Have you got the correct HDMI modes whitelisted AND enabled the refresh change on Start / Stop in the Player settings?


    I mainly watch 50Hz content and have my GUI set for 50Hz (to avoid re-syncs where possible) - but will check 23.976 or 59.94 stuff when I get a chance later today.

    I'm trying to get 60hz playback but LE doesn't show a 60hz option. The config seems to be read properly and my rockpro64 running LE using the same cable and port runs @ 60hz.

    Code
    1. LibreELECpi:~ # cat /proc/device-tree/model
    2. Raspberry Pi 4 Model B Rev 1.1 LibreELECpi:~
    3. #LibreELECpi:~ # vcgencmd get_config hdmi_enable_4k
    4. hdmi_enable_4k=1

    Polling the device doesn't show a 60hz UHD mode on RPI

    How can I enable 60hz UHD on my RPI?


    AIUI the Pi 4B doesn't support 2160p50-60 4:2:0 modes - so if your display only supports them - you're likely to be out of luck?


    4:2:0 was introduced to HDMI 2.0 specs to reduce the bandwidth required (bringing the 8-bit 4:2:0 2160p50-60 modes within HDMI 1.4b bandwidths avoiding a requirement for HDMI 2.0 full bandwidth support on some 'HDMI 2.0' TVs).


    My Sony TV has to have high-bandwidth HDMI 2.0 modes enabled (it's called 'Enhanced' on Denon and Sony) - and even then only 2 of the 4 HDMI inputs on my Sony UHD TV support the higher bandwidth ports - which are required for non-4:2:0 2160p50-60 inputs.


    My Pi 4B currently runs 2160p60-60 at RGB 8-bit - and I believe 4:2:2 is supported or will be. However 4:2:0 output requires vertical chroma subsampling as well as horizontal subsampling (4:2:2 is horizontally subsampled only) and I think I read one of the Pi devs comment that may be tricky for the Pi to implement?


    In other words - 2160p50-60 isn't supported by the Pi in all HDMI 2.0 flavours.


    Yes - confusingly the hdmi_enable_4k isn't needed to enable all 4K modes (4K24-30 is enabled without it) - it just enables the 4K50-60 modes...


    Without 4K60 enabled (which is an HDMI 2.0 mode)you are effectively running with a max of 4K30 (which is potentially an HDMI 1.4b mode in SDR)


    Movies and drama TV shows are traditionally 24-25p so will play with no obvious difference without 4K60 being enabled. However any live TV sport or entertainment (BBC iPlayer is carrying Wimbledon in 4K50 at the moment) will most likely be 50 or 60 - and the UI will look smoother in 50 or 60.

    I just need to figure out how much clearance above the fan shim I'll need for the TV HAT and how to bodge the Pimoroni Pibow case to fit it all (the case bolts won't be long enough).


    Phil

    Pimoroni used to sell extra slices for Pibow cases to let you make them HAT-friendlier. Not sure if they still do? They are usually pretty helpful via email (though a lot busier these days!)

    I think Da Flex is talking about getting the Raspberry Pi to decode DD+ to PCM in the Pi, whereas Novalis wants passthrough/bitstreaming, where the DD+ bitstream is passed, untouched, from the Pi to the AVR for the AVR to decode?


    Both are valid approaches for non-Atmos content, and the 'decode to PCM' is the only approach for the Pi 3B+ and below for Dolby True HD and DTS HD MA (which the Pi traditionally can't bitstream *), whereas the Pi can bitstream/passthrough DD and DTS. It seems some have reported success with DD+ bitstream/passthrough.


    (*) The Pi 4B supports 8 channel 192kHz over HDMI which means it should allow HD Audio passthrough (the previous generation of Pis only had enough bandwidth for 4 channel 192kHz so couldn't)

    Yeah, but as far as I know H.264 HW decode is limited to [email protected] and I want to use 4K content, so :(

    Or I'm wrong?


    PD: sorry for the off-topic hehehe


    My understanding is that the hardware decode of non-HEVC stuff is basically near-identical to previous Raspberry Pi models - with the new HEVCv2 4:4:4 4096x4096 decode capabilities added separately, so performance with h.264 will be the same as previous models.


    I guess the approach the Pi developers have taken is to maximise compatibility (by adding new functionality without replacing the elements that were present in previous Pis?)