8 hours ago, defcom5-rockchip said:

EGL_LOG_LEVEL=debug LIBGL_DEBUG=verbose RK_VAAPI_LOG=/tmp/rk.log google-chrome --enable-features=PlatformHEVCDecoderSupport,VaapiVideoDecoder,VaapiIgnoreDriverChecks,AcceleratedVideoDecodeLinuxGL --ignore-gpu-blocklist <the 10-bit file> 2>&1 | grep -iE "EGL user|libEGL|vaapi|POOL" | head
grep -c "10bit=1" /tmp/rk.log; grep -c "CreateSurfaces2:" /tmp/rk.log; grep -c "DestroySurfaces" /tmp/rk.log

google-chrome-hw did not launch with the above commands.

 

jfl@orangepi5-plus:~$ EGL_LOG_LEVEL=debug LIBGL_DEBUG=verbose RK_VAAPI_LOG=/tmp/r
k.log google-chrome-hw --enable-features=PlatformHEVCDecoderSupport,VaapiVideoDec
oder,VaapiIgnoreDriverChecks,AcceleratedVideoDecodeLinuxGL --ignore-gpu-blocklist
<the 10-bit file> 2>&1 | grep -iE "EGL user|libEGL|vaapi|POOL" | head
grep -c "10bit=1" /tmp/rk.log; grep -c "CreateSurfaces2:" /tmp/rk.log; grep -c "D
estroySurfaces" /tmp/rk.log
bash: syntax error near unexpected token `2'
grep: /tmp/rk.log: No such file or directory
grep: /tmp/rk.log: No such file or directory
grep: /tmp/rk.log: No such file or directory
jfl@orangepi5-plus:~$

 

Hi @defcom5-rockchip

 

Could be that the "ffmpeg" or "ffmpeg-mpp" on this image does not support 10 bit video?  And google-chrome-152.0.7977.82 does not support 10bit video yet?

OK You Poked a bear:   

 

Test box is back to release state (Ubuntu mpv gone, mpv 0.38 with zero missing libraries, ffmpeg intact). One supporting fact from it: our image carries all four libva pieces, including libva-wayland2, which is exactly the one Armbian may not install by default.

Reply 5 for the forum (also on the NAS):

 

@JFL — thanks for the clean rerun. I reproduced your setup on my side to take the guesswork out: your exact mpv build (the PPA's 1:0.36.0-1ubuntu1+noble4) with driver 2.1.4, same --no-config --hwdec=vaapi --gpu-context=wayland, on a 4K Main10 file: Using hardware decoding (vaapi), VO: [gpu] 4096x1714 vaapi[p010]. So the decoder and mpv 0.36 are fine together; something on your box stops mpv before it gets there, and Firefox doesn't hit it because Firefox opens the VA display through the DRM render node rather than through Wayland.

One verbose run tells us which step it is. The path has spaces, so keep the quotes:

mpv -v --no-config --hwdec=vaapi --gpu-context=wayland "/media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv" 2>&1 | grep -iE "VA display|Initialized VAAPI|Supported formats|Failed|Attempting next|Using hardware|hwdec" | head -20 apt list --installed 2>/dev/null | grep -E "^libva|^mesa|panfork" echo "LIBVA_DRIVER_NAME=$LIBVA_DRIVER_NAME"; vainfo --display wayland 2>&1 | head -6

What I expect to see on a working box, in order: Trying to open a wayland VA display... → Initialized VAAPI: version 1.20 → Supported formats: nv12 p010 → Using hardware decoding (vaapi). The line that's missing or replaced by a Failed tells us the fix. My first guess: if the Wayland VA display line never appears or fails, libva-wayland2 is not installed — sudo apt install libva-wayland2 and rerun. Second guess: a Supported formats list without p010, in which case it's the GPU stack on your image (which Mesa/panfork build are you on?), and the vainfo output plus that package list will show it.

 

His answer to that picks between a missing package on Armbian and a Mesa difference, and either one becomes a line in the Armbian guide rather than a driver change.

 

@JFL — reasonable guesses, and both can be ruled out with what's already in your logs:

ffmpeg: mpv's --hwdec=vaapi goes through FFmpeg's generic VA-API HEVC hwaccel — stock FFmpeg code, nothing Rockchip-specific — and your own mpv output lists yuv420p10 as the software fallback format, so your FFmpeg build handles 10-bit HEVC fine. If it didn't, you'd get no picture at all rather than a correct software one. The hardware path stalls before the decoder is chosen, which is why the verbose run matters: it prints which step (VA display / Supported formats / decoder init) refused.
Chrome: Chrome has decoded HEVC Main10 through VA-API on Linux since version 107 (behind PlatformHEVCDecoderSupport). "Not supported" would look like a refusal to play. Garbled-then-green means it decoded and something downstream broke — either the surface reaching Chrome's GPU path or the way the driver serves Chrome's per-frame surface churn. The EGL_LOG_LEVEL=debug run plus the 8-bit HEVC baseline from my earlier post picks between those two.
Same three commands as before (quoted path), whenever you have five minutes:

mpv -v --no-config --hwdec=vaapi --gpu-context=wayland "/media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv" 2>&1 | grep -iE "VA display|Initialized VAAPI|Supported formats|Failed|Attempting next|Using hardware|hwdec" | head -20
apt list --installed 2>/dev/null | grep -E "^libva|^mesa|panfork"
echo "LIBVA_DRIVER_NAME=$LIBVA_DRIVER_NAME"; vainfo --display wayland 2>&1 | head -6
For what it's worth, your exact mpv build with this driver plays 4K Main10 in hardware here, so whatever it is lives on the box, not in the codec support.

@JFL — let's take the guesswork out, because your own logs already rule most things out.

First, the Chrome run didn't happen. <the 10-bit file> in my earlier post was a placeholder, and bash read the < as a redirect — that's the syntax error near unexpected token '2'. Nothing launched, so /tmp/rk.log never existed. My fault for not saying so. Replace it with your real path in quotes (it has spaces) and it'll run.

What your logs already prove:

Your box decodes and displays 10-bit HEVC — your --hwdec=rkmpp --vf=scale_rkrga=force_yuv=auto run put P010 on screen. So MPP, 10-bit, and your GL stack's buffer import are all fine.
Your software fallback is yuv420p10 and looks right, so FFmpeg handles 10-bit fine.
The driver works on your box through the DRM node (Firefox), and the exact same mpv 0.36 build + driver 2.1.4 plays 4K Main10 in hardware here.
Cross those off and exactly one variable is left: how mpv opens the VA display on your session. So no more theories — four commands, each a yes/no:


echo $XDG_SESSION_TYPE
vainfo --display wayland 2>&1 | head -5
LIBVA_DRIVER_NAME=rockchip mpv --no-config --hwdec=vaapi --gpu-context=wayland "/media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv" 2>&1 | grep -E "Using (hardware|software)|VO:" | head -3
mpv --no-config --hwdec=vaapi --vaapi-device=/dev/dri/renderD128 "/media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv" 2>&1 | grep -E "Using (hardware|software)|VO:" | head -3
How to read them:

If the first line says x11, stop — everything about a Wayland VA display was the wrong question. Rerun with --gpu-context=x11egl instead and paste that.
If vainfo --display wayland fails to open, or names a driver other than rockchip, that's the fault: either libva-wayland2 isn't installed (sudo apt install libva-wayland2) or KWin is handing libva a device name it can't map.
If line 3 goes to Using hardware decoding (vaapi), it was the driver-name lookup on the Wayland path — one environment line fixes it.
Line 4 forces the DRM-node path Firefox uses; if it plays in hardware, that confirms the diagnosis from the other side.
Then the Chrome line, with the quoted path:


EGL_LOG_LEVEL=debug RK_VAAPI_LOG=/tmp/rk.log google-chrome --enable-features=PlatformHEVCDecoderSupport,VaapiVideoDecoder,VaapiIgnoreDriverChecks,AcceleratedVideoDecodeLinuxGL --ignore-gpu-blocklist "/media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv" 2>&1 | grep -iE "EGL user|libEGL|vaapi|POOL" | head
grep -c "10bit=1" /tmp/rk.log; grep -c "CreateSurfaces2:" /tmp/rk.log
Whichever line answers, it becomes one sentence in the Armbian guide, not a driver change. Thanks for sticking with it — you're the first person running this on a 5 Plus, and that's exactly the data we need.

Whichever of his four lines answers, that's the fix and the guide sentence, and the thread stops guessing.

@JFL they are brutal,

sorry for the brutality

Chin up I think we are almost done.

31 minutes ago, defcom5-rockchip said:

mpv -v --no-config --hwdec=vaapi --gpu-context=wayland "/media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv" 2>&1 | grep -iE "VA display|Initialized VAAPI|Supported formats|Failed|Attempting next|Using hardware|hwdec" | head -20
apt list --installed 2>/dev/null | grep -E "^libva|^mesa|panfork"
echo "LIBVA_DRIVER_NAME=$LIBVA_DRIVER_NAME"; vainfo --display wayland 2>&1 | head -6

My Armbian-opi5plus-kde-neon-6.1.172-vendor-rk35xx uses mesa-26.2.2-kisak not "panfork".  mpv did not launch with above command.

jfl@orangepi5-plus:~$ mpv -v --no-config --hwdec=vaapi --gpu-context=wayland file
:/media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv 2>&
1 | grep -iE "VA display|Initialized VAAPI|Supported formats|Failed|Attempting ne
xt|Using hardware|hwdec" | head -20 apt list --installed 2>/dev/null | grep -E "^
libva|^mesa|panfork" echo "LIBVA_DRIVER_NAME=$LIBVA_DRIVER_NAME"; vainfo --displa
y wayland 2>&1 | head -6
grep: echo: No such file or directory
grep: LIBVA_DRIVER_NAME=: No such file or directory
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/aarch64-linux-gnu/dri/panthor_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit
jfl@orangepi5-plus:~$

 

Whereas below command mpv play the video with NO vpu hardware acceleration

 

jfl@orangepi5-plus:~$ mpv -v --no-config --hwdec=vaapi --gpu-context=wayland "/me
dia/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv"  
[cplayer] Command line options: '-v' '--no-config' '--hwdec=vaapi' '--gpu-context
=wayland' '/media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc-10b
it.mkv'
[cplayer] mpv 0.36.0 Copyright © 2000-2023 mpv/MPlayer/mplayer2 projects
[cplayer]  built on UNKNOWN
[cplayer] libplacebo version: v6.338.2
[cplayer] FFmpeg version: 6.1.1-3ubuntu5+git240504.09cd2a2~noble
[cplayer] FFmpeg library versions:
[cplayer]    libavutil       58.29.100
[cplayer]    libavcodec      60.31.102
[cplayer]    libavformat     60.16.100
[cplayer]    libswscale      7.5.100
[cplayer]    libavfilter     9.12.100
[cplayer]    libswresample   4.12.100
[cplayer]  
[cplayer] Configuration: -Dpython.bytecompile=-1 -Dlibmpv=true -Dbuild-date=false
-Dcdda=enabled -Ddvdnav=enabled -Dsdl2=enabled -Dsndio=disabled -Ddvbin=enabled
-Dprefix=/usr -Dlibdir=lib/aarch64-linux-gnu -Dlocalstatedir=/var -Dsysconfdir=/e
tc -Dbuildtype=plain -Dwrap_mode=nodownload
[cplayer] List of enabled features: alsa av-channel-layout avif_muxer caca cdda c
plugins cuda-hwaccel cuda-interop dmabuf-interop-gl dmabuf-interop-pl dmabuf-wayl
and drm drm-is-kms dvbin dvdnav egl egl-drm egl-helpers egl-x11 ffmpeg ffnvcodec
gbm gl gl-wayland glibc-thread-name glob glob-posix gpl iconv jack javascript jpe
g jpegxl lcms2 libarchive libass libavdevice libbluray libdl libm libplacebo libp
lacebo-next librt linux-fstatfs lua52 manpage-build memfd_create noexecstack pipe
wire posix posix_shm pulse rubberband rubberband-3 sdl2 sdl2-audio sdl2-gamepad s
dl2-video sixel spirv-cross stdatomic threads uchardet vaapi vaapi-drm vaapi-egl
vaapi-libplacebo vaapi-wayland vaapi-x-egl vaapi-x11 vdpau vector vk_khr_display
vt.h vulkan vulkan-interop wayland wayland_protocols_1_27 wayland_protocols_1_31
wayland_protocols_1_32 x11 xv zimg zimg-st428 zlib
[cplayer] Setting option 'v' = '' (flags = 8)
[cplayer] Setting option 'config' = 'no' (flags = 8)
[cplayer] Setting option 'hwdec' = 'vaapi' (flags = 8)
[cplayer] Setting option 'gpu-context' = 'wayland' (flags = 8)
[cplayer] Waiting for scripts...
[osd/libass] libass API version: 0x1701000
[osd/libass] libass source: tarball: 0.17.1
[osd/libass] Shaper: FriBidi 1.0.13 (SIMPLE) HarfBuzz-ng 8.3.0 (COMPLEX)
[osd/libass] Setting up fonts...
[osd/libass] Using font provider fontconfig
[osd/libass] Done.
[cplayer] Set property: shared-script-properties -> 1
[cplayer] Set property: user-data/osc/visibility="auto" -> 1
[cplayer] Set property: shared-script-properties -> 1
[cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1
[cplayer] Done loading scripts.
[cplayer] Running hook: ytdl_hook/on_load
[ytdl_hook] ytdl:// hook  
[ytdl_hook] not a ytdl:// url  
[cplayer] Set property: shared-script-properties -> 1
[cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1
[ifo_dvdnav] Opening /media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uh
d-hevc-10bit.mkv
[bdmv/bluray] Opening /media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-u
hd-hevc-10bit.mkv
[file] Opening /media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc
-10bit.mkv
[demux] Trying demuxers for level=normal.
[mkv] Deferring reading cues.
[mkv] All headers are parsed!
[cplayer] Set property: shared-script-properties -> 1
[cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1
[osd/libass] libass API version: 0x1701000
[osd/libass] libass source: tarball: 0.17.1
[osd/libass] Shaper: FriBidi 1.0.13 (SIMPLE) HarfBuzz-ng 8.3.0 (COMPLEX)
[osd/libass] Setting up fonts...
[mkv] Start PTS: 0.067000
[demux] Detected file format: Matroska
[cplayer] Opening done: /media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k
-uhd-hevc-10bit.mkv
[osd/libass] Using font provider fontconfig
[osd/libass] Done.
[find_files] Loading external files in /media/jfl/writable/home/jfl/Videos/
[cplayer] Running hook: ytdl_hook/on_preloaded
[mkv] select track 0
[cplayer]  (+) Video --vid=1 (*) (hevc 3840x2160 29.970fps)
[vo/gpu/opengl] Initializing GPU context 'wayland'
[vo/gpu/wayland] Registered for protocol wl_compositor
[vo/gpu/wayland] Registered for protocol zxdg_decoration_manager_v1
[vo/gpu/wayland] Registered for protocol wp_viewporter
[vo/gpu/wayland] Registered for protocol wp_fractional_scale_manager_v1
[vo/gpu/wayland] Registered for protocol wl_shm
[vo/gpu/wayland] Registered for protocol wl_seat
[vo/gpu/wayland] Registered for protocol wl_data_device_manager
[vo/gpu/wayland] Registered for protocol wp_cursor_shape_manager_v1
[vo/gpu/wayland] Registered for protocol zwp_idle_inhibit_manager_v1
[vo/gpu/wayland] Registered for protocol wl_subcompositor
[vo/gpu/wayland] Registered for protocol wp_content_type_manager_v1
[vo/gpu/wayland] Registered for protocol wp_presentation
[vo/gpu/wayland] Registered for protocol wp_single_pixel_buffer_manager_v1
[vo/gpu/wayland] Registered for protocol zwp_linux_dmabuf_v1
[vo/gpu/wayland] Registered for protocol xdg_wm_base
[vo/gpu/wayland] Registered for protocol wl_output
[vo/gpu/wayland] Registered output Philips Consumer Electronics Company PHL 241V8
(0x40):
[vo/gpu/wayland]        x: 0px, y: 0px
[vo/gpu/wayland]        w: 1920px (527mm), h: 1080px (296mm)
[vo/gpu/wayland]        scale: 1
[vo/gpu/wayland]        Hz: 60.000000
[vo/gpu/wayland] Enabling server decorations
[vo/gpu/wayland] Obtained preferred scale, 1.000000, from the compositor.
[vo/gpu/opengl] EGL_VERSION=1.5
[vo/gpu/opengl] EGL_VENDOR=Mesa Project
[vo/gpu/opengl] EGL_CLIENT_APIS=OpenGL OpenGL_ES  
[vo/gpu/opengl] Trying to create Desktop OpenGL context.
[vo/gpu/wayland] GL_VERSION='3.1 Mesa 26.2.2 - kisak-mesa PPA'
[vo/gpu/wayland] Detected desktop OpenGL 3.1.
[vo/gpu/wayland] GL_VENDOR='Mesa'
[vo/gpu/wayland] GL_RENDERER='Mali-G610 MC4 (Panfrost)'
[vo/gpu/wayland] GL_SHADING_LANGUAGE_VERSION='1.40'
[vo/gpu/wayland] Loaded extension GL_ARB_sync.
[vo/gpu/wayland] Loaded extension GL_ARB_timer_query.
[vo/gpu/wayland] Loaded extension GL_ARB_invalidate_subdata.
[vo/gpu/wayland] Loaded extension GL_ARB_get_program_binary.
[vo/gpu/wayland] Loaded extension GL_ARB_buffer_storage.
[vo/gpu/wayland] Loaded extension GL_ARB_shader_image_load_store.
[vo/gpu/wayland] Loaded extension GL_ARB_shader_storage_buffer_object.
[vo/gpu/wayland] Loaded extension GL_ARB_arrays_of_arrays.
[vo/gpu/wayland] Loaded extension GL_ARB_debug_output.
[vo/gpu/wayland] Loaded extension GL_KHR_debug.
[vo/gpu] Testing FBO format rgba16f
[vo/gpu] Using FBO format rgba16f.
[vo/gpu] Disabling HDR peak computation (one or more of the following is not supp
orted: compute shaders=0, SSBO=1).
[vo/gpu] No advanced processing required. Enabling dumb mode.
[vd] Container reported FPS: 29.970000
[vd] Codec list:
[vd]     hevc - HEVC (High Efficiency Video Coding)
[vd]     hevc_rkmpp (hevc) - Rockchip MPP (Media Process Platform) HEVC decoder
[vd]     hevc_v4l2m2m (hevc) - V4L2 mem2mem HEVC decoder wrapper
[vd]     hevc_cuvid (hevc) - Nvidia CUVID HEVC decoder
[vd] Opening decoder hevc
[vd] Looking at hwdec hevc-vaapi...
[vo/gpu] Loading hwdec drivers for format: 'vaapi'
[vo/gpu] Loading hwdec driver 'vaapi'
[vo/gpu/vaapi] using EGL dmabuf interop
[vo/gpu/vaapi] Trying to open a x11 VA display...
[vo/gpu/vaapi] Trying to open a wayland VA display...
[vo/gpu] Loading failed.
[vd] Could not create device.
[vd] Using software decoding.
[vd] Detected 8 logical cores.
[vd] Requesting 9 threads for decoding.
[vd] Selected codec: hevc (HEVC (High Efficiency Video Coding))
[vf] User filter list:
[vf]   (empty)
[cplayer] Starting playback...
[vo/gpu] DR path suspected slow/uncached, disabling.
[vd] DR failed - disabling.
[vd] Using software decoding.
[vd] Decoder format: 3840x2160 yuv420p10 auto/auto/auto/limited/auto CL=mpeg2/4/h
264
[vd] Using container aspect ratio.
[vf] [in] 3840x2160 yuv420p10 bt.709/bt.709/bt.1886/limited/display SP=1.000000 C
L=mpeg2/4/h264
[vf] [userdeint] 3840x2160 yuv420p10 bt.709/bt.709/bt.1886/limited/display SP=1.0
00000 CL=mpeg2/4/h264
[vf] [userdeint] (disabled)
[vf] [autorotate] 3840x2160 yuv420p10 bt.709/bt.709/bt.1886/limited/display SP=1.
000000 CL=mpeg2/4/h264
[vf] [autorotate] (disabled)
[vf] [convert] 3840x2160 yuv420p10 bt.709/bt.709/bt.1886/limited/display SP=1.000
000 CL=mpeg2/4/h264
[vf] [convert] (disabled)
[vf] [out] 3840x2160 yuv420p10 bt.709/bt.709/bt.1886/limited/display SP=1.000000
CL=mpeg2/4/h264
[cplayer] Set property: shared-script-properties -> 1
[cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1
[cplayer] VO: [gpu] 3840x2160 yuv420p10
[cplayer] VO: Description: Shader-based GPU Renderer
[vo/gpu] reconfig to 3840x2160 yuv420p10 bt.709/bt.709/bt.1886/limited/display SP
=1.000000 CL=mpeg2/4/h264
[vo/gpu/wayland] Reconfiguring!
[vo/gpu] Resize: 3840x2160
[vo/gpu] Window size: 3840x2160 (Borders: l=0 t=0 r=0 b=0)
[vo/gpu] Video source: 3840x2160 (1:1)
[vo/gpu] Video display: (0, 0) 3840x2160 -> (0, 0) 3840x2160
[vo/gpu] Video scale: 1.000000/1.000000
[vo/gpu] OSD borders: l=0 t=0 r=0 b=0
[vo/gpu] Video borders: l=0 t=0 r=0 b=0
[vo/gpu] Texture for plane 0: 3840x2160
[vo/gpu] Texture for plane 1: 1920x1080
[vo/gpu] Texture for plane 2: 1920x1080
[vo/gpu] Testing FBO format rgba16f
[vo/gpu] Using FBO format rgba16f.
[vo/gpu] No advanced processing required. Enabling dumb mode.
[vo/gpu/wayland] Handling resize on the egl side
[vo/gpu] Resize: 1920x1008
[vo/gpu] Window size: 1920x1008 (Borders: l=0 t=0 r=0 b=0)
[vo/gpu] Video source: 3840x2160 (1:1)
[vo/gpu] Video display: (0, 0) 3840x2160 -> (64, 0) 1792x1008
[vo/gpu] Video scale: 0.466667/0.466667
[vo/gpu] OSD borders: l=64 t=0 r=64 b=0
[vo/gpu] Video borders: l=64 t=0 r=64 b=0
[vo/gpu] Reported display depth: 10
[cplayer] first video frame after restart shown
[cplayer] playback restart complete @ 0.000000, audio=eof, video=playing
[statusline] V: 00:00:00 / 00:00:30 (0%)
[vo/gpu/wayland] Enabling idle inhibitor
[statusline] V: 00:00:00 / 00:00:30 (0%)
[vo/gpu/wayland] Surface entered output Philips Consumer Electronics Company PHL
241V8 (0x40), scale = 1.000000, refresh rate = 60.000000 Hz
[vo/gpu/wayland] Given DND offer with mime type text/plain
[vo/gpu/wayland] Given DND offer with mime type text/plain;charset=utf-8
[vo/gpu/wayland] Received a new DND offer. Releasing the previous offer.
[vo/gpu/wayland] Resizing due to xdg from 1920x1008 to 1920x1080
[vo/gpu/wayland] Handling resize on the egl side
[vo/gpu] Resize: 1920x1080
[vo/gpu] Window size: 1920x1080 (Borders: l=0 t=0 r=0 b=0)
[vo/gpu] Video source: 3840x2160 (1:1)
[vo/gpu] Video display: (0, 0) 3840x2160 -> (0, 0) 1920x1080
[vo/gpu] Video scale: 0.500000/0.500000
[vo/gpu] OSD borders: l=0 t=0 r=0 b=0
[vo/gpu] Video borders: l=0 t=0 r=0 b=0
[vo/gpu] Reported display depth: 10
[vo/gpu] Assuming 60.000000 FPS for display sync.
[cplayer] Set property: shared-script-properties -> 1
[cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1
[statusline] V: 00:00:01 / 00:00:30 (5%) Dropped: 14
[cplayer] Set property: shared-script-properties -> 1
[statusline] V: 00:00:01 / 00:00:30 (5%) Dropped: 14
[cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1
[statusline] V: 00:00:01 / 00:00:30 (5%) Dropped: 14
[osd/libass] fontselect: (sans-serif, 400, 0) -> /usr/share/fonts/truetype/noto/N
otoSans-Regular.ttf, 0, NotoSans-Regular
[osd/libass] fontselect: (mpv-osd-symbols, 400, 0) -> mpv-osd-symbols-Regular, 0,
mpv-osd-symbols-Regular
[vo/gpu] Reallocating OSD texture to 2048x256.
[statusline] V: 00:00:01 / 00:00:30 (6%) Dropped: 16
[cplayer] Set property: shared-script-properties -> 1
[cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1
[statusline] V: 00:00:02 / 00:00:30 (7%) Dropped: 18
[cplayer] Set property: shared-script-properties -> 1
[cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1
[statusline] V: 00:00:02 / 00:00:30 (8%) Dropped: 22
[cplayer] Set property: shared-script-properties -> 1
[cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1
[statusline] V: 00:00:05 / 00:00:30 (17%) Dropped: 37
[cplayer] EOF code: 5   
[vo/gpu/wayland] Disabling the idle inhibitor
[vf] dropping frame due to pin disconnect
[cplayer] finished playback, success (reason 3)
[cplayer]  
[cplayer] Exiting... (Quit)
[cplayer] Set property: shared-script-properties -> 1
[vo/gpu/wayland] Deregistering output Philips Consumer Electronics Company PHL 24
1V8 (0x40)
jfl@orangepi5-plus:~$

 

 

2 hours ago, defcom5-rockchip said:

echo $XDG_SESSION_TYPE

Hi @defcom5-rockchip

 

jfl@orangepi5-plus:~$ echo $XDG_SESSION_TYPE
wayland

 

panthor_drv_video.so? error?  There is no /usr/lib/aarch64-linux-gnu/dri/panthor_drv_video.so
on my sd card.  /usr/lib/aarch64-linux-gnu/panthor_dri.so exist.

jfl@orangepi5-plus:~$ vainfo --display wayland 2>&1 | head -5
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/aarch64-linux-gnu/dri/panthor_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit
jfl@orangepi5-plus:~$

mpv never launch

jfl@orangepi5-plus:~$ LIBVA_DRIVER_NAME=rockchip mpv --no-config --hwdec=vaapi --
gpu-context=wayland "/media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uh
d-hevc-10bit.mkv" 2>&1 | grep -E "Using (hardware|software)|VO:" | head -3
jfl@orangepi5-plus:~$

mpv never launch

jfl@orangepi5-plus:~$ mpv --no-config --hwdec=vaapi --vaapi-device=/dev/dri/rende
rD128 "/media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc-10bit.m
kv" 2>&1 | grep -E "Using (hardware|software)|VO:" | head -3
jfl@orangepi5-plus:~$  

 

Edited September 8Sep 8 by JFL

Hi @defcom5-rockchip

 

jfl@orangepi5-plus:~$ EGL_LOG_LEVEL=debug RK_VAAPI_LOG=/tmp/rk.log google-chrome-
hw --enable-features=PlatformHEVCDecoderSupport,VaapiVideoDecoder,VaapiIgnoreDriv
erChecks,AcceleratedVideoDecodeLinuxGL --ignore-gpu-blocklist "/media/jfl/writabl
e/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv" 2>&1 | grep -iE "EGL
user|libEGL|vaapi|POOL" | head
grep -c "10bit=1" /tmp/rk.log; grep -c "CreateSurfaces2:" /tmp/rk.log
[9650:9823:0908/152854.730362:ERROR:media/gpu/vaapi/vaapi_wrapper.cc:3586] vaCrea
teSurfaces (allocate mode) failed, VA error: resource allocation failed
[9650:9823:0908/152854.730681:ERROR:media/gpu/vaapi/vaapi_wrapper.cc:3586] vaCrea
teSurfaces (allocate mode) failed, VA error: resource allocation failed
[9650:9823:0908/152854.730826:ERROR:media/gpu/vaapi/vaapi_wrapper.cc:3586] vaCrea
teSurfaces (allocate mode) failed, VA error: resource allocation failed
[9650:9823:0908/152854.730935:ERROR:media/gpu/vaapi/vaapi_wrapper.cc:3586] vaCrea
teSurfaces (allocate mode) failed, VA error: resource allocation failed
[9650:9823:0908/152854.731034:ERROR:media/gpu/vaapi/vaapi_wrapper.cc:3586] vaCrea
teSurfaces (allocate mode) failed, VA error: resource allocation failed
[9650:9823:0908/152854.731120:ERROR:media/gpu/vaapi/vaapi_wrapper.cc:3586] vaCrea
teSurfaces (allocate mode) failed, VA error: resource allocation failed
[9650:9823:0908/152854.731214:ERROR:media/gpu/vaapi/vaapi_wrapper.cc:3586] vaCrea
teSurfaces (allocate mode) failed, VA error: resource allocation failed
[9650:9823:0908/152854.731299:ERROR:media/gpu/vaapi/vaapi_wrapper.cc:3586] vaCrea
teSurfaces (allocate mode) failed, VA error: resource allocation failed
[9650:9823:0908/152854.731386:ERROR:media/gpu/vaapi/vaapi_wrapper.cc:3586] vaCrea
teSurfaces (allocate mode) failed, VA error: resource allocation failed
[9650:9823:0908/152854.731475:ERROR:media/gpu/vaapi/vaapi_wrapper.cc:3586] vaCrea
teSurfaces (allocate mode) failed, VA error: resource allocation failed
^C0
11983
jfl@orangepi5-plus:~$

google-chrome-hw output corrupted video output then green screen.

 

rk.log is 3.5MB did not seem to able to attached here.  rk1.log is a section of the output of rk.log.

rk1.log

 

This might just work...

@JFL — that log excerpt was exactly what was needed. Both problems are found, and both are mine, not your box's.

Chrome (garbled → green). Your driver log shows the pattern on every frame: Chrome creates a 10-bit surface, exports it, and only then decodes into it. The driver decided "10-bit or 8-bit" from the last decoded frame — which didn't exist yet — so every export described your 10-bit surfaces as 8-bit NV12 (10bit=0 on all 11,983 of them). Chrome then read P010 pixels through an NV12 description: garbled, then green. The vaCreateSurfaces errors were Chrome allocating ever more surfaces because none of them yielded a usable frame. Firefox never hit it because it exports after decoding. Fixed in v2.1.5: a surface is described by the depth it was created with until a frame is decoded. Verified with a new test that exports a 10-bit surface before any decode (2.1.4: NV12; 2.1.5: P010 / R16+GR1616).

mpv (software). Your vainfo line says it: Trying to open …/dri/panthor_drv_video.so. Your image runs the GPU on the mainline Panthor driver with kisak's Mesa 26, and libva names the VA driver after the render node's kernel driver — panthor — so it never looks for rockchip_drv_video.so. Firefox works because it opens a different node. v2.1.5 ships panthor_drv_video.so and panfrost_drv_video.so symlinks, so auto-detection just works; on any version LIBVA_DRIVER_NAME=rockchip in the environment does the same. (Your LIBVA_DRIVER_NAME=rockchip mpv … | grep … run probably did play in hardware — without -v, mpv prints nothing that matches that grep, so "no output" wasn't "didn't launch".)

v2.1.5: https://github.com/defcom5-rockchip/rockchip-vaapi/releases/tag/v2.1.5. After installing:

vainfo --display wayland | head -3 # should load the driver with no LIBVA_DRIVER_NAME set mpv -v --no-config --hwdec=vaapi "/media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv" 2>&1 | grep -E "Using hardware|VO:"

and the Chrome command you used before. Both should be hardware now; if Chrome still misbehaves, the same RK_VAAPI_LOG counts (10bit=1 should now equal the number of exports) will tell.

Thank you — the driver log with the frame-by-frame sequence is what cracked it. Two KNOWN-ISSUES entries (KI-8, KI-9) credit the report.

 

 

latest Release
 

https://github.com/defcom5-rockchip/rockchip-vaapi/releases/tag/v2.1.5

9 hours ago, defcom5-rockchip said:

panthor_drv_video.so and panfrost_drv_video.so symlinks, so auto-detection just works; on any version LIBVA_DRIVER_NAME=rockchip in the environment does the same. (Your LIBVA_DRIVER_NAME=rockchip mpv … | grep … run probably did play in hardware — without -v, mpv prints nothing that matches that grep, so "no output" wasn't "didn't launch".)

v2.1.5: https://github.com/defcom5-rockchip/rockchip-vaapi/releases/tag/v2.1.5. After installing:

Hi @defcom5-rockchip

Thank you.  A success.  With v2.1.5 google-chrome-hw successfully played "/media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv" with vpu hardware acceleration now.  Great work.  

 

google-chrome-hw also played 10bit vp9 profile 2 with vpu hardware acceleration.

 

fl@orangepi5-plus:~$ vainfo --display wayland 2>&1 | head -5
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/aarch64-linux-gnu/dri/panthor_drv_video.so
libva info: Found init function __vaDriverInit_1_20
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.20 (libva 2.12.0)

 

mpv also can now play 10bit hevc and vp9 profile 2 videos with --gpu-context=wayland or --gpu-context=x11egl (x11egl usually less dropped frames on this set up).  Great.
 

jfl@orangepi5-plus:~$ LIBVA_DRIVER_NAME=rockchip mpv --no-config --hwdec=vaapi --gpu-context=wayla
nd '/media/jfl/writable/home/jfl/Videos/The World in HDR.mkv'  
(+) Video --vid=1 (*) (vp9 3840x2160 59.940fps)
(+) Audio --aid=1 --alang=eng (*) (vorbis 2ch 44100Hz)
Using hardware decoding (vaapi).
AO: [pipewire] 44100Hz stereo 2ch floatp
VO: [gpu] 3840x2160 vaapi[p010]
AV: 00:02:34 / 00:02:34 (100%) A-V:  0.000 Dropped: 345

Exiting... (End of file)
jfl@orangepi5-plus:~$ LIBVA_DRIVER_NAME=rockchip mpv --no-config --hwdec=vaapi --gpu-context=x11eg
l '/media/jfl/writable/home/jfl/Videos/The World in HDR.mkv'  
(+) Video --vid=1 (*) (vp9 3840x2160 59.940fps)
(+) Audio --aid=1 --alang=eng (*) (vorbis 2ch 44100Hz)
Using hardware decoding (vaapi).
AO: [pipewire] 44100Hz stereo 2ch floatp
VO: [gpu] 3840x2160 vaapi[p010]
AV: 00:02:34 / 00:02:34 (100%) A-V:  0.000 Dropped: 97

Exiting... (End of file)
jfl@orangepi5-plus:~$

 

 

That's the confirmation the release needed: Chrome on his Orange Pi 5 Plus with the Armbian vendor kernel now plays 4K HEVC 10-bit and VP9 Profile 2 in hardware, libva auto-detects through the panthor symlink, and mpv is zero-copy 10-bit on both display stacks. Both v2.1.5 changes proved out on hardware we don't own.

His dropped-frame numbers are the one open thread, and they match ours: the 4K60 HDR corner is display-side cost, not decode. Draft reply below (also saved on the NAS as reply 8); post it as defcom5-rockchip.
 

Hi @JFL — that's the confirmation we were hoping for, thank you. Chrome playing the 120 Mbps 4K HEVC 10-bit jellyfish clip and VP9 Profile 2 in hardware on an Orange Pi 5 Plus / Armbian vendor kernel means the two things v2.1.5 changed (exporting P010 for surfaces created 10-bit before the first decode, and the panthor_drv_video.so name for libva's auto-detection) both do their job outside our own boards. With your permission I'll credit "JFL (Armbian forum)" for that in the release notes and the README's tested-hardware line.

On the dropped frames for The World in HDR (VP9 Profile 2, 3840x2160p60): the decode side is not where those go. The VPU does 4K60 VP9 P2 with room to spare; the drops happen after decode, when the GPU has to sample the 10-bit P010 planes, tone-map the HDR to your panel and scale, 60 times a second at 4K — the G610 is at its limit there, and every extra copy costs frames. That's also why x11egl (97 drops over the 2:34 clip, about 1%) beats Wayland (345, about 3.7%): under Wayland the compositor adds a pass. Two things worth trying, in this order:

Fullscreen (--fs) — a fullscreen surface can bypass the compositor's copy on both stacks.
--hwdec=vaapi-copy instead of vaapi for this one file. Counter-intuitive, but for 4K60 10-bit the copy path hands the GPU a plain P010 texture instead of two imported 16-bit planes, and on our boards that is sometimes the smoother of the two. We're deciding the default for 4K60 10-bit in the next image right now, so your numbers from the 5 Plus would go straight into that decision.
For 4K60 8-bit and for anything 10-bit at 24/30 fps, zero-copy vaapi stays the right default — the drops are specific to the 4K60 HDR corner.

Longer term the fix is to move that conversion off the GPU: RGA3 on the RK3588 converts NV15 to NV12 in hardware, and an export lane that uses it is on the roadmap. When that lands the 4K60 HDR case should stop dropping frames on either display stack.

Thanks again for running every one of these — the 5 Plus / Armbian column of the compatibility table is entirely your work.

Awesome

Great Release 

I just saw this:

https://jellyfin.org/posts/jellyfin-release-12.0/

Edited September 9Sep 9 by defcom5-rockchip

Hi @defcom5-rockchip

 

Just to share.  mpv --vf-add=scale_rkrga=force_yuv=auto --hwdec=rkmpp --gpu-context=x11egl '/media/jfl/writable/home/jfl/Videos/The World in HDR.mkv'.  Much better performance in terms of dropped frames.

 

jfl@orangepi5-plus:~$ mpv --vf-add=scale_rkrga=force_yuv=auto --hwdec=rkmpp --gpu-context=x11egl '
/media/jfl/writable/home/jfl/Videos/The World in HDR.mkv'  
(+) Video --vid=1 (*) (vp9 3840x2160 59.940fps)
(+) Audio --aid=1 --alang=eng (*) (vorbis 2ch 44100Hz)
Using hardware decoding (rkmpp).
rga_api version 1.10.0_[8]
AO: [pipewire] 44100Hz stereo 2ch floatp
VO: [gpu] 3840x2160 drm_prime[p010]
AV: 00:02:34 / 00:02:34 (100%) A-V:  0.000 Dropped: 1

Exiting... (End of file)
jfl@orangepi5-plus:~$

 

 

 

21 minutes ago, defcom5-rockchip said:

Longer term the fix is to move that conversion off the GPU: RGA3 on the RK3588 converts NV15 to NV12 in hardware, and an export lane that uses it is on the roadmap. When that lands the 4K60 HDR case should stop dropping frames on either display stack

Looking for the new release.  Thank you.

Kickin'

His number closes the argument: one dropped frame through the RGA lane against 97 through the GPU-only path on the same file. That's the hardware conversion we want inside the VA-API driver next, so browsers get it too. Speed reply, saved on the NAS as reply 9:
 

Hi @JFL — that's the result that settles the 4K60 HDR question, thank you. What you switched on is the RGA lane: the decoder hands the native NV15 frame to the RK3588's 2D engine, which does the 10-bit conversion and scaling in hardware (that's the rga_api 1.10.0 line), and the GPU only has to compose the finished P010 image. One dropped frame in 9,240 versus 97 through the GPU-only zero-copy path — same shape we measured on our boards, now confirmed on the 5 Plus.

So the practical rule for mpv on an ffmpeg-rockchip build like yours: --hwdec=rkmpp --vf-add=scale_rkrga=force_yuv=auto for 4K60 10-bit (keep force_yuv=auto — it stays 10-bit so the HDR tone-mapping is still done from real data), and --hwdec=vaapi remains the right lane for the browsers and for mpv builds without rkmpp.

That's also exactly why the next big item in the VA-API driver is an RGA export lane: Chrome and Firefox can't use rkmpp or scale_rkrga, so the driver has to do the same NV15-to-display conversion on the RGA itself before handing the buffer over. Your two runs are the before/after numbers for that work.

Well mine got better

Hi @JFL — the build you were waiting for is up as a test release: https://github.com/defcom5-rockchip/rockchip-vaapi/releases/tag/v2.2.0-rc1

What it does: 10-bit surfaces are now exported as true P010 converted from the decoder's NV15 on the RGA3 2D engine instead of on the CPU — the same conversion your scale_rkrga run used, done inside the driver so Chrome, Firefox and plain --hwdec=vaapi get it too. On our board it is bit-exact with the old path (probe, in-driver frame dump and the software-reference ladders all agree) and cuts mpv's CPU time at 4K60 HDR by about 5×. The 8-bit copy also runs on RGA now.
 

Install: sudo apt install librga2 if you don't have it, then sudo dpkg -i rockchip-vaapi-driver_2.2.0~rc1_arm64.deb. RKVA_RGA_P010=0 in the environment brings back the CPU path if you want to compare.

The run I'd love from the 5 Plus: The World in HDR with LIBVA_DRIVER_NAME=rockchip mpv --no-config --hwdec=vaapi --gpu-context=x11egl — your 97 drops were the CPU repack, so that number should fall toward your rkmpp result. One more thing we found on the way: mpv's default sync mode was the cause of most of our remaining drops at 4K60 — --video-sync=display-resample took a 4K60 HDR10 clip from 605 dropped in 900 to 0 here, with decode and GPU unchanged. Worth adding to your mpv.conf on the 5 Plus as well.

Hi @defcom5-rockchip

 

2 hours ago, defcom5-rockchip said:

The run I'd love from the 5 Plus: The World in HDR with LIBVA_DRIVER_NAME=rockchip mpv --no-config --hwdec=vaapi --gpu-context=x11egl — your 97 drops were the CPU repack, so that number should fall toward your rkmpp result

Installed v2.2.0-rc1.  LIBVA_DRIVER_NAME=rockchip mpv --no-config --hwdec=vaapi --gpu-context=wayland '/media/jfl/writable/home/jfl/Videos/The World in HDR.mkv' frame dropped has improved.

 

jfl@orangepi5-plus:~$ LIBVA_DRIVER_NAME=rockchip mpv --no-config --hwdec=vaapi --
gpu-context=wayland '/media/jfl/writable/home/jfl/Videos/The World in HDR.mkv'
(+) Video --vid=1 (*) (vp9 3840x2160 59.940fps)
(+) Audio --aid=1 --alang=eng (*) (vorbis 2ch 44100Hz)
Using hardware decoding (vaapi).
AO: [pipewire] 44100Hz stereo 2ch floatp
VO: [gpu] 3840x2160 vaapi[p010]
rga_api version 1.10.0_[8]
AV: 00:02:34 / 00:02:34 (100%) A-V:  0.000 Dropped: 46

 

mpv full-screen

jfl@orangepi5-plus:~$ LIBVA_DRIVER_NAME=rockchip mpv -fs --no-config --hwdec=vaap
i --gpu-context=wayland '/media/jfl/writable/home/jfl/Videos/The World in HDR.mkv
'
(+) Video --vid=1 (*) (vp9 3840x2160 59.940fps)
(+) Audio --aid=1 --alang=eng (*) (vorbis 2ch 44100Hz)
Using hardware decoding (vaapi).
AO: [pipewire] 44100Hz stereo 2ch floatp
VO: [gpu] 3840x2160 vaapi[p010]
rga_api version 1.10.0_[8]
AV: 00:02:34 / 00:02:34 (100%) A-V:  0.000 Dropped: 25

Exiting... (End of file)
jfl@orangepi5-plus:~$

 

With --gpu-context=x11egl --hwdec=vaapi basically equal --gpu-context=x11egl --hwdec=rkmpp for this  '/media/jfl/writable/home/jfl/Videos/The World in HDR.mkv' video. Great

jfl@orangepi5-plus:~$ LIBVA_DRIVER_NAME=rockchip mpv --no-config --hwdec=vaapi --
gpu-context=x11egl '/media/jfl/writable/home/jfl/Videos/The World in HDR.mkv'
(+) Video --vid=1 (*) (vp9 3840x2160 59.940fps)
(+) Audio --aid=1 --alang=eng (*) (vorbis 2ch 44100Hz)
Using hardware decoding (vaapi).
AO: [pipewire] 44100Hz stereo 2ch floatp
VO: [gpu] 3840x2160 vaapi[p010]
rga_api version 1.10.0_[8]
AV: 00:02:34 / 00:02:34 (100%) A-V:  0.000 Dropped: 1

Exiting... (End of file)
jfl@orangepi5-plus:~$

 

mpv --video-sync=display-resample

jfl@orangepi5-plus:~$ LIBVA_DRIVER_NAME=rockchip mpv --no-config --hwdec=vaapi --
gpu-context=wayland  --video-sync=display-resample '/media/jfl/writable/home/jfl/
Videos/The World in HDR.mkv'
(+) Video --vid=1 (*) (vp9 3840x2160 59.940fps)
(+) Audio --aid=1 --alang=eng (*) (vorbis 2ch 44100Hz)
Using hardware decoding (vaapi).
AO: [pipewire] 44100Hz stereo 2ch floatp
VO: [gpu] 3840x2160 vaapi[p010]
rga_api version 1.10.0_[8]
AV: 00:02:34 / 00:02:34 (100%) A-V:  0.000 DS: 1.030/369 Dropped: 26

 

 

 

Nice to have toys that work...

JFL's numbers land exactly where the measurements said they would, on hardware we don't own:
 

lane on the 5 Plus (4K60 VP9 P2 HDR, 9,240 frames)                                                                2.1.5                                                                    rc1

vaapi + x11egl                                                                                                                                    97    dropped                                                     1

vaapi + Wayland, windowed                                                                                                           345                                                                     46

vaapi + Wayland, fullscreen                                                                                                             —                                                                       25
 

One drop on x11egl equals his rkmpp-plus-RGA run, which was the whole point: the only difference between those lanes was the CPU repack. The Wayland residual is the compositor's extra pass, and his display-resample result (DS: 1.030) shows mpv misjudging his display rate by 3%, so that mode is right for our GNOME bench and wrong for his setup. Good to know before it went into anyone's advice.

Meanwhile rc1 is now the system driver on .176 for the soak (it reports 2.2.0-rc1 through vainfo, links librga, symlinks intact, 10-bit plays); the 2.1.5 deb is kept on the board for a one-line rollback. When the soak is quiet for a few days and JFL answers on the credit, rc1 promotes to 2.2.0 with his two results in the notes.

Reply for JFL (saved on the NAS as reply 11):
 

Hi @JFL — that's the result, exactly where the numbers said it would land: vaapi + x11egl went from 97 dropped frames to 1, the same as your rkmpp + scale_rkrga run, because the only difference between those two lanes was the CPU repack and it's gone. Thank you for turning it around so fast.

The Wayland column (345 → 46 windowed, 25 fullscreen) is the compositor's extra pass, as before; the driver can't remove that one. And your display-resample run tells me something useful: DS: 1.030 means mpv thinks your display runs about 3 % faster than the video, so it's resampling audio to chase it — on our GNOME setup the ratio is 1.000 and that mode gives 0 drops, on yours it isn't the right tool. x11egl stays the best lane for the 5 Plus; nothing to change there.

I'll credit "JFL (Armbian forum, Orange Pi 5 Plus)" in the 2.2.0 release notes for both the Chrome 10-bit confirmation and this one. rc1 becomes 2.2.0 after it has run as the system driver on our bench for a while; same link, non-rc file name.

Finishing move :  

Jellyfin 12 on RK3588 with the Rockchip VA-API driver

How to run Jellyfin 12.0 on an RK3588/RK3588S board (Orange Pi 5/5B/5 Plus and friends) so that the server transcodes in hardware and the browser clients on the same board direct-play in hardware through this driver. Written from a Pi Desktop 2.0.2 bench (Ubuntu 24.04, BSP 6.1 kernel, panfork Mesa), but the server part is the same on Armbian and plain Ubuntu with a vendor kernel.

Two different pieces of hardware acceleration are involved, and it helps to keep them apart:

https://github.com/defcom5-rockchip/rockchip-vaapi/blob/main/docs/JELLYFIN-12-RK3588.md

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.

The Shit Is Bananas...

Killed my own session with that pattern for the fourth time today; I clearly need to stop typing bare patterns. Retrying with it escaped.
 

I'm gonna say we need a restart service on Chrome. I did not see any firefox issue.. can we make chrome buttery smooth with a quick restart ?

 

That's a sound instinct, and there's a mechanism behind it: short-lived decode sessions never accumulate whatever this is. Headless ffmpeg processes are short-lived and never storm; Firefox's constant gaps may be why it looks immune.

The least disruptive "restart" isn't Chrome itself, it's Chrome's GPU process, which owns the decoder session. Chrome respawns it automatically and playback continues. If killing it resets the clock, a timer every ten minutes turns a twenty-second garbling episode into a one-second blink.

Testing whether playback actually survives it before promising anything.

Bash Stop Firefox, start Chrome fullscreen on the file, and confirm it is decoding

IN

SP="/tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 pi-desktop@192.168.1.176 'pkill -f "^/usr/lib/firefox/firefox" 2>/dev/null; pkill -x firefox 2>/dev/null; sleep 3; echo "firefox left: $(pgrep -cf firefox)"; sudo -n dmesg -C 2>/dev/null; export XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-0; nohup setsid /home/pi-desktop/.local/bin/google-chrome-hw --start-fullscreen "file:///home/pi-desktop/oled-30min.mkv" >/dev/null 2>&1 < /dev/null & disown; sleep 25; A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 5; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); echo "chrome decoding at $(( (B-A)/5 )) fps"; echo "gpu-process pid: $(pgrep -f "chrome.*type=gpu[-]process" | head -1)"' 2>&1 | grep -v Warning; date +%T | sed 's/^/chrome started /'

OUT

firefox left: 1 chrome decoding at 64 fps gpu-process pid: 68595 chrome started 18:48:44

i hear that there is nothing new under the sun.

A restart timer is indeed an old trick, and this bug may well be old too. What's new here is only the boundary: it needs a client holding frames on screen, which is why nobody transcoding on a server has ever hit it.

Chrome is decoding at 64 fps. Testing whether it survives losing its GPU process.

Bash Kill Chrome's GPU process during playback and watch whether decoding recovers

IN

SP="/tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 pi-desktop@192.168.1.176 'P=$(pgrep -f "chrome.*type=gpu[-]process" | head -1); echo "killing gpu process $P at $(date +%T)"; kill -9 $P 2>/dev/null; for i in 1 2 3 4 5 6 7 8; do sleep 2; N=$(pgrep -f "chrome.*type=gpu[-]process" | head -1); A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 2; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); echo " +$((i*4))s: gpu_pid=${N:-none} decode=$(( (B-A)/2 ))fps"; done; echo "chrome windows alive: $(pgrep -cf "/opt/google/chrome/chrome")"' 2>&1 | grep -v Warning

OUT

killing gpu process 68595 at 18:49:05 +4s: gpu_pid=68864 decode=0fps +8s: gpu_pid=68864 decode=0fps +12s: gpu_pid=68864 decode=0fps +16s: gpu_pid=68864 decode=0fps +20s: gpu_pid=68864 decode=0fps +24s: gpu_pid=68864 decode=0fps +28s: gpu_pid=68864 decode=0fps +32s: gpu_pid=68864 decode=0fps chrome windows alive: 17

Killing the GPU process doesn't work: Chrome respawns it within four seconds, but decoding never resumes, still zero after half a minute. The browser survives, the video doesn't. Is the picture frozen or black on your screen?

So a blunt process restart is out. The scriptable version is Chrome's own remote-control interface, which can pause and resume the video, or reload the page to build a fresh decoder, without killing anything.

Bash Relaunch Chrome with its remote-control interface so a workaround can be scripted and tested

IN

SP="/tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 pi-desktop@192.168.1.176 'pkill -f "/opt/google/chrome/chrome" 2>/dev/null; sleep 4; echo "chrome left: $(pgrep -cf "/opt/google/chrome/chrome")"; sudo -n dmesg -C 2>/dev/null; export XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-0; nohup setsid /usr/bin/google-chrome-stable --ozone-platform=wayland --remote-debugging-port=9222 --remote-allow-origins=* --start-fullscreen "file:///home/pi-desktop/oled-30min.mkv" >/dev/null 2>&1 < /dev/null & disown; sleep 25; echo "devtools endpoint: $(curl -s --max-time 5 http://127.0.0.1:9222/json/version | head -c 60)"; A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 5; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); echo "decoding at $(( (B-A)/5 )) fps"' 2>&1 | grep -v Warning; date +%T | sed 's/^/clock starts /'

OUT

clock starts 18:50:05

Killed my own session with that pattern for the fourth time today; I clearly need to stop typing bare patterns. Retrying with it escaped.

Bash Relaunch Chrome with remote control using a self-match-safe kill pattern

IN

SP="/tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 pi-desktop@192.168.1.176 'pkill -f "google-chrom[e]" 2>/dev/null; sleep 4; echo "chrome left: $(pgrep -cf "google-chrom[e]")"; sudo -n dmesg -C 2>/dev/null; export XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-0; nohup setsid /usr/bin/google-chrome-stable --ozone-platform=wayland --remote-debugging-port=9222 --start-fullscreen "file:///home/pi-desktop/oled-30min.mkv" >/dev/null 2>&1 < /dev/null & disown; sleep 30; echo "devtools: $(curl -s --max-time 5 http://127.0.0.1:9222/json/version 2>/dev/null | grep -oE "\"Browser\": *\"[^\"]+\"" | head -1)"; A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 5; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); echo "decoding at $(( (B-A)/5 )) fps"; echo "page: $(curl -s --max-time 5 http://127.0.0.1:9222/json/list 2>/dev/null | grep -oE "\"url\": *\"file[^\"]*\"" | head -1 | cut -c1-70)"' 2>&1 | grep -v Warning; date +%T | sed 's/^/clock starts /'

OUT

clock starts 18:50:22

Same trap: the pattern still matched the launch path in my own command. Using the exact process name instead, which can't match a shell.

Bash Relaunch Chrome with remote control, killing the old one by exact process name

IN

SP="/tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 pi-desktop@192.168.1.176 'pkill -x chrome 2>/dev/null; sleep 4; echo "chrome procs left: $(pgrep -cx chrome)"; sudo -n dmesg -C 2>/dev/null; export XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-0; nohup setsid /usr/bin/google-chrome-stable --ozone-platform=wayland --remote-debugging-port=9222 --start-fullscreen "file:///home/pi-desktop/oled-30min.mkv" >/dev/null 2>&1 < /dev/null & disown; sleep 30; echo "devtools: $(curl -s --max-time 5 http://127.0.0.1:9222/json/version 2>/dev/null | grep -oE "Chrome/[0-9.]+" | head -1)"; A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 5; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); echo "decoding at $(( (B-A)/5 )) fps"' 2>&1 | grep -v Warning; date +%T | sed 's/^/clock starts /'

OUT

chrome procs left: 0 devtools: decoding at 65 fps clock starts 18:51:21

Chrome is up with remote control and decoding at 65 fps. Rather than build a service before knowing whether the idea works, the cheapest test of the premise is a page that interrupts itself on a timer.

Bash Run Chrome on a page that pauses playback for 400 ms every eight minutes, to test whether a brief gap prevents the storm

IN

SP="/tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 pi-desktop@192.168.1.176 'cat > /home/pi-desktop/soak-blink.html <<'"'"'EOS'"'"' <!doctype html><meta charset=utf-8><title>blink soak</title> <style>html,body{margin:0;background:#000;height:100%}video{width:100vw;height:100vh;object-fit:contain} #t{position:fixed;left:8px;top:8px;color:#0f0;font:14px monospace;background:#000a;padding:4px 8px;z-index:9}</style> <div id=t>starting</div> <video id=v autoplay muted playsinline src="oled-30min.mkv"></video> <script> const v=document.getElementById("v"), t=document.getElementById("t"); const start=Date.now(); let blinks=0, lastBlink=0; const EVERY=8*60*1000, GAP=400; // pause 400 ms every 8 minutes setInterval(()=>{ const el=Date.now()-start; if (el-lastBlink>=EVERY && !v.paused) { lastBlink=el; blinks++; v.pause(); setTimeout(()=>v.play(), GAP); } const q=v.getVideoPlaybackQuality?v.getVideoPlaybackQuality():{totalVideoFrames:0,droppedVideoFrames:0}; t.textContent=`${Math.floor(el/1000)}s blinks ${blinks} frames ${q.totalVideoFrames} dropped ${q.droppedVideoFrames} pos ${v.currentTime.toFixed(0)}s`; },1000); </script> EOS echo "page written"; pkill -x chrome 2>/dev/null; sleep 4; sudo -n dmesg -C 2>/dev/null; export XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-0; nohup setsid /usr/bin/google-chrome-stable --ozone-platform=wayland --start-fullscreen "file:///home/pi-desktop/soak-blink.html" >/dev/null 2>&1 < /dev/null & disown; sleep 25; A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 5; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); echo "decoding at $(( (B-A)/5 )) fps — a 400 ms pause every 8 min, counter on screen"' 2>&1 | grep -v Warning; date +%T | sed 's/^/blink soak starts /'

OUT

page written decoding at 64 fps — a 400 ms pause every 8 min, counter on screen blink soak starts 18:52:27

The premise is now under test: same file, same Chrome, but the page pauses itself for 400 milliseconds every eight minutes. You'll see a brief blink at the eight and sixteen minute marks and a counter in the corner.

If this comes through 25 minutes clean, then a tiny interruption does reset whatever accumulates, and the workaround becomes trivial: no service, no process killing, just a periodic blink. If it storms at seventeen minutes anyway, the idea is dead and I'll say so.

Bash Monitor the blink-soak for resets through the failure window

IN

SP="/tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; S="setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=6 pi-desktop@192.168.1.176"; T0=$(( $(date +%s) - 90 )); for i in $(seq 1 10); do OUT=$($S 'A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 3; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); printf "decode=%sfps resets=%s temp=%sC" "$(( (B-A)/3 ))" "$(sudo -n dmesg 2>/dev/null | grep -cE "rkvdec-core.*resetting")" "$(( $(cat /sys/class/thermal/thermal_zone0/temp)/1000 ))"' 2>/dev/null); R=$(echo "$OUT" | grep -oE "resets=[0-9]+" | cut -d= -f2); EL=$(( $(date +%s) - T0 )); M=""; [ -n "$R" ] && [ "$R" -gt 0 ] && M=" *** STORM at ${EL}s — the blink does NOT help ***"; [ "$EL" -gt 1300 ] && [ "${R:-0}" -eq 0 ] && M=" <-- past 21 min clean with blinks"; echo "$(date +%T) playing=${EL}s $OUT$M"; sleep 55; done

OUT

Command running in background with ID: bbur7ndk8. Output is being written to: /tmp/claude-1000/-home-rich-defrese-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/tasks/bbur7ndk8.output. You will be notified when it completes. To check interim output, use Read on that file path.

Monitoring. First blink at eight minutes, the decisive window at seventeen.

Hang Tough

I Just want to remind people that this is a real cooking show>>>
 

Same trap: the pattern still matched the launch path in my own command. Using the exact process name instead, which can't match a shell.

Bash Relaunch Chrome with remote control, killing the old one by exact process name

IN

SP="/tmp/claude-1000/-homhomelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 pi-desktop@192.168.1.176 'pkill -x chrome 2>/dev/null; sleep 4; echo "chrome procs left: $(pgrep -cx chrome)"; sudo -n dmesg -C 2>/dev/null; export XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-0; nohup setsid /usr/bin/google-chrome-stable --ozone-platform=wayland --remote-debugging-port=9222 --start-fullscreen "file:///home/pi-desktop/oled-30min.mkv" >/dev/null 2>&1 < /dev/null & disown; sleep 30; echo "devtools: $(curl -s --max-time 5 http://127.0.0.1:9222/json/version 2>/dev/null | grep -oE "Chrome/[0-9.]+" | head -1)"; A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 5; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); echo "decoding at $(( (B-A)/5 )) fps"' 2>&1 | grep -v Warning; date +%T | sed 's/^/clock starts /'

OUT

chrome procs left: 0 devtools: decoding at 65 fps clock starts 18:51:21

Chrome is up with remote control and decoding at 65 fps. Rather than build a service before knowing whether the idea works, the cheapest test of the premise is a page that interrupts itself on a timer.

Bash Run Chrome on a page that pauses playback for 400 ms every eight minutes, to test whether a brief gap prevents the storm

IN

SP="/tmp/claude-1000/--notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 pi-desktop@192.168.1.176 'cat > /home/pi-desktop/soak-blink.html <<'"'"'EOS'"'"' <!doctype html><meta charset=utf-8><title>blink soak</title> <style>html,body{margin:0;background:#000;height:100%}video{width:100vw;height:100vh;object-fit:contain} #t{position:fixed;left:8px;top:8px;color:#0f0;font:14px monospace;background:#000a;padding:4px 8px;z-index:9}</style> <div id=t>starting</div> <video id=v autoplay muted playsinline src="oled-30min.mkv"></video> <script> const v=document.getElementById("v"), t=document.getElementById("t"); const start=Date.now(); let blinks=0, lastBlink=0; const EVERY=8*60*1000, GAP=400; // pause 400 ms every 8 minutes setInterval(()=>{ const el=Date.now()-start; if (el-lastBlink>=EVERY && !v.paused) { lastBlink=el; blinks++; v.pause(); setTimeout(()=>v.play(), GAP); } const q=v.getVideoPlaybackQuality?v.getVideoPlaybackQuality():{totalVideoFrames:0,droppedVideoFrames:0}; t.textContent=`${Math.floor(el/1000)}s blinks ${blinks} frames ${q.totalVideoFrames} dropped ${q.droppedVideoFrames} pos ${v.currentTime.toFixed(0)}s`; },1000); </script> EOS echo "page written"; pkill -x chrome 2>/dev/null; sleep 4; sudo -n dmesg -C 2>/dev/null; export XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-0; nohup setsid /usr/bin/google-chrome-stable --ozone-platform=wayland --start-fullscreen "file:///home/pi-desktop/soak-blink.html" >/dev/null 2>&1 < /dev/null & disown; sleep 25; A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 5; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); echo "decoding at $(( (B-A)/5 )) fps — a 400 ms pause every 8 min, counter on screen"' 2>&1 | grep -v Warning; date +%T | sed 's/^/blink soak starts /'

OUT

page written decoding at 64 fps — a 400 ms pause every 8 min, counter on screen blink soak starts 18:52:27

The premise is now under test: same file, same Chrome, but the page pauses itself for 400 milliseconds every eight minutes. You'll see a brief blink at the eight and sixteen minute marks and a counter in the corner.

If this comes through 25 minutes clean, then a tiny interruption does reset whatever accumulates, and the workaround becomes trivial: no service, no process killing, just a periodic blink. If it storms at seventeen minutes anyway, the idea is dead and I'll say so.

Bash Monitor the blink-soak for resets through the failure window

IN

SP="/tmp/claude-1000/notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad"; export SSH_ASKPASS="$SP/askpass.sh" SSH_ASKPASS_REQUIRE=force; S="setsid -w ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=6 pi-desktop@192.168.1.176"; T0=$(( $(date +%s) - 90 )); for i in $(seq 1 10); do OUT=$($S 'A=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); sleep 3; B=$(grep -iE "rkvdec|vdpu" /proc/interrupts | awk "{s=0; for(i=2;i<=NF-3;i++) s+=\$i; t+=s} END{print t+0}"); printf "decode=%sfps resets=%s temp=%sC" "$(( (B-A)/3 ))" "$(sudo -n dmesg 2>/dev/null | grep -cE "rkvdec-core.*resetting")" "$(( $(cat /sys/class/thermal/thermal_zone0/temp)/1000 ))"' 2>/dev/null); R=$(echo "$OUT" | grep -oE "resets=[0-9]+" | cut -d= -f2); EL=$(( $(date +%s) - T0 )); M=""; [ -n "$R" ] && [ "$R" -gt 0 ] && M=" *** STORM at ${EL}s — the blink does NOT help ***"; [ "$EL" -gt 1300 ] && [ "${R:-0}" -eq 0 ] && M=" <-- past 21 min clean with blinks"; echo "$(date +%T) playing=${EL}s $OUT$M"; sleep 55; done

OUT

Command running in background with ID: bbur7ndk8. Output is being written to: /tmp/claude-1000/-home-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/tasks/bbur7ndk8.output. You will be notified when it completes. To check interim output, use Read on that file path.

Monitoring. First blink at eight minutes, the decisive window at seventeen.

Edited September 10Sep 10 by defcom5-rockchip

OK its getting deep:

 

Not Chromium's, no. mpv stormed twice on the same file, at 21.5 and 28 minutes, which is what ruled that out. Firefox looked immune but its test was invalid: it was stalling constantly, decoding in bursts with dead gaps, so it never sustained the condition.

That's the pattern worth noticing. The failure needs uninterrupted decoding, and Chrome is simply the client that's good enough to deliver it: rock-steady 60 fps for twenty minutes. Firefox stutters and accidentally protects itself; mpv is steady and eventually breaks; headless ffmpeg decodes fine but never holds frames on screen.

So it's a decoder-side fault that only a well-behaved display client can reach. Which is also why your blink idea is promising rather than a hack: if 400 milliseconds of pause every eight minutes prevents it, that confirms the accumulation is per-continuous-run and gives users a real workaround while the kernel side gets fixed.

Worth staying honest about where we are, though: the blink run is only around ten minutes in, still short of the seventeen-minute mark where Chrome broke three times. Clean now doesn't mean much yet.

3 hours ago, defcom5-rockchip said:

I did not see any firefox issue.

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 @JFL — before you spend the evening on that A/B, save yourself the trouble: we chased this all day yesterday and the artifacts are not caused by rc1. Reverting will not remove them.

What we found, all measured on an Orange Pi 5B:

The garbling is the VPU decoder timing out and being reset by the kernel, in bursts of hundreds of resets at ~15/s for 20–60 s: mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23 (0x23 has the TIMEOUT bit set). That is what damages the picture until the next keyframe.
It arrives after ~17 minutes of uninterrupted 4K60 playback, and it happened in nine separate runs at 1051–1287 s.
It reproduces with the RGA copy disabled, i.e. on exactly the code path 2.1.5 ships — and also in mpv, which never touches Chrome's pipeline. Two unrelated videos, 8-bit and 10-bit, streamed and from local files.
It never happens when decoding without a display client: the same files through ffmpeg -hwaccel vaapi -f null - at real-time pace ran 20+ minutes with zero resets, every time.
Not heat (38–50 °C, first throttle point 75 °C), not the file (both decode with zero errors in software), not memory or file descriptors, and our VA-API driver logs 650k lines through a storm without a single allocation failure, pool exhaustion or sync timeout.
So it is a decoder-side fault that only a client holding decoded frames on screen can reach, and 2.1.5 has it too — you would have met it the first time you left a 4K60 video running for twenty minutes.

The objective test, if you want to confirm it on the 5 Plus (this is the data point I'd most like from you, on either driver version):

sudo dmesg -C                       # clear the log
# play any 4K60 clip fullscreen for 20+ minutes
dmesg | grep -c "rkvdec-core.*resetting"
Zero for the first seventeen minutes, then hundreds. If your board shows the same signature, that is a second, independent piece of hardware for the upstream report I'm drafting for Rockchip and Armbian.

On the Firefox drops you mention: worth knowing that when I measured Firefox here it was not decoding steadily at all — sampled every five seconds it read 65, 51, 0, 0, 13, 65, 12, 0, 0 fps. It stalls and catches up, which shows up as your 1–3 % drops. Chrome holds a steady 60. That difference is also why Firefox looked immune to the storms in my first test: it never sustains the condition long enough. I would not read it as Firefox being better or worse, just less steady.

 

OK I'm banging on linux-rockchip-mpp's door.

I Had them go through the open issues and PR's.

 

Surveyed. Four things worth knowing, and one recommendation.

The maintainers are responsive and take community patches. Most issues close the same day, several outside pull requests have been merged. Filing our report is worth doing.

Their standing answer to reset reports is exactly what our evidence contradicts. Two issues carry our kernel message, #588 and #701, and both were answered with "a data error causes a hardware reset, that's normal, it recovers at the next keyframe". That is a fair answer for a lossy network stream. It is not an answer for a local file that decodes with zero errors in software and runs clean headless for twenty minutes on the same board. That gap is precisely the new information we'd be contributing, and it's why the report should lead with the headless-versus-displayed comparison rather than with the error code.

Pull request #968 is the most interesting open item for us. A team running an RK3588 kiosk chased a 1.3 GB/day leak and found two lifecycle bugs in MPP, one of them decoder-side: the input packet is attached to the output frame's metadata while the decoder still owns it, so it can be released twice. Their symptom is a crash with a non-positive reference count. Ours isn't that, and our memory stayed flat, so I won't claim a connection. But it's evidence that decoder-side lifetime handling in MPP has real bugs that only long-running workloads expose, which is the same shape as ours.

Issue #958 is somewhere our own hard-won knowledge would help. Someone on an RK3576 can't play HEVC 10-bit in mpv because the exported buffer arrives with no pixel format declared. We solved exactly that class of problem in our driver, including the fourcc detail that cost us a day. A short factual comment there would be genuinely useful to them.

My recommendation: file our report as an issue on that tracker, since the venue is active and the maintainers answer. Say the word and I'll post the draft under your account, and separately offer the note on #958.

Measured, and it identifies exactly what differs between a run that fails and a run that never does:
 

driver activity, per run                                                                     headless (clean)                                                        display (storms)
surfaces exported as buffers                                                                  0                                                                              90,180, one per frame
synchronisation calls                                                                                0                                                                            127,403
frames decoded                                                                                        1,801 in 30 s                                                          90,180

The headless path never exports a single buffer. The display path exports one per frame, which the client then imports into the GPU's own memory unit and drops again, sixty times a second, for twenty minutes. That's roughly seventy thousand map-and-unmap cycles in the graphics domain before the decoder starts missing its deadline.

So to answer you directly: yes, it narrows to the MPP stack, since that's what emits the timeout and what owns the VP9 path. But the trigger appears to be sustained buffer traffic on the GPU side of the same memory subsystem, which is why HEVC at the same frame rate doesn't do it and why nothing headless ever does. That's a concrete lead rather than a shrug, and it belongs in the issue.

Bash Post the measured difference to the upstream issue and record it

2 hours ago, defcom5-rockchip said:

sudo dmesg -C                       # clear the log
# play any 4K60 clip fullscreen for 20+ minutes
dmesg | grep -c "rkvdec-core.*resetting"

Hi @defcom5-rockchip

 

Device:  opi5-plus

OS:  Armbian-KDE-Neon

Kernel:  6.1.172-vendor-rk35xx-26.11.0-trunk.42 (upgraded from 6.1.172-vendor-rk35xx-26.11.0-trunk.37.  With trunk.37 had wifi connectivity/stability issue at time)

rockchip-vaapi-driver_2.2.0.rc1_arm64.deb

 

jfl@orangepi5-plus:~$ sudo dmesg -C

 

google-chrome-hw streaming for 45 minutes.  53 dropped of 164553. 4K/60 vp09. Video output smooth,

 

 

jfl@orangepi5-plus:~$ dmesg | grep -c "rkvdec-core.*resetting"
0
jfl@orangepi5-plus:~$

 

Does it looks correct? No resetting?
 

 

Testing a custom kernel with newer MPP
Where your features live, and whether the port touches them:

feature                                                                       driver                                                                touched?

4K@120 output                                  drivers/gpu/drm/rockchip (VOP2, HDMI)                               no

NPUdrivers                                                            /rknpu                                                                        no

2D engine                                              1.3.13drivers/video/rockchip/rga3                                        no

Ethernet suspend fix                        drivers/net/phy, drivers/net/ethernet                                     no

CVE and Bluetooth                                                backports various                                                   no

video decode service                            drivers/video/rockchip/mpp                                                yes

On "latest vendor": Armbian's rk-6.1-rkr7.2 is Rockchip's BSP release 7.2 on kernel 6.1.172; ours is a 6.1.75 base from ubuntu-rockchip, an older Rockchip drop. Moving our whole base to rkr7.2 would be a different and much larger project, and that one genuinely would put 4K@120 at risk, because our display work is patched against the older VOP2 and would need reworking, plus NPU revalidation. Not something to do casually, and not what's building now.

The real risk of this port is narrower: the kernel driver talks to the userspace MPP library, and a newer driver could expect a newer library. If that mismatches, decoding fails immediately and obviously rather than subtly, and the whole thing reverts with one command since it's a single commit.

Issue placed:  https://github.com/rockchip-linux/mpp

Updated. The issue now reads, at a glance:

rkvdec2: VP9 decode fails after exactly 2^16 frames in a session, when the client imports an exported dma-buf per frame (err 0x23 timeout storms; HEVC and readback clients unaffected)