Posts by noggin

    Apologies for necro-posting again - but I've been running both add ons listed here - KodiDisplayInfo (which uses web access to Kodi, but has far less advanced display functionality) and Kodisplay (which is the main topic of discussion here - but seems to be an internal add on only)

    The advantage of KodisplayInfo using web access is that the SPI display and display code can be running on a small and cheap Pi Zero W or similar and SPI display, independent of your Kodi platform - which could be anything that supports LibreElec, CoreElec or Android Kodi I guess - and the Kodi device itself doesn't need to have SPI support and the code to drive SPI or similar displays.

    The advantage of Kodisplay is that it has far, far more functionality and is far more extendible.

    A question to those who know - is all the functionality available to an add-on, in Kodi status terms, available to an IP connected device via IP calls (JSON? http?) allowing an external device to be set-up as a comprehensive second display?

    I've played with Frontvew+ on Windows on a little Windows tablet - and it also offers a lot of functionality - but doesn't quite do what I'd hoped.

    (My aim is to have a bit more detail than the OpenVFD/LCDProc or similar displays - so PVR Channel logo and programme name, time elapsed/left bar graph for Live TV, Album art for Music - along with track number, track title and album title, time elapsed/left, movie name and art along with time elapsed/left etc. on a 2-3" display, possibly even something bigger like a DPI-connected Hyperpixel?)

    Thanks for the prompt reply, Klojum. Makes sense, lightning symbol and all. Would never have thought so because I sent for the complete package from Amazon just so as I would get the proper PSU with it. Ah well, live and learn!

    That's just a bunch of bits that a third party re-seller has collected to sell as a bundle. It's not an official complete package, and chances are the USB PSU they're bundling isn't particularly good, and it's not capable of delivering the required current and voltage.

    I'd always recommend people to buy the Raspberry Pi official PSUs. They are good value and 'just work'.

    Only DD, DTS (and possibly DD+) passthrough is currently supported (same as original Pi models)

    The new Pi 4B hardware supports 8 channel 192KHz PCM (so full lossless decode of all Dolby True HD and DTS HD MA/HRA HD Audio tracks) - and should support HD Audio passthrough when the software / firmware is written to support it (which is needed for True HD + Atmos and DTS:x support)

    No timescale that I'm aware of. Until then it's lossless decode (which should be audibly the same unless your AVR does metadata driven processing - after all you're just moving the PCM decoding process from your AVR to your Pi - it has to happen somewhere in the chain)

    Hi, I tried to play something in DTS HD MA and i got it decoded to 5.1, but i got 7.1. Dolby Atmos Home Cinema. When i play something in Atmos it is decoded to weird formats like 3.1 Theatre Dimensional.

    My settings in audio are 2.0., enable passthrough and enabled formats under it like DTS, AC3 and E-AC3. This works for DTS-HD MA in most of the time. Weird thing is when i set 7.1 in audio setting I got a 5.1.2 sound in output which should be right, but my receiver getting no Atmos (there is a LED which should be lit if Atmos is detected (working in old box S905x).

    If you have a 7.1 speaker set-up - you want 7.1 not 2.0 enabled in your sound settings.

    Also if you want DTS HD MA and Dolby True HD to be losslessly decoded, you will need to disable DD and DTS passthrough, as otherwise I think it will bitstream passthrough the lossy DD/DTS core/secondary streams rather than decode the lossless DTS HD MA or Dolby True HD losslessly to PCM 5.1/7.1.

    You won't get Atmos until HD Audio bitstreaming/passthrough is supported on the Pi 4B - PCM lossless decode is only for Dolby True HD and DTS HD MA - not Dolby True HD with Atmos or DTS:x. (You may - possibly - get DD+ with Atmos - but that's not intentional and usually only used for secondary language audio streams on BD/UHD BD)

    If you must have Dolby True HD with Atmos, the Pi 4B isn't currently for you.

    However if you want the best quality audio possible with a Pi 4B currently - disable passthrough, configure for 7.1 if you have 7.1 speakers (i.e. Front R,L, Centre, Side R, L and Rear R, L + Sub) or 5.1 if you have 5.1 speakers (note I'm ignoring 7.1.2. or 5.1.2 Atmos in this - if you have 7 speakers but 5.1.2 then configure for 5.1, if you have 9 speakers in 7.1.2 then configure for 7.1)

    Sorry - yes - people are absolutely right - it is MPEG2 not h.264 4:2:2. I can't think why I jumped to that conclusion as I opened it in MediaInfo. It's probably because I assumed it was recent - and I don't know of anyone in broadcast in the UK still using MPEG2 rather than h.264 for broadcast uplinks (as it's basically a waste of bandwidth to use MPEG2 these days)

    That's a broadcaster uplink feed (31Mbs 4:2:2 h.264 video with 384k MP2 stereo audio) not aimed at consumers.

    Consumer video (DVB/ATSC/ISDB, DVD, Blu-ray and UHD Blu-ray) is 4:2:0 - and that's what consumer devices have hardware acceleration for. As a result consumer devices - set top boxes, PC GPUs (**), ARM SoCs designed for consumer media playback etc. don't support it in hardware.

    4:2:2 is only used in the broadcast/professional environment - and you need a broadcast/professional device to decode it with hardware acceleration (*).

    For h.264 4:2:2 decode on a consumer device you need something with the CPU power to support software decoding (and probably software deinterlacing if the source material is 1080i25) This puts you in the Intel/AMD camp for realtime playback - not consumer ARM SoCs.

    If you want to watch this stuff on a Pi - you will need to transcode to 4:2:0. If you want to retain chroma resolution then 4:2:2 1080i25 -> 4:2:0 1080p50 may be your best route. (ffmpeg with a -vf "w3fdif=complex:all" deinterlace is my go to for that when converting broadcast 4:2:2 sources - h.264/ProRes/DNX/AVCi100 etc. to h.264 or h.265 4:2:0 consumer video)

    Personally I usually do this from the command line rather than in handbrake as I found handbrake would often deinterlace 1080i25 to 1080p25 not 1080p50 (and thus threw away 50% of the temporal - i.e. motion - resolution)

    (*) When MPEG2 4:2:2 was used for satellite uplink, a couple of oddball consumer devices did have unadvertised 4:2:2 MPEG2 decoding (one version of the WDTV Live did it I discovered). However I've yet to find any consumer devices with unadvertised 4:2:2 h.264 decode.

    (**) Some Non linear editors like FCPX, Prem Pro etc. will support GPU accelerated decode within their workflow - but this is bespoke within those packages.


    I haven't tested it yet, but big thumb up for no tearing GUI, if it's true.

    Did someone tested if HBR audio is fully supported (DTS HD MA and Dolby Atmos)?. That's what I want so bad on my RPi4. My home theatre just crying.

    DTS HD Master Audio is losslessly decoded to PCM 5.1/7.1 (and the Pi4B supports 192k/24bit at 5.1/7.1 and isn't limited to 4.0 at 192k as previous models are, I believe) - so it's only Atmos that your Home Theatre is crying for? (Or is stream metadata vital for your use case??)

    It looks like the OP should DISABLE 4kp60 in config.txt as the receiver specs confirm that it only supports 4:2:0 video at 2160p50 and above which the Pi doesn't output (at least currently - and probably won't)

    If 4KP60 output is disabled in config.txt the Pi will output up to a max 4K30 output - which the receiver should be compatible with.

    What happens if you run the Pi with 4Kp60 disabled?

    Yes - 2160p50 and 2160p59.94/60 support on some AVRs and TVs is limited to 4:2:0 which is a format the Pi 4 doesn't support (4:2:0 is only an HDMI standard for 2160p50 and above)

    Your Pi 4B will output RGB (which is the same bandwidth as 4:4:4) 8-bit at 2160p50 and above - not all AVRs and TVs support this.

    (4:2:0 8-bit support for 2160p50 and above was added to the HDMI 2.0 spec so that HDMI 1.4b hardware could be used to carry a 2160p50 and above signal - as the bandwidth just squeaks into HDMI 1.4b hardware limits. This was a way for manufacturers to 'upgrade' existing hardware that was HDMI 1.4b only to support HDMI 2.0. Just. However 4:2:0 is the only HDMI output spec that requires both horizontal AND vertical chroma subsampling - and the Pi doesn't support vertical subsampling - only horizontal - AIUI)

    I've just installed the latest Public Alpha Release (not a nightly) and my Pi4B CEC works fine from a Sony XF9005 and Denon AVR X2400H if I start the Pi whilst the TV and AVR are both routed to the Pi. TV Remote controls Pi, Pi controls Denon volume.

    However if I switch away from the Pi 4 routed through my AVR to another HDMI input on my TV (not my AVR) - where my TV will automatically switch the Denon AVR to ARC Audio - and then switch back to the AVR HDMI input (and the AVR switches back to the Pi 4B input on the AVR), the CEC control from the TV has stopped working, but the CEC control of the Pi4B to the AVR continues to work.

    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?