Posts by noggin

  • RPi4 testbuild with HDR support

    Quote from marantz

    is there a way to alter the brightness of subtitles only when watching HDR? in a dark room its almost impossible to have subtitles enabled.

    thanks for any help

    I think this is tied into the lack of support for SDR-in-HDR rendering. Same reason the GUI overlays are very bright when playing HDR content.

    I guess the issue is that with SDR content you might have subtitles set for something like peak-white (level 240 in 8-bit decimal) but in HDR10 PQ this would be massively into the HDR range, close to 1000nits - whereas SDR peak white is just 100nits).

    A stop-gap would be to have two or three different subtitle 'colours' for SDR, HDR10 and HLG content - or a real interim would be to chose a much darker grey for subtitles (though this would make them more difficult to read on SDR content I guess)?

  • RPi4 testbuild with HDR support

    Quote from onlyrock

    It appears that most if not all of my HDR10 videos get sent to my receiver using 12bit color. I think the builds prior to 2021.12.18 would send them as 8bit, as I detailed above.

    I thought HDR10 used 10bit color. Is that correct? If so, is there a reason LE outputs them as 12bit?

    UHD HDR10 content is encoded as 2160p (aka 4K) 4:2:0 YCbCr 10-bit with Rec 2020 colour gamut and using the h.265 codec typically.

    When HDR support first arrived on the Pi 4B in LibreElec, HDR10 content was replayed with the 10-bits truncated to 8-bit (losing the lowest 2 LSBs), and output in RGB. This meant that the two lowest bits were truncated which would mean a lower quality picture was being delivered.

    (I think some dither noise may have been added to reduce the visibility of the banding this would introduce on 10-bit capable displays - or those that simulate 10-bits with 8bit panels + FRC)

    This truncation was obviously not ideal, but HDMI 2.0 doesn't support 10-bit RGB in 2160p (aka 4K) at all frame rates - so just increasing the bit-depth and staying RGB wasn't really an option (it would mean no 2160p50 or above support).

    For higher frame rate UHD HDR with at least 10-bits, HDMI 2.0a supports either 4:2:0 YCbCr at 10-bit, or 4:2:2 YCbCr at 12-bit. The Pi 4B won't support 4:2:0 (as it requires both horizontal and vertical subsampling/scaling of chroma which the Pi GPU doesn't handle?), but the Pi 4B does support the horizontal-only scaling/subsampling for 4:2:2 YCbCr at 12-bit, which is now being used instead.

    HDMI 2.0a doesn't include any bit depths for 4:2:2 YCbCr other than 12-bit at UHD resolutions, so YCbCr output at UHD is always 12-bit. 10-bit content is just padded with zeroes in the two LSBs to pad the 10-bit content to 12-bit.

    Most of my UHD replay devices (UHD BD player, Apple TV 4K etc.) are set-up for 12-bit 4:2:2 output just as the Pi outputs, as is my AVR. (My Sky Q is 4:2:0 I think - haven't checked recently)

  • Atmos

    Quote from Nekromantik

    Hello

    Happy New Year all!

    Does LE 10 support Dolby Atmos decoding? Or do you have to passthrough?

    Does passthrough need certain NUCs to work or will NUC6 work?

    Thanks

    As far as I know there is no open source decoder / renderer for the Dolby Atmos Extensions used with Dolby Digital Plus or Dolby True HD - nor is there a majorly standardised route to sending them as PCM to an AVR.

    As a result Passthrough/Bitstream of DD+ with Atmos or True HD with Atmos to an Atmos compatible sound system is the route to getting Atmos decoding and height speaker playback.

    You can decode the DD+ and Dolby True HD stream to regular 5.1 / 7.1 PCM no problem though (as the streams are backwards compatible with non-Atmos decoders, which ignore the Atmos extensions)

  • RPi4 testbuild with HDR support

    I have an AVR-X2400H - I had to enable Enhanced HDMI support on both my TV and my AVR, and have to use HDMI 2 or HDMI 3 on my TV to allow 4:2:2 12-bit 2160p50/59.94 support. (HDMI 1 and HDMI 4 are 4:2:0 only - which the Pi won't support at 2160p50/59.94)

    HDMI 3 is my ARC port so that makes sense anyway.

  • RPi4 testbuild with HDR support

    Quote from onlyrock

    Ive got a few 4k hdr videos that I can play with the 12.18 build but not with newer builds. As far as I can tell the tv doesn't get put in to hdr10 mode in the newer builds. Brava xbr65a8h and denon avrx4300h. I can upload logs if useful.

    On most Sony HDR TVs you can tell if an HDR mode has been enabled by going to Picture Settings whilst the video is playing. If you see an HDR logo on the top right of the menu (there to tell you that you are altering the settings for HDR content on that source, as SDR and HDR picture settings are stored separately) you are in HDR10 or HLG mode.

    The only way of telling for certain if you are specifically in HLG HDR or HDR10 HDR mode is to go to Advanced Video settings and then manually altering Dynamic Range away from AUTO and forcing HLG or HDR10 to see if there is a difference between them and AUTO. (The same is true for Rec 2020 vs Rec 709 gamut switching in the Colour Space menu in the Advanced Video settings options)

    (Some devices will map HLG into HDR10 and output as HDR10, if they don't detect HLG support, I've found in some situations - though I think this was AML or RK, not Raspberry Pi)

  • RPi4 testbuild with HDR support

    frakkin64 Outputting 23.976/24.000Hz content natively in 23.976/24.000 Hz over HDMI shouldn't cause you 'Soap Opera Effect' issues unless your TV either cannot disable Frame Rate interpolation, or can't display 23.976/24.000fps content cleanly (i.e. without itself adding 3:2 or similar artefacts)

    My Sony TVs since my second HDTV set bought in 2007 have all supported native 23.976/24.000 support (my earlier displays used 48Hz refresh - which as they were LCD-based with constant backlight didn't flicker, my current display uses 120Hz 5:5 pulldown, as I have all the MotionFlow junk disabled)

  • RPi4 testbuild with HDR support

    Quote from HiassofT

    FYI: the 10/12-bit video output patches have been merged into the master branch and will be included in the next nightly build (20211219) - please use those for testing when they are available as they include other fixes as well (eg for deinterlace).

    Are nightlies here : https://test.libreelec.tv

    If so the Pi4 build seem to stop on the 18th Dec? Others are there for the 20th and 19th for other platforms. Does it take a while for Pi 4 nightlies to build?

  • RPi4 testbuild with HDR support

    Will have a play with this over the weekend. Have an HD Fury Vertex HDMI analyser so can see precisely what is being output in video terms.

    Great work!

    I guess the following is how the preferences work ?

    2160p30 and below : RGB 12-bit, YCbCr 4:2:2 12-bit, RGB 10-bit, RGB 8-bit

    2160p50 and above : YCbCr 4:2:2 12-bit, RGB 8-bit.

    (There are no 4:4:4/RGB modes at >8 bit supported in 2160p50 and above in HDMI 2.0, and 4:2:2 YCbCr is supported at 12-bit only)

    4:2:2 12-bit YCbCr at 2160p50/60 is often only supported by some (not all) HDMI inputs on some TVs (like my Sony XF9005 - which won't support this format on HDMI 1 and 4, only 2 and 3) and has to be enabled in TV menus. Similarly my Denon AVR has to have support for 4:2:2 12-bit enabled in its menus too. It's often called 'Enhanced HDMI' or similar. It also requires higher performance HDMI cables to work reliably as the bandwidth is pushing the limits of the HDMI 2.0a spec.

  • RPi Deinterlacer testbuild

    Quote from HiassofT

    "MMAL advanced" is borderline/too much for 1080i, therefore it's done using bob which needs fewer resources (memory bandwidth especially).

    I'm not 100% sure about RPi0-3 but ISTR they had similar issues - except for test streams I don't have any 1080i content here.

    RPis don't have a hardware deinterlace block therefore this is being done by software running on the videocore CPU - and that code is the same on all RPis.

    so long,

    Hias

    Ah - I thought there was some GPU acceleration for deinterlace on the Pi (a bit like there is for HEVC on the Pi 3B+ and below) - so not a hardware block for deinterlacing, but some assistance from GPU processing. I've clearly been wrong for years!

    (The MMAL is what made me think MMAL Advanced had some non-CPU support)

  • RPi Deinterlacer testbuild

    Didn't 1080i end up being "MMAL Advanced" (as opposed to Bob) deinterlaced eventually on Pi 3B/3B+ chips? (Or am I confusing MMAL Advanced being implemented on Pi Zero/A/B single core models eventually for SD stuff, where previously MMAL Advanced only worked on Quad core Pis?)

    ISTR that MMAL Advanced was quite similar to YADIF 2x. AIUI Weston 3-field may be a bit less computationally expensive (it's an option on some other playback applications now I think), and is certainly better than Bob.

  • RPi4 testbuild with HDR support

    Quote from HiassofT

    There's a draft PR to allow RGB/YCC selection via another connector property https://github.com/raspberrypi/linux/pull/4201 but ATM it's a bit unclear if it will be implemented that way or if it should be handled internally in the video driver (eg 4kp60 can't output 12bit 4:4:4 due to bandwidth limitations, auto-switching to 4:2:2 may be desirable in that case).

    so long,

    Hias

    I guess there are issues where there are HDMI output modes that are not supported (e.g. RGB or 4:4:4 YCbCr >8-bit at 2160p50 and higher) because they are out of spec, but there are also issues where you may wish to select from multiple supported options - such as 4:2:2 YCbCr 12-bit or 4:2:0 YCbCr 8-bit, 10-bit or 12-bit when both are supported on a given platform (a moot point on the Pi 4B as it only supports RGB, 4:4:4 YCbCr and 4:2:2 YCbCr and doesn't support 4:2:0 YCbCr)

    This isn't relevant on the Pi 4B where 4:2:2 YCbCr 12-bit is the only supported HDMI output format that will support UHD HDR at 10-bit or higher bit depth for 2160p50 and higher frame rates - but it is relevant to other platforms that may share the same framework - where 4:2:0 YCbCr 10-bit and 12-bit and 4:2:2 YCbCr 12-bit may both be valid options for 2160p50 and higher output. (The former being lower bandwidth than the latter)

    (Many UHD TVs will support 4:2:0 10-bit and higher at 2160p50 and higher on all their HDMI inputs, but only support 4:2:2 12-bit 2160p50 and higher on their 'Enhanced HDMI' inputs - and this also has to be enabled in menus. It often also has to be enabled on AVRs too. On my Sony UHD HDR TV only HDMI 2 and 3 support 4:2:2 12-bit at 2160p50 when enabled, and my Denon AVR also needs this to be explicitly enabled, otherwise it's 4:2:0 only for 10-bit and higher 2160p50 and higher)

    (NB people may wonder why I don't mention 4:2:2 10-bit - but that's because it's not a valid HDMI output format - 4:2:2 YCbCr is only supported at 12-bit on 2160p50 and higher modes - there are no other bit depth options. 10-bit HDR10 and HLG video is padded to 12-bit - ideally with 00s in the LSBs)

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

    Nobody's forcing you to upgrade - if you have a working system that does everything you want - no need to upgrade.

    However those of us who do upgrade will often provide bug reports and feedback to improve functionality - and test the newer features such as UHD HDR, HD Audio etc. that need to be tested to make them more reliable and robust, and for many of us using the 'Console' isn't a problem and the process of doing it stops the Linux commands being cryptic, as we learn more and more about Linux as we go. We're all different !

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

    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)

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

    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)

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

    Quote from twilightened

    So RPI3 did not have any kind of hardware video decoding right? It did everything via software.And RPI4 only has HEVC hardware decoding. And that is probably because no patent is required for the use of hevc. H264 on the other hand is bound to some patents. So RPI would be more costly if it was sold with a h264 hardware decoding enabled cpu on it (which i think is not even needed). I mean of course if you are trying to play 4K, 8K videos, maybe you run into problems there. I guess RPI is not built for this kind of media playback. Gotta have something more powerful. Gotta open up the wallet there :)

    No - that's incorrect.

    Pi0,1,2,3 all have h.264 hardware decoding for up to 1080p as standard. They had separate, optional paid-for licences for MPEG2 and VC-1 hardware decoding, again limited to 1080p.

    h.265/HEVC decoding on the Pi0-3 wasn't implemented in the video decoder (as h.264/MPEG2/VC-1 were) - but there was some clever GPU+CPU combination code that accelerated h.265/HEVC decoding more than basic CPU-only decoding on those platforms.

    The Pi 4B has the same, or very similar, VPU as the Pi0-3 range for h.264 decoding (again up to 1080p), but MPEG2 and VC-1 are now decoded in software only (with no hardware decode licences available for that platform). A separate, and additional h.265/HEVC decoder module has been added to the SoC used in the Pi 4B - which works up to UHD.

    My comment about h.265/HEVC being the only codec that is supported for UHD decoding in hardware on the Pi 4B stands, h.264 hardware decoding on all Pis (0-4) is only supported up to 1080p