Posts by noggin

Quote from HiassofT

camelreef thanks a lot for testing and the samples!

I've noticed the glitches on MPEG2 SD material, too, and popcornmix already has an idea what could be causing that - it might be related to software decoding, H264 hardware decoded videos don't seem to have those glitches (at least we haven't noticed them there yet).

So no need for a debug log ATM

IIRC SD content will use the "advanced" deinterlacer, HD will use bob, of the videocore chip - pretty much the same as on RPi2/3 with LE9.2

so long,

Hias

Display More

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.

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)

Quote from Niceguy

By the way this Thread should be about LibreELEC itself and not about technical problems with it.

So LibreELEC (Matrix) 10.0.1 is out now, and if I look around here on this Board I see again a lot of Problems with this Release.

And it seems these Problems can't be fixed the easy way.

Firts you must send in some "Error-Logs" to this Board and if there is a Solution for the Problem you can't simple fix it "with the switch of a Button", no, you must edit some "INI"-Files or open a "Console" and type in some cryptic Linux commands.

So I asked myself:

Why should I update from LibreELEC 9.2.8 to 10.0.1 ?

What is "better" in 10.0.1 ?

* I don't want to watch 4K/HDR Movies and I don't want to stream anything (for example from the Internet or a NAS)

* I want to watch Movies which are stored on an external HDD connected to an USB-Port of my Raspberry Pi 3 or my PC.

* 1080x1920 Full HD is enough for me and it works fine.

* Passthrough of the HD-Audio like Dolby Digital or DTS over HDMI to my Sony Soundbar works also without giving me any Troubles.

* I want to listen to MP3 Files and this works fine too, even over the 3.5 Jack connected to my Stereo System and with the Yatse Remote Control.

So why should I change a running System and Update to a Software which gave others a lot of Problems and Trouble and will give me maybe some too ?

Display More

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 !

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)

Quote from BrianM

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)

Display More

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)

Quote from BrianM

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

Display More

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)

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

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.

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?

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.

Quote from bkuhls

Hi,

sorry for stepping into this thread without ever testing the images provided here.

But I am planning to step into UHD content and I am willing to test related patches.

My current TV is limited to HD (1080p) and I would like to ask whether Kodi is able,

maybe with some patches added, to display UHD (2160p) content on a new UHD-

capable TV set yet to be bought.

My setup is:

- Intel Rocketlake i9-11900tT

- ASRock Z590 Extreme with HDMI 2.0b output

- kernel 5.13.x

- mesa3d 21.2.1

- media-driver 21.3.2

Do I need to use a fiber-based HDMI 2.0 cable to cover the 12m distance between

the PC and the TV? Currently I am using a HDMI 1.3 copper-based cable.

Will fiber-based cables still route CEC signals?

Is the limitation "4K60 4:2:0 8-bit" of the USB CEC adapter a problem in real life?

Display More

The bigger issue for you won't be UHD - it will be Wide Colour Gamut HDR.

Most UHD - but by no means all UHD - is also Wide Colour Gamut (aka Rec 2020) and HDR (usually HDR10). The UHD downscale to HD isn't usually a problem, so UHD Rec 709 (i.e. 'normal' colour) SDR video will be no problem at all. However for HDR stuff (which is Rec 2020) the player will have to also 'tone map' which is converting the HDR and Wide Colour Gamut video into the narrower colour range and narrower dynamic range of regular HD SDR content. That's the trickier task. (*)

If you plan on going UHD at some point then the 8-bit limitation will be an issue - as HDR really needs 10-bit - though that limitation may not be an issue at 4K30 and below.

(*) There are now some HDR Wide Colour Gamut 1080p TVs on the market - if you have one those you may be in a better situation with HDR content.

This sounds like a power supply issue. In my experience you get ticking from 2.5" external drives when the power supply isn't quite up to it. I always had to use a powered USB hub to feed 4TB drives from my Pi 4B (I now used a Celeron box with my 4TB drive), as the stock Pi supply wasn't quite able to provide enough power.

Quote from lobbie1978

I only play UHD 4K content and I'm pretty sure all content has the same video resolution. If I play the content on my PC in Kodi, it fills the screen (1080p).
Could it be my Sony Receiver that's causing this? Or is that unlikely? Anything else I can try?

What happens if you take your Sony Receiver out of circuit?

What content plays normally, what content plays 'shrunk'? Be useful if you logged it. For file-based stuff posting the Media Info of a file that plays OK and a file that plays shrunk could be useful too.

That said - Netflix full-screen content and Netflix 2:1 content are both likely to be carried in a 3840x2160p video standard - with the 2:1 stuff having black bars top and bottom. However if watching the exact same content on your PC fills the screen - then that suggests something is odd.

Can you playback the Netflix stuff that's shrunk using an alternative player solution to compare and check it's not your projector doing something odd?

Quote from lobbie1978

Hi guys,

There is something that's troubling me for a while and I wonder if you guys can give me some explanation of this.

I have a Raspberry Pi 4 with LE 10 beta (latest) running through a Sony STR-DN1080 and then to my Optoma 4K UHD-35 projector.

I'm playing 4K HDR movies and Netflix and some movies are full frame (the dark gray area on the screen) and some movies are not. They are playing in a smaller frame (the light gray area on the screen). As far as I can see, both movies have the same resolution in the video stream. Does anybody know why some files display in a smaller frame?

I can't wrap my head around this and I find it quite annoying tbh.

Thanks in advance guys!
Cheers,

Rob

Display More

Does the width definitely change - and are all the sources output at the same video resolution (i.e. 3840x2160p)

Do all the source files (apart from DRMed stuff you can't analyse) have the same native resolution ?

A lot of TV drama is now shot 2:1 (i.e. 16:8) so you get a bit of letterboxing (black bars top and bottom), but black bars left and right too is unusual.

SD stuff - particularly 50Hz stuff has the 702x576 vs 720x576 issue to contend with too - lots of platforms get this wrong. (702x576 = 4:3 or 16:9 - with 9 samples of padding left and right to create a 720x576 raster that is wider than 4:3 or 16:9)

I'm not a projector user - so can only compare with my Sony UHD HDR TV - but that shows everything I expect to fill the screen filling the screen (though Kodi - on at least some platforms - may have issues with some 720x576 stuff in PAR/DAR terms I think)

Quote from jollyjumpr

Hi there,

newbie here.

Is there an option to disable Hdr?

im not happy with some of my HDR Video Files and i like them better when i turn HDR off.

I cannot switch it off on my TV, so it seems Libreelec is forcing it.

Not the End of the world since i can use older builds for those files, but it would be a nice option

Display More

What do you mean by 'disable HDR'?

Do you mean convert HDR10 to SDR and output SDR (i.e. tone map)?

HDR10 (Rec 2020 with a PQ EOTF) video played back unconverted in SDR (Rec 709 with an SDR EOTF) will look unwatchable bad.

(HLG is a bit different as the HLG EOTF is compatible with an SDR EOTF - though Rec 2020 content played back unconverted and displayed as Rec 709 still looks awful)

Quote from chewitt

Random hunch: Check the whitelist and remove 4096x2160p "4K" entries leaving only 3840x2160p entries. Better?

Was about to say the same. 4096x2160 modes can be a real pain. I always whitelist them out as none of my displays are 4096x2160.

Quote from elonesna

I am glad that you saw that the SAT>IP server was not at fault. In my experience the SAT>IP servers work very well, I have a secondary CE server based on amlogic S912 that forwards the DVB-T channels, via SAT>IP, to a main server tvheadend LE based on intel x86_64 located 300 km away, and that in turn, It can forward all TV channels (tuners: USB, SAT>IP, and IPTV) to a CE client also based on amlogic S912 located 3000 km from the main server. Well, everything works great.

Yep - I had a set-up that used a Raspberry Pi with a DVB-T2 tuner to forward channels between countries - though I didn't use SAT>IP, I eventually used an SRT protected tunnel (initially I just used plain https transport stream)

Ah - I'm on HTS Tvheadend 4.3-1909~gc66e3bc7d which I think I compiled from GitHub myself (I usually create a .deb pkg when I build TV Headend under a Debian OS)

Afraid I'm not expert enough to give any more advice on the set-up of the SAT>IP tuner.

I don't use MC much - I usually just SSH in for command line access and copy stuff manually, or use an SFTP client like FileZilla for remote file transfer.

I would be surprised if Kathrein have much experience of their SAT>IP Tuners being used with TV Headend internally - but stranger things are known to happen!

Out of interest - if you go STATUS->Stream do you also see any Transport Errors as well as Continuity Errors?