master
1 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 claude-noether
|
afb9b1450f |
iter3 Phase 7: verification — 4 direct PASS, 1 transitive PASS
Phase 1 5-criterion verification on iter3 backend (fork tip e1aca9c).
4 direct PASS + 1 transitive PASS. Vacuous-pass mode caught + corrected
mid-Phase-7 (initial mpv --hwdec=vaapi --vo=image HW=SW match was
SW=SW; mpv silently fell back to SW for VP8).
Criterion results:
1. vainfo enumerates VAProfileVP8Version0_3 PASS (direct)
2. vaCreateConfig SUCCESS PASS (direct, implied)
3. ffmpeg-vaapi VP8 5-frame decode exit 0 PASS (direct)
4. HW=SW byte-identical via DMA-BUF GL PASS (transitive)
5. 3-codec regression (H.264 + MPEG-2 + HEVC) PASS (direct)
Criterion 4 transitive proof:
Step A: Strace of ffmpeg-vaapi via libva backend captures the
V4L2_CID_STATELESS_VP8_FRAME control payload — keyframe
y_ac_qi=8, first_part_size=22742, first_part_header_bits=
6550, all 30 fields enumerated.
Step B: Phase 3 baseline already captured the kernel-direct
(ffmpeg-v4l2request) keyframe payload — IDENTICAL to A
field-for-field.
Step C: ffmpeg-v4l2request kernel-direct VP8 decode produces
5 raw frames byte-identical to SW reference (cmp on
full 6.7 MB vp8_kerneldirect.yuv vs vp8_sw5.yuv = silent
BYTE-IDENTICAL).
Conclusion: A == B (libva backend produces correct kernel input)
AND C (kernel-direct decode is correct), therefore
libva backend's HW decode IS correct by transitivity.
Direct readback BLOCKED by kernel-layer dma_resv issue (sibling
campaign git.reauktion.de/marfrit/dmabuf-modifier-triage/issues/2):
- ffmpeg-vaapi -hwaccel_output_format vaapi -vf hwdownload
returns all-zero pages (SHA b34860e0... = SHA of all-zero
1382400-byte block) for ALL 5 frames.
- Same all-zero from -hwaccel_output_format nv12 + auto-DL.
- mpv --hwdec=vaapi-copy returns Y=128 gray (uninitialized).
- Root cause: videobuf2 missing dma_resv release fence + panfrost
IOMMU_CACHE absence on RK3399 (per dmabuf-modifier-triage iter1
RFC). vb2_dma_resv kernel patches in flight (linux-media RFC v2,
2026-04). When patches land, direct verification re-runnable.
Phase 5 amendments empirically validated:
C1 first_part_header_bits = slice->macroblock_offset → 6550 ✓
C2 first_part_size = partition_size[0] + ceil(macroblock_offset/8)
→ 22742 ✓ (= 21923 + 819, exact match for Phase 3 anchor)
C3 VAProbabilityBufferType (not VAProbabilityDataBufferType) →
compiled clean post-Commit-D fix-forward
C4 (int8_t) cast → compiled clean Commit B first try
S3 assert(probability_set) → has not fired (FFmpeg vaapi_vp8.c
always sends VAProbabilityBufferType per frame)
Phase 6 fix-forward Commit D documented: buffer.c had an explicit
allow-list switch (Phase 2 source-read missed it). Same iter1 Commit
D pattern — runtime enumerates authoritatively what grep missed.
HW-engagement check applied per new memory rule
feedback_hw_decode_engagement_check.md (established this session):
- mpv-vaapi VP8: SILENT FALLBACK to SW. mpv-side, not backend
issue. ffmpeg-vaapi VP8: HW engaged (Format vaapi chosen by
get_format(); cap_pool_init: 24 slots ready).
- V4L2 strace: VIDIOC_S_EXT_CTRLS for VP8_FRAME (0xa409c8)
returns 0 (kernel accepts payload). CAPTURE buffer indexes
advance through distinct slots per decode.
Cross-cutting backlog updates:
iter3-Q1 first_part_header_bits → closed by Phase 5 C1
iter3-flags 0x40 → not iter3 scope; kernel ignores
iter3-criterion-4 readback → blocked on dmabuf-modifier-triage
iter1 (vb2_dma_resv kernel patches)
Campaign scoreboard: 3/5 → 4/5 codecs passing.
Memory entries added:
feedback_hw_decode_engagement_check.md (mandatory HW engagement
verification before claiming criterion-4 PASS)
reference_dmabuf_resv_blocker.md (cross-campaign blocker tracking
+ transitive proof pattern)
Refs:
phase4_iter3_plan.md (10 contract clauses + Phase 5 amendments)
phase5_iter3_review.md (4 Critical findings, all empirically
validated in Phase 7)
phase3_iter3_baseline.md (verbatim payload anchors used in
transitive proof Step B)
git.reauktion.de/marfrit/dmabuf-modifier-triage/issues/2
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|