Posts by noggin

Quote from doof

I'm trying to get 60hz playback but LE doesn't show a 60hz option. The config seems to be read properly and my rockpro64 running LE using the same cable and port runs @ 60hz.

Code

LibreELECpi:~ # cat /proc/device-tree/model
Raspberry Pi 4 Model B Rev 1.1 LibreELECpi:~ 

#LibreELECpi:~ # vcgencmd get_config hdmi_enable_4k
hdmi_enable_4k=1

Polling the device doesn't show a 60hz UHD mode on RPI

Code

LibreELECpi:~ # tvservice -m DMT
Group DMT has 2 modes:
mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 82: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
LibreELECpi:~ # tvservice -m CEA
Group CEA has 11 modes:
mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive
mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced
(native) mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
mode 32: 1920x1080 @ 24Hz 16:9, clock:74MHz progressive
mode 63: 1920x1080 @ 120Hz 16:9, clock:297MHz progressive
mode 93: 3840x2160 @ 24Hz 16:9, clock:297MHz progressive
(prefer) mode 95: 3840x2160 @ 30Hz 16:9, clock:297MHz progressive
mode 100: 4096x2160 @ 30Hz unknown AR, clock:297MHz progressive

Display More

How can I enable 60hz UHD on my RPI?

AIUI the Pi 4B doesn't support 2160p50-60 4:2:0 modes - so if your display only supports them - you're likely to be out of luck?

4:2:0 was introduced to HDMI 2.0 specs to reduce the bandwidth required (bringing the 8-bit 4:2:0 2160p50-60 modes within HDMI 1.4b bandwidths avoiding a requirement for HDMI 2.0 full bandwidth support on some 'HDMI 2.0' TVs).

My Sony TV has to have high-bandwidth HDMI 2.0 modes enabled (it's called 'Enhanced' on Denon and Sony) - and even then only 2 of the 4 HDMI inputs on my Sony UHD TV support the higher bandwidth ports - which are required for non-4:2:0 2160p50-60 inputs.

My Pi 4B currently runs 2160p60-60 at RGB 8-bit - and I believe 4:2:2 is supported or will be. However 4:2:0 output requires vertical chroma subsampling as well as horizontal subsampling (4:2:2 is horizontally subsampled only) and I think I read one of the Pi devs comment that may be tricky for the Pi to implement?

In other words - 2160p50-60 isn't supported by the Pi in all HDMI 2.0 flavours.

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.

Quote from Freestyler

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.

Quote from philrandal

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!)

Quote from Iridium

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)

Quote from coniman

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?)

Quote from popcornmix

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.

Quote from popcornmix

For the stuttering reports there is a fix. Either wait for the next LE update or grab firmware from here:

start4.elf?raw=true

fixup4.dat?raw=true

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)

Quote from milhouse

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.

Video
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

Quote from milhouse

documentation/hdmi-config.md at master · raspberrypi/documentation · GitHub

In /flash/config.txt, add the following to enable 4Kp60 support:

Code

hdmi_enable_4k=1

HDR 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?

Quote from muppet007

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)

Quote from excalibur

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.

Quote from chewitt

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)

Quote from indianahorst

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)

Quote from cheungie

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.

Quote from Monie

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)

Quote from novalis

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.