libva-multiplanar/phase0_evidence/2026-05-04/findings.md

Phase 0 in-session re-verification — 2026-05-04

In-session re-execution of the failure-mode finding from Phase 0 substrate (phase0_findings.md items #1, #4 — re-verify 2026-04-26 picture, capture contract trace). Acquired today on ohm; this is the campaign's anchor data, not predecessor reference.

Verdict (boolean-correctness, the Phase 1 success criterion)

The 2026-04-26 picture holds. vainfo + mpv --hwdec=vaapi-copy engage the libva-v4l2-request backend end-to-end on ohm today; full V4L2-stateless contract trace lands on hantro at /dev/video1 + /dev/media0; 68 H.264 frames decoded successfully from bbb_1080p30_h264.mp4 with no EINVAL/EAGAIN/EBUSY anywhere on the request-API path.

No rig drift requiring Phase 2 loopback. Substrate intact for Phase 1 lock.

Inventory finding (substrate has shifted under us, but in our favor)

The installed /usr/lib/dri/v4l2_request_drv_video.so on ohm is not a build of libva-v4l2-request-fourier/master — it's the libva-v4l2-request-ohm-gl-fix 1.0.0.r0.ga3c2476-2 package, built on boltzmann 2026-05-02 from ~/src/marfrit-packages/arch/libva-v4l2-request-ohm-gl-fix/PKGBUILD (laptop). The PKGBUILD applies fourier-local.patch + Step 1 patches 0001..0018 on top of bootlin tarball a3c2476. Source tree intact on boltzmann at ~/build/libva-v4l2-request-ohm-gl-fix/. sha256 of extracted .so = 97a726ffcfc5a58d2e103139a7d1cfaa1a2d13a721535fc63e2e0e7d6b780c17 matches installed file exactly.

Implication: the git fork at ~/src/libva-multiplanar/libva-v4l2-request-fourier/master (e8c3937) is a pre-Step-1 substrate. It has the multi-planar wedge + HEVC strip + UAPI shim + STREAMON-defer WIP, but lacks all of 0002..0018 (request_pool, conditional PRED_WEIGHTS, frame-based slice-ctrl gating, ANNEX_B start codes, fill DECODE_PARAMS from VAAPI, no CAPTURE S_FMT, SCALING_MATRIX matrix_set predicate, level_idc derivation, ffmpeg-vaapi POC sentinel strip, P/B-frame flags, DPB pic_num correctness). Rebuilding from the fork as-is would be a regression. Phase 0 deliverable #2 (Step 1 reconciliation) is upstream of any "build from fork and install" step.

What was actually run

Command	Outcome
vainfo --display drm --device /dev/dri/renderD128 w/ LIBVA_DRIVER_NAME=v4l2_request	OK — 7 profiles enumerated (MPEG2 Simple/Main, H264 Main/High/ConstrainedBaseline/MultiviewHigh/StereoHigh)
mpv --hwdec=vaapi --vo=null --frames=60	Could not create device. → SW fallback. Rig issue, not libva — --vo=null doesn't provide a DRM context to vaapi proper. mpv main process opens libva.so for symbol resolution but never reaches the v4l2_request backend.
mpv --hwdec=vaapi-copy --vo=null --frames=60	OK — Initialized VAAPI: version 1.23, Using hardware decoding (vaapi-copy). 68 frames decoded cleanly.

Rig caveat captured: any Phase 3+ test consumer harness over SSH must use --hwdec=vaapi-copy (headless-safe) or run inside a real Plasma/X session. The 2026-04-26 STUDY claim presumably used the latter.

V4L2-stateless contract trace (captured spec for Phase 6)

Aggregate across 4 mpv worker threads during the 60-frame --hwdec=vaapi-copy run:

    136 VIDIOC_QBUF              (68 OUTPUT_MPLANE + 68 CAPTURE_MPLANE)
    136 VIDIOC_DQBUF             (68 OUTPUT_MPLANE + 68 CAPTURE_MPLANE)
     78 VIDIOC_G_FMT
     69 VIDIOC_S_EXT_CTRLS       (1 device-wide pre-STREAMON + 68 per-request)
     68 MEDIA_REQUEST_IOC_REINIT
     68 MEDIA_REQUEST_IOC_QUEUE
     22 VIDIOC_ENUM_FMT          (with single→MPLANE fallback EINVALs — fork's probe pattern)
     11 VIDIOC_QUERYBUF
      8 VIDIOC_CREATE_BUFS
      7 MEDIA_IOC_REQUEST_ALLOC  (request_pool fd allocation, patch 0004)
      2 VIDIOC_STREAMON          (OUTPUT + CAPTURE)
      2 VIDIOC_STREAMOFF
      2 VIDIOC_REQBUFS
      1 VIDIOC_S_FMT             (OUTPUT_MPLANE H264_SLICE 1920x1088)
      1 VIDIOC_QUERYCAP

Per-frame lifecycle (worker 138524 excerpt, 17 of the 68 total requests):

1. setup: S_FMT OUTPUT_MPLANE H264_SLICE 1920×1088 → G_FMT CAPTURE_MPLANE returns NV12 1920×1088 (driver-derived) → CREATE_BUFS for OUTPUT (4) + CAPTURE (1+) → QUERYBUF × N → S_EXT_CTRLS device-wide (DECODE_MODE=FRAME_BASED + START_CODE_ANNEX_B per patch 0002) → STREAMON both queues → MEDIA_IOC_REQUEST_ALLOC × pool size
2. per-frame: MEDIA_REQUEST_IOC_REINIT (recycle fd) → S_EXT_CTRLS (per-request: SPS, PPS, DECODE_PARAMS, conditionally SCALING_MATRIX) → QBUF OUTPUT_MPLANE w/ request_fd → MEDIA_REQUEST_IOC_QUEUE (fire) → QBUF CAPTURE_MPLANE → DQBUF CAPTURE_MPLANE (frame ready) → DQBUF OUTPUT_MPLANE (slice consumed)

NV12 CAPTURE format is reported with num_planes=1 in MPLANE container — semi-planar (Y + interleaved UV) packed in one allocation, 3 655 712 B (1920×1088 ×1.5 + driver padding). That's correct V4L2 semantics; NV12M would be 2-plane and we don't see that.

No errors on the request-API path. The only EINVALs are the expected single-plane ENUM_FMT probes that drive the MPLANE fallback (fork patch 2f54a8d / Step1 fourier-local.patch) and one index=N+1 end-of-enum sentinel.

Full extracted trace: contract_trace_worker138524.txt (140 lines, 4 workers' worth of trace files preserved at mpv_vaapi_copy_2026-05-04.strace.*).

Predecessor claims, retested

Claim (source)	2026-05-04 result
"vainfo enumerates seven H.264 profiles cleanly" (phase0_findings.md § ohm_gl_fix close-out)	HOLDS. 7 profiles enumerated via --display drm --device /dev/dri/renderD128.
"vainfo + mpv probes work end-to-end" (STUDY.md, 2026-04-26)	HOLDS with rig caveat: vaapi-copy works headless; vaapi proper requires a DRM-providing VO.
"Brave-side wall is chromeos pipeline upstream of libva" (STUDY.md, 2026-04-26)	NOT RETESTED today. Brave deferred per phase0_findings § Test consumers; the test consumers that should be retested next are Firefox VAAPI and chromium-fourier 149 (regression).
"/dev/video1 + /dev/media0 = hantro decoder" (carry-over)	CONFIRMED via media-ctl -p /dev/media0 topology dump: rk3568-vpu-dec source/proc/sink, M2M_MPLANE caps. /dev/video2 + /dev/media1 = encoder; /dev/video0 = rga (2D blit).
"build artifact is a ~265 KB .so" (STUDY.md)	STALE. Current .so is 67 KB stripped release. Either STUDY's number predates meson --buildtype=release or counted a different artifact. Doesn't affect correctness.
"STREAMON ordering on hantro is the load-bearing pending fix" (STUDY.md item #4)	SOLVED in Step 1: patches 0002 (pre-STREAMON device controls) + 0004 (request_pool) implement the proper sequence. Trace confirms: device-wide S_EXT_CTRLS → STREAMON both queues → per-request S_EXT_CTRLS + QBUF + REQUEST_QUEUE. The fork's 44a7327 WIP: defer STREAMON in CreateContext is an incomplete approach to the same wedge.

Rig state captured (for Phase 1 anchor)

• Host: ohm (PineTab2, RK3568, 4× Cortex-A55, Mali-G52 MP2)
• Kernel: 6.19.10-danctnix1-1-pinetab2 #1 SMP PREEMPT_DYNAMIC Sat, 28 Mar 2026 02:45:08 +0000 aarch64
• Userspace: Arch Linux ARM rolling, mesa 1:26.0.5-1, libva 2.23.0-1, libva-utils 2.22.0-1, mpv 1:0.41.0-3 (built against ffmpeg 8.0.1, runtime ffmpeg 8.1), strace 6.19-1
• Governor: performance
• Hantro decoder: /dev/video1 (V4L2_CAP_VIDEO_M2M_MPLANE), media controller /dev/media0, bus platform:fdea0000.video-codec
• Test clip: /home/mfritsche/fourier-test/bbb_1080p30_h264.mp4, 1920×1080 H.264 24 fps, sha256 dcf8a7170fbd49bbd6d6137753ea3b1679abaa2d29dca057fa385598674ce61a (matches phase0_findings.md SHA-16 prefix)

Phase 0 deliverables status

• #1: Re-verify 2026-04-26 failure-mode finding in-session. Done. Picture holds.
• #2: Reconcile Step 1 (0001..0018) against fork master. Not started. Recommended next step now that the inventory gap is documented. Three options remain (fold-in / supersede WIP / branch-and-keep), and the data here makes fold-in look correct: Step 1 is a strict superset of fork master in capability terms.
• #3: Verify Firefox configuration end-to-end. Not started. Independent of #2.
• #4: Phase 0 baseline anchor (in-session N≥1 contract trace). Captured for mpv vaapi-copy on bbb. Original spec said chromium-fourier 149; mpv trace is a clean reproducible substitute (same backend, same per-frame lifecycle). A chromium trace is still worth capturing for cross-validation but is no longer blocking.

Artifacts in this directory

• vainfo_v4l2_request_2026-05-04.{strace,stdout,stderr} — vainfo run with strace
• mpv_vaapi_2026-05-04.{strace.*,stdout,stderr} — mpv --hwdec=vaapi --vo=null (failed: rig issue)
• mpv_vaapi_copy_2026-05-04.{strace.*,stdout,stderr} — mpv --hwdec=vaapi-copy --vo=null (success: 68 frames)
• contract_trace_worker138524.txt — extracted 140-line per-frame V4L2 lifecycle from one worker thread

Recommended next steps

1. Capture chromium-fourier 149 contract trace for cross-validation against mpv's. Same backend should produce the same per-frame V4L2 sequence; if it doesn't, that's the finding.
2. Tackle Step 1 reconciliation (Phase 0 deliverable #2). With both marfrit-packages/arch/libva-v4l2-request-ohm-gl-fix/PKGBUILD patches and the fork's git history available, the rebase/fold-in is mechanical; the open question is just the strategy (linear fold-in onto bootlin tip, vs reset fork master to PKGBUILD's effective state, vs preserve fork's WIP commits as a branch).
3. Verify Firefox configuration (Phase 0 deliverable #3). Independent path; can run in parallel with #2.
4. Lock Phase 1. Boolean-correctness criterion confirmed feasible for the test consumers we plan to use. The metric "every consumer in the test corpus completes the V4L2 request-API ioctl sequence to first DQBUF" is now grounded in observed behaviour — it was a hypothesis going into Phase 0 and the data backs it.