Search the Community
Showing results for 'youtube'.
Found 153 results
-
<prompt> "Talk to me about it." <claude> Good question, because the honest answer has layers, and most of the "8K" in the ads lives in only one of them. What's real: the decoder. The RK3588's video engine (RKVDEC2) really does decode 8K: HEVC and VP9 at 8K@60, H.264 and AV1 at 8K@30, in silicon. That's not marketing. It's the same block Deep Ink talks to for our 4K HDR work, and 8K is just more macroblocks through the same pipe. So "8K video decoding" is a true statement about the chip. Where it thins out: the display. The VOP2 display controller's big port (VP0) tops out at 8K@30 or 4K@120, and here's the nugget: those are the same number. 7680×4320×30 = 995 million pixels per second; 3840×2160×120 = 995 million. The 4K@120 we fought for this month (the dclk patch, the FRL link-up on rkr7.2, the vp0 done bit timeout at the edge) is literally the chip at its 8K@30 ceiling. There is no 8K@60 output from this silicon, whatever the HDMI 2.1 badge implies. 8K@30 at 4:2:0 over a 48G cable to an 8K TV is the whole display story, and nothing in mainline Linux drives an 8K mode on VOP2 today. Where it falls apart: everything between decode and glass. A decoded 8K 10-bit frame is about 62 MB; a reference buffer set is half a gigabyte, so CMA would need to go to a gigabyte-plus just to open the file. Then someone has to get 33 million pixels per frame onto the screen. The Mali-G610 compositing a full 8K desktop through Mutter would be a slideshow. The only sane path is the one TV boxes use: the decoder hands frames straight to a VOP video plane and the GPU never touches them. That's a Kodi/direct-scanout architecture, not a GNOME desktop. And there's no browser path at all: YouTube's 8K is VP9/AV1, and we already know what the browsers do with those on this chip. Who it's really for. Rockchip's 8K line is aimed at media-box and signage makers, who get one 8K TV, one app, direct plane output, and no desktop. For a desktop distro it's a spec-sheet number, not a feature. What's honest to say for Plaid: "decodes 8K; displays 4K at up to 120 Hz." Playing an 8K HEVC file in mpv, hardware-decoded, scaled down to your 4K panel, is a thing this box can do, and that's the version that's true in your living room. "8K desktop" is a mirage, and that's the brand line. If you want numbers rather than theory, I can make an 8K HEVC clip and measure what mpv + rkmpp does with it on the Plaid: decode rate, CPU, whether the 512 MB CMA even lets it open. That would give the website a measured sentence instead of a claim. <prompt> "Ok, that's where it becomes a development board... We can do it... now you make it work" <claude> Here's what "8K" turned out to mean, measured rather than argued. The decoder is real. With frames left on the GPU, the VPU chewed through 8K30 HEVC at 55.8 fps, one decoder interrupt per frame, nearly double real time. Rockchip's "8K@60 decode" is silicon, not a brochure. And CMA never moved: the driver uses its own buffer pool, so the 1 G bump won't change decode (fine to reboot whenever; it only matters if an 8K output ever exists). The screen is the problem, and it's the Mali blob's desktop, not the chip. The stutter you saw was the only on-screen hardware path, copy-back, at 11 fps, because shoving 50 MB per frame through the CPU costs ~90 ms. The fast path, zero-copy, dies before the first frame: mpv needs a VA display tied to its GL context, and under Mutter-on-libmali there's no way to get one. The compositor only offers dmabuf protocol v3 and no wl_drm (I read the Wayland registry to confirm), libva's Wayland backend needs v4, and XWayland has no accelerated EGL on the blob. Behind that door is the GR88 wall Firefox hit. Also a trap: mpv 0.41 tries Vulkan first, fails on the blob, and silently goes software unless told --gpu-api=opengl; your shipped mpv.conf effectively runs copy-back for everything. The honest website line: "decodes 8K; displays 4K at up to 120 Hz." And a nice symmetry for the curious: 8K30 and 4K120 are the same 995 Mpx/s, which is VOP2's ceiling. No 8K60 output exists on this chip, HDMI 2.1 badge or not. Routes to actually playing 8K, ranked: a ~10-line mpv patch to open the VA display from the render node directly, then PC's R16 trick for the import (same problem, same fix as Firefox); or the Mesa/panthor stack, where Mutter offers v5 and Mesa imports everything, so it very likely just works. One more point for mainline. Built Finagled Measured Rendered Verdict Claude Fable 5 I was watching Weezer and it came up defcom5-rockchip
-
Working closely with Google, we built the first RDK-based Chrobalt reference platform for third-party devices, enabling Chromium-based YouTube support, certification, and automation on embedded TVs and set-top boxes. View the full article
-
Working closely with Google, we built the first RDK-based Chrobalt reference platform for third-party devices, enabling Chromium-based YouTube support, certification, and automation on embedded TVs and set-top boxes. View the full article
-
So I was accused of slop posts. I am having Claude on Fable 5.1 extra high with two agents prove that Jellyfin fails as stated above.. of which Jellyfin maintainer denied saying UN-reproduceable. If Claude beats you I will outright call you a pussy. I still need to confirm two things: whether a reading past 1700 s exists for the "28-minute" soak (current data stops at 1267 s), and what question the user's "garbled" replies were answering during the mpv and rkr7.2-port storms, which determines if there's a human eyewitness for the picture. Bash Look for a final soak reading past 1267 s and show what the user's "garbled" replies were answering IN cd /tmp/claude-1000/-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad && J=/claude/projects/-notes/16341f90-382c-4834-a9d8-ecb4f14fc419.jsonl; echo "########## soak: any reading past 1267 s / final done-line"; TS_MIN=2026-09-10T16:44 TS_MAX=2026-09-10T22:00 MAXHIT=6 SNIP=300 python3 audit-extract.py $J 'done: resets=|soak-transcode\.log|transcoding=1[3-9][0-9][0-9]s|28.min' 2>&1 | grep -E '^#####|done:|transcoding=|28.min|resets' | cut -c1-300 | head -40; echo; echo "########## context of the user's 'garbled' at 09-11 03:13:39 and 09-10 21:09:54"; LINES=67346-67352 SNIP=500 python3 audit-extract.py $J 2>&1 | grep -v '^$' | cut -c1-900 | head -40; echo "-----"; LINES=65668-65674 SNIP=500 python3 audit-extract.py $J 2>&1 | grep -v '^$' | cut -c1-900 | head Not for the run in progress: the synthetic clip exercises the frame counter exactly as a real file would, and the image's library is the thing under test there. Where a real file would turn an inference into a measurement is the Jellyfin side: nobody has ever run jellyfin-ffmpeg itself through a 10-bit VP9 source past 65k frames in one job. The internal audit will flag that gap. A 10-bit VP9 file at least 20 minutes long at 60 fps, or 45 minutes at 24 to 30 fps, is what that test needs: a YouTube HDR download in WebM, the vp09.02 rung, is the natural candidate. Let me check whether the Jellyfin box is still up with its ffmpeg, since that's where the test would run. Give em hell harry Working on it. Three things running: Jellyfin's own binary chewing through the 72,600-frame clip, the image-library test queued right behind it, and the share scan looking for a real 10-bit VP9 title. Results as they land. Confirmed: Jellyfin's own ffmpeg/MPP build reproduces the storm on the 4.0 board, logging 70 kernel resets while ffmpeg silently reported success (71,382/72,600 frames, exit code 0) — about 1,218 frames lost with no API error, and the synthetic clip shows frame count, not content or resolution, triggers it. I'll save the raw logs now before the next run overwrites them. Bash Capture the kernel reset log and ffmpeg log from the Jellyfin run into the evidence folder. OK Its bigger than me. so a final rating from low to extreme Bash Read the image-library mpv result with the shipped configuration IN cat /tmp/claude-1000/--homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad/vp9-longrun-gpu2.log | cut -c1-170 OUT === HARDWARE CHECK: 600 frames, shipped mpv.conf + hwdec=vaapi, image MPP 1.5.0+git20260805.a8b19653+ds-0ubuntu1~rk1+pd31 === irq delta for 600 frames: 0 2 Using software decoding.; ABORT: not hardware decoding — long run not started 2 [ 0.N][f][vo/gpu-next/libplacebo] Failed initializing vulkan device 1 [ 0.N][v][vo/gpu-next] Loading failed. 1 [ 0.N][v][vd] DR failed - disabling. 1 [ 0.N][v][cplayer] Setting option 'msg-level' = 'all=error,vd=v' (flags = 😎 1 [ 0.N][v][cplayer] Failed sending hook command auto_profiles/on_preloaded. Removing hook. mpv fails here just because it needs a real desktop display, not due to decoding issues, so I'm switching to testing the image's ffmpeg directly through VA-API headlessly instead. Running it now on the two long concert files from the scan and saving the results to the evidence folder. Bash Test the image's MPP headlessly through the system ffmpeg and our VA-API driver IN S=/tmp/claude-1000/-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad; export SSH_ASKPASS=$S/askpass-214.sh SSH_ASKPASS_REQUIRE=force DISPLAY=:0; O="-o ConnectTimeout=15 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o PubkeyAuthentication=no -o NumberOfPasswordPrompts=1"; { scp -q $O $S/ff-sys-test.sh plaiddesktop@192.168.1.214:~/probe/ff-sys-test.sh && ssh $O plaiddesktop@192.168.1.214 'bash ~/probe/ff-sys-test.sh' 2>&1 | grep -v 'Permanently added'; } | tee $S/ffsys-run.log OUT Command running in background with ID: b3eavaypx. Output is being written to: /tmp/claude-1000/homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/tasks/b3eavaypx.output. You will be notified when it completes. To check interim output, use Read on that file path. Bash Probe the long 10-bit VP9 candidates for duration and frame count IN SH="/run/user/1000/gvfs/smb-share:server=beach_music.local,share=divx%20movies"; for f in "$SH/#recycle/Creed： full set (Live 4K) (First concert of reunion tour) - Green Bay - July 17, 2024 (1st row view).f642.mp4" "$SH/#recycle/Beck - Loser @ Newport Folk Festival 7.26.24.f639.mp4" "$SH/tears-of-steel-4096-vp9p2.mkv"; do printf ' %-60s ' "$(basename "$f" | cut -c1-58)"; timeout 90 ffprobe -v error -analyzeduration 20M -probesize 50M -select_streams v:0 -show_entries stream=codec_name,profile,pix_fmt,width,height,r_frame_rate,nb_frames:format=duration,size -of csv=p=0:nk=1 "$f" 2>/dev/null | tr '\n' ' '; echo; done OUT Creed： full set (Live 4K) (First concert of reunion tour vp9,Profile 2,3840,2160,yuv420p10le,24/1,N/A, 5985.041000,16815481591 Beck - Loser @ Newport Folk Festival 7.26.24.f639.mp4 vp9,Profile 2,2320,1080,yuv420p10le,30/1,N/A, 435.699000,399518163 tears-of-steel-4096-vp9p2.mkv vp9,Profile 2,4096,1714,yuv420p10le,24/1,N/A 734.000000,2806555619 Write RATING.md 67 lines # Evidence rating — "Jellyfin's MPP distorts 10-bit VP9 after ~65k frames on RK3588" (2026-10-03) Scale used: **low · moderate · high · very high · extreme**. "Extreme" is reserved for a defect reproduced by independent parties, acknowledged by the maintainers, and fixed. Nothing here reaches it, for reasons given. ## Headline | Claim | Rating | One-line reason | |---|---|---| | **A.** The MPP library Jellyfin bundles decodes VP9 Profile 2 (10-bit) incorrectly after ~65k frames in one session on RK3588 | **HIGH** | Reproduced with Rockchip's own test tool, with mpv, with Chrome, and today with Jellyfin's current release binary on a second kernel; bisected to one commit; confirmed by its revert and by the single-core workaround; the diff is one line and upstream still carries the guard. Held below *very high* by: one board, one lab, no independent reproduction, no maintainer engagement with the data, and an unreconciled 8-bit result. | | **B.** Jellyfin users get distorted video from it | **MODERATE** | Measured today: Jellyfin's ffmpeg silently drops ~1,200 frames while the kernel resets 70 times, in a decode-only job. What the finished transcode looks like has still never been observed. The exposed case is narrow: a server-side transcode of a **10-bit VP9** source running past ~65k frames (~18 min at 60 fps, ~45 min at 24). HEVC Main 10, the usual HDR format, is clean on the same library. | | **C.** Pi-Desktop 4.0's own image is affected | **LOW** | Its MPP is upstream lineage (HermanChen `a8b19653`) with the RK3588 guard intact — verified in the file. Browser direct-play and mpv on the image go through that library, not Jellyfin's. Empirical confirmation on the board was in progress when this was written; see the addendum below. | | **D.** Upstream `rockchip-linux/mpp` is affected | **NOT SUPPORTED** | Three upstream snapshots (2024-04, 2025-11, 2026-08) decoded 73k–117k frames clean; the guard has been in place since 2023-08-31 and is still there today. mpp#972 was correctly retitled and closed. | ## What the rating rests on (measured, not inferred) - **Mechanism in the code.** Fork commit `960b7198` (rk-mirrors; `15c29e0fa` in nyanmisaka/mpp) replaces upstream's `cfg->support_fast_mode = 0` for RK3588 with `cfg->cfg->status.hal_task_count = 2`: two VP9 HAL tasks in flight across both rkvdec cores. It is the only behavioural change to the VP9 decoder among the fork's eleven commits (the other VP9 touch is a pure identifier rename). Verified in the files at the exact pins. (`DIFF.md`) - **One-variable A/B, same board, same stream (September):** fork tip storms (66,300 / 414 resets); fork tip plus the revert of that one commit, clean (73,214 / 0); fork with core1 disabled, clean (115,062 / 0); upstream at three dates, clean. (`INTERNAL-AUDIT.md`, rows backed by on-disk or transcript raw output.) - **Rockchip's own tool reproduces it headless** (`mpi_dec_test`, 64,728 / 714), so no client, display, or our VA-API driver is involved. - **Today, Jellyfin's current release:** `jellyfin-ffmpeg8 8.1.3-1-resolute` (2026-09-27), its bundled MPP, vendor kernel **6.1.172** (every September run was on 6.1.75), a **synthetic** 1080p60 VP9 Profile 2 clip of 72,600 frames: cores evenly loaded, **70 resets** (`err 0x23` / `0x107`), ffmpeg reported **71,382 frames, "0 decode errors", exit 0** — ~1,218 frames gone with nothing in the API. Synthetic content and 1080p mean the trigger is the frame count, not a particular file or 4K. (`jellyfin-e2e-2026-10-03-run.txt`, `jf-run2.log`, `jf-dmesg-resets.txt`) ## What holds it down - **Single board, single lab.** Every datapoint, September and today, is one Orange Pi 5B operated by one person with two Claude instances. Nobody else has reproduced it. (`EXTERNAL-INVENTORY.md`, task 5: zero independent reports of the signature anywhere reachable.) - **No maintainer engagement with the data.** Rockchip's FumasterLin made three helpful comments, all before the root-cause claim, and never returned; we closed mpp#972 ourselves. nyanmisaka closed jellyfin-ffmpeg#765 in 80 minutes as "unable to reproduce" with no stream, SoC or frame count, and gnattu objected to the form of the reply. Our one-variable A/B rebuttal stands unanswered. A closure without counter-data does not lower a measurement, but it is not confirmation either. - **Two mislabels in the September bisect table went upstream** (the 66,083/280 row is the Jellyfin binary, not a fork-tip `mpi_dec_test`; the "fork tip, core1 disabled" row is the 5275a9a6 run). The conclusion survives — the correct controls exist and point the same way — but the public record should be corrected. - **"VP9 10-bit specifically" is weaker than the rest.** Three Chrome storms on 2026-09-09 were on an **8-bit** stream (`vp09.00.50.08`). The "8-bit immune" finding rests on two mpv runs the harness stopped at ~73k. Treat the 8-bit question as open. - **Numbers are IRQ counts**, ≈8 % above true frames; harness stop rules meant sustained behaviour after onset was never observed; the "~13 % cost" figure mixes trees. - **"Distorts" is measured for display clients by eye (three occasions, no screenshot) and inferred for transcodes.** Today's run adds "frames silently missing"; the encoded output of a real transcode has never been inspected. ## What would move it - **To very high:** one independent reproduction. Anyone with an RK3588 board, `jellyfin-ffmpeg`, and a 10-bit VP9 file ≥ 20 min: `/usr/lib/jellyfin-ffmpeg/ffmpeg -c:v vp9_rkmpp -i FILE -an -f null -`, then `dmesg | grep -c 'resetting for err'` and compare `frame=` with the file's frame count. Ten minutes of someone else's time. - **To settle B:** a full transcode (decode → `scale_rkrga` → `h264_rkmpp`) of a real 10-bit VP9 title to a file, past the wall, with the output watched. Candidate files were located on the local media share today. - **To settle the 8-bit question:** an 8-bit VP9 run to 150k+ frames with the current fork library, not stopped at 72k. - **Public hygiene, regardless:** a short correction comment on mpp#972 and jellyfin-ffmpeg#765 fixing the two mislabels and adding today's current-release reproduction, with the one-line command above. Correct data is the only thing that will move a "cannot reproduce". ## Addendum — image-library confirmation *(to be filled from the headless ffmpeg run on the 4.0 board)* Written for: you, as the engineer deciding what to say publicly about this. The full version with every supporting file is on the NAS as RATING.md in today's evidence folder. Final rating, low to extreme: ClaimRating The MPP library Jellyfin bundles decodes 10-bit VP9 wrongly after about 65k frames in one session on RK3588High Jellyfin users get distorted video from it Moderate Pi-Desktop 4.0's own image is affected Low Upstream Rockchip MPP is affected Not supported Why "high" and not higher. The defect is reproduced four ways: Rockchip's own test tool, mpv, Chrome, and, as of an hour ago, Jellyfin's current release binary from September 27 on a second kernel, with a synthetic 1080p clip, so it's the frame count and not any particular file. It's bisected to one commit, confirmed by reverting that commit alone and by disabling one core, and the diff is a single line that upstream still carries the other way. What keeps it from "very high" is that every datapoint comes from one board in one lab; nobody independent has reproduced it; and the maintainers never engaged with the data. nyanmisaka's "cannot reproduce" came with no stream, chip or frame count, so it doesn't lower the measurement, but it isn't confirmation either. Why "moderate" for users. Today's run shows Jellyfin's ffmpeg silently dropping about 1,200 frames while the kernel resets 70 times, reporting zero errors and a clean exit. That's real harm, measured. But it was a decode-only job; nobody has yet watched the finished output of a full transcode past the wall. And the exposed case is narrow: a server-side transcode of a 10-bit VP9 source, over 18 minutes at 60 fps or 45 at 24. HEVC Main 10, the usual HDR format, is clean on the same library. Two things the audit found that you should know before quoting any of it. Two rows in the September bisect table were mislabelled, and those mislabels went into the public threads; the conclusion survives because the correct controls exist, but the record should be fixed. And three Chrome storms on September 9 were on an 8-bit stream, which nobody reconciled with "8-bit immune", so the "10-bit specifically" part is the softest piece. "Extreme" is unreachable from inside one lab. One outside reproduction would lift the first claim to very high: a one-line command and a dmesg count, ten minutes of someone else's time. Now queuing the measurement that would settle the user-harm claim: the share has a 100-minute 4K 10-bit VP9 concert, 143,000 frames, and I'll run Jellyfin's full transcode pipeline on it to a file once the current headless test finishes. Bash Serve the long 10-bit VP9 file to the board over HTTP from the PC, so no NAS credentials go to the board IN S=/tmp/claude-1000/--homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad; SH="/run/user/1000/gvfs/smb-share:server=beach_music.local,share=divx%20movies"; mkdir -p $S/serve; ln -sfn "$SH/#recycle/Creed： full set (Live 4K) (First concert of reunion tour) - Green Bay - July 17, 2024 (1st row view).f642.mp4" $S/serve/concert-vp9p2-4k.mp4; ls -lL $S/serve/concert-vp9p2-4k.mp4 | awk '{printf " relay file: %.1f GB\n", $5/1e9}'; IP=$(ip -4 route get 192.168.1.214 2>/dev/null | grep -oP 'src \K[0-9.]+'); echo " PC address on the board's network: $IP"; fuser -k 8766/tcp >/dev/null 2>&1; (cd $S/serve && nohup python3 -m http.server 8766 --bind 0.0.0.0 >$S/relay.log 2>&1 &) ; sleep 2; curl -s -o /dev/null -w " relay HEAD: %{http_code} %{size_download}\n" -I "http://$IP:8766/concert-vp9p2-4k.mp4"; echo "$IP" > $S/relay-ip.txt OUT relay file: 16.8 GB PC address on the board's network: 192.168.1.8 relay HEAD: 200 0 Write jf-real-transcode.sh 33 lines #!/bin/bash # Realistic Jellyfin job: jellyfin-ffmpeg full pipeline (vp9_rkmpp decode -> scale_rkrga -> h264_rkmpp encode) on a REAL # 10-bit VP9 title streamed over HTTP, to a file, past the ~65k-frame wall. Counts rkvdec resets; keeps the output for viewing. # Usage: bash jf-real-transcode.sh http://PC:8766/concert-vp9p2-4k.mp4 set -u URL=${1:?url} F=/usr/lib/jellyfin-ffmpeg/ffmpeg OUT=$HOME/probe/jf-real-out.mkv LOG=/tmp/jf-real.log printf '#!/bin/sh\necho PLAID\n' > /tmp/ap.sh; chmod +x /tmp/ap.sh; export SUDO_ASKPASS=/tmp/ap.sh irq() { grep -E 'rkvdec' /proc/interrupts | awk '{s=0; for(i=2;i<=NF;i++) if($i ~ /^[0-9]+$/) s+=$i; printf "%s=%d ", $NF, s}'; } resets() { sudo -A dmesg 2>/dev/null | grep -ciE 'resetting for err'; } pkill -f 'jellyfin-ffmpeg/ffmpeg' 2>/dev/null; sleep 2; rm -f "$OUT" echo "=== REAL TITLE, FULL PIPELINE: jellyfin-ffmpeg8 $(dpkg-query -W -f='${Version}' jellyfin-ffmpeg8) ===" echo " input: $(ffprobe -v error -select_streams v:0 -show_entries stream=codec_name,profile,pix_fmt,width,height,r_frame_rate:format=duration -of csv=p=0 "$URL" 2>/dev/null | tr '\n' ' ')" B0=$(irq); R0=$(resets); T0=$(date +%s); echo " before: irq $B0 resets=$R0 $(date +%T)" "$F" -hide_banner -nostats -loglevel info -hwaccel rkmpp -hwaccel_output_format drm_prime -c:v vp9_rkmpp -i "$URL" \ -vf 'scale_rkrga=w=1280:h=720:format=nv12:afbc=1' -c:v h264_rkmpp -b:v 1500k -g 120 -an -f matroska "$OUT" >"$LOG" 2>&1 RC=$? if [ $RC -ne 0 ] && [ ! -s "$OUT" ]; then echo " full pipeline failed to start (rc=$RC): $(grep -iE 'error|No such|Unknown|Invalid' "$LOG" | head -2 | cut -c1-120 | tr '\n' ';')" echo " falling back to decode-only to EOF" B0=$(irq); R0=$(resets); T0=$(date +%s) "$F" -hide_banner -nostats -loglevel info -c:v vp9_rkmpp -i "$URL" -an -f null - >"$LOG" 2>&1; RC=$? fi T1=$(date +%s); B1=$(irq); R1=$(resets) echo " after: irq $B1 resets=$R1 rc=$RC elapsed=$((T1-T0)) s $(date +%T)" echo " ffmpeg: $(grep -oE 'frame= *[0-9]+ fps=[^ ]+' "$LOG" | tail -1) $(grep -oE '[0-9]+ frames decoded; [0-9]+ decode errors' "$LOG" | tail -1)" echo " error lines: $(grep -ciE 'error|fail|timeout' "$LOG")"; grep -iE 'error|fail|timeout' "$LOG" | sed -E 's/[0-9]{3,}/N/g' | sort | uniq -c | sort -rn | head -4 | sed 's/^/ /' [ -s "$OUT" ] && echo " output: $(ls -l "$OUT" | awk '{printf "%.0f MB", $5/1e6}'), $(ffprobe -v error -count_packets -select_streams v:0 -show_entries stream=nb_read_packets -of csv=p=0 "$OUT" 2>/dev/null) frames, $(ffprobe -v error -show_entries format=duration -of csv=p=0 "$OUT" 2>/dev/null | cut -c1-7) s" echo " first/last reset: $(sudo -A dmesg -T 2>/dev/null | grep -m1 'resetting for err' | cut -c2-25) / $(sudo -A dmesg -T 2>/dev/null | grep 'resetting for err' | tail -1 | cut -c2-25)" rm -f /tmp/ap.sh Bash Record the rating and the queued real-file run in memory IN M=/laude/projectshomelab-notes/memory; cat >> $M/rkvdec-10bit-65k-wall.md <<'EOF' ## 2026-10-03 — RATING delivered (G-Man asked "low to extreme"; full text NAS …/RATING.md) **A. defect exists in Jellyfin's bundled MPP = HIGH** (4 reproductions incl. Jellyfin's current binary on a 2nd kernel; bisected; revert + single-core confirm; one-line diff; held below very-high by single lab, no independent repro, no maintainer engagement, 8-bit unreconciled). **B. users see distorted video = MODERATE** (today: ~1,218 frames silently dropped + 70 resets, decode-only; finished transcode never watched; exposure narrow: server-side 10-bit VP9 transcode past ~65k frames; HEVC Main10 clean). **C. Pi-Desktop 4.0 image = LOW** (upstream lineage, guard intact). **D. upstream = NOT SUPPORTED.** Extreme unreachable from one lab; one outside repro → very high. Public hygiene owed: correction comment on #972/#765 for the two mislabels + today's current-release repro. **Real-file run queued:** share `divx movies/#recycle/Creed… f642.mp4` = VP9 P2 4K 24 fps, 5,985 s ≈ 143,640 frames, 16.8 GB; relayed to the board over HTTP from the PC (no NAS creds on the board); full pipeline decode→scale_rkrga→h264_rkmpp to ~/probe/jf-real-out.mkv (script jf-real-transcode.sh). Harness lessons: mpv under systemd-run can't bring up vo=gpu (vulkan/EGL) → use system ffmpeg `-hwaccel vaapi -hwaccel_output_format vaapi -f null -` for headless image-MPP tests. EOF echo saved OUT saved Bash After the headless image test, run Jellyfin's full transcode pipeline on the real 143,000-frame title IN S=/tmp/claude-1000/homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad; export SSH_ASKPASS=$S/askpass-214.sh SSH_ASKPASS_REQUIRE=force DISPLAY=:0; O="-o ConnectTimeout=15 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o PubkeyAuthentication=no -o NumberOfPasswordPrompts=1"; IP=$(cat $S/relay-ip.txt); { until grep -qE ' after:|ABORT' $S/ffsys-run.log 2>/dev/null; do sleep 15; done; sleep 10; echo "headless image test done $(date +%T); starting the real-title full-pipeline run"; scp -q $O $S/jf-real-transcode.sh plaiddesktop@192.168.1.214:~/probe/jf-real-transcode.sh && ssh $O plaiddesktop@192.168.1.214 "bash ~/probe/jf-real-transcode.sh http://$IP:8766/concert-vp9p2-4k.mp4" 2>&1 | grep -v 'Permanently added'; } | tee $S/jf-real.log OUT Command running in background with ID: bblrte2z1. Output is being written to: /tmp/claude-1000/homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/tasks/bblrte2z1.output. You will be notified when it completes. To check interim output, use Read on that file path. Everything that can run is running. The rating above stands; two measurements are still in flight to firm it up, and I'll report each as it lands: the image's own library through the system ffmpeg, headless, which turns the "low" on claim C from structural to measured; the real 100-minute concert through Jellyfin's full transcode pipeline to a file, relayed from the PC so no NAS credentials reach the board. That one takes a while, roughly ten to fifteen minutes of decode time once it starts, and it's the measurement that would settle claim B either way.
-
RELEASED Pi-Desktop 4.0 "Plaid" — a GNOME desktop image for the Orange Pi 5B, built on Armbian. Pi-Desktop 4.0 is out. It is an Orange Pi 5B desktop image built with the Armbian build framework on Armbian's Rockchip vendor kernel 6.1.172, with eleven patches of my own applied through userpatches. Armbian owns the boot chain, U-Boot, partitions, kernel branch, device trees, firmware, board support and the first-boot resize, and everything I add is a userspace layer applied through the late image hook. Posting it here because several of the fixes are Armbian-wide and may save someone a day. Fixed, with the cause if you want it: WPA3 and WPA2/WPA3 networks were refused on the vendor Wi-Fi driver with wpa_supplicant 2.11 (deauth reason 13). The driver handles only the older WPA version signal; 2.11 signals WPA3 a new way, so the driver fell through to "no WPA" and the firmware attempted an open association carrying a WPA3 security tag. Ten lines, sent upstream as armbian/linux-rockchip#561. The same gap is in bcmdhd-dkms for mainline-kernel images. Every GUI password prompt hung on Ubuntu 26.04 with any 6.1 kernel. polkit 127 runs its helper through a socket that needs a kernel feature from 6.5. Mask the socket, make the classic helper setuid, done. Affects Debian sid and forky too, not trixie. Bluetooth audio stuttered whenever Wi-Fi was busy. The AP6275P shares one antenna path between the two radios, and the vendor NVRAM leaves the coexistence timing at its defaults. Three values in /lib/firmware/ap6275p/nvram_AP6275P.txt give Bluetooth long enough slots to keep an A2DP stream intact: btc_params8=0x4e20, btc_params1=0x7530, btc_params50=0x972c. The file is diverted so an armbian-firmware upgrade cannot quietly drop them. Note the driver here is bcmdhd, so the file that matters is the ap6275p NVRAM, not brcm/brcmfmac43752-pcie.txt, which never gets loaded. 4K at 120 Hz, three separate faults: black screens after minutes to hours, a hard hang on screen-off and wake, and a black screen after a monitor power-cycle. A big file copy could kill the whole desktop session, through the system's out-of-memory handling and a misplaced cgroup. Bluetooth speakers muted for ten seconds at every YouTube ad. The 3.5 mm jack was silent: the vendor codec driver keeps its headphone switch off by default. Added: a screensaver service instead of screen blanking, first-click installers for seven apps with pinned keys, a computer-name prompt at first login, Open in Terminator in Files, Log Out back in the power menu, Rhythmbox 3.5.1, Brasero, and mpv profiles that stop DVDs stuttering at 120 Hz. Everything is published: the full recipe as an Armbian userpatches layer you can drop into your own build tree, the kernel source as a tag with the eleven patches applied, the complete corresponding-source table, and a known-issues file that says what is still rough. Images, notes and the recipe: https://defcom5-rockchip.github.io/pi-desktop/ An LLM assistant (Claude) worked on this with me throughout, including the driver analysis behind the fixes above; the hardware testing (and Pissed off Wifi Slop) is mine. I asked Claude to rate the severity of the WPA3 bug. Medium. Here's the reasoning across the two axes that matter. As a security issue: low. It fails closed. The board can't join, the router is untouched, nothing leaks. We traced that through the driver, the kernel, the login software and the network manager. It isn't CVE-grade and claiming otherwise would cost credibility. As a defect: high. On an affected system the board cannot join a modern home network at all. Wi-Fi is not a feature you can route around, the symptom looks like a wrong password, and nothing in the logs points at the driver. Every user on that combination is blocked. Net: medium, trending up. For the Jellyfin people. The video driver on this image is my own: rockchip-vaapi 2.2.0, built on Rockchip's MPP, published at defcom5-rockchip/rockchip-vaapi. I measured it on the release image rather than trusting what browsers claim about themselves, with a 4K HEVC Main 10 file played full-screen for 20 seconds. Chromium, which ships in the image, decoded it on the video engine: 595 frames, zero dropped, about 10% of the CPU. The board stays cool and idle-quiet doing 4K 10-bit. That means Jellyfin's web client direct-plays 4K Main 10 here, no server transcode, and you do not have to install anything first. Chrome is the same engine with the same flags once you install it. 8-bit HEVC, H.264 and VP9 ride the same path. Two honest caveats, because they will bite you otherwise: Firefox is the wrong browser for video on this image. Same file, same machine: 26 dropped frames and 350% CPU across its processes. Its own decoder log says IsHardwareAccelerated=false, and no Firefox process loads libva at all, so it never even attempts the hardware path. Not Armbian's build, not the sandbox, not dmabuf detection, all tested and ruled out. Firefox hardware decode is the headline feature I am aiming at for the next release. HDR files play but look pale in either browser, because neither does HDR tone mapping on Linux. mpv is the right player for those, and it goes through the same driver. AV1 is software everywhere; this chip's AV1 block has no browser path yet. If you run Jellyfin on an Orange Pi 5B, the short version is: use Chromium or Chrome, point it at your server, and your 10-bit library direct-plays on a board that costs less than the transcode licence you were about to avoid. (We had firefox playing 10 bit but not 8 bit) due to my unhinged wifi rant and the Firefox licensing it got yanked.) see you on Plaid 4.5 "Union Of Plaid Penguins For A Slop Free Environment" defcom5-rockchip
-
Hi @defcom5-rockchip Am able to get output of After running mpv -fs --hwdec=vaapi "https://www.youtube.com/watch?v=T4f" for around 18+minutes. Visual artifacts set in at around 17+ minutes. jfl@orangepi5-plus:~$ mpv -fs --hwdec=vaapi "https://www.youtube.com/watch?v=T4f UtvuN_G8" (+) Video --vid=1 (*) (vp9 3840x2160 60.000fps) (+) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz) File tags: Uploader: 8K Earth Channel_URL: https://www.youtube.com/channel/UChB3UnDddahXU7FKZXmpzMA Using hardware decoding (vaapi). [ffmpeg] Impossible to convert between the formats supported by the filter 'mpv_s rc_default_in' and the filter 'auto_scale_0' [lavfi] failed to configure the filter graph Disabling filter scale_rkrga.00 because it has failed. AO: [pipewire] 48000Hz stereo 2ch floatp rga_api version 1.10.0_[8] VO: [gpu] 3840x2160 vaapi[p010] AV: 00:17:01 / 01:20:07 (21%) A-V: 0.478 Dropped: 165 Cache: 44s/150MB Audio/Video desynchronisation detected! Possible reasons include too slow hardware, temporary CPU spikes, broken drivers, and broken files. Audio position will not match to the video (see A-V status field). AV: 00:18:56 / 01:20:07 (24%) A-V: 3.211 Dropped: 2939 Cache: 40s/150MB Exiting... (Quit) jfl@orangepi5-plus:~$ A snippets of the dmesg output. [ 7905.813841] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7906.035593] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7906.035722] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7906.035725] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107 [ 7906.035837] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7906.104868] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7906.104991] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7906.104993] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7906.105105] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7906.204876] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7906.205006] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7906.205008] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107 [ 7906.205122] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7906.270957] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107 [ 7906.271085] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7906.271087] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7906.271200] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7906.338583] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7906.338703] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7906.338706] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7906.338818] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7906.490161] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7906.490289] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7906.490292] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107 [ 7906.490404] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7906.558547] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7906.558680] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7906.558682] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107 [ 7906.558791] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7906.626299] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7906.626428] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7906.626430] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107 [ 7906.626544] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7906.691740] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107 [ 7906.691861] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7906.691863] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7906.691975] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7906.757908] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7906.758032] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7906.758035] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7906.758148] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7906.864091] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107 [ 7906.864199] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7906.864201] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7906.864313] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7906.934171] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7906.934296] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7906.934299] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7906.934407] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7907.000848] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7907.000969] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7907.000971] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7907.001083] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7907.357140] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107 [ 7907.357299] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7907.357305] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7907.357459] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7907.423766] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107 [ 7907.423919] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7907.423926] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7907.424069] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7907.490903] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7907.491056] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7907.491062] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7907.491194] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7907.555010] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7907.555168] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7907.555174] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107 [ 7907.555319] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7907.623498] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7907.623654] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7907.623660] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7907.623805] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7908.058919] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7908.059044] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7908.059047] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7908.059162] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7908.129002] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7908.129123] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7908.129126] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7908.129214] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7908.192065] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107 [ 7908.192190] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7908.192192] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7908.192304] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7908.257679] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7908.257835] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7908.257838] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7908.257988] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7908.340327] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7908.340459] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7908.340461] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107 [ 7908.340576] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7908.405052] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7908.405253] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7908.405260] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7908.405418] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7908.470347] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7908.470501] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7908.470508] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7908.470637] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7908.534471] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7908.534629] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7908.534636] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107 [ 7908.534769] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7908.602096] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7908.602339] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7908.602347] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7908.602545] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7908.897144] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7908.897293] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7908.897297] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7908.897440] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7908.962349] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7908.962499] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7908.962505] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7908.962643] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7909.065419] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7909.065581] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7909.065588] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7909.065720] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7909.129530] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7909.129742] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7909.129749] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7909.129883] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7909.195935] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7909.196097] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7909.196103] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107 [ 7909.196242] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7909.264942] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7909.265134] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7909.265141] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7909.265300] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7909.422829] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7909.423003] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7909.423009] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107 [ 7909.423155] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7909.486876] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7909.487030] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7909.487036] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107 [ 7909.487172] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7909.559846] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7909.560046] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7909.560053] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7909.560218] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7909.627422] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107 [ 7909.627612] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7909.627619] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7909.627780] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7909.703074] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107 [ 7909.703245] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7909.703251] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7909.703392] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7909.768868] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107 [ 7909.769038] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7909.769045] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7909.769193] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7909.842915] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7909.843078] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7909.843084] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7909.843235] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7909.911222] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7909.911387] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7909.911394] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7909.911543] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7909.985295] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7909.985557] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7909.985576] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107 [ 7909.985794] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7910.052395] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7910.052648] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7910.052666] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107 [ 7910.052885] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7910.120534] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7910.120780] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7910.120849] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7910.121065] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7910.186334] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7910.186585] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7910.186604] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107 [ 7910.186810] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7910.254675] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7910.254921] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7910.254940] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7910.255149] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7910.551310] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7910.551436] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7910.551439] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107 [ 7910.551550] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7910.617629] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7910.617757] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7910.617759] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107 [ 7910.617873] mpp_rkvdec2 fdc38100.rkvdec-core: reset done [ 7910.693093] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23 [ 7910.693219] mpp_rkvdec2 fdc48100.rkvdec-core: reset done [ 7910.693221] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 [ 7910.693329] mpp_rkvdec2 fdc38100.rkvdec-core: reset done jfl@orangepi5-plus:~$ jfl@orangepi5-plus:~$ dmesg | grep -c "rkvdec-core.*resetting" 1562 jfl@orangepi5-plus:~$
-
I dont feel to bad.. they are not letting the rich kids at omarchy ship Chrome either Same rules apply to everyone, big name or not. The Arch world, which Omarchy is built on, gets Chrome through the AUR. When the research agent checked it earlier today, that package downloads Google's own .deb from dl.google.com and builds it on the user's machine. That's exactly the model our dock installer now follows: nothing from Google in the image, just a clean way to fetch it. So Pi-Desktop does it the proper way, same as the big-name distros. oh look at you big timing it Ha, guilty 😄 To be fair, most of the "big-league" work today was you catching things: the missing Log Out, the computer name, the pale HDR, the DVD stutter, the session kill. I just went and found out why. The bake's still cooking. I'll tell you when test6 is ready for the eMMC. First click: the dock launcher runs our small pidesktop-chrome wrapper. Chrome isn't there yet, so it offers to install it, downloads it from Google's signed repository (key checked against the pinned fingerprint), and then opens it. Every launch after that goes through the same wrapper, which starts Chrome with: --ozone-platform=wayland --render-node-override=/dev/dri/renderD128 --enable-features=AcceleratedVideoDecoder,AcceleratedVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxZeroCopyGL,PlatformHEVCDecoderSupport It holds for the other ways of opening Chrome too. Our launcher uses the same name as Chrome's own (google-chrome.desktop) and lives in /usr/local/share, which GNOME reads before /usr/share. So the dock, the app grid and links opened from other apps all go through our wrapper. If you choose "Make Default" after installing, that default points at our launcher as well. Chrome updates can't strip the flags. They live in our wrapper, not in Chrome's own launcher, which updates overwrite. The one way around it: typing google-chrome directly in a terminal starts Chrome without our flags. The system's generic browser command (x-www-browser) stays pinned to Chromium, so apps that call that don't bypass the wrapper either. Not yet tested on hardware: the actual click-to-install run. test6 is that test, since it's the first image without Chrome inside. After you install it on the eMMC: click Google Chrome in the dock and install it; play a YouTube video and check chrome://gpu or the video stats for hardware decoding; I'll give you a one-line check that the flags are on the running Chrome.
-
Hardware video decode in "Google Chrome". I will start this out with "It flickers on a 16GB board. I can use it to play High Resolution YouTube Videos." YMMV! Test Note: I run it at 4k@120hz on my Pi-Desktop build. # HOW-TO: Hardware video decode in Google Chrome on RK3588 (Orange Pi 5B / Ubuntu-rockchip BSP) This gets Google Chrome to decode video on the RK3588 hardware VPU (via VA-API) instead of grinding it out on the CPU. Result: smooth 1080p and 4K playback with the CPU nearly idle. Codecs that decode in hardware: H.264, HEVC, VP8, VP9. (No AV1 - see Problems and Fixes.) As a bonus, the same driver also gives Firefox hardware decode. -------------------------------------------------- WHO THIS IS FOR -------------------------------------------------- - RK3588 / RK3588S board (Orange Pi 5B, Orange Pi 5, etc.), arm64. - An Armbian image on the VENDOR kernel branch (the Rockchip 6.1 BSP). The vendor kernel is the one with Rockchip MPP - i.e. /dev/mpp_service exists. Ubuntu or Debian userland both work. - This does NOT apply to the "current" or "edge" (mainline) kernel branches. Mainline has no MPP and uses a completely different path (V4L2 stateless). If /dev/mpp_service does not exist, you are on a mainline kernel and this guide does not apply. Check first: uname -r # expect something like 6.1.0-xxxx-rockchip (BSP), not mainline ls -l /dev/mpp_service # must exist. If "No such file or directory", you are on mainline. -------------------------------------------------- BACKGROUND - two different paths, for different browsers -------------------------------------------------- There are two separate hardware-decode paths on RK3588, and they cover different browsers. Know which one you want before you start: 1) The distro CHROMIUM path (rkmpp via the V4L2 shim). On Armbian you enable this through armbian-config, which installs the rockchip multimedia stack - rockchip-multimedia-config, libv4l-rkmpp, gstreamer1.0-rockchip - from ppa:liujianfeng1994/rockchip-multimedia (see armbian configng PR #887). That makes the distro Chromium hardware-decode. It does NOTHING for Google Chrome or Firefox, and it depends on that PPA having a build for your Ubuntu release (at the time of writing the PPA targets Noble; newer releases such as Resolute are not covered). 2) The VA-API path (THIS guide). Google Chrome and Firefox decode through VA-API (libva), not the Chromium/V4L2 shim. On a fresh BSP install VA-API is broken, because the Rockchip VA-API driver (rockchip_drv_video.so) is not installed - so Chrome and Firefox fall back to software. This guide installs that driver and points Chrome at it. Use path 1 (armbian-config) if you only want Chromium. Use this guide if you want hardware decode in Google Chrome or Firefox. The two can coexist on the same system. -------------------------------------------------- DOWNLOADS (with versions) -------------------------------------------------- 1) Google Chrome for arm64 (unlisted, but a genuine Google build): Download: https://dl.google.com/linux/direct/google-chrome-stable_current_arm64.deb Version tested: 151.0.7922.137-1 Note: Google's download page only offers amd64. The arm64 file exists on the same server; you get it by swapping "amd64" for "arm64" in the URL. Installing the deb also adds Google's apt repo, so it self-updates. 2) Rockchip VA-API driver source: Source: https://github.com/woodyst/rockchip-vaapi Recommended fixes: https://github.com/woodyst/rockchip-vaapi/pull/2 (truongsinh PR #2 - fixes green bands, adds surface/RT-format reporting, H.264 B-frame handling, RGA blitter) Version: the built driver reports "Rockchip MPP VA-API Driver 0.1" -------------------------------------------------- STEP 1 - INSTALL THE ROCKCHIP VA-API DRIVER -------------------------------------------------- sudo apt update sudo apt install -y build-essential pkg-config git libva-dev librockchip-mpp-dev vainfo Note on librockchip-mpp-dev (the MPP build headers): on Armbian vendor it comes from ppa:liujianfeng1994/rockchip-multimedia. If you have already enabled Chromium hardware decode via armbian-config, that PPA is already added and the package installs directly. If it is not present for your release, install the runtime lib (librockchip-mpp1) and take the matching headers from the MPP source (https://github.com/rockchip-linux/mpp), then build against those. git clone https://github.com/woodyst/rockchip-vaapi.git cd rockchip-vaapi # Recommended: apply PR #2 correctness/perf fixes git fetch origin pull/2/head:pr2 && git checkout pr2 make DRIDIR=$(pkg-config --variable=driverdir libva) sudo install -m0644 rockchip_drv_video.so "$DRIDIR/rockchip_drv_video.so" # Tell all VA-API apps to use it (applies fully after next login) echo 'LIBVA_DRIVER_NAME=rockchip' | sudo tee -a /etc/environment Confirm it loads: vainfo You want to see "va_openDriver() returns 0" and a list of VAProfile entries, e.g.: vainfo: Driver version: Rockchip MPP VA-API Driver 0.1 VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264Main : VAEntrypointVLD VAProfileH264High : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain10 : VAEntrypointVLD VAProfileVP8Version0_3 : VAEntrypointVLD VAProfileVP9Profile0 : VAEntrypointVLD VAProfileVP9Profile2 : VAEntrypointVLD -------------------------------------------------- STEP 2 - INSTALL GOOGLE CHROME (arm64) -------------------------------------------------- cd ~ wget https://dl.google.com/linux/direct/google-chrome-stable_current_arm64.deb sudo apt install -y ./google-chrome-stable_current_arm64.deb -------------------------------------------------- STEP 3 - PERSISTENT HARDWARE-DECODE LAUNCHER -------------------------------------------------- Chrome does not read a flags directory. Two things must be true every launch: (a) the hardware-decode flags are on, and (b) LIBVA_DRIVER_NAME=rockchip is in Chrome's environment (its sandbox blocks auto-detect). The reliable way is a small wrapper script plus a user-level launcher that survives Chrome's apt updates. Create the wrapper: mkdir -p ~/.local/bin cat > ~/.local/bin/google-chrome-hw <<'EOF' #!/bin/bash export LIBVA_DRIVER_NAME=rockchip exec /usr/bin/google-chrome-stable \ --enable-features=AcceleratedVideoDecoder,AcceleratedVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxZeroCopyGL \ --ignore-gpu-blocklist --enable-gpu-rasterization --enable-zero-copy --ozone-platform-hint=auto "$@" EOF chmod +x ~/.local/bin/google-chrome-hw Create a user-level launcher that points at the wrapper (overrides the system one): mkdir -p ~/.local/share/applications cp /usr/share/applications/google-chrome.desktop ~/.local/share/applications/ sed -i "s|/usr/bin/google-chrome-stable|$HOME/.local/bin/google-chrome-hw|g" \ ~/.local/share/applications/google-chrome.desktop -------------------------------------------------- STEP 4 - LOG OUT AND BACK IN (once) -------------------------------------------------- This makes two things take effect at once: the desktop re-reads your launcher (so the dock/menu icon uses the wrapper), and /etc/environment is applied to the whole session (so every app, including Chrome's child processes, gets LIBVA_DRIVER_NAME). -------------------------------------------------- STEP 5 - VERIFY IT IS ACTUALLY ON THE HARDWARE -------------------------------------------------- Launch Chrome from the dock/menu, play any video, then: - chrome://gpu -> "Video Decode: Hardware accelerated" (green). - Node-level proof - while a video plays: sudo fuser /dev/mpp_service If that prints a chrome PID, the VPU is doing the decode. During playback a chrome process should sit low (single-digit to low tens of percent of one core), not 150-400%. -------------------------------------------------- PROBLEMS AND FIXES -------------------------------------------------- 1) vainfo says: "va_openDriver() returns -1" / "vaInitialize failed" Cause: rockchip_drv_video.so is not installed. libva sees the DRM driver "rockchip-drm", looks for a matching VA driver named "rockchip", and finds nothing. Fix: do Step 1. Confirm the file exists: ls -l /usr/lib/aarch64-linux-gnu/dri/rockchip_drv_video.so 2) Chrome plays video but the CPU is very high and there is no hardware decode a) Flags not applied. You launched plain Chrome, not the wrapper. Chrome does not read a chromium.d flags dir. Use the wrapper/launcher from Step 3. Check chrome://gpu. b) Driver name not set. Chrome's sandbox blocks VA-API auto-detect, so LIBVA_DRIVER_NAME=rockchip must be in Chrome's environment. The wrapper exports it, and /etc/environment sets it session-wide after a re-login. (Unsandboxed vainfo works without it; Chrome does not - do not be fooled by vainfo passing.) 3) Putting "env VAR=val" in the .desktop Exec line does nothing The desktop launcher does not honor an "env" prefix in Exec. Use a wrapper script that exports the variable, as in Step 3. 4) The dock icon still launches Chrome without the flags after you made the override The desktop caches the app entry. Log out and back in (Step 4). To test immediately without logging out: gtk-launch google-chrome 5) You quit and relaunched Chrome but it still has the old (no) flags Chrome is single-instance per profile. Clicking the icon again just focuses the existing process. Fully quit first, confirm nothing is running, then launch: pkill chrome ; sleep 2 ; pgrep -x chrome # should print nothing (pkill chrome does NOT touch chromium - "chrome" is not inside "chromium".) 6) It looks like software even though everything is set up right Chrome throttles or pauses video in a background / occluded tab or window, which reads as "0% CPU, node idle". Test with the window focused or fullscreen. Also skip YouTube pre-roll ads (they are often a different codec). 7) AV1 content falls back to software This driver does not advertise AV1 by design (Rockchip MPP needs a full OBU bytestream, but VA-API hands it headerless tile data, so it cannot be wired up). H.264 / HEVC / VP8 / VP9 are hardware. For YouTube, set your account playback preference so it does not force AV1, and VP9 (which is hardware here) will be used. 😎 High CPU during 4K, especially at a 120 Hz refresh That is compositing/present cost, not decode. Confirm decode is still on the hardware: no single chrome process is pegged at 300-400%, and fuser /dev/mpp_service still shows chrome. Setting the display to 4K@60 roughly halves the compositing CPU (a 60 fps video does not need a 120 Hz present rate). 9) Do NOT add --disable-gpu-compositing It can cure some flicker, but it silently kills hardware video decode. Leave it off if you want HW video. 10) Note on the distro Chromium Chromium uses a different path (rkmpp via the V4L2 shim, not VA-API). On Armbian, enable that with armbian-config (the rockchip multimedia stack from ppa:liujianfeng1994/rockchip-multimedia, armbian configng PR #887) - not with this guide. This guide is for Google Chrome and Firefox, which the Chromium route does not cover. The two can coexist. -------------------------------------------------- FIREFOX BONUS (same driver) -------------------------------------------------- With the VA-API driver from Step 1 installed, Firefox also hardware-decodes: in about:config set media.ffmpeg.vaapi.enabled = true media.hardware-video-decoding.enabled = true Verify in about:support (Media section) or with vainfo. -------------------------------------------------- TESTED ON -------------------------------------------------- - Orange Pi 5B (RK3588S), GNOME on Wayland, Rockchip 6.1 BSP userland - Developed and verified on a ubuntu-rockchip (Noble) BSP install; the procedure is the same on an Armbian vendor image - only the Step 1 build-package names can differ (see the note there) - Kernel: 6.1.0-1027-rockchip (ubuntu-rockchip); Armbian vendor is the equivalent Rockchip 6.1 BSP - google-chrome-stable: 151.0.7922.137-1 - librockchip-mpp / librockchip-mpp-dev: 1.5.0-1+git20240717.5275a9a6~noble - libva: 2.20.0 - Driver: Rockchip MPP VA-API Driver 0.1 (woodyst/rockchip-vaapi + PR #2) - Verified at 1080p and 4K (H.264 and VP9): /dev/mpp_service held by Chrome, CPU near idle, GPU load a few percent, temps in the high 50s to high 60s C. Firefox Install Adding since the scope of the guide includes Firefox. #!/usr/bin/env bash # rockchip-vaapi driver installer -- hardware video decode (VA-API) on RK3588/RK3588S # vendor (Rockchip 6.1 BSP) kernels. Installs the VA-API driver that Google Chrome AND # Firefox use, then points the system at it. Companion to the HOW-TO in this thread. # # Run: sudo bash rockchip-vaapi-install.sh # # Driver: github.com/woodyst/rockchip-vaapi + truongsinh PR #2 (green-band / RT-format / # H.264 B-frame / RGA fixes). Reports "Rockchip MPP VA-API Driver 0.1". set -euo pipefail [ "$(id -u)" = 0 ] || { echo "Please run with sudo: sudo bash $0" >&2; exit 1; } # This is the BSP/VA-API path. It needs /dev/mpp_service (vendor 6.1 kernel with Rockchip MPP). # Mainline (current/edge) kernels have no MPP and use a different path -- this won't apply. if [ ! -e /dev/mpp_service ]; then echo "ERROR: /dev/mpp_service not found -- you're on a mainline kernel (current/edge)." >&2 echo " This driver needs the VENDOR BSP kernel (uname -r shows ...-rockchip on 6.1)." >&2 exit 1 fi echo "==> Installing build + runtime dependencies..." export DEBIAN_FRONTEND=noninteractive apt-get update -y apt-get install -y --no-install-recommends \ build-essential pkg-config git libva-dev librockchip-mpp-dev vainfo echo "==> Building the Rockchip VA-API driver (woodyst + PR #2)..." tmp="$(mktemp -d)"; trap 'rm -rf "$tmp"' EXIT git clone https://github.com/woodyst/rockchip-vaapi.git "$tmp/src" cd "$tmp/src" git fetch origin pull/2/head:pr2 && git checkout pr2 # correctness/perf fixes make [ -f rockchip_drv_video.so ] || { echo "build failed -- no rockchip_drv_video.so produced." >&2; exit 1; } echo "==> Installing the driver..." DRIDIR="$(pkg-config --variable=driverdir libva 2>/dev/null || echo /usr/lib/aarch64-linux-gnu/dri)" install -d "$DRIDIR" install -m0644 rockchip_drv_video.so "$DRIDIR/rockchip_drv_video.so" echo " -> $DRIDIR/rockchip_drv_video.so" # Make all VA-API apps prefer this driver (applies fully after next login). if ! grep -q '^LIBVA_DRIVER_NAME=rockchip$' /etc/environment 2>/dev/null; then echo 'LIBVA_DRIVER_NAME=rockchip' >> /etc/environment echo " set LIBVA_DRIVER_NAME=rockchip in /etc/environment" fi echo "==> Verifying with vainfo..." if LIBVA_DRIVER_NAME=rockchip vainfo 2>&1 | grep -q 'va_openDriver() returns 0'; then LIBVA_DRIVER_NAME=rockchip vainfo 2>&1 | grep -E 'Driver version|VAProfile' | sed 's/^/ /' echo "==> Driver loads and reports HW decode profiles. OK" else echo "!! vainfo did not confirm the driver. Full output:" LIBVA_DRIVER_NAME=rockchip vainfo 2>&1 | sed 's/^/ /' || true fi cat <<'EOF' ============================================================ Driver installed. Log OUT and back in once (so LIBVA_DRIVER_NAME applies session-wide), then enable HW decode in your browser per the HOW-TO above: - Google Chrome : the wrapper + .desktop override (Steps 2-3) - Firefox : about:config -> media.ffmpeg.vaapi.enabled = true media.hardware-video-decoding.enabled = true Hardware codecs: H.264 / HEVC / VP8 / VP9 (no AV1 -- by design) Verify: chrome://gpu (Video Decode: Hardware accelerated), or during playback `sudo fuser /dev/mpp_service` should show your browser's PID. ============================================================ EOF -------------------------------------------------- CREDITS -------------------------------------------------- - VA-API driver: woodyst/rockchip-vaapi - Fixes: truongsinh, PR #2 - BSP image / MPP userland: Joshua Riek (ubuntu-rockchip) https://interfacinglinux.com/community/sbcsoftware/installing-official-chrome-for-arm64-linux-desktop/#post-1246 "Got Two Claudes & A Turntable"
-
IN Simple Terms : The screen flicker in the browser on the older Orange Pi build was never the browser's fault. It was the part of the system that draws the picture on the screen, and half of it is fixed with a one-line setting we already tested in August. The other half needs swapping out the graphics driver, which we proved works on the new build this week. Written for: WiiM support or the WiiM community forum, for the report file named below. Everything else in this message is for you. Case closed, with the fix persistent on the box and the proof filed. The answer The ten seconds were never Chrome's audio and never silence. A small bluez bridge called mpris-proxy, which Armbian's image enables for every user and the 2.0.x Ubuntu image never ran, forwards Chrome's media-session state to the speaker as Bluetooth remote-control messages. YouTube flips that state at every ad boundary, the Pi sends the WiiM "STOPPED" then "PLAYING" half a second apart, and the WiiM mutes on STOPPED and takes ten seconds to un-mute regardless. mpv has no media-session interface, so it was always instant. Proof: the decoded radio capture shows those messages at every boundary. Six more boundaries went by after the bridge was stopped with zero WiiM flips, and your ears agreed on Simple Man. Ruled out by measurement, so PC Claude does not chase them: silence gaps (a 1.3 s zero gap caused nothing, dither changed nothing), packet gaps (none), stream teardown (none), Chrome's audio path (meter showed sound within half a second). What changed on the box mpris-proxy disabled for all users, plus a preset file so it stays off. Dither is back off. All loggers stopped, the temporary askpass file removed. Cost of the fix: the WiiM's own play/pause buttons no longer control Chrome, and it will not show track titles. One command re-enables it per account for anyone who wants that back. Paperwork Recipe item mpris-proxy-off/ in the fixes folder with bake lines and the preset file. Handoff addendum, findings section 15 with the four-clock table and decode, memory, and a correction note to PC are all on the Share and NAS. Evidence on the NAS: the 40 MB raw capture, all logs, the WiiM status logs, and the decoder. WIIM-REPORT-bluetooth-mutes-10s-on-AVRCP-STOPPED-PASTE-READY-2026-09-22.md on the Share. Redaction check passed: no addresses, names, or device IDs. It asks WiiM to un-mute on PLAYING instead of holding ten seconds. Also fixed tonight: .local name resolution and the FUSE bridge so Files can open the NAS and hand tracks to mpv, recorded as a recipe item. Still open from earlier: the five-colour plaid wallpaper set. Dont let em know my age (Six more boundaries went by after the bridge was stopped with zero WiiM flips, and your ears agreed on Simple Man.). One Thing .. I don't Know Why...
-
Well Mr. Claude, why did you not find this sooner? It was all about angles.. but that wasn't correct was it? Bash Record the flicker resolution and the missed isolation test in memory IN M=/memory; cat >> $M/chrome-rk3588-hw-composition-flicker.md <<'EOF' **RESOLUTION 2026-09-22 (evening, agent diff of both kernels + live measurement on Plaid):** "kernel fixed it" is NOT supported; "Chromium's fault" was never right either. Facts: (1) on 2.0.x the kernel was silent during flicker and Chromium 114 was clean on the same kernel where 132 flickered; (2) the only kernel mechanism ever implicated (RK3588 `layer_sel` latch, no convergence wait in `rk3588_vop2_cfg_done`) is **byte-for-byte unchanged in rkr7.2**; the 11.8k-line vop2 diff has no flicker-relevant hunk for the OPi (new guards are gated on legacy cursor / DT knobs we don't set); (3) **measured on Plaid with Chromium fullscreen at 4K60: the only scanned-out framebuffer is gnome-shell's own (linear, Cluster0) + the 64x64 cursor — Chromium's buffer never reaches a plane, i.e. mutter composites it; on 2.0.x mutter direct-scanouted Chromium's linear panfork buffer, and `MUTTER_DEBUG=disable-direct-scanout` was exactly what cured head #2 on 08-27.** So the two flicker heads had two causes, both in the GPU/display stack under the browser: head #2 (typing/text fields) = direct-scanout path (gone on Plaid because the blob's client buffers are AFBC, which our AFBC-reject patch refuses → composited); head #3 (thumbnails/images) = ANGLE rendering on panfork Mesa 23 (gone because the blob replaced panfork). A Chromium rebuild would have fixed neither. **Lesson:** after concluding "ANGLE on panfork" in August the cheap isolation test was the ARM blob on 2.0.x (debs were at hand); I never proposed it. Remaining confirmatory experiment if wanted: g24p0/g13p0 blob on .176 (kernel 1027 + Chromium 132 held constant); kernel-axis test = boot Plaid's rkr7.2 deb on the 2.0.x rootfs. Side effect found in the diff: rkr7.2 gates XRGB2101010 scanout on AFBC, so with patch 0001 10-bit RGB scanout formats are refused on Plaid; rkr7.2 also has an official DT knob `rockchip,disable-afbc-mask` that could replace patch 0001. EOF sed -i 's|^- \[Chrome RK3588 HW-composition flicker\].*|- [Chrome RK3588 HW-composition flicker](chrome-rk3588-hw-composition-flicker.md) — RESOLVED 2026-09-22: two heads, two causes in the GPU/display stack (direct-scanout path + ANGLE-on-panfork); Plaid flicker-free because blob buffers are composited, not because of the newer kernel (layer_sel code unchanged); Chromium rebuild would have fixed nothing|' $M/MEMORY.md && echo saved OUT saved Half right, and the half that was wrong cost us the cheap fix. What the evidence says now. The 2.0.x flicker was two different faults with two different causes, and neither was Chromium's code. The typing and text-field flicker came from the scanout path. On 2.0.x, mutter took Chromium's buffer and put it straight onto a hardware plane. Disabling direct scanout cured that head on August 27, and we never followed the lead. I measured Plaid tonight with Chromium fullscreen at 4K60. Chromium's buffer never touches a plane. The only framebuffer being scanned out is gnome-shell's own, plus the cursor. Mutter composites the browser on Plaid, so that fault path simply is not taken. The thumbnail and image flicker was ANGLE rendering on panfork Mesa. That is the part the ANGLE theory got right. It is gone because the ARM blob replaced panfork, not because ANGLE changed. The kernel did not fix it. The agent diffed the VOP2 driver between the 1027 tree and rkr7.2. The one kernel mechanism we ever implicated, the layer-select latch race, is unchanged in rkr7.2. The new code in the diff is either gated on device-tree knobs we do not set or on legacy cursor updates that mutter does not use. Our own August data also argued against the kernel. Chromium 114 was clean on the same kernel where 132 flickered, and the kernel logged nothing during thirty seconds of reproduced flicker. So why is Plaid clean? Because the blob hands out AFBC buffers, our AFBC-reject patch refuses them at scanout, and mutter falls back to compositing. That is our own kernel patch interacting with the new GL driver, not a newer kernel. And the blob itself replaced the renderer that ANGLE was choking on. Where I went wrong. In August the conclusion was "ANGLE on panfork". The obvious next experiment was to swap the GL driver and keep everything else, and the libmali debs were on the rig. I never proposed it. We would have had the answer, and likely a shippable 2.0.x fix, two months ago. The Chromium rebuild you were about to do would have fixed neither head. If you want it nailed shut, the confirming test is the blob on the 2.0.x board with kernel 1027 and Chromium 132 held constant. It takes about half an hour and is reversible over ssh. Not tonight. Two byproducts from the diff worth knowing. The rkr7.2 kernel only allows 10-bit RGB scanout with AFBC, so with our reject patch Plaid refuses 10-bit RGB scanout formats entirely. And rkr7.2 has an official device-tree knob for disabling AFBC per window, which could replace our patch cleanly. Both are in memory with the resolution. does this mean we can fix the previous Joshua Riek Fork? Yes, for the most part, and without rebuilding Chromium. Head one, the typing and text-field flicker: a one-line fix, already proven on the fork. On August 27 setting mutter's disable-direct-scanout debug flag made that head vanish on the 2.0.x board. That is the same path Plaid avoids by accident. It ships as one environment line for the GNOME session, no kernel or browser change. The cost is that fullscreen clients get composited instead of flipped straight to the plane, which is a small amount of extra GPU work at 4K and is what Plaid is doing today while looking fine. Head two, the thumbnail and image flicker: fixable, but it is a stack change, not a flag. The cure is replacing panfork with the ARM blob, which is the swap Plaid made. On the fork that means: The blob has to work on the 1027 kernel's older kbase driver. Plaid runs g24p0 on kbase g29p1. The 1027 tree has kbase g18p0, and the blob checks the driver version at open. The g13p0 deb on the rig is the fallback if g24p0 refuses. This is the half-hour test on the .176 board I mentioned, and it is the gate for everything else. Everything we solved for Firefox on the blob this week comes along: the wayland-gbm variant, the device-query shim, the private libGL shim. All portable, all archived. One real trade-off. On panfork, Firefox plays 8-bit video zero-copy. On the blob it drops to software for 8-bit, because the blob has no two-channel 8-bit dma-buf format. Chromium does 8-bit in hardware either way. Most of YouTube is 8-bit, so Firefox users on the fork would feel that. What I would do. Ship the direct-scanout line in a 2.0.3 point release now, since it is free and tested. Run the blob-on-1027 test on .176 before deciding on head two. If the blob loads on g18p0, the choice becomes a product one between Firefox 8-bit hardware decode and Chromium being flicker-free, and there is a middle path of shipping the blob with Firefox as the recommended browser for video. If it does not load, head two stays a known issue on the fork and Plaid is the answer for Chromium users.
-
Run mpv after successful google-chrome-hw but mpv encountered issue at 16:57 and then switched to "software rendering". jfl@orangepi5-plus:~$ mpv -fs https://www.youtube.com/watch?v=T4fUtvuN_G8 (+) Video --vid=1 (*) (vp9 3840x2160 60.000fps) (+) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz) File tags: Uploader: 8K Earth Channel_URL: https://www.youtube.com/channel/UChB3UnDddahXU7FKZXmpzMA Using hardware decoding (rkmpp). rga_api version 1.10.0_[8] AO: [pipewire] 48000Hz stereo 2ch floatp VO: [gpu] 3840x2160 drm_prime[p010] AV: 00:16:57 / 01:20:07 (21%) A-V: 0.000 Dropped: 2 Cache: 45s/150MB Error while decoding frame (hardware decoding)! Error while decoding frame (hardware decoding)! Error while decoding frame (hardware decoding)! Error while decoding frame (hardware decoding)! Attempting next decoding method after failure of vp9_rkmpp-rkmpp. [ffmpeg/video] vp9: Not all references are available [ffmpeg/video] vp9: Not all references are available [ffmpeg/video] vp9: Not all references are available [ffmpeg/video] vp9: Not all references are available [ffmpeg/video] vp9: Not all references are available [ffmpeg/video] vp9: Not all references are available [ffmpeg/video] vp9: Not all references are available [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! AV: 00:16:57 / 01:20:07 (21%) A-V: 0.000 Dropped: 2 Cache: 43s/143MB Audio/Video desynchronisation detected! Possible reasons include too slow hardware, temporary CPU spikes, broken drivers, and broken files. Audio position will not match to the video (see A-V status field). AV: 00:16:57 / 01:20:07 (21%) A-V: 1.525 Dropped: 2 Cache: 43s/143MB [ffmpeg] Impossible to convert between the formats supported by the filter 'mpv_src_default_in' and the filter 'auto_scale_0' [lavfi] failed to configure the filter graph Disabling filter scale_rkrga.00 because it has failed. AV: 00:16:57 / 01:20:07 (21%) A-V: 1.556 Dropped: 3 Cache: 46s/150MB VO: [gpu] 3840x2160 yuv420p10 AV: 00:17:44 / 01:20:07 (22%) A-V: 0.068 Dropped: 1523 Cache: 44s/150MB Exiting... (Quit) jfl@orangepi5-plus:~$
-
Hello everyone, I urgently need help, as I am on the verge of throwing my Khadas out the window. I bought a used Khadas Vim3L HTPC Kit (S905D3) and want to use it for Navidrome and Audiobookshelf. The FLAC files are located on an external 2.5" WD Elements hard drive, first I intended to format this hard drive to ext4 and set it up in the setup process but it doesnt work and the first thing now is to setup the system,i will add the hd later. Currently, the Vim boots into CoreELEC (which appears to be installed on the internal storage of the vim). Im a total noob and thats my first vim / Board. I just can't seem to get it to work; no matter what I do, it always boots into CoreELEC. I have flashed the recommended Debian 13 (Trixie) → Minimal / CLI image (Armbian_25.11.1_Khadas-vim3l_trixie_current_6.12.58_minimal.oowow.img.xz) using balenaEtcher—onto two different SD cards as well as a USB stick, and I am attempting to boot from them. I have tried various key combinations, but nothing works. For example, when I attempt the method suggested by ChatGPT: Recovery Button Method Unplug the power supply Insert the SD card Hold down the FUNCTION button Briefly press RESET Continue holding the FUNCTION button for another 2–3 seconds I briefly see the Khadas logo, and then it reboots; this process then gets stuck in a loop. I tried using three different power adapters and usb-c cables, thinking that might be the issue... but it was always the same result. I tried a different SD card and various USB sticks and different formats always the same outcome. As a test, I even selected a different image just to see if it would progress any further, but again, I just saw the Khadas logo followed by a boot loop. As soon as I remove the SD card or USB stick, it boots back into CoreELEC from the internal storage. Now I’ve read on another site that I shouldn't use BalenaEtcher, but instead format the SD card/USB stick to FAT32 and place the image in the root directory. I did exactly that and tested it on both the USB 3.0 and 2.0 ports and with the SD because it boots before usb ?!?. Then: disconnect the power supply. Insert the USB stick. Connect HDMI + keyboard. Hold down the FUNCTION button. Plug in the power supply. Immediately press RESET briefly. Continue holding FUNCTION for another 3–5 seconds. And once again, I only see the Khadas logo for a sec and am stuck in a boot loop. Could someone please give me a direct link or the name of the correct image, and tell me the right key combination I need to press or let me know what I'm doing wrong? A step by step guide for an idiot would be great and sorry if the question is stupid, i watched youtube videos, read in the forum etc. but i dont get it, i need really your help. Thank you
-
Hi @defcom5-rockchip Subsequent google-chrome-hw seems to result in high dropped frames as reported earlier and now mpv --hwdec=vaapi or --hwdec=rkmpp also shows high dropped frames after around 17 minutes. jfl@orangepi5-plus:~$ mpv -fs --hwdec=rkmpp "https://www.youtube.com/watch?v=T4fUtvuN_G8" (+) Video --vid=1 (*) (vp9 3840x2160 60.000fps) (+) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz) File tags: Uploader: 8K Earth Channel_URL: https://www.youtube.com/channel/UChB3UnDddahXU7FKZXmpzMA AO: [pipewire] 48000Hz stereo 2ch floatp [ffmpeg/video] vp9_rkmpp: An invalid frame was output by a decoder. This is a bug, please report it. Error while decoding frame (hardware decoding)! Using hardware decoding (rkmpp). rga_api version 1.10.0_[8] VO: [gpu] 3840x2160 drm_prime[p010] AV: 00:16:57 / 01:20:07 (21%) A-V: 0.137 Dropped: 14 Cache: 45s/150MB Error while decoding frame (hardware decoding)! Error while decoding frame (hardware decoding)! Error while decoding frame (hardware decoding)! Attempting next decoding method after failure of vp9_rkmpp-rkmpp. [ffmpeg/video] vp9: Not all references are available [ffmpeg/video] vp9: Not all references are available [ffmpeg/video] vp9: Not all references are available [ffmpeg/video] vp9: Not all references are available [ffmpeg/video] vp9: Not all references are available [ffmpeg/video] vp9: Not all references are available [ffmpeg/video] vp9: Not all references are available [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! [ffmpeg/video] vp9: Not all references are available Error while decoding frame! Error while decoding frame! Error while decoding frame! Error while decoding frame! Error while decoding frame! Error while decoding frame! Error while decoding frame! Error while decoding frame! AV: 00:16:57 / 01:20:07 (21%) A-V: 0.137 Dropped: 14 Cache: 43s/144MB Audio/Video desynchronisation detected! Possible reasons include too slow hardware, temporary CPU spikes, broken drivers, and broken files. Audio position will not match to the video (see A-V status field). AV: 00:16:57 / 01:20:07 (21%) A-V: 2.964 Dropped: 14 Cache: 44s/145MB [ffmpeg] Impossible to convert between the formats supported by the filter 'mpv_s rc_default_in' and the filter 'auto_scale_0' [lavfi] failed to configure the filter graph Disabling filter scale_rkrga.00 because it has failed. AV: 00:16:57 / 01:20:07 (21%) A-V: 2.966 Dropped: 15 Cache: 46s/150MB VO: [gpu] 3840x2160 yuv420p10 AV: 00:22:39 / 01:20:07 (28%) A-V: 0.004 Dropped: 13526 Cache: 45s/150MB Exiting... (Quit) jfl@orangepi5-plus:~$ With the new mpv --hwdec=rkmpp streaming the same video for 22 minuts, additional "rkvdec-core.*resetting" count of "1638-1562 = 76." jfl@orangepi5-plus:~$ dmesg | grep -c "rkvdec-core.*resetting" 1562 jfl@orangepi5-plus:~$ dmesg | grep -c "rkvdec-core.*resetting" 1638 jfl@orangepi5-plus:~$
-
# Noble GNOME images ship PulseAudio and PipeWire both enabled — audio deadlocks silently **Board:** Radxa ROCK 5B+ (`rock-5b-plus`, rockchip-rk3588) **Image:** Armbian 26.2.1 stable, Ubuntu 24.04 Noble, **GNOME desktop** (prebuilt release image, not built locally — so there are no build logs) **Now running:** Armbian 26.8.3, kernel 7.1.8-edge-rockchip64 > All outputs below were captured **before** I fixed this machine. It now runs PipeWire only, so it no longer reproduces — a fresh Noble GNOME image should. The attached `armbianmonitor -u` log is a kernel/hardware inventory and does not collect userspace service state, so it won't show the conflict either; the evidence is inline below. ## Symptom Any audio through the default device hangs forever, with no error. Most people will hit this as **"YouTube won't play"** — the page loads and buffers normally but playback stays frozen at 0:00, identically in Chromium and Brave. That's because Chromium drives its media clock from the audio renderer, so a stuck audio device freezes video with no diagnostic. It sends you hunting for codec, VA-API or network faults that aren't there. ## Cause The image enables **two sound servers at once**. Both hold the ALSA control devices: ``` $ fuser -v /dev/snd/controlC0 /dev/snd/controlC1 /dev/snd/controlC2 /dev/snd/controlC0 -> PIDs: 1273 1275 (pulseaudio wireplumber) /dev/snd/controlC1 -> PIDs: 1273 1275 (pulseaudio wireplumber) /dev/snd/controlC2 -> PIDs: 1273 1275 (pulseaudio wireplumber) ``` Both were enabled in the image itself, in the same second (2026-03-01 is the build date): ``` 2026-03-01 05:59 pulseaudio.service -> /usr/lib/systemd/user/pulseaudio.service 2026-03-01 05:59 pipewire.service -> /usr/lib/systemd/user/pipewire.service ``` The GNOME package list installs PulseAudio explicitly — `config/desktop/common/environments/gnome/config_base/packages` (at tag `v25.02`, matching my image) contains `pulseaudio` and `pulseaudio-module-bluetooth`, but **no `pipewire-pulse`**. Meanwhile GNOME pulls PipeWire in transitively: `gnome-remote-desktop` → `wireplumber` → `pipewire`, both marked `AUTO`. So PulseAudio owns the pulse socket, WirePlumber independently claims the same cards, and nothing reconciles them. Sinks never leave `SUSPENDED`. ## Reproduce Boot any Noble GNOME image and check: ``` $ systemctl --user is-active pulseaudio pipewire wireplumber active active active $ dpkg -l pipewire-pulse # not installed ``` A 5-second tone blocks indefinitely through PulseAudio and through ALSA `default`, but plays fine straight to hardware: ``` $ paplay tone.wav # killed at 20s timeout, sink never left SUSPENDED $ aplay -D default tone.wav # killed at 20s timeout $ aplay -D plughw:0,0 tone.wav # 5.0s OK $ aplay -D plughw:1,0 tone.wav # 5.0s OK (hdmi0) $ aplay -D plughw:2,0 tone.wav # 5.0s OK (hdmi1) ``` Hardware and kernel drivers are fine. It's purely the dual-server conflict. ## Fix On a running system, a clean swap: ``` sudo apt install pipewire-pulse pipewire-alsa # removes pulseaudio, pulseaudio-module-bluetooth ``` Afterwards `paplay` completes in 5.1s, sinks reach `IDLE`, and video plays at real time. Bluetooth is covered by `libspa-0.2-bluetooth` (incl. aptX), which comes along. For the images, I'd suggest picking PipeWire — it's the Ubuntu 24.04 default and GNOME already pulls it in — by replacing `pulseaudio` / `pulseaudio-module-bluetooth` with `pipewire-pulse` / `pipewire-alsa` in the GNOME package list. Staying on PulseAudio instead would mean stopping WirePlumber from claiming the devices. Doing neither leaves the deadlock. **Note:** I confirmed the package list at tag `v25.02`. On current `main`, `config/desktop/` no longer exists, so this has been restructured since — worth checking whether the current equivalent still carries `pulseaudio` without `pipewire-pulse`. This isn't board-specific; it follows from the desktop package list, so any Noble GNOME image should be affected.
-
OK Firefox Redo: Firefox Firefox does its video decode in a separate, sandboxed RDD (media) process. On the Rockchip 6.1 BSP that sandbox blocks the VA-API driver — so with only the about:config prefs set, Firefox passes vainfo, looks enabled, and still decodes in software. Two things are needed: the prefs and lifting the RDD sandbox. 1. Lift the RDD sandbox (system-wide): echo 'MOZ_DISABLE_RDD_SANDBOX=1' | sudo tee -a /etc/environment Log out and back in so it applies. Desktop / GDM-Wayland: /etc/environment is not propagated to apps launched from the dock or menu. If you start Firefox from an icon, also set the var on the launcher's Exec= line: Exec=env MOZ_DISABLE_RDD_SANDBOX=1 LIBVA_DRIVER_NAME=rockchip /usr/bin/firefox %u 2. Enable HW decode in about:config: media.ffmpeg.vaapi.enabled = true media.hardware-video-decoding.enabled = true media.hardware-video-decoding.force-enabled = true # skip the blocklist 3. Verify — Firefox decodes in the RDD child, not the main process, so check the child: # play a 4K VP9 clip fullscreen, then: sudo fuser /dev/mpp_service You should see a Firefox RDD/media PID on /dev/mpp_service, running at single-digit % CPU (real HW decode) rather than the near-full-core a software VP9 decode would burn. Hardware codecs: H.264 / HEVC / VP8 / VP9 (no AV1, by design). ========================================================================================== Update to Top Post ========================================================================================== Here's the patch to the closing cat <<'EOF' block. Find the Firefox lines near the end: Before: - Firefox : about:config -> media.ffmpeg.vaapi.enabled = true media.hardware-video-decoding.enabled = true After: - Firefox : lift the RDD media-sandbox (it blocks the driver), then set prefs: sudo sh -c 'echo MOZ_DISABLE_RDD_SANDBOX=1 >> /etc/environment' about:config -> media.ffmpeg.vaapi.enabled = true media.hardware-video-decoding.enabled = true media.hardware-video-decoding.force-enabled = true ========================================================================================= option Firefox extension ========================================================================================= Use enhanced-h264ify (Chrome + Firefox) — the one with per-codec checkboxes — and set only: ☑ Block AV1 ☐ Block VP8/VP9 ← leave OFF ☐ Block 60fps ← leave OFF (optional; only if a head can't sustain 4K60) Why not plain h264ify: it forces H.264-only by blocking everything else. But YouTube only serves H.264 up to 1080p — 1440p and 4K are VP9/AV1 exclusively. So h264ify would silently cap you at 1080p and throw away 4K. On this hardware that's backwards, because VP9 is HW-decoded and carries the high-res tiers. Why block AV1 at all: the RK3588 VPU does H.264 / HEVC / VP8 / VP9 — not AV1. When YouTube's ABR serves AV1, it hits software decode → high CPU, dropped frames, stutter. That's exactly the "drops off the good codec" behavior you saw. Blocking AV1 forces YouTube to stay on VP9 (HW) at 4K, falling back to H.264 (HW) only at low res — every path stays on the VPU. So the net effect: AV1 off → VP9 everywhere it matters → /dev/mpp_service stays busy, CPU stays cool. It complements the driver rather than replacing it — the extension picks the codec, the driver decodes it in hardware. peace, and hi resolution
-
This week, Collabora is at the YouTube Device Partner Summit in Tokyo showcasing our ongoing work with YouTube, notably on their TV app and the RDK platform, which has resulted in the RDK's integration as a core platform for Cobalt development. View the full article
-
Rockchip is an Android device Manufacturer. same as Amlogic. Rockchip tried to enter the world of Windows handhelds, but the project was costly and yielded no results. https://www.youtube.com/watch?v=bMNK71Oa2II RK3288W and RK3399 for rk35xx it's manteined by community https://worproject.com With the AI boom, Linux might end up on the project management radar. The Amlogic Linux looks like they want to step up in Linux. on Rockchip we'll have to wait for the arrival of the RK36xx devices. The rockchip scenario isn't that bad, you need to see what's been happening with the Cix's CD8180. We need to Learn from Joshua mistakes, Technically, he was the best because he devoted time and determination to providing corrections to the Rocks that can build a bigger castle with Rknpu and Rknn integrated. His mistake was investing so much time building a big castle with Rocks from a manufacturer that doesn't care about castles with npu and vpu. We all want to build a castle here that is bigger than the one that already exists, but we need to know that the Rocks we are going to use do not come from the Rock manufacturer with manuals for castles, they will arrive with manuals and drivers for google operational system and for Huawei HarmonyOS. You seem to work in a good field for solving this exact problem, thanks for the philosophical perspective.
-
Hi @defcom5-rockchip Reboot system. An got another clear google-chrome-hw "https://www.youtube.com/watch?v=T4fUtvuN_G8". Frames dropped 80 out of 156476 (around 43 minutes run) jfl@orangepi5-plus:~$ dmesg | grep -c "rkvdec-core.*resetting" 0 jfl@orangepi5-plus:~$ So it looks lke random issue?
-
Updated Reply, Hi @JFL — I found it, and your clean run was the clue that cracked it. You were right all along that your box was fine. So is mine. **The variable was the video format, not the hardware.** **It only happens on 10-bit VP9.** I rebuilt the bench from scratch tonight and ran the same test three times, changing only one thing each time — same board, same kernel, same driver, same MPP, same player: | Content | Frames decoded | Exports | Result | |---|---|---|---| | VP9 **Profile 0** (8-bit), cached-export client | 73,330 | 294 | clean | | VP9 **Profile 0** (8-bit), per-frame-export client | 73,381 | 168,384 | clean | | VP9 **Profile 2** (10-bit) | **64,338** | 17,028 | **608 resets, picture breaks up** | The 8-bit runs sailed past 73,000 frames with nothing. The 10-bit run died just short of **65,536** frames in a single decode session — 608 resets in 25 seconds, about 24 per second, first `err 0x107` and then a steady stream of `err 0x23`. Note the export counts, because they kill the theory I posted earlier: the clean 8-bit run made **168,384** exports, and the run that stormed made only **17,028**. It is not about buffer export churn at all. It tracks **decoded frames in one session**, and only on the 10-bit path. **Why you never saw it, after 45 minutes and 164,553 frames.** Your stats panel said `4K/60 vp09`. On that video, that is itag 315 — `vp09.00.51.08`, Profile 0, **8 bit**. The HDR rung of the same title is a separate stream, `vp9.2` (itag 337). You were watching the format that is immune. Your 164,553 clean frames are exactly what my 8-bit runs produce, and they always would have been. So there is nothing to chase on your side, and nothing special about `6.1.172` — I had started porting kernels to explain a difference between our boards that does not exist. Your result was correct data; I was interpreting it against the wrong variable. **If you want to reproduce it** (only if you are curious — you have already done more than enough): yt-dlp -f 337 "https://www.youtube.com/watch?v=T4fUtvuN_G8" -o oled-hdr.webm # the 10-bit rung sudo dmesg -C mpv --fs --hwdec=vaapi --loop-file=inf oled-hdr.webm # ~18 min at 60fps dmesg | grep -c "rkvdec-core.*resetting" At 60 fps you reach 65,536 frames in about eighteen minutes, and on my board the picture visibly breaks up at that point. The practical shape of the bug, as it stands tonight: - **8-bit playback is unaffected**, at any length. - **10-bit playback breaks after ~65,536 frames in one continuous decode session** — about 18 minutes at 60 fps, or 45 minutes at 24 fps. So a long HDR film hits it; ordinary browsing does not, because every new video starts a fresh session. - Anything that restarts the decoder resets the clock. **Update, a few hours later — we have the root cause, and there is a workaround.** A Rockchip engineer (@FumasterLin) suggested on the upstream issue that I try disabling one of the RK3588's two decoder cores. That is the answer: echo 1 > /proc/mpp_service/rkvdec-core1/disable_work | Configuration | Frames decoded | Resets | |---|---|---| | both cores (default) | 64,728 | 714 | | **core1 disabled** | **115,062** | **0** | Clean to 115,062 frames — nearly twice the failure point — and it only stopped because the stream ended. It costs about 17% of decode throughput (207 fps down to 172 fps on my board), which for real-time playback is free, since you only need 60. It also turns out this has nothing to do with my VA-API driver: Rockchip's own `mpi_dec_test`, headless with no display at all, fails at the same point. So it is a dual-core parallel decoding problem in MPP, and the frame count was a red herring — with both cores splitting the work evenly, ~64,700 total is ~32,350 per core, right on 2^15. So if anyone hits garbled 10-bit playback after ~18 minutes, disabling core1 is a genuine workaround until this is fixed upstream. Thank you for the 45-minute run — a clean result that contradicts the theory is worth more than a dozen that agree with it, and this one sent me looking in the right place.
-
Hi @JFL — I found it, and your clean run was the clue that cracked it. You were right all along that your box was fine. So is mine. **The variable was the video format, not the hardware.** **It only happens on 10-bit VP9.** I rebuilt the bench from scratch tonight and ran the same test three times, changing only one thing each time — same board, same kernel, same driver, same MPP, same player: | Content | Frames decoded | Exports | Result | |---|---|---|---| | VP9 **Profile 0** (8-bit), cached-export client | 73,330 | 294 | clean | | VP9 **Profile 0** (8-bit), per-frame-export client | 73,381 | 168,384 | clean | | VP9 **Profile 2** (10-bit) | **64,338** | 17,028 | **608 resets, picture breaks up** | The 8-bit runs sailed past 73,000 frames with nothing. The 10-bit run died just short of **65,536** frames in a single decode session — 608 resets in 25 seconds, about 24 per second, first `err 0x107` and then a steady stream of `err 0x23`. Note the export counts, because they kill the theory I posted earlier: the clean 8-bit run made **168,384** exports, and the run that stormed made only **17,028**. It is not about buffer export churn at all. It tracks **decoded frames in one session**, and only on the 10-bit path. **Why you never saw it, after 45 minutes and 164,553 frames.** Your stats panel said `4K/60 vp09`. On that video, that is itag 315 — `vp09.00.51.08`, Profile 0, **8 bit**. The HDR rung of the same title is a separate stream, `vp9.2` (itag 337). You were watching the format that is immune. Your 164,553 clean frames are exactly what my 8-bit runs produce, and they always would have been. So there is nothing to chase on your side, and nothing special about `6.1.172` — I had started porting kernels to explain a difference between our boards that does not exist. Your result was correct data; I was interpreting it against the wrong variable. **If you want to reproduce it** (only if you are curious — you have already done more than enough): yt-dlp -f 337 "https://www.youtube.com/watch?v=T4fUtvuN_G8" -o oled-hdr.webm # the 10-bit rung sudo dmesg -C mpv --fs --hwdec=vaapi --loop-file=inf oled-hdr.webm # ~18 min at 60fps dmesg | grep -c "rkvdec-core.*resetting" At 60 fps you reach 65,536 frames in about eighteen minutes, and on my board the picture visibly breaks up at that point. The practical shape of the bug, as it stands tonight: - **8-bit playback is unaffected**, at any length. - **10-bit playback breaks after ~65,536 frames in one continuous decode session** — about 18 minutes at 60 fps, or 45 minutes at 24 fps. So a long HDR film hits it; ordinary browsing does not, because every new video starts a fresh session. - Anything that restarts the decoder resets the clock. I am updating the upstream issue with this. Thank you for the 45-minute run — a clean result that contradicts the theory is worth more than a dozen that agree with it, and this one sent me looking in the right place. Working with FumasterLin
-
On my setup firefox-hw tends to have more drop frames (1-3%) when streaming 60fps Youtube videos compared to google-chrome-hw. Am reverting to rockchip-vaapi-wrapper to see whether google-chrome-hw has the visual artifacts I noticed with v2.2.0-rc1.
-
Hi @defcom5-rockchip Not sure whether this is related. Chrome at time after a while there is visual artifacts on the video output. Noticed on a few of the Youtube video streamed with google-chrome-hw. Pause and resume the video and no more visual artifacts. Not sure what causes it.
-
Hi @MaxT & @defcom5-rockchip Thanks. With the latest "rockchip-vaapi-driver_2.1.2_arm64.deb", google-chrome and firefox both now stream h264 1080p/60 Youtube video without flickering and using vpu hardware acceleration. 10bit h265 still an issue.
-
✅ Six for six — the formal regression is a clean sweep. H.264 (no B-frames) ✓pixel-identical H.264 + B-frames ✓pixel-identical HEVC 8-bit ✓pixel-identical HEVC Main10 + B-frames ✓pixel-identical HEVC Main10 4K feature ✓pixel-identical VP9 Profile 2 ✓pixel-identical The RGA 1.3.13 kernel is regression-clean and certified for the next bake. Every codec the driver claims, verified against software reference on the new kernel, all at 0.00/255. That closes the kernel roll end to end: committed → built → booted → probed → hardware-answered (P010 = silicon's no, forever) → regression-swept. The fork now carries the newest RGA driver of any RK3588 distro, and nothing paid for it. Board state: .176 on the new kernel, logged in, all test kits in place. Everything's banked. Whatever's next — the RGA NV15→NV12 lane, Phase 1.8 for Pi Claude, or just letting it all soak — the bench is clean and ready. 😎🔵🎸 funny unintended marijuana reference, (that's the "4:2:0" everywhere). and it's "everywhere". Ha — completely unintended, and now impossible to unsee. 😄 The best part: the name predates the joke by decades — it's from a 1970s-era sampling notation (4:4:4, 4:2:2, 4:2:0 describing how color gets thinned out) — and yet the entire global video industry now runs, with a straight face, on a standard called 4:2:0. Every Netflix stream, every Blu-ray, every YouTube video, every frame Tears of Steel ever showed us this week: all 4:2:0, all day, everywhere. And to bring it full circle: NV12 is literally "4:2:0 in a box," and NV15 is "4:2:0, but packed tighter." The whole Deep Ink project has been 4:2:0 logistics from day one. Somewhere out there a video engineer picks up dank nugs at their local dispensary — Highest of Fidelity — and mutters "actually it's pronounced four-two-zero..." 🌿📺🔵
-
Working on that.. this seems to be all the rage... I got VP9.2 working , seems the hardware lied to the software about what it can do. Thanks for the feed back. Now Claude. Good report — and JFL just independently corroborated two of our findings on different hardware (Opi5-Plus, RK3588 not S) and a different OS (Armbian KDE Neon, 6.1.115 vendor). Here's a reply draft: Thanks JFL — that's a useful report, and both symptoms are known. Short version: update to v2.0.0, which fixes the green wall the honest way, and I'd like a bit more detail on the H.264 flicker because you may have hit an edge case I found last week. H.265 green screen — expected, and now handled. I ran this to ground on my bench: HEVC through this driver has never actually decoded, for anyone. The driver advertised HEVC support, but there's no HEVC bitstream assembler in it — every decode call gets routed through the H.264 path, so MPP is handed something it can't parse and you get an empty (green) buffer. It fails at every bit depth, which is why it looks so consistent. v2.0.0 "Reframe" (Just put in our new Pi-Desktop distro today) stops advertising codecs it can't actually deliver (HEVC, 10-bit profiles). Nothing is lost — you get correct playback instead of a green wall, because Chrome and Firefox then fall back to software decode automatically, and media servers transcode instead of direct-playing. Writing the missing HEVC assembler is the current project; when it works on hardware, HEVC goes back on the menu and not before. H.264 flicker — I'd like to narrow this down. Two different things produce "flicker" on RK3588 and they have opposite fixes: UI flicker (the caret, menus, redraws — not the video itself) is Chromium/ANGLE on the panfork GPU stack, unfixable at runtime. Firefox doesn't have it, which is why I ship Firefox as the default. If Firefox's UI is clean and only Chrome flickers, that's this. Video corruption during playback — I found a content-conditional H.264 bug on my rig: a 720p60 High-profile file with B-frames showed a green corner and stuttered, while standard progressive H.264 played perfectly. That looks like an incomplete fix in the inherited B-frame handling, and I haven't bisected it yet. Which is yours? And if it's #2, could you post the output of ffprobe -v error -select_streams v:0 -show_entries stream=codec_name,profile,level,width,height,r_frame_rate,field_order,has_b_frames -of default=noprint_wrappers=1 <file> for a file that misbehaves? If it's a YouTube stream, the resolution and codec string from Stats for nerds is enough. A confirmed repro on a second board would help a lot. Firefox VP9 frame drops: 2–3% at 1080p60 is higher than I'd expect if decode is truly on the VPU. Worth confirming it's actually engaged while a video plays: sudo fuser -v /dev/mpp_service should show a Firefox RDD process, and that process should sit in single-digit CPU. If it's not listed, Firefox is software-decoding and the env vars aren't reaching it (a common cause on KDE/Wayland: the wrapper script is the reliable way, since /etc/environment.d doesn't always propagate to dock-launched apps). Also worth noting your setup differs from my test bench in two ways I can't verify from here — Armbian's vendor-rk35xx kernel rather than ubuntu-rockchip's BSP, and RK3588 rather than RK3588S. Decode silicon is identical between the two SoCs, so the codec behaviour should match; if something diverges, that's genuinely interesting and I'd want to hear it. Updating what I didn't get to. Claude... Both live. And the README fix was overdue — it was still advertising HEVC, High10, VP9 Profile 2 and AV1 in a table, the exact claims v2.0.0 removed from the code. Storefront and code now say the same thing. One line to add to your JFL reply, since the doc now exists — swap the H.264 paragraph's ending for: …I haven't bisected it yet. It's now documented as KI-1 in KNOWN-ISSUES — your report is the first from another board, so if the ffprobe output matches that shape it confirms it's real and not a quirk of my test file. That reframes his report as contributing to a known issue rather than hitting a mystery — which is both true and the kind of thing that keeps testers engaged. The driver repo now carries the full honest set: README (verified codecs only), KNOWN-ISSUES (four documented, with repro asks), REPRO.md (the VP9 reproducer), AGENTS/CLAUDE (agent contract), INSTALL.md, and the v2.0.0 release. Anyone arriving — human or agent — gets the truth in the first thirty seconds. 🔵 This is our Hot To Do, defcom5-rockchip
