Raspberry Pi 4B and LibreELEC 10.0: Not so "great" after all ?

    My biggest gripe with RPi4 is a lack of hardware VC-1 decoding which no release of LE is able to fix. I've seen people claim it's a niche format which it is except it's standard for Blu-ray movies and is actually quite common especially among early releases. I wonder if software playback without framedrops is feasible with CPU overclock.

    Quote from chewitt

    Software optimisation for HEVC is unlikely to be reimplemented as it was. Most of the tricks required will be hard to upstream and this time around (after 9+ years of learning the hard-way what it means to maintain downstream forks) the goal for the Pi Foundation is to upstream everything. I'll never say it will be never be done, but I think it's unlikely and best case, it's going to take a large effort over a long period of time to happen .. by which time a large percentage of users will have upgraded to new hardware.

    Out of curiosity what kind of optimization are we talking about? Decoding stuff in kernel?

    Quote from doubleP

    My way was a very long way with the RPI4 and libreelec. But now it works. I have 2 55" TVs from Sony with a RPI 4. All working flawlessly with 4K content with HDR.

    Hey that's a nice setup you have there. Considering that typical 4K HDR content is encoded with 10 bit color depth and that current LE release supports only 8 bits and trims the extra bits, have you experienced any trouble with that?

    Quote from gibbon

    My biggest gripe with RPi4 is a lack of hardware VC-1 decoding which no release of LE is able to fix. I've seen people claim it's a niche format which it is except it's standard for Blu-ray movies and is actually quite common especially among early releases. I wonder if software playback without framedrops is feasible with CPU overclock.

    VC1 plays fine with software decoding which is why the Pi Foundation designers haven't bothered adding an IP block in hardware for it since the original RPi and RPi2 boards (which had weaker CPUs and needed it). It's the same for MPEG4 and a bunch of other codecs.

    Quote from gibbon

    Out of curiosity what kind of optimization are we talking about? Decoding stuff in kernel?

    RPi0/1/2/3 have no hardware decode capability for HEVC but this emerged as a more popular codec. The Pi devs used compute capabilities on the GPU (not the ARM CPU) to assist the software decoding process. It adds just-enough compute headroom on RPi3/3B/3B+ to handle lower-bitrate 1080p, as used with streaming services like Amazon/Netflix. It works, but there are no public APIs to handle this kind of thing in FFMpeg so it requires a bunch of proprietary code. That code and the optimisation tricks it contains depends heavily on the workflow of the video output pipeline; which is the bit that has been completely reinvented with the move to GBM/V4L2.

    Quote from gibbon

    Hey that's a nice setup you have there. Considering that typical 4K HDR content is encoded with 10 bit color depth and that current LE release supports only 8 bits and trims the extra bits, have you experienced any trouble with that?

    None. Current 8-bit output works fine and the majority of users won't be able to tell the difference once 10/12-bit output is supported (it is being worked on).

    Quote from gibbon

    Hey that's a nice setup you have there. Considering that typical 4K HDR content is encoded with 10 bit color depth and that current LE release supports only 8 bits and trims the extra bits, have you experienced any trouble with that?

    Hi gibbon,

    sorry if I explained it wrong. I have 2 Sonys working on 2 RPI 4. A new Sony in my master bed room and the old Sony in my guest room. Both work fine. And no, I have no problems at all. Do I see a difference in the playback between my UHD HDR Player and the same movie as a mkv? Not much. That does not bother me at all. For my BenQ I have a modified colour profile against the washed out colours. That helps alot.

    Can I watch movies in a user-friendly way from one NAS in my home .... I can. Can my girlfriend listen to her audiobooks and audio dramas from one NAS in my home .... She can (high WAF .... women acceptance factor).

    Can the picture and sound quality be better? Of course it can. It always can get better. But I don't want to buy a Sony OLED-8K-X1.

    For me it is the price-perfomance balance what makes it all damn good.

    A wonderful start in a new week to all of you ..... and for the motivation ..... it is the last monday this week

    Quote from gibbon

    My biggest gripe with RPi4 is a lack of hardware VC-1 decoding which no release of LE is able to fix.

    Yup. VC1 just doesn't work well on Libreelec/Kodi at all. I've basically given up with it and use Handbrake to recode any VC-1 to X264/X265 and that fixes the issue. Its a simple enough process to do, just take a bit of time.

    Hi chewitt

    Hope you are chillin'

    I have a long standing problem with my LibreElec 10.0. RPi4B and getting 4k 60hz on my Panasonic UHD TV (meaning I've mostly given up) via my Amp. I was rather hoping to watch Dune in glorious HDR

    I have enabled 4k60 and this displays as expected on the single HDMI port if connected direct to the TV. But if I connect this via my Yamaha UHD compatible Amp it fails to passthrough to the TV. (The UHD YouView box connects in this way just fine. Yamaha support claim this is likely to be an HDCP issue.) Is this one of those EDID handshaking issues that still seem to be around?

    A further issue arose with HEVC content last night - failed to play Audio (no alternate offered in settings) had to watch it on the Laptop...

    Am I missing something?

    Thanks

    Brian

    What flavours of 4K60 does your Yamaha amp handle?

    Some amps can only carry 2160p30 and below, some can only carry 2160p50 and above in 4:2:0 mode (which the Pi 4B doesn't support), whilst others will support 4:4:4/RGB 8-bit and/or 4:2:2 12-bit at 2160p50 and above.

    At the moment I think the Pi will only output 8-bit RGB and 4:4:4 - though there is hope for 4:2:2 12-bit (but it's not with us yet AFAIK)

    Chance are your YouView box is 4:2:0 2160p50 (which was a kludge added to HDMI 2.0 that squeezed 4K50/60 into the bandwidth required for HDMI 1.4 - allowing HDMI 1.4 hardware to be 'upgraded' to HDMI 2.0 - which nVidia GPUS and early Sony UHD TVs exploited to allow 2160p50 support with HDMI 1.4 bandwidth hardware.) and your Yamaha is happy with that.

    Your Yamaha may not be happy with the RGB/4:4:4 output by the Pi 4B - which is higher bandwidth. (You may find there is an option in your Yamaha to enable 'Enhanced HDMI' (though this is usually for 4:2:2 it may also enable RGB/4:4:4 compatiblity)

    It's unlikely to be HDCP (the Pi doesn't use it) - it's more likely to be HDMI flavour. The lack of 4:2:0 compatibility on the Pi 4B (which is the only form of 2160p50/60 supported on some hardware) has caught a few people out. I think I read that the issue with 4:2:0 is that the GPU can't subsample chroma in both X and Y dimensions (which is required for 4:2:0 output), and can only do it in one dimension (required for 4:2:2)

    4:4:4/RGB 8-bit and 4:2:2 12-bit are the only two HDMI flavours supported at all 2160p frame rates ISTR. (4:2:0 can't be used for 2160p30 and below, and 4:4:4/RGB 10-bit and above can't used for 2160p50 and above)

    Edited once, last by noggin (October 26, 2021 at 3:11 PM).

    OK, so taking the outputs questions:
    The (DTR t4000 Humax/BT) UHD YouView box, I have only seen [3840x]2160p 50Hz as an input on the TV. On the box settings it offers UHD 50fps 8 bit or 10 bit
    As far as the Yamaha Amp RX-V581 is concerned - it has two HDMI modes:

    Selects the format of signals input/output at the unit when HDMI 4K (60 Hz/50 Hz)
    compatible TV and playback device are connected to the unit.

    MODE 1
    Inputs/outputs 4K (60 Hz/50 Hz) signals in 4:4:4, 4:2:2 or 4:2:0 format.
    Depending on the connected device or HDMI cables, video may not be
    displayed correctly. In this case, select “MODE 2”.
    MODE 2
    Inputs/outputs 4K (60 Hz/50 Hz) signals in 4:2:0 format.
    Note
    When “MODE 1” is selected, use a high-speed HDMI cable that supports 18 Gbps. (this is the mode selected, in Mode 2 the YouView box is not recognised as a UHD device)

    Edited 3 times, last by BrianM (October 26, 2021 at 4:59 PM).

    ...oh, and incidentally, couldn't agree more about HDMI Cables and their inability to perform. I bought a dozen, allegedly High Speed (incl "Ethernet") until I got Hologram certified.

    Edited once, last by BrianM (October 26, 2021 at 4:32 PM).

    MODE 1 doesn't list RGB support - maybe that is the issue. I don't know if the Pi switches from RGB to 4:4:4 YCbCr - I'd assumed it does but that may have been an error on my part.

    The fact that the YouView box isn't working with Mode 2 suggests it's running at a high bandwidth - probably 4:2:2 12-bit I would expect.

    Decent (not expensive) HDMI cables are required for 18Gbs (I swapped out all of my existing HDMI cables for the hologram premium certified stuff when I bought an 18Gbs AVR and UHD HDR TV)

    Quote from popcornmix
    Code
    Chroma subsampling                       : 4:4:4

    That's not supported (and is a very uncommon encoder setting).

    Yes - hardware acceleration of h.264/AVC and h.265/HEVC is limited to 4:2:0 on most platforms including the Pi (*) as 4:2:0 is the standard used for DVB TV, Blu-ray, UHD Blu-ray, Netflix/Prime/Apple/Disney etc. streaming services. (MPEG2 is the same in consumer terms - but the Pi 4B doesn't have hardware acceleration of that codec.)

    4:2:2 and 4:4:4 are not used in media aimed at consumer device playback, so are not supported on most mainstream platforms.

    (*) Apple devices DO support hardware accelerated decoding of 4:2:2 and 4:4:4 h.265/HEVC because modern iOS/iPadOS/tvOS/MacOS devices use HEVC/h.265 compression for their screen sharing platform and the subsampling of 4:2:0 would smudge fine chroma detail on desktop stuff. (My Apple TV is the only platform I've found that will replay 2160p50 4:2:2 h.265/HEVC video content with hardware acceleration. 4:2:2 is used in production, not final broadcast emission/streaming)

    Edited once, last by noggin: Merged a post created by noggin into this post. (October 27, 2021 at 9:18 AM).

    Issues with HDMI YCbCr conversion - Raspberry Pi Forums

    Tue Oct 16, 2018 10:55 pm

    Runing Kodi, you might check:

    Code: Select all

    Code
    tvservice -s

    And so you get the current configuration.

    Possible options configuring config.txt

    Code: Select all

    Code
    hdmi_pixel_encoding=0 default (limited for CEA, full for DMT)
hdmi_pixel_encoding=1 RGB limited (16-235)
hdmi_pixel_encoding=2 RGB full ( 0-255)
hdmi_pixel_encoding=3 YCbCr limited YCbCr 4:2:0 Y=16-235 (ITU-R BT.709)
hdmi_pixel_encoding=4 YCbCr full YCbCr 4:4:4 Y=0-255

    With connection via Yamaha Amp or direct to TV, I get:

    ##############################################

    # LibreELEC #

    # https://libreelec.tv #

    ##############################################

    LibreELEC (official): 10.0.0 (RPi4.arm)

    LibreELEC:~ # tvservice -s

    state 0x120001 [TV is off]

    Also - output to TV direct from Pi @ 3840x2160 has now disappeared and a whole set of minor changes in 10.0.0 mean I cannot set refresh rate separately :(

    Stupid question - but which HDMI output from the Pi are you using - the one closest to the USB Type-C power connector?

    Also checking that you switch devices on in this order :

    1. TV

    2. AVR

    3. Raspberry Pi

    If you switch them on in a different order the Pi won't get the full EDID from both the TV and AVR (the AVR will add its EDID to the TV's or replace it)

    YCbCr output isn't implemented in the graphics driver yet, so output will always be RGB 4:4:4, 8bit ATM.

    The hdmi settings in config.txt won't have any effect and tvservice is also obsolete - newer tvservice versions will now show a warning instead of printing confusing and wrong info like "TV is off"

    Code
    LibreELEC:~ # tvservice -s
tvservice is not supported when using the vc4-kms-v3d driver.
Similar features are available with standard linux tools
such as modetest from libdrm-tests.

    "modetest" is included in LibreELEC and will show you what modes are available, the EDID read from the TV/monitor, output properties etc.


    so long,

    Hias