ohm mpv HW result: --hwdec=v4l2request engages, gpu-next still drops

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) <noreply@anthropic.com>

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