Posts by noggin

  • 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

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

    Quote from ebym

    RPi 4 8GB - LE 10 can't play 4k "Lupa sync test" video in h264 format. Strange thing is the audio playback happens, not sure if video require an actual 4K display.

    Code
    Codec: H264 - MPEG-4 AVC(part 10) (avc1)
Video resolution: 3840x2160
Frame rate: 25

    Pi4 only supports hardware acceleration of UHD content if it's h.265/HEVC encoded. This file is h.264/AVC encoded and the Pi only supports that codec up to 1080p resolution, so won't play UHD/4K h.264/AVC content.

  • Can't get TV to recognise 7.1 sound

    Quote from caned_monkey

    I am playing .mkv files. Some are DD+ others Dolby True Hd and as I've already said it doesn't work through HDMI either.

    I have a gaming pc plugged directly into the TV which displays in 4k and gives 7.1 sound.

    If i plug the pi into the receiver, I get 7.1 sound but no 4k. If I plug it into the TV, I get 4k but no 7.1.

    Sorry - I thought in your earlier post you said you were using Optical from your TV to your AVR - not ARC?

    However ARC can't carry True HD, PCM 7.1 etc. (it's limited to PCM 2.0, DD, DTS and in some implementations DD+) - only eARC (introduced much later than your AVR) can do HD Audio.

    Can you clarify how you are getting True HD?

  • Can't get TV to recognise 7.1 sound

    What 7.1 DD+ sources on your Pi are you playing?

    You won't get PCM 7.1/FLAC 7.1/Dolby True HD 7.1/DTS HD MA 7.1 audio from the Pi to your AVR over an optical cable.

    The only 7.1 codec that is just about potentially supported via that route is DD+ 7.1 (and possibly 6.1 DTS ES which is very rare) - which isn't that widespread. Kodi will transcode other codecs to 5.1 DD, but not 7.1 DD+.

    Also - what other 7.1 HDMI sources have you successfully passed through via HDMI to your TV and then via optical to your AVR? Internal streaming apps on your TV don't count in the same way - as they aren't using the HDMI route.