Posts by noggin

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.

I've found my Pi 4 and Pi 5s both confuse my Denon AVR-X2400H + Sony TV 49XF900? combo (haven't tried with my new LG OLED yet) does something similar. When the Pi boots you see the LibreElec splash screen and then get corrupt video (sometimes no signal on the TV, often digital shash).

I found disconnecting the Pi's HDMI output and reconnecting (Hot plug force?) re-establishes a video display that's robust from then on as frame rates and resolutions change (I'm using a Pi Foundation Micro HDMI to HDMI short cable and then an Amazon HDMI 2.0b Premium Certified cable to the AVR, so break the connection at the in-line HDMI junction between the two cables)

I think I've seen something similar with this combo when I change screen resolution and/or frame rate settings in Raspberry Pi OS - so suspect it's something to do with underlying HDMI handling that the Pi and Denon don't agree on.

DV and HDR10+ dynamic metadata makes tonemapping content that is potentially outside your display's capabilities better (as HDR10 does to a lesser degree). However some manufacturers ignore the metadata (for HDR10 at least - treating it as PQ10) and use their own algorithms instead of using metadata information. (*)

Ironically DV and HDR10/10+ are based on PQ and a direct 1:1 link between video level and pixel nit light output - HLG isn't (it doesn't mandate a 1:1 mapping between video level and light output - it's relative instead), and HLG has built-in support for ambient light level compensation. Dolby have had to accept that PQ doesn't work for some viewing scenarios and use DV IQ to do something similar to what HLG can do.

Personally if DV and HDR10+ can improve my TV's peformance I'm happy to take it - but I'm not going to spend LOTS of money chasing after support for them. That said not having DV did partially influence me not to buy a Samsung Quantum Dot OLED - I've gone for an LG C3 (65").

(*) Some DV profiles use ICtCp colour space instead of YCbCr/YUV which can in theory improve picture quality as it better maps the high and low bandwidth channels to match the eye/brain perception - and also comes closer to constant luminance (I think) - which has always been an issue with YCbCr/YUV vs RGB gamma processing (I think). Other DV implementations use YCbCr/YUV HDR10/10+ base layers and add an enhancement layer to get nearer 12-bit representation rather than 10-bit - which can also help (You don't need a 12-bit capable display for the benefit as you'll get some benefits with tonemapped 12-bit content mapped to a reduced range 10-bit display I think)

Quote from wyup

Libplacebo open source library, which is "provided by ffmpeg as a Vulkan-based video filter, does native support for Dolby Vision HDR, including Profile 5 conversion to HDR/PQ or SDR, reading DV side data, and reshaping. (BL only, currently"). RPi4 has Vulkan 1.2 and GL 3.0 compatibility.

LE Wiki says:

Kodi supports Dolby Vision under Android (if the device is licensed for it) but not Linux. Dolby requires manufacturers to license their Intellectual Property and use integration libraries to decode the HDR metadata. Until FFMpeg comes up with a "clean room" reverse engineered open-source implementation, Kodi will not support it.

I guess this is an open source implementation that LE could use to decode Dolby Vision to HDR10.

Who could implement it, Kodi or LibreElec?

NB the CoreElec implementation for DV implemented on DV Licensed platforms requires that CoreElec Linux runs alongside an existing Android (including DV Support) installation and hooks into the DV decoder stuff in the Android file system and uses it within CoreElec. It's a neat solution that's VERY bespoke to specific installations - and only works on licensed systems (though is potentially pushing at the edges of legality - though I'm not a lawyer)

Quote from wyup

Well, at least decode DV to HDR10 with libplacebo open source library, provided as a vulkan-based video filter in FFmpeg?

Is this ICtCp to YCbCr/YUV conversion for native DV HEVC stuff that uses the ICtCp style representation? (Used for the DV profiles commonly used by Netflix, Prime, Apple TV+ etc.) rather than just using the DV RPUs to generate new metadata for HDR10 YCbCr/YUV encodes? (Ignoring FEL - Full Enhancement Layer - DV streams that expand the HDR10 stuff to >10-bit?)

Beware using 'DolbyVision' as a catch-all. There are lots of different variants of DV...

Some are based around YCbCr (aka YUV) PQ HDR10 or HLG 10-bit HEVC/h.265 and then Dolby Vision RPU metadata (and in some cases also an expansion layer to get from 10-bit to 12-bit depth). These can usually be replayed with no Dolby Vision licensing requirement for the HDR10/HLG stuff. Examples of this type of DV sources are Dolby Vision UHD Blu-rays and DV video shot on iPhones.

Other DV stuff is encoded purely in a DolbyVision video format using ICtCp representation and PQ instead of YCbCr/YUV - though still encoded in 10-bit HEVC/h.265. When these are replayed by non-Dolby Vision licensed devices they replay with magenta/green colours instead of normal colours, because they are interpreted as YCbCr when they aren't. This format is widely used for streaming platforms - where the streaming player can request a specific encode that it can play (rather than a single encode needing to be playable by multiple devices). The CoreElec DV implementation can play these OK, few other devices can.

Quote from wolfgang61

Pi 5 goes to Yamaha RX-V685 goes to a 4K TV.

Replacing the cable from Pi 5 to the Yamaha fixed the problem. I have no idea if this cable is 2.0 or whatever, but it looks more expensive.

Could it be that the Pi 5 produces a higher HDMI data rate than the Pi 4? Why is that so with the same video material? DVB-S2, HD. If so, that might be worth mentioning in future upgrade instructions. Or reduce the HDMI data rate to what is really needed for the actual video.

Different HDMI output resolutions, frame rates and bit depths require different bandwidth HDMI cables. I think both the Pi 4B and Pi 5 can output the higher bandwidth 18Gbs modes in 2160p60 4:2:2 12-bit (there isn't a 4:2:2 10-bit option in HDMI 2.0). Someone please correct me if I'm wrong.

However it could be that your previous set-up with a Pi 4B didn't try to use 18Gbs modes and your Pi 5 set-up is?

Quote from twilightened

I am still using the "9.2.8" version on a RPI3B. It is amazing how it can decode 10bit 1080p x265 videos with ease. If i install the new version, even 720p videos suffer. This goes to show that when optimized, software can do amazing things, even on low end hardware. We don't really need all that power.

To be fair - AIUI it's using GPU compute (i.e. offloading some computation to the GPU) to lighten the load on the CPU - so it's using more processing power than the CPU alone used for pure software decode can provide.

Quote from liverty

Agree that DTS-HD is a high-bitrate audio format that requires a more powerful processor than the Raspberry Pi 4. This may result in lags and interruptions in the audio.

Not sure I follow - the bitrate of DTS-HD Master Audio is no different to Dolby True HD or something like 192kHz 5.1 PCM? The Pi 4B can handle all of them OK in my experience. (It can also decode DTS HD MA to PCM with no major issue). Audio's not hugely processor-hungry (particularly if you aren't decoding it and just moving it from A to B).

The usual stuttering stuff is caused by work-in-progress buffer code, or a non-complete understanding of some of the specs, as this is all being partially implemented by enthusiasts trying to solve a problem, rather than people being paid to commercialise a product.

There was a long-standing issue relating to high-bitrate Dolby True HD on multiple platforms (including Intel ISTR) that took a while to get to the bottom of.