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