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>
28 lines
2.5 KiB
Markdown
28 lines
2.5 KiB
Markdown
# 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.
|