This page replaces the original Phase 1 lock at phase1_2026-04-30. The original locked an mpv-specific quantitative target (“drops from 1039/1440 → within transient-startup floor of gst→waylandsink”) on a single test invocation. By the time Phase 3 revised landed, the campaign had been reframed twice (Markus 2026-04-30: “drops post warmup, not drops total”; Markus 2026-04-30 evening: “I do not seek to optimize mpv. I seek to identify the structural gap”). This refinement folds those corrections plus the empirical evidence from Phase 3 revised into a single load-bearing Phase 1.

The original Phase 1 page stands as audit trail; Phase 3 revised + this Phase 1 revised are the live driver going forward.

Buffer-to-display achieves zero-copy for libavcodec / libva consumers on Mali-G52 + KWin Wayland, such that in-scope workloads run with the same memory-subsystem pressure profile as the GStreamer + linux-dmabuf-v1 reference path.

“Same memory-subsystem pressure profile” is what makes the goal measurable below. The reference path is named in §3.

• YouTube / HTML5 <video> in Brave — the highest-traffic video-decode workload on this device class.
• Web browsing in Brave — compositor-side video + animation surfaces; same Chromium GPU-process pipeline as YouTube.
• VS Code (Electron + Chromium under the hood) — same pipeline as Brave for any embedded video / animation rendering.

Workloads outside this list are not the campaign's subject. This is deliberate scope-tightening — see §6.

gst-launch-1.0 -q filesrc location=bbb_1080p30_h264.mp4 \! qtdemux \! h264parse \! v4l2slh264dec \! waylandsink sync=true on ohm (scenario S1 in Phase 3 revised). Empirical numbers, 60 s steady-state, current stack:

This is the empirical operating point a successful campaign aims to reach for libavcodec / libva consumers on the in-scope workloads.

Measurements taken on the in-scope workload (e.g. Brave + bbb-class H.264 video over a 60 s steady-state window, with strace + perf-stat instrumentation per phase3_revised_2026-05-01 §3).

1. C1 — Drops. Post-warmup drops ≤ 10 over 60 s. Warmup = first 10 s. Drops in warmup may be up to ~10; drops after warmup must be 0. Sanity cap on total drops across the full 60 s = 10.
2. C2 — Memory-subsystem pressure. LLC-load-misses ≤ 3 × baseline over 10 s steady-state (i.e. ≤ ~9 M). cache-misses ≤ ~6 M as a leading indicator.
3. C3 — Display-path activity. DRM_IOCTL_* per second ≤ 100. Current libavcodec-using contenders sit at 800-1 050 per sec; target is the baseline rate (0) plus tolerance.
4. C4 — Boundary fd-passing. At least one of:
   • (a) VIDIOC_EXPBUF count > 0 from V4L2 hantro AND the resulting fd flowing to the compositor via SCM_RIGHTS over the Wayland socket, OR
   • (b) PRIME_FD_TO_HANDLE count > 0 from a V4L2-produced dmabuf flowing into the GPU process / browser compositor.

C1 is the user-visible criterion (“the video plays smoothly”). C2 and C3 are the physical-layer criteria for “no CPU memcpy of frame data, no per-frame Mesa GL+DRM round-trips”. C4 is the structural criterion (“the path actually exists, not just is fast”).

• C1 ✓ + C2 ✗ + C3 ✓ → not possible without something else creating cache pressure; flag for re-investigation.
• C1 ✓ + C2 ✓ + C3 ✗ → Level-1 zero-copy fixed, Level-2 still missing (decoder produces dmabuf but display path goes through Mesa GL). Re-enter Phase 4 fix-surface choice.
• C1 ✗ at Phase 7 verification → re-enter Phase 4 with new perf evidence per Phase 4 §6 loopback condition.
• C4 ✗ but C1 ✓ + C2 ✓ + C3 ✓ → the path is not what we expected (e.g. compositor copies despite client passing fd; or a hidden zero-copy mechanism exists we haven't characterised) — treat as a measurement-classification problem, surface to Phase 5 review.

• A specific patch site. That's Phase 4's job; this Phase 1 only sets the success criteria the patch must meet.
• An absolute CPU% target. cycles/cache-misses are the binding physical-layer metrics; CPU% is a leading indicator that varies with kernel scheduling decisions and is not directly comparable across single- vs multi-process pipelines (Brave's CPU% is spread across renderer + GPU process; mpv's is one process).
• Out-of-scope workload performance. 3D games, Proton/DXVK, general-purpose Vulkan applications may regress arbitrarily — for example, a panvk-1.2-fakeshim (Phase 4 §6 row C2) would crash Vulkan workloads other than the in-scope video presentation path. That is the explicit trade.
• The S5 regression (gst-launch waylandsink ~0.3 drops/sec on today's stack) — separate iteration. Stack drift between fourier 2026-04-24 (0/62) and ohm_gl_fix 2026-04-30 (~16/60). Likely candidates within marfrit-packages' custom mesa / ffmpeg / alsa / libdrm-pinebookpro builds (per Markus 2026-04-30). A separate ohm-gl-fix-companion campaign would bisect via pacman.log.
• Per-application HW-decode engagement. Different consumers may take different fix surfaces (e.g. browser via libva-v4l2-request multiplanar — fix surface A; mpv via libavcodec drm_prime → linux-dmabuf-v1 — fix surface B). Phase 1 does not pre-select which.

The CSV schema captures these criteria as machine-readable rows. As of 2026-05-01:

• metrics.csv — extended with llc_load_misses, drm_ioctl_per_sec, boundary_fd_passed columns and refined phase1r_* rows.
• phase3/io_cache_2026-05-01/boundary_counts.csv — per-scenario EXPBUF/DQBUF/PRIME_*/SCM_RIGHTS/anon-mmap counts.
• phase3/io_cache_2026-05-01/perfstat.csv — per-scenario cache-misses, LLC-load-misses, cycles, instructions, IPC.

C1 / C2 / C3 / C4 are computable from these CSVs at any future measurement point.

• Phase 3 revised — empirical bucket-attribution + boundary characterisation across six contenders.
• Phase 4 — the gap, fix-surface options, ranked. This Phase 1 refines the success criteria against which Phase 4's chosen fix surface will be measured.
• Phase 2 — substrate (versions, V4L2 9-fd buffer pool, panfrost capability surface).
• Original Phase 1 — superseded by this page; preserved for audit trail.
• Namespace landing.

Phase 1 (revised) ends here. Phase 4 fix-surface choice + Phase 6 implementation will deliver against C1-C4. Phase 7 verification re-runs the strace + perf-stat instrumentation from Phase 3 revised on the in-scope workload and writes the resulting numbers to metrics.csv as phase7_verify_* rows.