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

Phase 0 deliverable #3 — Firefox VAAPI engagement, LIVE Plasma session (2026-05-04)

Re-test of phase0_evidence/2026-05-04-firefox/findings.md inside an active Plasma 6 Wayland session on ohm (XDG_SESSION_TYPE=wayland, XDG_RUNTIME_DIR=/run/user/1001, kwin_wayland 144533, plasmashell 144667, Xwayland :0). Same Firefox profile + LIBVA env vars; only the gfx environment changed.

Verdict

Two-layer finding that inverts the prior Phase 0 re-verification verdict.

Layer	Result
Firefox loads libva-v4l2-request driver	✓ dlopen v4l2_request_drv_video.so succeeds; no sandbox/gating issue under real Plasma session
Firefox completes the V4L2-stateless contract lifecycle on hantro	✓ REQUEST_ALLOC → S_FMT → CREATE_BUFS → STREAMON → S_EXT_CTRLS → QBUF + REQUEST_QUEUE → DQBUF + EXPBUF, no EINVAL on the request-API path
Kernel produces decoded pixel output	✗ CAPTURE buffer returns with patch-0011 sentinel 0xab unchanged. Hantro never wrote the buffer.
Consumer reaction to bad output	Firefox detects the failed first frame and silently falls back to software decode in RDD's FFmpeg-OS-library PDM. User-visible playback continues normally; observed t=337s (5+ minutes) of stable bunny playback via SW.

This means the prior Phase 0 re-verification verdict (commit f15ba8b, "the 2026-04-26 picture holds at boolean-correctness level") was wrong — the prior test was a clean contract trace but never inspected the actual decoded pixel content.

What the live-session strace shows

Decode happened on PID 146420 (Firefox utility process for hwaccel), /dev/video1 fd 7, /dev/media0 fd 8.

Single-frame attempt (full ioctl summary, exhaustive — not a sample):

22 VIDIOC_ENUM_FMT       (probe, including expected MPLANE-fallback EINVALs)
 5 VIDIOC_QUERYBUF
 4 VIDIOC_G_FMT
 2 VIDIOC_STREAMON       (OUTPUT_MPLANE + CAPTURE_MPLANE)
 2 VIDIOC_STREAMOFF      (the bail-out after frame 0)
 2 VIDIOC_S_EXT_CTRLS    (1 device-wide DECODE_MODE+START_CODE per patch 0002, 1 per-request)
 2 VIDIOC_REQBUFS
 2 VIDIOC_QBUF           (1 OUTPUT, 1 CAPTURE)
 2 VIDIOC_DQBUF          (1 OUTPUT, 1 CAPTURE)
 2 VIDIOC_CREATE_BUFS
 1 VIDIOC_S_FMT          (OUTPUT_MPLANE H264_SLICE 1920x1088)
 1 VIDIOC_EXPBUF         (DMA-BUF export of CAPTURE buffer)
 1 MEDIA_REQUEST_IOC_QUEUE
 1 MEDIA_REQUEST_IOC_REINIT
 1 MEDIA_IOC_REQUEST_ALLOC

Single QBUF/DQBUF pair, single MEDIA_REQUEST_IOC_QUEUE = exactly one frame attempted. No EINVAL on any request-API ioctl. Two STREAMOFF = clean shutdown of both queues after the failed frame.

After the libva STREAMOFF, no further V4L2 ioctls anywhere in the strace. Bunny continued playing for 5+ minutes via SW decode — confirmed by user inspection (t=337s playback time visible in window title).

What the .so DEBUG instrumentation shows

stderr_live (4 lines, 553 B, the entire output of patches 0010+0011+0014):

v4l2-request: VAPictureH264 sizeof=36 CurrPic[0..31]: 00 00 00 04 00 00 00 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
v4l2-request: VAPictureH264 CurrPic field reads: picture_id=0x04000000 frame_idx=0 flags=0x0 TopFOC=65536 BottomFOC=65536 frame_num=0
v4l2-request: OUTPUT[idx=0, len=6272]: 00 00 01 25 b8 20 20 21 44 c5 00 01 57 9b ef be fb ef be fb ef be fb ef be fb ef be fb ef be fb
v4l2-request: CAPTURE[idx=0, plane0]: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab

• VAPictureH264 dump (patch 0014): TopFOC=65536 and BottomFOC=65536 — these are the ffmpeg-vaapi POC sentinel values that patch 0015 is supposed to strip. The dump shows the values BEFORE patch 0015's strip. The strip happens after the dump in the code path — so the dump captures the raw VAAPI input. After strip, the values handed to V4L2 should be 0/0. (Worth verifying via a second dump after the strip.)
• OUTPUT buffer (patch 0010): 00 00 01 25 b8 20 ... is correct ANNEX_B start code + IDR slice NAL header (0x25 = forbidden_zero=0, nal_ref_idc=01, nal_unit_type=00101 = IDR slice). The ef be fb repeating pattern that initially looked like poison is real H.264 RBSP slice data (CABAC bin sequences are random-looking). 6272 bytes is plausible for a 1080p IDR slice.
• CAPTURE buffer (patch 0011): All 32 bytes of plane 0 still hold 0xab — the sentinel pattern patch 0011 wrote before QBUF. The kernel returned the buffer via DQBUF without writing to it. Hantro did not decode this frame.

Cross-check against the 2026-05-04 mpv vaapi-copy run

Re-examined phase0_evidence/2026-05-04/mpv_vaapi_copy_2026-05-04.stderr (which we previously called "68 frames decoded cleanly"):

$ grep "CAPTURE\[" mpv_vaapi_copy_2026-05-04.stderr | wc -l
68
$ grep "CAPTURE\[" mpv_vaapi_copy_2026-05-04.stderr | grep -c "ab ab ab ab"
68

68 of 68 mpv CAPTURE buffers show the same sentinel-survives pattern. mpv --vo=null consumed all 68 sentinel buffers as if they were valid NV12 frames; with no real VO to render to, the failure was invisible.

OUTPUT bytes for frame 0 are byte-for-byte identical between mpv and Firefox (same IDR slice from same source clip, both via libavcodec). Both consumers feed hantro the same data; hantro silently drops both.

Why the 2026-04-26 STUDY claim survived as long as it did

The claim was "vainfo + mpv probes work end-to-end." This is true at the libva-engagement layer: vainfo enumerates profiles, mpv completes the contract lifecycle, no errors on the request-API path. The check that was missing was pixel-content verification:

• vainfo doesn't decode — it only enumerates capabilities. Always green.
• mpv with --vo=gpu or --vo=vaapi would have shown garbage (all 0xab = mid-gray NV12), but the test rig in the predecessor campaign was probably the same as ours: SSH + --vo=null.
• fourier_attribution cell A (chromium-fourier 149 with Step 1 patches, browser_cpu_median = 54 %) was visually inspected by the operator on a real screen during that campaign. Cell A's bunny WAS visible and playing — but on Brave/Chromium, not on mpv or Firefox. Chromium's V4L2 path may differ (uses its own backend in addition to libva, depending on flags); the cell A success could be a different code path than the one we just traced.
• The patch-0011 sentinel test was apparently authored to detect this exact failure mode but its output wasn't being grepped in the close-out. The patch series was held to be working based on the contract-trace cleanliness — which we now know is necessary but not sufficient.

Implication: Phase 0 substrate result is "kernel decode broken"

The Phase 0 in-session re-verification (campaign repo commit f15ba8b) overstated the case. The corrected verdict:

• libva engagement: ✓ on both mpv and Firefox in their respective rigs
• V4L2-stateless contract trace: ✓ no EINVAL on the request-API path
• Hantro produces decoded pixel output: ✗ on every frame attempted, by either consumer

Phase 1 boolean-correctness criterion as currently locked says "boolean correctness — libva accepted + providing access to hardware decoder." We reached "libva accepted" but not "providing access to hardware decoder" in the meaningful sense. The criterion should be sharpened to require pixel-content verification, e.g.: "the CAPTURE buffer returned from DQBUF must contain decoded pixel data (sentinel-overwritten); a smoke test of NV12 luma min/max range across at least one frame must reject the all-0xab pattern."

Phase 1 lock now needs amendment.

What this means for Phase 6 / Step 1

The deployed Step 1 18-patch series engages the libva path correctly but doesn't make hantro decode. The bug surface is in one of these areas (rough priority order, based on patch-comment hints):

1. reference_ts not propagated. Patch 0017's commit message: "hantro doesn't read pic_num (uses reference_ts)." Implication: hantro depends on reference_ts being populated correctly to find DPB references for inter prediction. For an IDR (frame 0), reference_ts is irrelevant — but if reference_ts is malformed in a way that breaks SPS parsing, hantro might bail before decode.
2. DECODE_PARAMS missing slice_header bit_size fields. Patch 0008's open question was explicitly "does hantro tolerate the bit_size fields being zero, or do we need a slice_header() bit-level parser?" The Step 1 series did NOT add a slice_header parser — those fields are zero. Maybe hantro doesn't tolerate that and silently skips decode.
3. POC sentinel still leaking. Patch 0015's strip happens at the right call sites, but the DEBUG dump (patch 0014) runs before the strip — so the dump shows the raw 65536 values. Verify the values handed to V4L2 are actually stripped by adding a post-strip dump or reading the V4L2_CTRL_TYPE_H264_DECODE_PARAMS via VIDIOC_G_EXT_CTRLS just before QBUF.
4. Level_idc over-allocation interaction. Patch 0013 hardcodes level_idc=51; patch 0018 derives it from Annex A.3 (so for 1080p we'd get level_idc=41). hantro uses level_idc to size DPB/MV buffers. Wrong sizing might allocate too small and drop the decode silently.
5. CAPTURE format derivation. Patch 0009 removed VIDIOC_S_FMT on CAPTURE per "Hantro derives CAPTURE format from per-request SPS." The G_FMT shows NV12 1920×1088, which looks right — but if SPS isn't being submitted, the kernel might decode into a different layout that overwrites neither the sentinel nor the real CAPTURE bytes.
6. Other hantro silent-failure paths: V4L2_EVENT_SOURCE_CHANGE (open Q #5 in phase0_findings.md), per-frame timestamp / VIDIOC_S_PARM, missing frame_num / IDR-bit setup in DECODE_PARAMS flags.

The correct Phase 6 starting point is to instrument the kernel side: ftrace events/v4l2/ and events/hantro/ (if exposed), or dmesg for any silent-decode-error messages, while the userspace contract trace runs. That's the actual Phase 3 baseline we need.

Artifacts

• firefox_live.log.{moz_log,child-1.moz_log} — MOZ_LOG output from the live-session run
• firefox_stderr_live — the .so DEBUG output (only 4 lines because only 1 frame was attempted)
• firefox_stdout_live — empty
• strace_146420 — the decode utility process: full V4L2-stateless lifecycle
• strace_146198, strace_146199, strace_146200, strace_146201, strace_146203 — RDD + content + GPU process traces
• strace_146147 — Firefox parent
• strace_146164 — fork-server / GMP-related child

Phase 0 deliverables status (updated)

• #1 Re-verify failure-mode finding in-session — ✗ AMENDED: contract trace lands cleanly, but kernel produces no decoded pixels. Prior commit f15ba8b overstated the verdict.
• #2 Step 1 reconciliation — ✓ done in commit 74b3793 on fork master.
• #3 Firefox configuration end-to-end — ✓ engagement confirmed in live Plasma session; pixel-content failure mode identical to mpv (libva ✓, hantro ✗).
• #4 Phase 0 baseline anchor — ✗ AMENDED: the captured contract trace describes Step 1's userspace behaviour, not what Phase 6 must reproduce. Phase 6's spec needs to include kernel-side observability (ftrace / dmesg) so we can actually characterize hantro's silent failure.

Phase 1 lock should be deferred until we have a sharpened boolean-correctness criterion (pixel-content verification) and at least a hypothesis about why hantro is silent. Phase 0 isn't done yet.