Posts by noggin

    Yep, fixed it for me, TV was unwatchable with interlacing enabled - juddering and out of sync mess. Rpi4 + TVHeadend. Switched to a totally different system (Xbian) because it was driving me nuts. Didn't make any sense at all that it could play a 160GB 4k video but not 1080i/480i TV. Tried three different PVR backends/frontend over the last few days!


    :thumbup::thumbup::thumbup::thumbup::thumbup:

    Worth remembering that h.264 and interlaced content are handled by totally separate parts of the Pi4B SoC to h.265/hevc. The h.264/interlaced stuff is decoded and deinterlaced by the legacy VPU that remains the same as the Pi 3B+ and before, whereas the hevc/h.265 decoder is a separate unit and handled separately. I believe some builds at the moment are not handling stuff particularly effectively using the old decoder?

    I still find it admirable that folks are persisting with these technically dead Intel platforms when there are fully functional ARM alternatives available, waiting for working HDR on x64 is like waiting for this pandemic to end.

    I guess the benefit of Intel in speed terms is worthwhile - I switched to AMLogic platforms as my main daily driver and miss the snappiness of my Intel boxes. That said - the Apple TV 4K SoC is a beast - it software decodes stuff that the other ARM platforms just choke on (38Mbs 1080i25 4:2:2 h.264 with deinterlacing is do-able on an ATV 4K in software)


    My understanding is that HDMI 1.4 audio has a max spec of 8 channels of 192kHz / 24 bit uncompressed PCM audio - which gives a max audio output bit rate of :


    8 x 192000 x 24 = ~ 36.9Mbs


    I guess any buffering for HDMI audio should be considering that as the top audio bitrate that HDMI can carry?


    My understanding is that 8 x 192 x 24 is also the spec that is required for lossless compressed HD Audio to be carried over HDMI - which is why the Raspberry Pi 3B+ and earlier can't carry HD Audio - as they could only carry 4 x 192 x 24 bit (or 8 x 96 x 24 bit) which doesn't guarantee enough bitrate for the peaks of HD Audio lossless compressed content (which may not compress hugely on very complex content?)


    Dolby True HD and DTS HD MA sound tracks are usually lossless compressed 8 channels at 48k 24 bit (some are 96k and a very small number are 192k) which gives an uncompressed bitrate of around 9Mbs (or 18Mbs if 96kHz is used), however releases like Akira can contain 6 channel 192k 24 bit tracks (and 8 channel is theoretically allowed).


    For very complex audio the lossless compression used by DTS HD MA and Dolby True HD may not deliver huge bandwidth savings - and if you add in Atmos and DTS:x data as well on newer tracks this will also increase the bitrate a bit I guess?

    I see no video quality issues. A "white haze" usually means incorrect black level.

    Yep - desaturated video levels also happen if YCbCr content is handled in the incorrect level space.


    'White Haze and Desaturated" can also describe HDR Rec 2020 content displayed incorrectly in SDR and/or Rec 709 level space without tone mapping.

    I think it was a "timing" problem more than anything else. Not long after Slice launched (late) RPi2 came along, and the lack of CM2 card meant the specs looked weak, and then RPi3 arrived to drive nails further into the coffin. CM3 eventually caught up, but that was some time later again and by that point the day-jobs of the "Five" had also multiplied via Pi success and the company they'd formed hadn't sold enough product volume to really be viable. These days the Pi Foundation owns the IP/designs, but while I think having them create/release an "official" HTPC box would be good for their own sales it would also put them into competition with their ecosystem in a negative way.. but I should ask Gordon anyway :)

    That all makes sense - the CM1 vs Pi 2 was very unfortunate timing - and the CM1 was just a little bit underpowered (though with the MPEG2 and VC-1 licences it was still a very capable HD and SD media player).


    ISTR there was an issue with the continued use of the original Slice skin in Kodi - but hadn't realised that the Pi Foundation now owned the IP and designs. I totally understand why the Pi foundation wouldn't want to compete with others in the ecosystem. However they do make the DVB-T2 HAT - and that integrated into a modern Pi 4-based Slice (once the HDR and HD Audio stuff is implemented) would be lovely.

    None of these after market cases really come close to looking as well designed as the Slice though :( - though the Argon cases are some of the nicest looking out there at the moment IMO.


    I think the Slice was very much a passion project from the developers - the fact it didn't evolve and continue to be manufactured suggests it didn't make that much money (and it was very much a premium product).

    Which tv box with Amg soc currently supports 4: 2: 2 H264 or H265 videos either by hardware or software? S922x?


    i tried a rpi4 and it doesn't work with 4: 2: 2 H264 or H265 videos


    Very few boxes support 4:2:2 video as it isn't a consumer format (DVD, DVB TV broadcasts, Blu-ray, UHD Blu-ray, Netflix, Prime etc. are all 4:2:0) so there is no reason to implement it in chipsets aimed at consumer devices.


    4:2:2 h.264/h.265 is only used by broadcasters on contribution circuits - not final-leg distribution - so unless you are building a box for feed hunters (a small market) 4:2:2 isn't really a 'must have' feature.


    None of the AMLogic chipsets that I am aware of support 4:2:2 hardware decode for this reason - so you need a box fast enough to decode it (and if it's interlaced also YADIF or W3DIF 2x deinterlace it) with CPU power.


    The only ARM media player platform that I know that can currently do software decode (and deinterlace) of 1080i25 for MPEG2 and h.264 4:2:2 is the Apple TV 4K (the ARM SoC in that is a beast)


    The other BIG advantage of the Apple TV 4K is that it has hardware acceleration support for 4:4:4 and 4:2:2 h.265/HEVC decode - because Apple use that codec for their Airplay/Sidecar iPad dual display function which compresses desktop video to h.265 for carriage over WiFi or Lightning/USB Type-C connection (to avoid reducing the chroma res to 4:2:0 and it all going smeary when you use your iPad as a second display) The Apple TV also has that functionality. I've played 2160p50 4:2:2 h.265/HEVC on the Apple TV in mrMC with very low CPU (but it was still not perfect because of some A/V sync issues)


    If you want MPEG2 and h.264 4:2:2 with LibreElec then a decent Intel or AMD solution is probably your best bet - I used to use a Haswell i5 NUC to play 4:2:2 stuff and it coped - just - once multithreaded software decode of h.264 was implemented in ffmpeg. However the LibreElec implementation seemed to do a 4:2:2 to 4:2:0 conversion without interlaced aware chroma decode/conversion so you had saturated areas deinterlaced with p25 rather than p50 motion (a known issue in ffmpeg)

    Also if you are running 4K then your audio extractor also needs to be 4K friendly - counterintuitive as this may seem. The reason for this is that HDMI audio is not carried separately to the video, it's actually embedded in the video signal (it's carried in the blanking period of the HDMI video signal where there isn't active video).


    If you are running a higher data rate video signal (4:2:2 2160p60 for instance) then your extractor also needs to support the higher bandwidth.

    As I have found them for 11€ a piece delivered, I ordered few. Using them for DVB-T2 h265 TV at RPi4 with all current LibreELEC 9.2.5.


    They work OOTB, just needed to be activated in TVh. They display DVB-T2 (channel 40, 626 mHz ) normally. No transport or continuity errors. Strangely, in TVh, PER and Uncorrected Blocks pop up. I have almost never seen that in many years of using several other tuners at any of my systems. Nothing visibly wrong with the picture; then again I have tested them for just a few hours. In this usage, lack of tuner's h265 support is not an issue as tuners just have to deliver a DVB-T2 stream, RPi4 will display it (h265). To use T2 channel, I had to manually change desired channel from T to T2 which may not be clear for many users.


    Same as MyGica T230 and T230C2, sync problems with sound being ahead of the picture when recording and changing channels, but that is an LE problem.


    Yep - the DVB-T/T2 tuner does no video decoding - so MPEG2, h.264/AVC, h.265/HEVC make no difference - it just sends the video streams to other devices to decode.


    The TV Headend DVB-T vs DVB-T2 setting can be confusing as not all tuners need it (The first gen DVB-T2 stick, the PCTV 290e, had a driver that automatically switched to T2 when you pointed it at a T2 mux and didn't need T2 to be explicitly defined in TV Headend for instance. Most newer sticks do need you to set the T vs T2 delivery system parameter)


    I had lots of errors on the PSB3 DVB-T2 stream in London - which is a 40.25Mbs DVB-T2 stream using 8MHz bandwidth, 256QAM and 32kE carriers with 2/3 FEC (aka DTG-6 mode) at 545.833MHz. They were visible.

    I've attempted to get audio passthrough working (with the latest nightly build) on the second hdmi port (HDMI 2) without success, the avr (Denon AVR-4308) is detected in libreelec however no audio is sent to the receiver (video is sent to HMDI 1 which is working), have I misunderstood the passthrough feature? Thank you

    I don't think there is any suggestion that you can take video from HDMI1 and audio from HDMI2 ?


    The HD Audio passthrough option adds the option for 1080p modes (but not 2160p?) to bitstream passthrough HD Audio codecs like Dolby True HD and DTS HD Master Audio and High Resolution Audio (sending the compressed bitstream to your AVR for your AVR to decode to PCM), whereas previously on the Pi they had been decoded in software within Kodi and output as PCM 5.1/7.1 (which apart from Atmos should be lossless - other than losing metadata that some downstream AVR processing may use for loudness control etc.)

    Also some TVs are not good at displaying the video resolution of the BIOS splash screen quickly enough for you to see the BIOS POST menu. PC monitors are often a bit better in this regard in my experience. Also in my experience cabled keyboards are often better than RF remote keyboards as BIOSs sometimes don't recognise the RF receivers quickly enough.

    Just a question ... HDR with PI 4 will come in future? I´m aware, nothing is final, but just on technical aspect it is possible and well get enjoying this feature?

    The Pi is capable of decoding 2160p 10-bit HEVC, and we're told the hardware supports output of 10-bit video with Infoframes to flag HDR and switch TVs into HDR mode. (These are the three things necessary for 'standard' HDR10 replay)


    HD Audio bit streaming (for HD video output) has been added recently to the Pi 4B+'s capabilities - so stuff is happening to develop the platform.


    If you want HDR now - then look at some other platforms (though these are using custom Kodi builds to enable HDR) - if you are prepared to wait then HDR support for the Pi 4B+ should happen at some point - but there is no real timeline in the public domain for when.


    One thing to be aware of is that if your TV only supports HDR UHD at 50/60fps at 4:2:0 the Pi 4B+ is not going to besuitable - as it can't output 4:2:0 (which is required for some TVs). There isn't that much 50/60fps HDR stuff - but BBC iPlayer is 50fps for UHD HDR streaming for instance.