# Iteration 3 — Phase 3 (baseline anchor: pre-patch Firefox 150 behavior on ohm)

Goal: anchor the pre-patch behavior so Phase 7 has a "before" picture. Two distinct baselines matter for iter3:

- **Baseline-S (sandbox):** stock Firefox 150 with default RDD sandbox → libva fails at `open(/dev/media0)` with ENETDOWN → Firefox SW-falls-back. This is what Track F's patch is supposed to fix.
- **Baseline-A (frame-11 EINVAL):** stock Firefox 150 with `MOZ_DISABLE_RDD_SANDBOX=1` → libva engages hantro, decodes 10 frames, then EINVAL on `set_controls` at frame 11. This is the carryover defect Track A is supposed to fix.

## Anchored baseline source

ohm is currently powered off (probe `ping -c 1 ohm.fritz.box` from rpi at 2026-05-04 ~23:50 returned `100% packet loss`; PineTab2 has no WoL — manual power-on by operator required). So the in-session re-acquire of `/tmp/ff-stdout.log` is not possible right now. The substantive risk this poses to Phase 3 is **low**, because:

1. iter2 close (`phase8_iteration2_close.md`, commit `c36c61e`) recorded the same baseline observations on **2026-05-04**, the same day this Phase 3 anchor is being written. Same kernel (6.19.10), same userspace (Firefox 150.0.1, libva 2.23.0, mesa 26.0.5), same fixture (bbb_1080p30_h264.mp4 sha256 `dcf8a7170fbd...`), same driver build (sha256 `f27e0064...`). No state has drifted.

2. The "before" picture is what we want to PROVE WRONG via the patch. The verifying observation is the "after" picture in Phase 7. Re-acquiring the "before" within hours of an identical observation that's already in git would be ceremonial.

So this Phase 3 doc anchors the iter2-close evidence by reference, with the explicit understanding that Phase 7 will produce the corresponding "after" rig. If at Phase 7 we discover the stock Firefox baseline has shifted (e.g. Firefox 151 has dropped through pacman update by then), we re-acquire then.

## Baseline-S evidence (anchored from iter2 close)

Quoted verbatim from `phase8_iteration2_close.md`:

> Firefox 150 (default sandbox) | ✗ libva init fails inside RDD sandbox on `open(/dev/media0)` returning ENETDOWN — Firefox SW-falls-back. **NOT an iter2 code regression** (iter1 init code is byte-identical), but a Firefox routing change since iter1: iter1's findings.md shows decode happened on the **utility** process (`sandboxingKind=0`), iter2 today shows the libva path goes through RDD which is sandbox-blocked. Workaround: launch Firefox with `MOZ_DISABLE_RDD_SANDBOX=1`.

Signature to match in Phase 7:
- Command: stock `firefox /home/mfritsche/fourier-test/bbb_1080p30_h264.mp4` (no MOZ_DISABLE_RDD_SANDBOX)
- driver stderr: shows `open("/dev/media0", O_RDWR)` returning -1 ENETDOWN
- decode behavior: SW fallback, no hantro engagement

Phase 7 verifies: with `firefox-fourier` patched binary and same launch (no env var), the open succeeds and ≥10 frames decode through hantro.

## Baseline-A evidence (anchored from iter2 close)

> Firefox 150 (sandbox-disabled) | ✓ engages our libva, decodes 10 frames cleanly through hantro (luma gradient `0x10→0x1c` matching BBB intro fade, real NV12 pixels), then EINVAL on `set_controls` at frame 11. The EINVAL is a non-iter2 issue — same Sonnet 7.x family carryover from iter1 (likely 7.5 mid-stream / 7.2 num_ref_idx). cap_pool model is NOT the regression.

> The 10-frame decoded sequence under sandbox-bypass confirms Fix 3's cap_pool architecture works correctly with Firefox: surface IDs 67108864..67108871 each acquired their own slot, and surface IDs were recycled across frames 5,6,9 with the slot state machine cycling through IN_DECODE → DECODED → recycle on next BeginPicture for the same surface. Pool was operating exactly as designed.

Signature to match in Phase 7 (track A):
- Command: `firefox-fourier /home/mfritsche/fourier-test/bbb_1080p30_h264.mp4` with the libva-v4l2-request-fourier driver instrumented to log per-request control values
- driver stderr: `Unable to set control(s): Invalid argument` emerging at the 11th frame
- Where to look: per-request controls submitted from `EndPicture` — DECODE_PARAMS, SLICE_PARAMS, SCALING_MATRIX, SPS, PPS — for the slice immediately after the cap_pool's first recycle event

Phase 7 verifies: with iter3's libva fix applied (Phase 4 also produces this), the EINVAL no longer fires; ≥30s of bbb_1080p30 decode without `Unable to set control(s)`.

## Phase 3 carry-over to Phase 4

Phase 4 (patch + PKGBUILD overlay authorship) does not need Baseline-S or Baseline-A re-acquired live. It needs:

1. The verbatim Mozilla source from Phase 2 (already captured in `phase2_iter3_situation.md`)
2. The cap-set of hantro on ohm to confirm whether `V4L2_CAP_VIDEO_M2M_MPLANE` is set (cheap to check at Phase 7 boot via `v4l2-ctl --device=/dev/video1 --info`)
3. The fixture and driver state (anchored, unchanged since iter2)

Operator action item for Phase 7 prep: when ohm is next powered on, run `v4l2-ctl --device=/dev/video1 --info | grep -E 'Capabilities|Device'` and capture output. If `Video M2M Multiplanar` is in the cap list, the cap-filter extension is unnecessary and the patch shrinks to "just add /dev/media0". If absent, both pieces of the patch are needed.

## Stop point

Phase 3 anchored. Proceeding to Phase 4: write the firefox-fourier patch + the AUR PKGBUILD overlay. Operator-side action item flagged above. ohm offline does NOT block Phase 4 (writing the patch is desk work).