From bc1e2813289e3ae4cce7c32eb694a4a0e3db5344 Mon Sep 17 00:00:00 2001 From: Markus Fritsche Date: Sat, 25 Apr 2026 22:17:38 +0000 Subject: [PATCH] ohm mpv HW result: --hwdec=v4l2request engages, gpu-next still drops MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit mpv on ohm (with the marfrit ffmpeg-v4l2-request-git installed) auto- exposes h264-v4l2request as an hwdec choice and loads the drmprime VO helper when --hwdec=v4l2request is set. Decode IS hardware. But the VO side is still gpu-next + KWin, so we hit the same compositor bottleneck the SW mpv test exposed: 122% CPU, 930/1440 dropped frames (~64% drop rate, ~8.5 fps delivered). --vo=dmabuf-wayland would be the canonical fix (gst's waylandsink path gives 6-7% CPU through the same compositor), but mpv's hwdec → dmabuf- wayland negotiation fails today: "hardware format not supported", with mpv treating the decode output as yuv420p and trying to upload it to drm_prime. Disentangling that is its own dive; not pursuing now. Recommended ohm playback recipe stays: - Graphical: gst-launch-1.0 ... ! v4l2slh264dec ! waylandsink (6% CPU) - Headless / scripted: ffmpeg -hwaccel v4l2request -hwaccel_output_format drm_prime (14% CPU) Co-Authored-By: Claude Opus 4.7 (1M context) --- README.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/README.md b/README.md index 032b200..cb969f3 100644 --- a/README.md +++ b/README.md @@ -192,6 +192,7 @@ against. | HW: `ffmpeg -re -hwaccel v4l2request -f null -` | 67 % | 1440 / 59.9 s | 24.0 (paced) | n/a | | HW: `ffmpeg -hwaccel v4l2request -hwaccel_output_format drm_prime -f null -` | 51 % | 1440 / 15.4 s | **93.5** | n/a | | HW: `ffmpeg -re + drm_prime -f null -` | **14 %** | 1440 / 59.9 s | 24.0 (paced) | n/a | +| HW: `mpv --hwdec=v4l2request --vo=gpu-next`, DSI-1 | 122 % | 1440 source / 60 s| ~8.5 delivered| **930** | Reading: - SW decode alone has ~3.2× headroom over source rate (77.6 / 24 fps) but @@ -218,6 +219,19 @@ Reading: for 1080p60 with headroom. GStreamer's `v4l2codecs → waylandsink` path still wins on CPU (6–7 %) because its dmabuf-direct scanout avoids every copy; ffmpeg's `null` muxer costs a few percent even with drm_prime. +- **mpv with `--hwdec=v4l2request` does engage the HW decoder** (mpv + loads the `drmprime` hwdec driver, mpv's `--hwdec=help` lists + `h264-v4l2request` after the marfrit ffmpeg install), but with + `--vo=gpu-next` we hit the same compositor bottleneck as SW mpv: 122 % + CPU + 930 / 1440 dropped frames. The decode is essentially free; KWin / + gpu-next's GL composition path still drops most frames waiting on the + compositor. `--vo=dmabuf-wayland` would be the right VO for zero-copy + to KWin, but mpv's hwdec → dmabuf-wayland format negotiation fails + ("hardware format not supported", `yuv420p → drm_prime` upload fails). + Until that's untangled, the **recommended ohm playback recipe is + GStreamer `v4l2slh264dec → waylandsink`** for graphical use, and + `ffmpeg -hwaccel v4l2request -hwaccel_output_format drm_prime` for any + scripted / headless work. ### Browser HW decode (Brave / Chromium) — partially wired, library-blocked