marfrit
4bbf255ea6
Operator decision 2026-05-08: the iter1 fix is shipped only when frame 10 of the bbb fixture under --vo=dmabuf-wayland matches the expected reference (captured via --vo=gpu on same hardware/session). - screenshots/frame10_dmabuf_green.png — current broken state - screenshots/frame10_expected.png — target post-fix state - screenshots/README.md — verification protocol (SSIM > 0.95 + valid WAYLAND_DEBUG .add() semantics + no regression on vo=gpu / vo=wlshm) - phase0_findings.md — references the criterion in the conclusion section This locks the campaign's deliverable. Patches that change wire-protocol .add() shape but don't restore the picture do not satisfy iter1. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.5 KiB
Screenshots — iter1 acceptance criterion anchor
These two screenshots are the locked acceptance criterion for the iter1 fix per operator decision 2026-05-08. The fix in mpv vo_dmabuf_wayland.c (or wherever the plane-semantics mismatch turns out to live) is considered shipped only when frame 10 of the bbb fixture under --vo=dmabuf-wayland matches the expected reference.
Before fix (current broken state) — frame10_dmabuf_green.png
mpv --hwdec=v4l2request --vo=dmabuf-wayland --pause --start=00:00:00.42 --fullscreen fourier-test/bbb_1080p30_h264.mp4 on ohm, frame ~10 of bbb_1080p30_h264.mp4 (24 fps), captured via spectacle -b -f -n 2026-05-08.
Uniform dark green fill ≈ RGB(0, 75, 0). Matches the predicted output of an all-zero NV12 buffer (Y=0, U=0, V=0) through BT.601/709 → RGB conversion. Confirms the marfrit/dmabuf-modifier-triage#1 diagnosis: KWin reads UV plane past-EOF on its fd 42, gets zeros, renders dark green.
Black bars top/bottom are letterboxing (PineTab2 1280×800 display vs 1920×1080/16:9 source) — not part of the bug.
After fix (expected target) — frame10_expected.png
Same command but --vo=gpu (the working VO that bypasses the wl_dmabuf protocol path). Same frame, same fixture, same display.
Bbb's intro fades in from black, so frame 10 of the source is genuinely dark — the dim grass/silhouette on the right edge is real content. (For a more visually distinct anchor, frame 100+ would show the butterfly scene; frame 10 stays per operator spec.)
Verification protocol
The iter1 fix has shipped when:
- With the fix applied, running the
--vo=dmabuf-waylandreproduction command at frame 10 produces a screenshot that structurally matchesframe10_expected.png. Pixel-level identity is not required (compositor scaling / ditherering may differ); structural similarity (SSIM > 0.95 for the central frame area, ignoring letterbox bars) is the threshold. - The
WAYLAND_DEBUG=1capture of the same run shows the.add()calls in either of the two valid forms documented in marfrit/dmabuf-modifier-triage#1:- same fd repeated for both planes with non-zero offset for plane 1 (single-allocation form), or
- different fds for each plane with offset=0 for both (per-plane form)
- The fix doesn't regress the
--vo=gpuworking path or--vo=wlshmworking path on the same fixture.