Have you tried the new firmware here : LibreELEC (Leia) 9.2 ALPHA1 with Raspberry Pi 4B Support
That helped me with h.264 stuff that wasn't playing well in the Pi 4 Alpha release.
Posts by noggin
-
-
Hi I didn't enabled this option in config.txt and I was able to play 4k HEVC movie anyway. Is that possible? Now i tried enable this option and only difference is, that I can put Kodi interface to 4k 60fps mode, previously I could use just 4k 30fps.
I'm doing it right: I opened SD card on my computer, opened config.txt file and added line hdmi_enable_4k=1.
But i'm surprised, that 4k worked without this line.
Thanks
Yes - confusingly the hdmi_enable_4k isn't needed to enable all 4K modes (4K24-30 is enabled without it) - it just enables the 4K50-60 modes...
Without 4K60 enabled (which is an HDMI 2.0 mode)you are effectively running with a max of 4K30 (which is potentially an HDMI 1.4b mode in SDR)
Movies and drama TV shows are traditionally 24-25p so will play with no obvious difference without 4K60 being enabled. However any live TV sport or entertainment (BBC iPlayer is carrying Wimbledon in 4K50 at the moment) will most likely be 50 or 60 - and the UI will look smoother in 50 or 60.
-
I just need to figure out how much clearance above the fan shim I'll need for the TV HAT and how to bodge the Pimoroni Pibow case to fit it all (the case bolts won't be long enough).
Phil
Pimoroni used to sell extra slices for Pibow cases to let you make them HAT-friendlier. Not sure if they still do? They are usually pretty helpful via email (though a lot busier these days!)
-
I'm sure a third party will soon come up with a GPIO cooling solution so the fan is only one once it get too hot. Maybe even there will be a RPi4B++ with an on board fan controller - but don't hold your breath.
Pimoroni launched a fan shim shortly before the Pi 4B launched.
Fan SHIM for Raspberry Pi – Pimoroni It has a user definable switch and RGB LED.
-
I think Da Flex is talking about getting the Raspberry Pi to decode DD+ to PCM in the Pi, whereas Novalis wants passthrough/bitstreaming, where the DD+ bitstream is passed, untouched, from the Pi to the AVR for the AVR to decode?
Both are valid approaches for non-Atmos content, and the 'decode to PCM' is the only approach for the Pi 3B+ and below for Dolby True HD and DTS HD MA (which the Pi traditionally can't bitstream *), whereas the Pi can bitstream/passthrough DD and DTS. It seems some have reported success with DD+ bitstream/passthrough.
(*) The Pi 4B supports 8 channel 192kHz over HDMI which means it should allow HD Audio passthrough (the previous generation of Pis only had enough bandwidth for 4 channel 192kHz so couldn't)
-
Yeah, but as far as I know H.264 HW decode is limited to 1080p@60 and I want to use 4K content, so
Or I'm wrong?
PD: sorry for the off-topic hehehe
My understanding is that the hardware decode of non-HEVC stuff is basically near-identical to previous Raspberry Pi models - with the new HEVCv2 4:4:4 4096x4096 decode capabilities added separately, so performance with h.264 will be the same as previous models.
I guess the approach the Pi developers have taken is to maximise compatibility (by adding new functionality without replacing the elements that were present in previous Pis?)
-
High bitrate HEVC is next on the list to investigate. Currently it's just been "got working" rather than optimised.
Cheers - I'm really not complaining! This is where Raspberry Pis really stick out from other SBCs - amazing support.
-
For the stuttering reports there is a fix. Either wait for the next LE update or grab firmware from here:
rename and replace http://start.elf/fixup.dat on the FAT partition of sdcard.
This fixes the issues I have seen with h.264 1080i interlaced content (i.e. Freeview HD stuff) - but my 2160p59.94 Rec 709 SDR HEVC test stuff is still frame dropping like crazy. (Some other 2160p59.94 stuff isn't though)
Decoder is ff-hevc-mmal (HW)
Pixel format is rpi
Also 5.1 PCM is now working for me (though I discovered an HDMI issue elsewhere in my set-up that may have resolved that)
-
Just trying to rule out possible causes in an effort to identify what is happening.
As it happens, there should be a fix for the "washed out" videos in the next release as MMAL required some extra support for the Rec2020 colour space that had been omitted. It would still be very nice if someone could upload a test sample or provide a link to a file that demonstrates the problem so we can fix it at the first attempt.
Also, stuttering issues with interlaced videos should be fixed in the next release.
I got my 4GB 4B last night. First boots of both Raspbian and the LibreElec Alpha from the downloads page with my UHD TV connected to HDMI 1 didn't go well, and LibreElec TV ran in 4096x2160p mode with very odd level space (and odd pulsing audio). Disconnected and using HDMI 0 (a tight fit with a Micro HDMI->HDMI adaptor and the USB-C power connector) it worked OK, starting up in 4096x2160/24p but with correct levels.
2160p60 output is RGB 8-bit currently on my set-up.
I'll upload some Rec 2020 HLG and HDR10 content once I've tested it. SDR Rec 2020 is pretty rare - I'm not sure I have any. HLG Rec 2020 is backwards compatible with SDR Rec 2020 though - the highlights just look a bit different because of the HLG EOTF differing from BT.1886 once you get past about 75%.
BTW - other observations. Interlaced 1080i h.264 is very juddery, and 5.1 FLAC is output 2.0 (even with 5.1 configured) Totally understand this is a very early alpha - and not complaining!
*** EDIT : Watching some 2160p59.94 10-bit HEVC SDR Rec 709 content, played from a locally connected USB 3.0 ExFAT drive, I'm seeing hundreds of dropped frames too *** I'll message you with a DropBox link to some test content.
Code
Display MoreVideo ID : 481 (0x1E1) Menu ID : 1 (0x1) Format : HEVC Format/Info : High Efficiency Video Coding Format profile : Main [email protected]@Main Codec ID : 36 Bit rate : 31.1 Mbps Width : 3 840 pixels Height : 2 160 pixels Display aspect ratio : 16:9 Frame rate : 59.940 (60000/1001) fps Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 10 bits Bits/(Pixel*Frame) : 0.063 Stream size : 49.7 GiB (93%) Color range : Limited Color primaries : BT.709 Transfer characteristics : BT.709 Matrix coefficients : BT.709 -
documentation/hdmi-config.md at master · raspberrypi/documentation · GitHub
In /flash/config.txt, add the following to enable 4Kp60 support:
Codehdmi_enable_4k=1HDR metadata should be ignored for now, so if your display looks washed out try toggling Settings > System > Display > Use limited colour rage (16-235).
Why would 0-255 or 16-235 be an issue for Rec 2020 HDR10 output flagged as Rec 709 SDR?
Wouldn't you be better forcing your TV into Rec2020 and HDR10 mode? (My Sony lets you do this in its video settings)
This won't help cope with the different Rec 709 vs Rec 2020 RGB<->YCrCb matrix (so if any RGB processing takes place it will be a bit out), but will use the required EOTF for HDR10 (i.e. use the right dynamic range) and will switch to Rec 2020 primaries (so that the colours are in the correct gamut) assuming the Pi 4B LibreElec is just treating HDR Rec 2020 stuff as if it is Rec 709 SDR (and not trying to do any gamut or EOTF conversion)
Or are you saying that the UHD HDR 16-235 content is flagged 0-255 permanently?
-
Hi all,
I installed this release on my PI4 2gb and and have a few questions.
I can play 4K HEVC files fine but as all of them are HDR which isn't supported yet will this result in incorrect playback? They seem to be washed-out and lacking colour but this could be in my mind.
The maximum refresh rate I can get is 30. In 1080p I can get 60. Is this likely to be down to the HDMI cable I'm using? I seem to remember I had this with my laptop and had to buy a quality cable. I'm using a micro to full size adaptor which I think might be limiting things.
Thanks in advance for any help.
If HDR10 HDR with a Rec 2020 gamut content (i.e. UHD Blu-ray material) is played as if it is SDR Rec 709 it will look very washed out as the colour primaries and 'gamma' (for want of a better word) are very different and unless a tone mapping conversion is taking place it will look terrible. You may find you can force your TV into HDR10 and Rec 2020 but this still may not make things 100% correct (as the RGB<->YCrCb matrices for 709 and 2020 are different)
-
Good news to hear HEVC hardware decoding !
What about H.264, will 1080p videos at 20Mb/s be smooth ?
I have no problem with 30+Mbs h.264 1080p50 videos on a Raspberry Pi 3B+ - why would this change with a Pi 4B?.
In fact my high bitrate 1080p50 h.264 files play on a Pi Zero from local storage.
-
I'm told Atmos should be okay. If you aren't using pass-through you'll only get the DTS core (5.1) anyway and if it is being passed through it's not being decoded and thus a license isn't needed. Or something like that .. IANAL
Don't you mean you'll get either a lossy Dolby Digital accompanying secondary stream (if DD passthrough is enabled but True HD disabled) or Dolby True HD decoded to 5.1PCM (if all passthrough disabled and thus lossless decode - ignoring Atmos extensions - kicks in? ISTR that most True HD + Atmos has a 5.1 True HD core?)
Not sure where DTS comes from (And True HD technically isn't a DD core + True HD extension is it? Unlike DTS + DTS HD MA - True HD is self contained and there is usually a secondary DD standalone stream - though this is sometimes hidden from view on discs)
-
Does somebody know if the 4B has support for HDMI-CEC?
This would be a very important feature for me to use it as media server.
All previous models of Pi (Zero up to 3B+) have supported HDMI-CEC so I'd expect the Pi 4B to continue to do so, though the dual HDMI ports could complicate these I guess (though I think CEC can be multi-device friendly)
-
Does Dolby Vision also involves metadata passthrough as well?
DV requires metadata passthrough - and there are different ways of doing this (early DV tunnelled the metadata within the video, which requires displays to extract the DV metadata from the video) Not all displays support all metadata routes (more recent displays only support the low latency DV system that carries metadata separately, I believe similarly to HDR10+?).
In fact DV's main reason for existence is to pass Dolby metadata through the viewing chain to Dolby licensed processing elements.
-
I understand it has hardware decoding for HEVC content but what about 10 bit? Will it smoothly run 1080 and 4K x265 10 bit content?
The HEVC/h.265 decode hardware is quoted as supporting 4:4:4 4096x4096 at 10-bit in specs I've seen reported elsewhere.
That should be fine for 3840x2160 4:2:0 10-bit consumer HEVC/h.265 as used on UHD Blu-ray etc. in decode terms.
(I don't think anyone would seriously now offer 8-bit limited UHD HEVC/h.265 decoding)
-
I'd just like to know. Is it possible to get a definite answer to this question? Or is it a secret? So far I don't get it running with my AVR. But maybe I'm doing something wrong.
It works with Windows though.
Light please.
Kodi supports DD+ passthrough, so LibreElec support will depend on the hardware support in the surrounding Linux ecosystem that LibreElec uses, which means it's based on the hardware platform you are running.
-
Yes, thats a good idea, i will try to do handle all videos with software and report back!
The RK3399 has quite a powerful CPU - it may do quite well with h.264 stuff up to 1080p?
