Search the Community
Showing results for 'h264'.
Found 136 results
-
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:~$
-
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.
-
Hi @defcom5-rockchip Device: Opi5-Plus OS: Armbian-KDE-NEON Firefox-155.0.1 (launch using firefox-hw) Kernel: 6.1.172-vendor-rk35xx-26.11.0-trunk.37 (upgraded from 6.1.115-vendor-rk35xx-26.8.3) h264 (test video bbb_sunflower_1080p_60fps_normal.mp4) still flicker, green screen, played in slow motion. h265 8bit (Test_Jellyfin_4K_HEVC_8bit_90M.mp4) played with vpu hardware acceleration. Good. h265 10bit 1080p/60 (Test Jellyfin 1080p HEVC 10bit 3M.mp4). Works good. h265 10bit 4K/30 (jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv). No vpu hardware acceleartion, video in slow motion. HTOP report high CPU.
-
Hi @defcom5-rockchip Device: Opi5-Plus OS: Armbian-KDE-NEON Chrome_152.0.7977.82 (launch using "google-chrome-hw") Kernel: 6.1.172-vendor-rk35xx-26.11.0-trunk.37 (upgraded from 6.1.115-vendor-rk35xx-26.8.3) Install https://github.com/defcom5-rockchip/rockchip-vaapi/releases/download/v2.1.1/rockchip-vaapi-driver_2.1.1_arm64.deb as per suggestion. h264 (test video bbb_sunflower_1080p_60fps_normal.mp4) still flicker badly and visual artifacts. chrome://media-internals h265 8bit (Test_Jellyfin_4K_HEVC_8bit_90M.mp4) played with vpu hardware acceleration. Good. h265 10bit (Test Jellyfin 1080p HEVC 10bit 3M.mp4) Does NOT play.
-
Hi @defcom5-rockchip Just a feed back. Device: Opi5-Plus OS: Armbian-KDE-Neon-6.1.115-vendor-rk35xx (linux-image-vendor-rk35xx_26.8.3) Installed https://github.com/defcom5-rockchip/rockchip-vaapi/releases/download/v1.0.11-defcom5.vp9align1/rockchip-vaapi-driver_1.0.11+defcom5.vp9align1_arm64.deb and followed the steps above and install google-chrome. google-chrome-hw works well with vp9 but h264 videos flickers does not play well and h265 video just blank green screen. Any suggestions how to get it to stream/play h264 and h265 video? Same issue on firefox-hw. Firefox stream vp9 Youtube videos (though reasonably high frame drops around 2-3 percent frame dropped for 1080/60).
-
Making 2nd. post. || should we diff with Ghidra? sync Pi Claude's flicker memory notes so I'm not re-deriving something Pi Claude already nailed. Two good questions — let me answer the Ghidra one straight, then actually do the sync. Let me hunt down Pi Claude's flicker notes on the share and rockchip-notes: Bash Locate Pi Claude flicker memory notes on share/rockchip-notes IN echo "=== search share + rockchip-notes for Pi Claude's flicker memory notes ===" for base in "/mnt/orange/CLAUDE PI" "$HOME/rockchip-notes"; do [ -d "$base" ] && echo "--- under: $base ---" && \ find "$base" -type f \( -iname '*electron*' -o -iname '*compositing*' -o -iname '*flicker*' -o -iname '*vop2*' -o -iname '*video-playback*' -o -iname '*aquarium*' \) -printf '%TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null | sort -r done echo echo "=== also grep for the note SLUGS Pi Claude cited (in case they live in a memory/ dir) ===" grep -rl -iE 'electron-gpu-compositing-fix|flicker-4k120-vop2-timeout|video-playback-rk3588' "/mnt/orange/CLAUDE PI" "$HOME/rockchip-notes" 2>/dev/null | head OUT === search share + rockchip-notes for Pi Claude's flicker memory notes === --- under: /mnt/orange/CLAUDE PI --- 2026-08-25 16:55 /mnt/orange/CLAUDE PI/HANDOFF-PC-4k120-flicker-is-zerocopy-h264-decode.md 2026-08-25 16:30 /mnt/orange/CLAUDE PI/chrome-flicker/HANDOFF-to-Pi-Claude-flicker-capture.md 2026-08-01 14:44 /mnt/orange/CLAUDE PI/DRAFT-discussion-reply-crash-flicker.md 2026-07-30 08:00 /mnt/orange/CLAUDE PI/TESTCARD-v1.4-emmc-and-flicker.md 2026-06-25 12:28 /mnt/orange/CLAUDE PI/vop2-aclk-800-test.md --- under: /home/rich-defrese/rockchip-notes --- 2026-06-26 16:36 /home/rich-defrese/rockchip-notes/vop2-noflicker-patch.md 2026-06-25 13:36 /home/rich-defrese/rockchip-notes/vop2-aclk-800-test-RESULTS.md === also grep for the note SLUGS Pi Claude cited (in case they live in a memory/ dir) === /mnt/orange/CLAUDE PI/TEST-RESULTS-emmc-4k-crash-repro.md /mnt/orange/CLAUDE PI/HANDOFF-PC-4k120-flicker-is-zerocopy-h264-decode.md /mnt/orange/CLAUDE PI/HANDOFF-PC-construct-audio-RESULTS.md Pi Claude's canonical memory notes (electron-gpu-compositing-fix, flicker-4k120-vop2-timeout, etc.) aren't on the share — they live in Pi Claude's own memory on the Orange Pi, which I can't reach from here. But there ARE related notes on disk, including a vop2-noflicker-patch.md. Let me read the two most relevant: Read vop2-noflicker-patch.mdRead DRAFT-discussion-reply-crash-flicker.md Go Team Red! This sync just paid for itself — because I found the thing you were worried about: I was about to re-derive work you already finished. Let me answer Ghidra, then lay out what the sync turned up. Ghidra? No — and here's the proof Every flicker head we've actually cracked was solved by DRM plane-state / buffer-metadata diffing on open source, not binary RE: The AFBC one was nailed by matching DRM modifiers (flicker ⇔ AFBC 0x800000000000051, smooth ⇔ LINEAR 0x0) — a plane-state diff. Pi Claude's decode one was isolated by codec/decoder variable (zero-copy vs -copy) — a behavioral diff. The whole stack here is open: rockchip_drm_vop2.c, the woodyst VA-API driver, MPP, Mesa/Panfrost. Ghidra is for a closed binary with no source — libmali or the VPU firmware — and we haven't hit that wall. Reserve it for a real source dead-end; right now it'd be reaching for a scalpel when the patient's already open. The sync — you were 100% right to stop me The AFBC-disable lever I offered to "go scout" this session? Already root-caused on hardware AND patched — back in June. From ~/rockchip-notes/vop2-noflicker-patch.md: Windowed/composited 4K@120 flicker = AFBC-compressed scanout (proven on spare .181, 2026-06-25). VOP2 can't decompress AFBC in the 8.3 ms frame at 120 Hz; at 60 Hz/16.6 ms it fits. Ruled out DDR-bw, GPU, done-bit timeout, POST_BUF, aclk, PHY. Working fix: reject the AFBC modifier in rockchip_vop2_mod_supported() → linear scanout → no flicker. Branch pi-studio-lowlatency-noafbc. That's exactly the fix I was going to "discover." Done deal. The reconciled taxonomy — there are (at least) FOUR flickers #FlickerStatus 1AFBC scanout (4K@120 only)✅ fixed — noafbc patch / pi-studio-lowlatency-noafbc 2Zero-copy H.264 decode (green band)✅ fixed — use -copy decoder (Pi Claude, today) 3Chromium/Electron compositing glitch (Panfrost; ultrawide/resize; F11 clean)workarounds only — [[electron-gpu-compositing-fix]] 4VOP2 frame-done timeout (mode-level)[[flicker-4k120-vop2-timeout]] And here's the catch that reframes this session: you reported the browser flicker at 60 and 120. But the AFBC head is 120-only (60 fits in-frame). So the flicker you and I chased this session (VSCode/Vivaldi/Chromium, 60-too) is almost certainly head #3 — the Chromium/Panfrost compositing glitch — not AFBC. My whole AFBC/RGA framing this session was aimed at the wrong head. The gap Pi Claude's canonical notes for #3 and #4 (electron-gpu-compositing-fix, flicker-4k120-vop2-timeout, video-playback-rk3588) live in Pi Claude's memory on the Orange Pi — not on the share, so I can't read them from here. I reconstructed a lot from the on-disk notes, but to finish the sync cleanly I need those. Let me fold everything I can see into my memory now so we stop re-deriving, and I'll draft a short ask for Pi Claude to export its three canonical flicker notes to the share. Recording the reconciliation: Edit chrome-rk3588-hw-composition-flicker.md Added 8 lines 🔴 Go Team Red! — and appropriately, we didn't even have to break out the offensive tooling. No Ghidra required: the intel was already in-house, we just weren't reading our own files. The best recon is knowing what you already own. Sync is banked in memory — the four-headed flicker taxonomy, which heads are already killed (AFBC → noafbc patch; zero-copy H.264 → -copy decoder), and the correction that this session's browser flicker is head #3 (Chromium/Panfrost), not the AFBC one I was chasing. Future me won't re-derive it. One open item to finish the sync: Pi Claude's three canonical notes (electron-gpu-compositing-fix, flicker-4k120-vop2-timeout, video-playback-rk3588) live on the OPi, out of my reach. Want me to draft a quick handoff asking Pi Claude to export those to the share so I can fold head #3 and #4 in at full detail? That closes the last gap — then both of us are working from one map instead of two. Otherwise: real talk, that was a great catch on your part. "Sync before you scout" just saved us from rebuilding a June patch from scratch. 🔴🎸
-
A difference between FriendlyElec image and Armbian image is U-Boot ( bootloader/firmware ) variant I think. For my NanoPi-R6C, HDMI audio does not work if I boot from SD-card where an image with a U-Boot from 2026 is written in the boot area (between main GPT and 1st partition). If I wipe that U-Boot by zeroing that area, the OS will take EDK2 UEFI v1.1 that I have written to eMMC. Then there is HDMI sound, on Armbian and Opensuse Tumbleweed. I need to check if I run it in hybrid ACPI+DeviceTree mode or just DeviceTree mode. The setting is anyway 'mainline kernel' DT, which should be about 6.10 or later. If I select 'vendor kernel', it can only run Armbian 6.1.115, but I don't remember if KDE6 Wayland does work then. I only did that to check if I idle power consumption was still < 1.5 Watt, which was the case. Else it is 3 Watt and min clock is 1GHz instead of 480MHz and more differences. I remember I saw some U-Boot version scrolling by when I messed up partitions on eMMC (might just be corrupt 2nd backup GPT), I think the UEFI code did fall back to some build-in U-Boot. Now I did check certain things: # gunzip < rk3588-sd-debian-trixie-gnome-wayland-desktop-6.1-arm64-20260629.img.gz | dd count=32k status=none | grep -FUzi "U-Boot SPL 20" U-Boot SPL 2017.09-g50821b3c8bd-241113 #fa (Jan 02 2025 - 16:53:42) # cat nanopi-r6c_UEFI_Release_v1.1.img | dd count=32k status=none | grep -FUzi "U-Boot SPL 20" U-Boot SPL 2017.09-g5f53abfa1e-221223 #zzz (Dec 26 2022 - 09:10:09) So the EDK2 seems to contain some old base U-Boot and also the FriendlyElec image same U-Boot base, however, it can be different and certainly is incompatible with mainline recent year U-Boot and also likely the vendor tagged one from Armbian. FriendlyElec could do various HW initialization in a different way and on top of that or mixed with it, EDK2 again does things. It needs rebuild EDK2 from source or so in order to gain more know-how and check. I also see the kernel version string in the FriendlyElec image is '6.1.141' (Armbian is '6.1.115-vendor-rk35xx' ), what that means I don't know, kernel.org is at 6.1.177 (2026-07-04). I am using 7.1.3+deb14-arm64-16k #1 SMP PREEMPT Debian 7.1.3-1 (2026-07-04) from Debian Sid repo, userspace is Armbian Trixie. So no HW accel, at least not in KDE6 with FireFox. The added RKMPP libs are 1 thing, the DMA devices are another. Names like 'uncached' and 'dma32' are important hints on how and what is implemented, wrapping tactics etc. The whole issue with those FriendlyElec images is, at a Debian minor update for example, those libav* files get overwritten. In addition, kernel sources w.r.t RKMPP are banned from github. So those images from FriendlyElec are a 1-time shot, works as longs as you don't update. I spent a lot of time to build RPI kernels and their ffmpeg/libav variant. It changed several times, now I don't use it anymore in a generic way, mainly because the HW encoder is fairly limited and does also not work anymore with Jellyfin ffmpeg build (for transcoding on-the-fly). Same for OpenSuse, they are strict on MPEG licensing/royalties, so no MPEG2,H264,HEVC etc, you extra need other repo to make it work. To come back to OP topic title, LibreElec (so dedicated Kodi) worked fine HW accel for HEVC, H264, H265, AV1 and partly for VP9. Was about 9 months ago I ran that dedicated from separate SD-card, so LE's own U-Boot and kernel etc, all mainline based. But is only decoders, so playing video on a usually larger HDMI monitor. So the kernel can do it, it is just many different API's and protocols. FireFox focuses on VAAPI AFAIK, so known to work fine on Intel HW, but needs then tweaks to work with v4l2_m2m AFAIK. Maybe look at RPi's FireFox patches, although I think it is proprietary for their Broadcom tailored kernel, so won't work with mainline Linux nor Rockchips stuff on RK3588.
-
With the official friendlyelec image for Nano Pi M6 (trixie, gnome, 6.1 kernel), I'm getting hardware acceleration with the plain vanilla mpv from Debian: mpv --vo=gpu my.mp4 mpp[2968]: mpp_platform: client 18 driver is not ready! ● Video --vid=1 (h264 1080x1920 59.9998 fps) [default] ● Audio --aid=1 (aac 2ch 44100 Hz 128 kbps) [default] arm_release_ver: g24p0-00eac0, rk_so_ver: 10-616430-r0 mpp[2968]: mpp_info: mpp version: 958803d7 author: Herman Chen 2026-02-26 fix[h265d_rkv]: Fix rkv ref and poc setup overflow Using hardware decoding (rkmpp). AO: [pipewire] 44100Hz stereo 2ch floatp VO: [gpu] 1080x1920 drm_prime[nv12] Everything works wonderfully, and CPU usage is about 25%, compared to 500% for Armbian. Why can't rkmpp be enabled on Armbian to give us harware accel out of the box? @Igor: The overlay link you provided above (mesa-vpu) is broken. And no such overlay exists in the prebuilt images for the Nano Pi M6. Result: still no hardware acceleration for my M6 with Armbian.
-
Unnoficial Image: Download Link enabled CMA, increased CMA to 32mb and enabled rknn Board logs: https://paste.armbian.com/hoqejiqeno Build logs: https://paste.armbian.eu/cekehuhule Installing ffmpeg with encoders and decoders, armhf - armv7: ffmpeg-rockchip-armhf.zip On rv1126 armbian device: cd /media/usb/esp32-rv1126-ffmpeg-rockchip ./install-on-target.sh Verify: /opt/ffmpeg-rockchip/bin/ffmpeg -hide_banner -encoders | grep -Ei 'rkmpp|mpp' /opt/ffmpeg-rockchip/bin/ffmpeg -hide_banner -decoders | grep -Ei 'rkmpp|mpp' /opt/ffmpeg-rockchip/bin/ffmpeg -hide_banner -filters | grep -Ei 'rkrga|rga' Please don't trust pre-compiled files. compile yourself: Use this only if you really want hardware H.264 encode for the go2rtc bridge. A normal upstream FFmpeg build with --enable-rkmpp may expose Rockchip decoders but not the encoder set needed here. For encoder support, use an encoder-capable Rockchip FFmpeg fork such as nyanmisaka/ffmpeg-rockchip, which documents h264_rkmpp, hevc_rkmpp, and mjpeg_rkmpp under encoders. Build FFmpeg With RKMpp Encoders: sudo apt update sudo apt install -y \ git build-essential pkg-config cmake meson ninja-build \ yasm nasm libdrm-dev libudev-dev The MPP and RGA sources below are hosted on Gitee. If git clone prompts with Username for 'https://gitee.com':, sign in with a Gitee account. That prompt is expected for these URLs and is not an FFmpeg/RKMpp build error. Build and install Rockchip MPP runtime and headers: mkdir -p ~/src cd ~/src if [ -d rkmpp/.git ]; then git -C rkmpp pull --ff-only elif [ -e rkmpp ]; then echo "rkmpp exists but is not a git checkout; move it aside or choose a new directory" >&2 exit 1 else git clone -b jellyfin-mpp --depth=1 https://gitee.com/nyanmisaka/mpp.git rkmpp fi cd rkmpp cmake -S . -B build \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=/usr/local \ -DBUILD_SHARED_LIBS=ON \ -DBUILD_TEST=OFF cmake --build build -j"$(nproc)" sudo cmake --install build sudo ldconfig Build and install RGA. The FFmpeg fork can use RGA for hardware color conversion/scaling; this is useful because the ESP32 camera enters as raw YUYV and encoders usually want a YUV420/NV12-style input. cd ~/src if [ -d rkrga/.git ]; then git -C rkrga pull --ff-only elif [ -e rkrga ]; then echo "rkrga exists but is not a git checkout; move it aside or choose a new directory" >&2 exit 1 else git clone -b jellyfin-rga --depth=1 https://gitee.com/nyanmisaka/rga.git rkrga fi if [ -d rkrga_build ]; then meson setup --reconfigure rkrga_build else meson setup rkrga rkrga_build \ --prefix=/usr/local \ --libdir=lib \ --buildtype=release \ --default-library=shared \ -Dcpp_args=-fpermissive \ -Dlibdrm=false \ -Dlibrga_demo=false fi meson compile -C rkrga_build sudo meson install -C rkrga_build sudo ldconfig Build FFmpeg to /opt/ffmpeg-rockchip so it does not overwrite the system FFmpeg: set -e cd ~/src if [ -d ffmpeg-rockchip/.git ]; then git -C ffmpeg-rockchip pull --ff-only elif [ -e ffmpeg-rockchip ]; then echo "ffmpeg-rockchip exists but is not a git checkout; move it aside or choose a new directory" >&2 exit 1 else git clone --depth=1 https://github.com/nyanmisaka/ffmpeg-rockchip.git ffmpeg-rockchip fi cd ffmpeg-rockchip make distclean >/dev/null 2>&1 || true # RV1126 is ARMv7-A. Disabling ARMv5TE avoids assembler failures in # libavcodec/arm/mlpdsp_armv5te.S on some armhf toolchains. PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/local/lib/arm-linux-gnueabihf/pkgconfig:/usr/lib/arm-linux-gnueabihf/pkgconfig \ ./configure \ --prefix=/opt/ffmpeg-rockchip \ --enable-gpl \ --enable-version3 \ --enable-libdrm \ --enable-rkmpp \ --enable-rkrga \ --disable-armv5te \ --enable-shared \ --disable-static \ --disable-doc \ --disable-debug make -j"$(nproc)" sudo make install echo /opt/ffmpeg-rockchip/lib | sudo tee /etc/ld.so.conf.d/ffmpeg-rockchip.conf sudo ldconfig This only disables FFmpeg's CPU hand-written assembly. It does not disable the Rockchip MPP encoder or RGA support, and it is acceptable for this camera path because the input is only 320x240 @ 3 fps. Verify that FFmpeg was built with actual encoders: /opt/ffmpeg-rockchip/bin/ffmpeg -hide_banner -encoders | grep -Ei 'rkmpp|mpp' /opt/ffmpeg-rockchip/bin/ffmpeg -hide_banner -decoders | grep -Ei 'rkmpp|mpp' /opt/ffmpeg-rockchip/bin/ffmpeg -hide_banner -filters | grep -Ei 'rkrga|rga' Expected Result: /opt/ffmpeg-rockchip/bin/ffmpeg -hide_banner -encoders | grep -Ei 'rkmpp|mpp' /opt/ffmpeg-rockchip/bin/ffmpeg -hide_banner -decoders | grep -Ei 'rkmpp|mpp' /opt/ffmpeg-rockchip/bin/ffmpeg -hide_banner -filters | grep -Ei 'rkrga|rga' V..... h264_rkmpp Rockchip MPP (Media Process Platform) H264 encoder (codec h264) V..... hevc_rkmpp Rockchip MPP (Media Process Platform) HEVC encoder (codec hevc) V..... mjpeg_rkmpp Rockchip MPP (Media Process Platform) MJPEG encoder (codec mjpeg) V..... av1_rkmpp Rockchip MPP (Media Process Platform) AV1 decoder (codec av1) V..... h263_rkmpp Rockchip MPP (Media Process Platform) H263 decoder (codec h263) V..... h264_rkmpp Rockchip MPP (Media Process Platform) H264 decoder (codec h264) V..... hevc_rkmpp Rockchip MPP (Media Process Platform) HEVC decoder (codec hevc) V..... mjpeg_rkmpp Rockchip MPP (Media Process Platform) MJPEG decoder (codec mjpeg) V..... mpeg1_rkmpp Rockchip MPP (Media Process Platform) MPEG1VIDEO decoder (codec mpeg1video) V..... mpeg2_rkmpp Rockchip MPP (Media Process Platform) MPEG2VIDEO decoder (codec mpeg2video) V..... mpeg4_rkmpp Rockchip MPP (Media Process Platform) MPEG4 decoder (codec mpeg4) V..... vp8_rkmpp Rockchip MPP (Media Process Platform) VP8 decoder (codec vp8) V..... vp9_rkmpp Rockchip MPP (Media Process Platform) VP9 decoder (codec vp9) ... overlay_rkrga VV->V Rockchip RGA (2D Raster Graphic Acceleration) video compositor ... scale_rkrga V->V Rockchip RGA (2D Raster Graphic Acceleration) video resizer and format converter ... vpp_rkrga V->V Rockchip RGA (2D Raster Graphic Acceleration) video post-process (scale/crop/transpose)
-
If you use and Armbian image with kernel '6.1.115-vendor-rk35xx' (note there are many builds over time, all same name, but you need to look in config-6.1.115-vendor-rk35xx and maybe also consider the gcc compiler version to have RKMPP based method working. I mean the API is there, you need a special ffmpeg (from jellyfin for example to use it) in order to use RKMPP based decoding and encoding in HW. That is just CLI, server use-case, works on RK3568 and RK3588. RK3576 should have the same speed/ASIC blocks as RK3588 AFAIK, but check yourself. It can do 5x realtime speed 1080p50 HEVC to H264. mpv 'uses open and agreed standards' and RKMPP is not. Also Android is completely different. Same is Windows or Apple iOS. Those are implemented by commercial/paid developers. In fact it is worse, ffmpeg open-source developers have concluded already long time ago the Rockchip downstream kernel code was copied and violates licenses. (Rockchip copied code and put their names in it.). So since a few months, ffmpeg developers requested github to remove access and that happened. So following GPL licensing, that 6.1.115 kernel is essentially illegal. How you want to deal with that is up to you. It is like it is. Anyway, 6.1.x downstream is getting old and might contain several unpatched security holes. So over time the 'problem' will solve itself as people won't trust it anymore despite being able to use every HW block in RK35xx. As already said, decoding generally is implemented as part on mainline kernel, you just need matching latest userspace. Encoding is much more complex. If you want that, only Intel/AMD is more or less viable option. Like N100, so in cheap miniPCs, certainly considering high RAM prices, is just a way better option. Plays all HW accelerated in FireFox (and mpv as well). Does also VP9 encoding for example, is a royalty free codec, so you won't see this 2 decades old patents issues for H264 and HEVC. Also note AV1 HW decoding was the first to be available in mainline kernel for RK3588. There is just not much content I think. And HW AV1 encoding is another level of new silicon, is not really an option to do in software.
-
As far as my experience is, there is no difference in final result if you do manual 'install' like you did. It runs the usual (user) setup scripts. It is even the same when you start an image as container, done that many times for various platforms. In fact writing SPI-flash is non-automatic, is manual as can be quite invasive. With modern ARM64 SBC like ROCK5B also people might threat it like a PC, with difference that PC comes with a motherboard that has already firmware/bootloader/UEFI/BIOS written by the manufacturer. Although some motherbaords also can use open source, like coreboot I think, but guessing. What to do as further tuning and customization depends on what you want to do with the ROCK5B. There is 1.5 decades between the single core ARMv6 based RaspberryPi1 and the current high-end SBC's that are 100x faster and can be treated like an Intel/AMD PC. I actually have no NVME for x86-64 (is still SATA SSD although also M.2 slot as well), but use my 500GB Samsung 970 EVO+ in the ROCK5B. I use Btrfs and compress-force=zstd for almost all Linux rootfs, so always create an extra swap partition, although a swapfile also works nowadays with special create options. I rather not use the (currently very expensive) RAM for swap when 4-lane PCIE v3 NVME is there. But that is also because my ROCK5B acts as a server, containers and KVM etc and also I use the RAM and NVME for caching a large HDD. So in terms of wear of flash storage, that caching is just way more demanding than what happens on a decade old SD-card only SBC. But NVME/SATA SSD's have perfectly readable stats and many good brands can write more TeraBytes than the specs mention from manufacturer. SD-cards can be very poorly design internally, and have no stats. So you simply don't know when they will break. If the SBC only does some simple things like camera streaming or some sensor's on GPIO pins, it makes sense to keep as much as possible in RAM. So then just keep it like it is. Or even disable journal to non-volatile storage if never any issues and only enable if troubles. One problem I had with zram swap is that on a 256MiB NanoPi-NEO, it failed when media streaming under memory pressure. mp3 or opus or h264 etc don't compress and can still buffer a lot, so the OOM killer started acting. I was not able to change the whole media stuff so stopped zram swap and put swap on normal extra swap partition.
-
I've made some progress in debugging the mpv error... I introduced some additional debug display instructions into the mpv source code, so I could see what was actually happening. And here is the new log: [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] Opening decoder hevc [vd] Looking at hwdec hevc_rkmpp-rkmpp... ctx->hwdec_devs = 0xffff64347e20 [vo/gpu] Loading hwdec drivers for format: 'drm_prime' [vo/gpu] Loading hwdec driver 'drmprime' [vo/gpu/drmprime] Using EGL dmabuf interop via GL_EXT_EGL_image_storage [vo/gpu/drmprime] Using DRM device: /dev/dri/renderD128 [vo/gpu/drmprime] ADDING DRMPRIME DEVICE [vo/gpu/drmprime] hw->devs=0xffff64347e20 [vo/gpu/drmprime] av_device_ref=0xffff64348860 ADD: ctx=0xffff6434af60 hw_imgfmt=1057 type=8 av_device_ref=0xffff64348860 num_hwctxs=1 [vo/gpu/drmprime] DEVICE ADDED [vo/gpu] Loading hwdec driver 'drmprime-overlay' [vo/gpu/drmprime-overlay] Failed to retrieve DRM fd from native display. [vo/gpu] Loading failed. Searching: hw_imgfmt=1057 device_type=12 (rkmpp) num_hwctxs=1 ENTRY 0: ctx=0xffff6434af60 av_device_ref=0xffff64348860 hw_imgfmt=1057 type=8 (drm) hw_ctx = (nil) [vd] Could not create device. [vd] Using software decoding. [vd] Detected 8 logical cores. [vd] Requesting 9 threads for decoding. [vd] Selected decoder: hevc - HEVC (High Efficiency Video Coding) [vd] DR parameter change to 1920x1088 yuv420p align=64 [vd] Allocating new (host-cached) DR image... [vo/gpu] DR path suspected slow/uncached, disabling. [vd] ...failed.. [vd] DR failed - disabling. [vd] Using software decoding. [vd] Decoder format: 1920x1080 yuv420p bt.709/bt.709/bt.1886/limited/auto CL=mpeg2/4/h264 crop=1920x1080+0+0 A=none [vd] Using container aspect ratio. [vo/gpu] reconfig to 1920x1080 yuv420p bt.709/bt.709/bt.1886/limited/display CL=mpeg2/4/h264 crop=1920x1080+0+0 A=none [vo/gpu/wayland] Reconfiguring! [vo/gpu] max content size: 1024x600 [vo/gpu] monitor size: 1024x600 The result says exactly this: VO (drmprime): add a DRM type device Decoder (rkmpp): look for an RKMPP type device => can't find it => hw_ctx = NULL => Could not create device => decoding software More precisely: ADD: hw_imgfmt = 1057 type = DRM and immediately after: Searching: hw_imgfmt = 1057 device_type = RKMPP So the problem is not: The MPP, FFmpeg, mpv does not create hwdec_devs, drmprime driver The problem is that the two components are not talking about the same type of device. Actually, that tells me something else very important: hwdec_drmprime.c from mpv was written for decoders using: Vape, V4L2, other DRM backends It creates AVHWDeviceType = DRM, instead, FFmpeg's hevc_rkmpp is a new decoder, which expects AVHWDeviceType = RKMPP. These two pieces of code were not made for each other. That also explains why the decoder exists... I have hevc_rkmpp, but mpv knows absolutely nothing about RKMPP. mpv only knows: drmprime and drmprime creates a DRM device. My logical conclusion is that the official MPV is not suitable for the rkmpp hardware (it doesn't know about its existence). So what to do ? Where do I get a suitable MPV ?
-
I've just installed Ubuntu KDE vendor image and now the proper refresh rates are detected. Thank you However, now it seems video players are not working properly. No HW decoding and no audio. It works if I play youtube videos through via Chrome though Strange thing is that after the clean installation, lots of basic KDE packages were missing (dolphin, Konsole, mpv, etc), which I had to install via apt. After that I also performed a apt full-upgrade, but it didnt solve the problem Tried to play h264 and 265 with no success I add some logs, but feel free to request more if they may help
-
Hello, I'm trying to play a video on my Orange Pi Zero 2w using MPV. I tried using different Armbian images including Armbian-unofficial_26.05.0-trunk_Orangepizero2w_bookworm_current_6.18.25_minimal.img. This however results in a "Failed to create framebuffer with drmModeAddFB2 on layer 0" for every frame. Can anyone help me to get it working? (+) Video --vid=1 (*) (h264 1920x1080 24.000fps) (+) Audio --aid=1 (*) (aac 6ch 48000Hz) [vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device [vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable. Using hardware decoding (drm). [W][00814.699591] pw.conf | [ conf.c: 939 try_load_conf()] can't load config client.conf: No such file or directory [E][00814.699881] pw.conf | [ conf.c: 963 pw_conf_load_conf_for_context()] can't load default config client.conf: No such file or directory AO: [alsa] 48000Hz stereo 2ch float VO: [gpu] 1920x1080 drm_prime[nv12] [vo/gpu] Using HW-overlay mode. No GL filtering is performed on the video! [vo/gpu/drmprime-overlay] Failed to create framebuffer with drmModeAddFB2 on layer 0: Invalid argument [vo/gpu/drmprime-overlay] Failed to create framebuffer with drmModeAddFB2 on layer 0: Invalid argument AV: 00:00:00 / 00:00:30 (0%) A-V: 0.000 [vo/gpu/drmprime-overlay] Failed to create framebuffer with drmModeAddFB2 on layer 0: Invalid argument
-
-
-
It will only work for h265, as that is the only hardware decoder available in the Pi 5. So it won't help you with for instance YouTube, as they use VP9 and AV1 (or you can force h264 with a browser plugin). You can try Firefox. https://bugzilla.mozilla.org/show_bug.cgi?id=1833354 Or change some of the flags in Chromium, but it feels as if they keep changing, so you might find other suggested flags all over the internet. You can set the mentioned flags in: chrome://flags/ https://bbs.archlinux.org/viewtopic.php?id=244031
-
-
Is HEVC 10-bit supported by the rkvdec2 mainline driver with the V4L2 request driver? I have compiled the ffmpeg and mpv with v4l2 PRs on Ubuntu 24.04 noble with Armbian 26.2.1 edge kernel 6.19. I have H264, HEVC 8-bit and AV1 working. Only HEVC 10-bit and VP9 (which is coming soon) are not working with patched mpv using vo=gpu-next and hwdec=v4l2request-copy.
-
Can you repeat your amrbian OS version, Linux, and hardware? I can't give a confident advice for you, but have you tried: * extraargs=cma=256M in armbianEnv.txt * turn off compositor, if using xfce (others have suggested it, and I found it unnecessary) In mpv, turn on verbosity by adding -v to the command. Then while it is running, close it and copy all the mpv text in a text editor. Search for the words h264, ffmpeg, v4l2, hardware, software
-
With a lot of trial and error I figured out the issue but not the cause. This seems to only effect HEVC (x265) videos when drm is successfully enabled with MPV from this repository. If I try a different player, they play fine but no hardware acceleration. If I encode the videos to x264 they play but hardware acceleration fails with the following error [ffmpeg/video] h264: v4l2_request_probe_video_device: set controls failed. Invalid argument (22) The issue is the width of the video. Outside of certain ranges it will display a black video (audio works). It doesn't seem to matter what the height is set to. Eg) 704x480, 704x960 image is displayed. 706x480, 706x960 black screen The ranges go for 14 pixels and each range is separated by 50 pixels. eg) widths in the range of 690 to 704 display an image. Widths between 706 and 752 display a black screen. 754 to 768 display an image. It's a strange one.... Here is a list of ranges that work. Any widths outside of these ranges produces a black screen. It only goes up to 1984 but I'm sure the same rules would apply above this value.
-
Just a feedback. Device: Orange Pi 5 Plus OS Image: Armbian_26.2.0-trunk.370_Orangepi5-plus_noble_current_6.18.8_gnome_desktop.img.xz media-player: mpv-.37.0-1ubuntu4 Following the gudide on the first page and added "profile=fast" (in order to have smooth 4K/60 playback) in /etc/mpv/mpv.conf. mpv-.37.0-1ubuntu4 playback 8bit 4K/60 h264 and h265 (hevc) video with vpu hardware accceleration. 10bit h265 or any vp9 and av1 video NO vpu hardware acceleration as far as I can tell. 10bit 4k/60 hevc video -- No vpu hw acceleration 4K/60 hevc -- with vpu hw acceleration. Error messages. Full HD av1 -- No vpu hw acceleration Full HD vp9 -- No vpu hw acceleration Edit: Chromium_v144 can play 8bit 4K/60 h264, h265 and av1 videos with vpu hw acceleration. No vpu hw acceleration with vp9 videos. If not mistaken the current kernel-6.18.8-current-rockchip64 or 6.19-rc8-edge-rockchip64 do not support vpu hw acceleration with vp9 codec.
-
There was a successful test with Debian Forky in RK3566 I saw some progress and success in the last 2 days. Someone made compiled ffmpeg 8.0+v4l2request and made it work in Debian Forky... which also carries ffmpeg 8.0 https://github.com/mpv-player/mpv/pull/14690#issuecomment-3500141427 Does this mean that I need to use Debian Forky too? (I was staying with Debian Bookworm because H264 hwaccel only worked there) References: https://code.ffmpeg.org/Kwiboo/FFmpeg/src/branch/v4l2request-v3 https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20847 https://tracker.debian.org/pkg/ffmpeg
-
@jock thanks for the information! The reason I was experimenting with the kernel is because I’m testing OpenAuto (Android Auto) on top of Armbian-minimal. While MPV works fine with hardware decoding, I noticed that using things like kmssink to process the Android feed (720p, 30/60fps) introduces significant latency between touch input and screen response. For example, in today’s test I tried decoding a 720p 60fps H.264 stream using GStreamer with this command: gst-launch-1.0 filesrc location=test.h264 ! \ h264parse ! v4l2h264dec capture-io-mode=dmabuf ! \ queue max-size-buffers=2 leaky=downstream ! kmssink sync=false While the pipeline runs, the latency is too high for Android Auto responsiveness clicks and touch inputs visibly lag behind the video output. This is why I also tried patching Armbian to kernel 6.16-rc1, which gave me the following devices: [ 1.340230] rockchip-rga 20060000.rga: Registered rockchip-rga as /dev/video0 [ 1.345260] hantro-vpu 20020000.video-codec: registered rockchip,rk3399-vpu-enc as /dev/video2 [ 1.345656] hantro-vpu 20020000.video-codec: registered rockchip,rk3399-vpu-dec as /dev/video3 …but unfortunately, HDMI output stopped working completely, so that approach wasn’t usable for my setup. The goal is still to achieve smooth, low-latency video decoding that can keep up with real-time Android Auto interaction, which is why I’m exploring alternatives like the FFmpeg v4l2-request interface, even if it requires patching OpenAuto. PS: i also just like to explore how the rk322x works, so yeah I've been testing a lot for a few days now. Another thing is i plan to make a DIY head unit with this unused rk3229 box i have
-
Hello, I just created this account! I just want to ask if the newer OS / Firmware has VPU + MPP support? I've been trying to build OpenAuto for the RK3229 and the only issue im having is the lack of h264 decoding (i only need h264, but it would be nice to have a full support) I'm using the latest trixie (minimal) with somewhat of a success, except for a laggy video decoding due to again lack of h264. I can't seem to find an older build with a kernel of 4.4.xxx that probably has the full GPU support with VPU + MPP working.
