Posts by noggin

Quote from chewitt

I would run the Kodi desktop/GUI at 1080@60 not 4K@30. Use the mode whitelist to permit switching to 4K for media playback when needed but otherwise allow the TV to scale the 1080p skin and 1080p GUI to the panel 4K native resolution using it's native scaling capabilities that do a better job than Kodi and have no load impact on the HTPC device.

NB: The only hardware that doesn't struggle with 4K desktop output is high(er) end Intel CPUs. All ARM boards run the GUI best at 1080p.

Yes - or if you're in Europe and watch European DVDs, Live/Recorded TV, or European VoD services (like BBC iPlayer etc.) which are all 25/50fps and have frame rate matching enabled, then a default GUI rendered in 1080 at 50Hz makes sense as it avoids constant 'HDMI bonks' as your TV switches from 60Hz to 50Hz etc.

Quote from Nekromantik

interesting

I just got pi 5 as decided to want smoother UI experience

I cant power off the Pi 5 using remote though. Using media player keys and flirc.

What happens if you navigate to the power menu and select Power Off, or map S to a key (that's the shortcut to bring up the Power Off menu)?

I've had no problems switching my Pi 5 off via those routes, and then pressing the Pi5's power button (!) switches it back on again!.

There's a config.txt entry you can enter that massively reduces current draw in shutdown (it's not - or wasn't - on by default as it can cause problems with some HATs because of which power is removed and which remains in that mode.)

Quote from Nekromantik

fuzzy

Do you mean that it's clear that there's horizontal chroma subsampling (i.e. the text is aliasy/jaggy/soft)?

If so - wouldn't a chroma grating, multiburst or zone plate be a better test for 4:2:2 vs 4:4:4/RGB chroma?

As others have suggested - what your devices EDID states support for and how your Pi's output is configured can play a part too.

For 2160p50/60 output modes HDMI 2.0 supports 4:4:4/RGB output at 8-bit only (which isn't suitable for HDR 10-bit video - or SDR 10-bit for that matter), and I think - by default - the Pi will thus prefer HDR-friendly 4:2:2 12-bit output modes at 2160p50/60 if an option.

For 2160p24/25/30 (2160p25/30 aren't universally supported by displays) and lower resolutions you can run 4:4:4/RGB at higher bit depths - so your output refresh rate and resolution can play a part in deciding whether 4:4:4/RGB or 4:2:2 output is used ?

Quote from chewitt

We loathe Argon cases but whatever you like

Glad it's not just me. Superficially they look like a great solution (IR receiver, integrated fan, nice arrangement with all IO on the back etc.)

However I lost countless hours to HDMI connectivity issues - all ended up being caused by poor quality HDMI extenders in the cases...

Quote from Nekromantik

easiest way to test is put this file on pi and view on TV

https://i807.photobucket.com/albums/yy352/f…e-rgb-1080p.png

if the red and magenta columns are not clear then it does not support it

Could you define 'not clear'?

Quote from tomstephens89

Switching to AUX2 on my Denon AVR-X3600H has not solved this problem.

I have just added hdmi_force_hotplug=1 to config.txt and will see what that does.

Is the AUX 2 input on your X3600H HDMI 2.1 or HDMI 2.0? (i.e. does it support 4K/120 and 8K/60?)

(If all of the inputs on your X3600H are the same that would explain the lack of difference. My previous X2400H, which was HDMI 2.0a only - and limited to 4K/60 and no 8K - exhibited very odd behaviour with LE on a Pi 4B/5)

For info - I'm running my Pi 5 4GB into my Denon X2800H (non-DAB) and an LC C3 via an EZCOO remote controlled HDMI 2.1 (i.e. 48Gbs, not 18Gbs) switch connected to Aux 2 - one of the HDMI 2.1 ports and so far have no problems. I've not changed my config.txt file

(Denon reduced the number of HDMI inputs on their newer AVRs so I'm having to upstream switch as I've run out)

Quote from andirama

PS: I didnt tested CEC so far, because i always use a Harmony One as Remote for all Devices and thus i dont need CEC.

When you said you've not tested CEC - can I check that means you have CEC disabled on the Pi and other devices - or you've just not tested remote control pass-through (which is a tiny part of CEC)?

Quote from chewitt

Diff

diff --git a/packages/network/bluez/package.mk b/packages/network/bluez/package.mk
index 9170f27418..0dd5ebef4d 100644
--- a/packages/network/bluez/package.mk
+++ b/packages/network/bluez/package.mk
@@ -62,6 +62,8 @@ post_makeinstall_target() {
         -e "s|^#\[Policy\]|\[Policy\]|g" \
         -e "s|^#AutoEnable.*|AutoEnable=true|g" \
         -e "s|^#JustWorksRepairing.*|JustWorksRepairing=always|g"
+    echo "[General]" > ${INSTALL}/etc/bluetooth/input.conf
+    echo "ClassicBondedOnly=false" >> ${INSTALL}/etc/bluetooth/input.conf
 
   mkdir -p ${INSTALL}/usr/share/services
     cp -P ${PKG_DIR}/default.d/*.conf ${INSTALL}/usr/share/services

Display More

noggin https://chewitt.libreelec.tv/testing/LibreE…h64-11.80.0.tar contains ^ this patch based on information from https://github.com/bluez/bluez/issues/696 and https://github.com/bluez/bluez/is…ment-1854599254 which reads like the same issue.

Thanks for this chewitt - using the above patched tar I can trust and connect using the LE add-on (though I initially used bluetoothctl to connect to test) - and so far it seems to work - no constant nags for a PIN. (No need to pair in the add-on or bluetoothctl but the controller does need to be in pairing mode - SELECT+ENTER held down gets it into pairing mode.)

I'm having the same issue trying to pair a PS3 BD Remote on a Pi 5 running LE 12 nightly from 20240106. The PS3 BD remote is a second gen one (with TV and AVR IR remote functionality) that used to work fine with older versions of LE (not sure when I last used it) and I can't pair it either via bluetoothctl or the Add On.

(I get prompts for a PIN when the remote tries to connect with the Pi5 - but 0000 and 1234 don't do anything - and I used not to have a PIN prompt I'm sure - it just paired?)

Attempting to pair with 64:D4:BD:6A:C2:62
[bluetooth]# hci0 device_flags_changed: 64:D4:BD:6A:C2:62 (BR/EDR)
[bluetooth]#      supp: 0x00000001  curr: 0x00000000
[bluetooth]# hci0 type 7 discovering off
[bluetooth]# hci0 64:D4:BD:6A:C2:62 type BR/EDR connected eir_len 24
[CHG] Device 64:D4:BD:6A:C2:62 Connected: yes
[BD Remote Control]# hci0 64:D4:BD:6A:C2:62 auth failed with status 0x0b (Rejected)
[BD Remote Control]# Failed to pair: org.bluez.Error.AuthenticationRejected
hci0 64:D4:BD:6A:C2:62 type BR/EDR disconnected with reason 2
[CHG] Device 64:D4:BD:6A:C2:62 Connected: no

I found this reference to an issue https://forums.raspberrypi.com/viewtopic.php?f=28&t=21045

Could it be relevant?

Quote from maxi

On Pi 5 with 12.0-nightly so far no problems reproducing 1080p 4:2:2 h.264/265 video files or streaming, but Hevc UHD feeds not capable, it was supposed to reproduce via HW, but it switches to SW and the CPU goes to the limit...

UHD example...

https://www.mediafire.com/file/i0rv6rukd…+record.ts/file

Mine are all 1080i25 - not 1080p - so also need to be deinterlaced.

Quote from popcornmix

I've just tested and some similar files are playing for me (nighyl LE12 on Pi5):

Code

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2@L4
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 16 s 50 ms
Bit rate : 252 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 (30000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.004
Stream size : 493 KiB (99%)
Writing library : x264 core 152 r2854 e9a5903
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language : English
Color range : Full
Codec configuration box : avcC

Display More

and

Code

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Format Range@L4@Main
Codec ID : hev1
Codec ID/Info : High Efficiency Video Coding
Duration : 34 s 76 ms
Bit rate : 1 102 kb/s
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.030
Stream size : 4.48 MiB (70%)
Writing library : x265 3.2.1+1-b5c86a64bbbe:[Linux][GCC 9.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1111039 / frame-threads=5 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=2 / input-res=1920x800 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=5 / scenecut=40 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=28.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00
Language : English
Color range : Limited
Menus : 3
Codec configuration box : hvcC

Display More

(10-bit, 12-bit, and 444 variants also playing). So I guess there's something different in your files.

Interesting - those are all progressive - mine are interlaced - as will a lot of 4:2:2 media carried on broadcast uplinks (as the bulk of broadcast outside of North America - where 720p59.94 and 1080p59.94 is more of a thing - is 1080i25 or 1080i29.97 - even if it ends up 720p50 for transmission - like in Scandinavia and Germany for instance)

Had a quick look before I left - will DM you a clip when I get a chance.

I'm running LE 12 - the 20240106 nightly on a Pi 5 (6ca79da is the end suffix)

4:2:2 MPEG2 content triggers a restart from the LE splash screen

4:2:2 h.264 content also triggers a restart from the LE splash screen

Quote from popcornmix

Is this LE11 or LE12? I did spend a while making sure the software paths for the all the weird formats I would find (which did include 422/444 as well as 10-bit/12-bit) did the right thing. That may be LE12 only.

If LE12 fails, can you point me at a sample file that crashes and I'll look into it.

I'll try and check this evening and get back to you. It's 4:2:2 h.264 8-bit or 10-bit that crashed for me (both are in use for broadcast links now)

Quote from powerarmour

Ah interesting, appreciate the info!

Yep - that's 4:2:2 h.264 (used for broadcast backaul/uplinks) not for feeds to the consumer (4:2:0 is used for that).

4:2:2 video like that currently causes my LE Pi 5 to reboot - though AIUI the CPU should be fine to decode it in software (as it also should 4:2:2 MPEG2) so this is less likely to be a hardware limitation on the Pi 5, more a software issue that needs some work.

Quote from yamcenutzer

All these cases that are not FLUSH with hdmi connector will cause problems. In fact the only really good ones seem to be the official plastic cases.

Repeat after me: the pi is conceptually NOT living room material. Its a educational device for tinkerers and nerds.

Depends on your living room. I have Pi 4Bs in Flirc cases which have been great living room LibreElec boxes. They just sit there working. Early days so far with the Pi 5 - but it seems to be the same (but with a snappier UI). They sit in the AV unit, out of sight, often powered via PoE, and with RF remote controls (usually a PS3 Bluetooth Media Remote or a Vero RF remote) and just work for me. (I've switched to booting some from a USB 3 external SSD)

Quote from chewitt

I'd use the 3840 "4K" modes: have a read here: https://wiki.libreelec.tv/configuration/4k-hdr

Yep - 100%. All consumer '4K' content and displays are 3840x2160 (also known as UHD), not 4096x2160 (technically '4K' but not what people call 4K in the consumer space)

My issues with Pi 4B/5 and Denon AVR-X2400H were in 3840x2160 modes (I never use the default and annoying 4096x2160 resolution).

However it's early days but I recently also upgraded to a Denon AVR-X2800H (as I needed HDMI 2.1 support for a 2160p120 PS5 and our new LG TV) and things MAY have improved.

Quote from Cissou

The best case for pi4 is the argon one V1/V2, on/off power management, and for the remote i use for year rii mini keyboard, far better than a simple remote control

Beware the Argon cases with integrated HDMI extension - they can cause issues if you are running in a high bandwidth 4K HDMI 2.0 mode like 2160p60 4:2:2 12-bit. I had to stop using them for Pi 4B Kodi LibreElec installs for this reason, and switched to Flirc cases.

Quote from popcornmix

Is there an easy way (e.g. using mediainfo, what is the relevant string to look for) to see which case a video is in?

Do you believe the first case here can be decoded and displayed correctly, purely by outputting the untouched YCbCr data from decoder and the appropriate metadata? I believe the second case requires per-pixel processing which is likely infeasible at 4k without dedicated hardware or a very high performance gpu.

It looks as if anything with dvhe.05 in its profile will be IPTPQc2 colour space rather than YCbCr. The dvhe.07 and dvhe.08 are based on Dolby Metadata with YCbCr Rec 2020 PQ HDR10 video (plus an optional enhancement layer for added Dolby-ness). However I think this is what happens aleady in LE? The dvhe.05 stuff plays as purple and green. This may be because it's been ripped or mastered incorrectly.

The UHD BD ripped and remuxed stuff usually contains something like dvhe.08.06, BL+RPU or dvhe.07.06, BL+EL+RPU and HDR10 compatible in the HDR format field for the HDR10 YCbCr HEVC Rec 2020 PQ base layer + DV BPU metadata. (Profile 7 is designed for a base encode (backwards compatible with other formats) plus accompanying Enhancement Layer (which can deliver greater bit depth AIUI) and RPU Metadata, Profile 8 just for a backwards compatible encode and RPU Metadata (with no DV enhancement data for increased bit depth)

The stuff that is ICtCp-ish (IPTPQc2 technically) usually contains something like dvhe.05.03, BL+RPU and no reference to HDR10 and no HDR10 metadata as it's not HDR10 backwards compatible, and has an ICtCp PQ encoding (in HEVC usually, though I think AV1 is also an option?) with DV BPUs. (Media Info still reports YUV as the color space - though I don't know if this is an assumption or a flagging thing)

AIUI libplacebo will decode IPTPQc2 encoded video but I don't know how fully - some discussions about Dolby-specifics such as NLW and MMR.