# 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](https://git.reauktion.de/marfrit/dmabuf-modifier-triage/issues/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:

1. With the fix applied, running the `--vo=dmabuf-wayland` reproduction command at frame 10 produces a screenshot that **structurally matches** `frame10_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.
2. The `WAYLAND_DEBUG=1` capture of the same run shows the `.add()` calls in either of the two valid forms documented in [marfrit/dmabuf-modifier-triage#1](https://git.reauktion.de/marfrit/dmabuf-modifier-triage/issues/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)
3. The fix doesn't regress the `--vo=gpu` working path or `--vo=wlshm` working path on the same fixture.