Posts by popcornmix

Feb 16 19:10:56.709875 LibreELEC kernel: vc4-drm gpu: [drm] *ERROR* Failed to read TMDS config: -121

I've never seen this error on a Pi. It comes from an SCDC command to check scrambling status (something specific to 4kp60 modes).

This uses the I2C pin (also used for reading edid) to communicate with the display.

I'd typically suggest trying with a different hdmi cable, trying a different hdmi input to display, or trying a different display.

But:

Quote

As of today, I use an RPi4 4GB in an Argon One housing.

Argon cases are widely reported to cause hdmi issues, so first step would be to test without the case.

A workaround would be to avoid 4kp60 modes (4kp30 should be okay).

As most 4k content is 24fps or 30fps this may not lose you much.

Choose 1080p60 as GUI resolution and enable 4kp24 and 4kp30 in the whitelist.

Quote from noggin

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

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

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

and

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

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

Quote from noggin

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.

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.

Quote from noggin

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.

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.

Quote from wyup

Any chance of LLDV decoding from Kodi on RPI4 (I read ffmpeg libplacebo can decode DV) and do HDR10 dynamic tonemapping like hdfury processor?

My TV is a Samsung and it doesn't decode DV.

I'd say no possibility for 4K video (neither cpu nor 3d hardware has performance for this).

I don't know if 1080p would be possible.

But most hdr content is 4k.

Quote from synrgii

I'm now seeing the latest version doesn't even have analogue output as an audio option anymore. So that's a definite deal-breaker for me with my old stereo system. Apparently I'm expected to either replace my hardware/stereo, or buy an additional adapter (micro-HDMI to audio) just because Kodi thinks I should be limited to just HDMI and bluetooth outputs?

Add "dtparam=audio=on" to config.txt.

Quote from chewitt

FWIW, I've not seen any issues with stalls and the iPlayer add-on; using an RPi5 not RPi4 but that shouldn't make any difference.

Have you tried "Watch Live"? Only that has the stall issue.

gpu_mem won't help with hevc playback. Setting it will just leave less memory for the system.

Remove the setting, and then post a debug/crash log.

Quote from noname101

I booted with no sdcard. The netboot screen came up and said ESC for diagnostics. I hit ESC and the screen went blank.

I said boot with just hdmi and power connected. No keyboard. Otherwise you won't get the diagnostic display.

Can you just connect hdmi and power (no sdcard inserted) and check output on display.

You should see a diagnostic screen. Report the output of the "display:" line.

Does adding "audio_pwm_mode=1" to config.txt help?

Quote from hundrakg

Still want to know why OMXPlayer dont support decode to 5.1 PCM 96khz, only MMAL does?

Im talkning about Rpi3

Simple answer is omxplayer is ancient and its replacements have had far more recent work on them including support for new features.

MMAL is still ancient (but a little less so). On Pi4 and Pi5 you can't use HBR audio passthrough (DTS-HD, TrueHD) with MMAL, but you can with the latest interfaces (arm side ALSA, and V4L2/DRM for video).

Quote from tomstephens89

Is this operating at 60fps?

Yes (assuming you have chosen 60 for framerate above.

"Unlimited/1080 > 30FPS" means no limit resolution when current hdmi mode is 30fps or lower, and limit to 1080p above that.

But really keep it at 1080p - the skin only renders to 1080p, so any higher is usually just slowing it down with no visible change.

Also see info here: https://wiki.libreelec.tv/configuration/4k-hdr

TLDR: set default hdmi mode to 1080p60 and whitelist any 4k modes you want when actually playing videos.

Quote from Michael_B

Disabling DRMPRIME in the expert settings solved the problem for me.

I wasn't aware that the hardware decoders can have such an impact on system stability. If the decoder stops playing my (maybe broken/non-standard) ile -> ok. But, freezing the whole RPi4?

Can you be more specific. There are a few combinations of options here that will narrow it down. You have:

1) Allow using DRM PRIME decoder

2) Allow hardware acceleration with DRM PRIME

3) PRIME render method

The default is 1=enabled, 2=enabled and 3=direct which you've reported as hangs

Can you test:

1=enabled, 2=enabled, 3=EGL

1=enabled, 2=disabled, 3=direct

1=enabled, 2=disabled, 3=EGL

1=disabled, 2=N/A, 3=EGL

As chewitt says, provide us with an example file. Ideally cut one down to a couple of minutes, confirm issue still occurs and upload it somewhere (e.g. google drive).

If you believe it occurs with all files, then can you test a publicly available file (e.g. Big Buck Bunny and confirm you still see the issue?

If you disable "Allow using DRM PRIME decoder" in settings/player/video then the orientation flag is supported.

But performance will be lower.

I think on the nightly builds, you can leave that setting enabled but change "PRIME Render method" to EGL,

which will have better performance (but still not as good as using DRM for rendering).

It may be possible to setup dual audio using pulseaudio combine-sink. See here:

Post

RE: Libreelec 10.0.1 on RPi-4B : Simultanous output to HDMI and Bluetooth Box?

it works for me

my /storage/.config/autostart.sh :

pactl load-module module-udev-detect

pactl load-module module-combine-sink slaves=alsa_output.0.hdmi-stereo,alsa_output.3.iec958-stereo



however I have 2 problems

1) playing video create sometimes echo artifacts (crackling) on hdmi output

2) playing spotify plugin librespot? causes lagging / pitch during palyback

Not sure if this is pulseaudio problem or HW is just too weak to send audio to 2 sinks.. (RPi3)

anyone knows?b

b22222222222

November 15, 2022 at 10:11 PM

Quote from Nahannidog

3. With old cable and 4KTV, I had flicker problems until resolution dropped all the way down to 720x576!!!! Any guesses as to why the old cable performed so much more poorly (poorly only with RPi4 & 4KTV, fine with RPi4 & 4K Monitor)? The microHDMI connector seems like a weak link, being so tiny. Or maybe 4KTV spews alot more EMI and old cable was poorly shielded?

The usual reason is thin wires, which means high resistance, which means significant voltage drop (and that is more significant with the higher resolution, higher clock frequency hdmi modes).

This video may be illuminating showing just how many random hdmi cables are sub-par.

My guess would be the HDMI cable. 4kp60 requires a very high clock rate and that needs a high quality cable.

Just because it works on another TV doesn't guarantee the cable is perfect (the other TV may just be better and handling a low level noisy signal).

But as chewitt says, follow the recommended instructions and you'll rarely be running at 4kp60 (most video content is 24fps) so are much less likely to hit the issue.