fresnel-fourier/phase3_iter1_baseline.md

Iteration 1 — Phase 3 (baseline measurements)

Phase 3 baselines for the iter1 MPEG-2 boolean-correctness work, captured 2026-05-08 00:39 CEST after fresnel reboot. All four baseline runs and the verbatim output anchors are in phase0_evidence/2026-05-07/iter1_phase3/.

Phase 3 discipline (per feedback_dev_process.md): raw data leads, derived numbers are anchored to the visible tool invocation that produced them. Every "this matches Phase 2 prediction" claim cites a verbatim line from the captured trace, not a paraphrase.

Reset context

$ ssh fresnel 'hostname; uname -r; uptime'
fresnel
6.19.9-99-eos-arm
 00:31:35 up 4 min,  2 users,  load average: 1.01, 0.70, 0.34

$ loginctl list-sessions --no-pager | head
SESSION  UID USER      SEAT  LEADER CLASS   TTY  IDLE SINCE
      2 1000 mfritsche seat0 2244   user    tty1 no   -

fresnel rebooted between Phase 2 and Phase 3 (uptime 4 min explains the No route to host Phase 2 noted). SDDM watchpoint condition not triggered: journalctl -u sddm -b | grep -E "(qFatal|crash|Error|fatal|SIGABRT)" returns empty for this boot. Plasma Wayland session active on tty1, mfritsche logged in.

Baseline A — pre-patch failure mode

Goal: capture the exact path that produces vaCreateConfig: 12 (UNSUPPORTED_PROFILE) on master tip 65969da, before any iter1 work touches the code.

Invocation:

strace -ff -tt -y -e trace=ioctl,openat,close \
  -o /tmp/iter1_phase3/baseline_A_ffmpeg/ffmpeg.strace \
  env LIBVA_DRIVER_NAME=v4l2_request \
      LIBVA_V4L2_REQUEST_VIDEO_PATH=/dev/video5 \
      LIBVA_V4L2_REQUEST_MEDIA_PATH=/dev/media2 \
      LIBVA_TRACE=/tmp/iter1_phase3/baseline_A_ffmpeg/libva.trace \
  ffmpeg -hide_banner -loglevel debug -hwaccel vaapi \
    -i ~/fourier-test/bbb_720p10s_mpeg2.ts -frames:v 2 -f null -

Verbatim libva trace (baseline_A_ffmpeg/libva.trace.*):

[5276.234210][ctx none] VA-API vendor string: v4l2-request
[5276.234352][ctx none] vaInitialize ret = VA_STATUS_SUCCESS, success (no error)
[5276.264142][ctx none] vaQueryConfigProfiles ret = VA_STATUS_SUCCESS, success (no error)
[5276.264347][ctx none] va_TraceCreateConfig
[5276.264351][ctx none]   profile = 1, VAProfileMPEG2Main
[5276.264354][ctx none]   entrypoint = 1, VAEntrypointVLD
[5276.264357][ctx none]   num_attribs = 0
[5276.264606][ctx none] vaCreateConfig ret = VA_STATUS_ERROR_UNSUPPORTED_PROFILE, the requested VAProfile is not supported
[5276.425879][ctx none] va_TraceTerminate
[5276.426283][ctx none] vaTerminate ret = VA_STATUS_SUCCESS, success (no error)

Verbatim ffmpeg log (baseline_A_ffmpeg/ffmpeg.stdout):

[VAAPI @ 0xaaaaef94e010] libva: User environment variable requested driver 'v4l2_request'
[VAAPI @ 0xaaaaef94e010] libva: Trying to open /usr/lib/dri/v4l2_request_drv_video.so
[VAAPI @ 0xaaaaef94e010] libva: Found init function __vaDriverInit_1_23
[VAAPI @ 0xaaaaef94e010] Initialised VAAPI connection: version 1.23
[VAAPI @ 0xaaaaef94e010] VAAPI driver: v4l2-request.
[mpeg2video @ 0xaaaaef99ee10] Format vaapi chosen by get_format().
[mpeg2video @ 0xaaaaef99ee10] Format vaapi requires hwaccel mpeg2_vaapi initialisation.
[mpeg2video @ 0xaaaaef99ee10] Failed to create decode configuration: 12 (the requested VAProfile is not supported).
[mpeg2video @ 0xaaaaef99ee10] Failed setup for format vaapi: hwaccel initialisation returned error.
[mpeg2video @ 0xaaaaef99ee10] Format vaapi not usable, retrying get_format() without it.

Verbatim ioctl summary:

     10 ioctl(6</dev/video5>, VIDIOC_ENUM_FMT
      4 ioctl(4</dev/dri/renderD128>, DRM_IOCTL_VERSION
      1 ioctl(6</dev/video5>, VIDIOC_QUERYCAP

12 ftrace v4l2 lines (the ENUM_FMT probe events). Zero VIDIOC_S_FMT, zero REQBUFS, zero S_EXT_CTRLS, zero MEDIA_IOC_REQUEST_ALLOC. Decode never starts.

Confirms Phase 2 Bug 1 directly: vaCreateConfig returns VA_STATUS_ERROR_UNSUPPORTED_PROFILE for VAProfileMPEG2Main — the missing break; at src/config.c:65-66 makes execution fall through to default: (line 67-68) which returns the error code we observe (12).

mpv-as-driver does not reach this path: a separate baseline run with mpv --hwdec=vaapi-copy instead of ffmpeg -hwaccel vaapi showed mpv silently fall back to SW decode without ever loading libva for MPEG-2 (no [vaapi] log lines, zero V4L2 ioctls, zero libva trace files). mpv's hwdec policy filters MPEG-2 out of vaapi-copy candidates before libva is touched. Phase 1 success criterion #3 (mpv MPEG-2 engages backend) requires either an mpv config override or a different invocation path — to be addressed in Phase 4 plan. ffmpeg-direct invocations exercise the full path.

Baseline B — post Bug 1 patch failure mode

Goal: with the missing break; added as a Phase 3 scratch test, see what fails downstream. Predicted by Phase 2: VIDIOC_S_EXT_CTRLS returns EINVAL because the staging-era CID V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS (= 0x9909fa) doesn't exist on this kernel.

Patch applied (scratch only, on throwaway branch iter1-phase3-scratch, reverted at end of Phase 3):

@@ -63,6 +63,8 @@ VAStatus RequestCreateConfig(VADriverContextP context, VAProfile profile,
 		break;
 	case VAProfileMPEG2Simple:
 	case VAProfileMPEG2Main:
+		// Phase 3 scratch — would break here in real fix
+		break;
 	case VAProfileHEVCMain:
 	default:
 		return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;

Rebuilt + installed (ninja -C build && sudo ninja -C build install).

Verbatim libva trace showing config-create now succeeds:

[5329.689037][ctx none] vaQueryConfigProfiles ret = VA_STATUS_SUCCESS
[5329.689228][ctx none] va_TraceCreateConfig
[5329.689233][ctx none]   profile = 1, VAProfileMPEG2Main
[5329.689237][ctx none]   entrypoint = 1, VAEntrypointVLD
[5329.689239][ctx none]   num_attribs = 0
[5329.689471][ctx none] vaCreateConfig ret = VA_STATUS_SUCCESS, success (no error)
[5329.689703][ctx none] vaQuerySurfaceAttributes ret = VA_STATUS_SUCCESS
... (9 more vaQuerySurfaceAttributes calls; surface format negotiation works)

Verbatim failing ioctl (extracted from baseline_B_postbug1/ffmpeg.strace.*, 6 occurrences across 5 frames):

ioctl(6</dev/video5>, VIDIOC_S_EXT_CTRLS,
    {ctrl_class=0xf010000 /* V4L2_CTRL_CLASS_??? */,
     count=1,
     controls=[
       {id=V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS,
        size=56,
        string="h\1\17\0\0\0\0\0H\307Z\226\254i\255\30..."}
     ]}
    => {controls=[...], error_idx=1}
    ) = -1 EINVAL (Invalid argument)

• CID V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS = V4L2_CID_MPEG_BASE+250 = 0x9909fa — the fork's include/mpeg2-ctrls.h:13 symbol. The kernel doesn't recognize this CID (mainline removed it; replaced by the split V4L2_CID_STATELESS_MPEG2_{SEQUENCE,PICTURE,QUANTISATION} at 0xa409dc/dd/de).
• size=56 matches sizeof(struct v4l2_ctrl_mpeg2_slice_params) from the fork's local header (combined sequence + picture + slice fields).
• error_idx=1 = first (and only) control in the array failed validation.
• 6 calls visible across the 5-frame attempt — one per frame, plus one buffer-pool bring-up artefact.

Confirms Phase 2 Bug 2 directly: the kernel rejects the staging-era CID. The fork's UAPI is stale; rewriting mpeg2.c against the new split API is non-optional.

Auxiliary EINVAL — H.264 device-init runs unconditionally on hantro:

ioctl(6</dev/video5>, VIDIOC_S_EXT_CTRLS,
    {ctrl_class=0,
     count=2,
     controls=[
       {id=0xa40900 /* V4L2_CID_STATELESS_H264_DECODE_MODE */, size=0, value=1, value64=1},
       {id=0xa40901 /* V4L2_CID_STATELESS_H264_START_CODE */,  size=0, value=1, value64=1}
     ]}
    => {error_idx=2}
    ) = -1 EINVAL (Invalid argument)

Source: src/context.c:142-155 unconditionally sets the H.264 device-wide controls (V4L2_CID_STATELESS_H264_DECODE_MODE = FRAME_BASED, V4L2_CID_STATELESS_H264_START_CODE = ANNEX_B) on every CreateContext, regardless of profile. This is intentional per the existing comment at src/context.c:138-141:

Errors here are not fatal: not every backing driver supports both controls (e.g. cedrus may default to SLICE_BASED without exposing DECODE_MODE).

The error is silently swallowed via (void)v4l2_set_controls(...) (line 153 — explicit cast discards the return). For MPEG-2 on hantro-vpu-dec the call's a no-op; the EINVAL is noise in the trace, not a bug. Out of scope for iter1; documented as auxiliary finding.

Verbatim ioctl summary (post-Bug-1 path engages full V4L2 lifecycle):

     40 ioctl(6</dev/video5>, VIDIOC_QUERYBUF
     22 ioctl(6</dev/video5>, VIDIOC_ENUM_FMT
     16 ioctl(7</dev/media2>, MEDIA_IOC_REQUEST_ALLOC
     10 ioctl(6</dev/video5>, VIDIOC_QBUF
     10 ioctl(6</dev/video5>, VIDIOC_G_FMT
     10 ioctl(6</dev/video5>, VIDIOC_DQBUF
      6 ioctl(6</dev/video5>, VIDIOC_S_EXT_CTRLS    <-- 6 fail with EINVAL
      4 ioctl(4</dev/dri/renderD128>, DRM_IOCTL_VERSION
      2 ioctl(6</dev/video5>, VIDIOC_STREAMON
      2 ioctl(6</dev/video5>, VIDIOC_STREAMOFF
      2 ioctl(6</dev/video5>, VIDIOC_REQBUFS
      2 ioctl(6</dev/video5>, VIDIOC_CREATE_BUFS
      1 ioctl(9<anon_inode:request>, MEDIA_REQUEST_IOC_REINIT
      1 ioctl(9<anon_inode:request>, MEDIA_REQUEST_IOC_QUEUE
      1 ioctl(6</dev/video5>, VIDIOC_S_FMT
      1 ioctl(6</dev/video5>, VIDIOC_QUERYCAP

The buffer-pool bring-up + per-frame plumbing (CREATE_BUFS, QUERYBUF, REQBUFS, STREAMON, REQUEST_ALLOC, QBUF, DQBUF, REQUEST_IOC_QUEUE) all succeeds. Only the codec-specific control submission is broken. This bounds the iter1 fix scope sharply.

Baseline C — cross-validator verbatim contract anchor

Goal: extract the exact byte-level VIDIOC_S_EXT_CTRLS payload that the working independent V4L2 client (ffmpeg's -hwaccel v4l2request) submits per MPEG-2 frame. This is the contract Phase 4 implementation must match.

Invocation (verbose strace decoding compound v4l2_ext_control payloads):

strace -ff -tt -y -v -e trace=ioctl \
  -o /tmp/iter1_phase3/baseline_C_xvalidator/ffmpeg.strace \
  ffmpeg -hide_banner -loglevel error -hwaccel v4l2request \
    -i ~/fourier-test/bbb_720p10s_mpeg2.ts -frames:v 2 -f null -

Verbatim per-frame submission (5 frames captured, frame 1 shown verbatim):

ioctl(5</dev/video5>, VIDIOC_S_EXT_CTRLS,
  {ctrl_class=0xf010000 /* V4L2_CTRL_CLASS_CODEC_STATELESS */,
   count=3,
   controls=[
     {id=0xa409dc /* V4L2_CID_STATELESS_MPEG2_SEQUENCE */,
      size=12,
      string="\0\5\320\2\0\30\25\0\0\0\1\1"},
     {id=0xa409dd /* V4L2_CID_STATELESS_MPEG2_PICTURE */,
      size=32,
      string="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\202\0\0\0\17\17\17\17\1\3\0\0\0\0\0\0"},
     {id=0xa409de /* V4L2_CID_STATELESS_MPEG2_QUANTISATION */,
      size=256,
      string="\10\20\20\23\20\23\26\26\26\26\26\26\32\30\32\33\33\33\32\32\32\32\33\33\33\35\35\35\"\"\"\35..."}
  ]}) = 0

Field-by-field decode (frame 1, BBB +30s seek into MPEG-2 fixture):

SEQUENCE (12 bytes, struct v4l2_ctrl_mpeg2_sequence per linux/v4l2-controls.h:2009):

Bytes (LE)	Value	Field
\0\5	0x0500 = 1280	horizontal_size
\320\2	0x02d0 = 720	vertical_size
\0\30\25\0	0x00151800	vbv_buffer_size
\0\0	0x0000	profile_and_level_indication
\1	1	chroma_format (4:2:0)
\1	V4L2_MPEG2_SEQ_FLAG_PROGRESSIVE (0x01)	flags

PICTURE (32 bytes, struct v4l2_ctrl_mpeg2_picture per linux/v4l2-controls.h:2056):

Bytes (LE)	Value	Field
\0\0\0\0\0\0\0\0	0	backward_ref_ts (I-frame, no ref)
\0\0\0\0\0\0\0\0	0	forward_ref_ts (I-frame, no ref)
\202\0\0\0	0x82 = FRAME_PRED_DCT(0x02) | PROGRESSIVE(0x80)	flags
\17\17\17\17	f_code = {{15,15},{15,15}} (default for I)	f_code[2][2]
\1	1	picture_coding_type (I)
\3	3	picture_structure (FRAME)
\0	0	intra_dc_precision (8-bit)
\0\0\0\0\0	0	reserved[5]

Frame 2 (P-picture per the MPEG-2 GOP) shows different values, verbatim from the next strace line:

PICTURE: "\0\0\0\0\0\0\0\0p\27\0\0\0\0\0\0\202\0\0\0\1\1\17\17\2\3\0\0\0\0\0\0"

Bytes (LE)	Value	Field
\0\0\0\0\0\0\0\0	0	backward_ref_ts (P, no backward)
p\27\0\0\0\0\0\0	0x1770 ns = 6000 (matches the I-frame's timestamp)	forward_ref_ts (refers to frame 1)
\202\0\0\0	0x82	flags (same FRAME_PRED_DCT | PROGRESSIVE)
\1\1\17\17	f_code = {{1,1},{15,15}} (real motion vectors for P)	f_code
\2	2	picture_coding_type (P)
\3	3	picture_structure (FRAME)
\0	0	intra_dc_precision
\0\0\0\0\0	0	reserved[5]

QUANTISATION (256 bytes = 4 × 64 bytes):

intra_quantiser_matrix[64] = [8, 16, 16, 19, 16, 19, 22, 22, 22, 22, 22, 22, 26, 24, 26, 27, 27, 27, 26, 26, 26, 26, 27, 27, 27, 29, 29, 29, 34, 34, 34, 29, ...]

This is the canonical MPEG-2 default intra matrix in zigzag scanning order — 8 is at zigzag-position 0 (DC coefficient), 16,16 at positions 1-2 (first AC pair). Confirms the kernel-doc claim that matrices arrive in zigzag scanning order (linux/v4l2-controls.h:2076-2084).

The remaining 192 bytes (non-intra, chroma_intra, chroma_non_intra) all start with \20\20... = 16,16,... — MPEG-2 default non-intra is a flat 16 matrix; chroma matrices duplicate luma when chroma_format=4:2:0.

This is the iter1 contract anchor: every Phase 4 implementation diff and Phase 7 verification must produce a VIDIOC_S_EXT_CTRLS call that's structurally indistinguishable from this — count=3, ctrl_class=V4L2_CTRL_CLASS_CODEC_STATELESS=0xf010000, the three CIDs in this order, with sizes 12 / 32 / 256 and the per-frame field values matching what VAAPI's VAPictureParameterBufferMPEG2 and VAIQMatrixBufferMPEG2 carry for the same fixture.

Baseline D — H.264 regression check (Phase 1 success criterion #5)

Goal: prove Bug 1 fix in isolation doesn't break H.264. Re-runs T4's reference incantation against bbb_1080p30_h264.mp4 with the scratch backend installed; expects byte-identical SHA-256 hashes against T4's reference values (f623d5f7… for frame 1, 7d7bc6f2… for frame 2 at +30s seek).

Verbatim hash output:

f623d5f7a41697f67dd227275c6f1b21ffc257f65626d32fde8229357f8764c9  /tmp/iter1_phase3/baseline_D_h264_regr/png_seek_hw/00000001.jpg
7d7bc6f2146dda8b2d223bba622c4b9fbe9674181ff1e02afe286b620342e0a8  /tmp/iter1_phase3/baseline_D_h264_regr/png_seek_hw/00000002.jpg
f623d5f7a41697f67dd227275c6f1b21ffc257f65626d32fde8229357f8764c9  /tmp/iter1_phase3/baseline_D_h264_regr/png_seek_sw/00000001.jpg
7d7bc6f2146dda8b2d223bba622c4b9fbe9674181ff1e02afe286b620342e0a8  /tmp/iter1_phase3/baseline_D_h264_regr/png_seek_sw/00000002.jpg

Pass: HW frame 1 == SW frame 1 == T4 reference; HW frame 2 == SW frame 2 == T4 reference. Bug 1 fix in isolation does not regress H.264.

Scratch state cleanup

After Baseline D, the scratch patch was reverted to keep master clean for Phase 4 work:

$ git checkout -- src/config.c
$ ninja -C build && sudo ninja -C build install
$ git branch -D iter1-phase3-scratch       # branch was empty — patch was uncommitted

Sanity check (master backend reinstalled, MPEG-2 should fail again):

$ ffmpeg -hwaccel vaapi -i bbb_720p10s_mpeg2.ts -frames:v 2 -f null -
[mpeg2video] Failed to create decode configuration: 12 (the requested VAProfile is not supported).
[mpeg2video] Failed setup for format vaapi: hwaccel initialisation returned error.

Back to Baseline A state — scratch state successfully cleaned.

What Phase 3 confirms / refutes from Phase 2

Phase 2 claim	Phase 3 evidence	Status
Bug 1: RequestCreateConfig rejects MPEG-2 via fall-through to default: returning VA_STATUS_ERROR_UNSUPPORTED_PROFILE	Baseline A libva trace shows vaCreateConfig ret = VA_STATUS_ERROR_UNSUPPORTED_PROFILE for profile=VAProfileMPEG2Main	✅ confirmed
Bug 1 fix is sufficient to advance past vaCreateConfig	Baseline B libva trace shows vaCreateConfig ret = VA_STATUS_SUCCESS post-patch	✅ confirmed
Bug 2: mpeg2.c uses staging-era CID V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS (0x9909fa) which mainline kernel removed	Baseline B strace shows VIDIOC_S_EXT_CTRLS id=V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS size=56 = -1 EINVAL	✅ confirmed
Bug 2: kernel exposes the new split API (0xa409dc/dd/de)	Baseline C strace shows ffmpeg-v4l2request submits these three CIDs successfully	✅ confirmed
Cross-validator submits 1 batched VIDIOC_S_EXT_CTRLS, count=3 per frame	Baseline C verbatim payload shows exactly that	✅ confirmed
Quantisation matrices arrive in zigzag order	Baseline C QUANTISATION first 4 bytes [8, 16, 16, 19] matches MPEG-2 default intra matrix in zigzag	✅ confirmed
H.264 device-init in context.c is best-effort and silently swallows EINVAL on hantro	Baseline B strace shows the 0xa40900/0xa40901 EINVAL (silently); src/context.c:153 has (void)v4l2_set_controls(...) cast	✅ confirmed (auxiliary, not iter1 scope)
Phase 1 criterion #5 (H.264 regression check) holds with scratch Bug 1 fix in isolation	Baseline D hashes match T4 reference exactly	✅ confirmed
mpv-as-driver engages the libva backend for MPEG-2	Baseline A's mpv variant: zero V4L2 ioctls, zero libva trace, silent SW fallback	❌ refuted — mpv silently bypasses vaapi for MPEG-2; Phase 1 criterion #3 needs adjustment

Phase 1 criterion #3 needs adjustment (Phase 3 → Phase 1 loopback)

Per feedback_dev_process.md's Phase 3 → Phase 1 loopback edge:

If baseline reveals the Phase 1 metric was tracking the wrong thing → loop back to Phase 1 with the corrected target.

The Phase 1 lock specified:

3. End-to-end decode engages the backend. mpv --hwdec=vaapi-copy --frames=2 --vo=null --no-audio … logs the [vaapi] libva: Trying to open … chain, the Using hardware decoding (vaapi-copy) confirmation, and exits 0 with no Failed to create decode configuration lines.

Phase 3 baseline shows mpv-vaapi-copy never engages libva for MPEG-2 in the current configuration — neither pre-patch nor post-Bug-1-patch produces [vaapi] log lines or VA-API ioctls when invoked via mpv on the MPEG-2 fixture. The mpv hwdec policy (or ffmpeg-mpv glue layer) filters MPEG-2 out before libva is touched. So the Phase 1 criterion #3 wording can never be satisfied via the original incantation, regardless of whether iter1 fixes the libva backend.

Adjusted Phase 1 criterion #3 (proposed; locks alongside Phase 4 plan):

3. End-to-end decode engages the backend. ffmpeg -hwaccel vaapi -i bbb_720p10s_mpeg2.ts -frames:v 2 -f null - 2>&1 (with the v4l2_request env vars set) shows the [VAAPI] libva: Trying to open /usr/lib/dri/v4l2_request_drv_video.so chain, vaCreateConfig ret = VA_STATUS_SUCCESS, no Failed to create decode configuration lines, no EINVAL from VIDIOC_S_EXT_CTRLS, and exits 0 cleanly.

The mpv invocation moves from criterion to optional follow-up (potentially needs an --vd override or a fix to mpv's hwdec-codecs filter; a separate, smaller iteration after iter1 lands).

The other four Phase 1 criteria (vainfo enumeration regression, vaCreateConfig success, DMA-BUF GL pixel verify HW=SW, T4 H.264 regression) hold as locked — no adjustment needed.

Phase 4 plan inputs

Phase 4 plan should specify:

1. Diff scope (per Phase 2 phase2_iter1_situation.md):

   • src/config.c:55-69 — add break; for VAProfileMPEG2Simple/Main cases (3 lines).
   • src/mpeg2.c — full rewrite against the new split API.
   • include/mpeg2-ctrls.h — delete or empty (drop the staging-era header that masks the kernel's modern definitions).
   • src/picture.c — no changes (verified wired correctly in Phase 2).
   • src/context.c — no changes (the H.264 device-init EINVAL is auxiliary, by-design swallowed).

2. Contract anchor (per Phase 6 contract-before-code per feedback_dev_process.md):

   • Cite verbatim from linux/v4l2-controls.h:1985-2105 — the three control struct definitions and flag constants.
   • Cite verbatim from FFmpeg libavcodec/v4l2_request_mpeg2.c:130-155 — the batched submission shape (3 controls, ctrl_class=V4L2_CTRL_CLASS_CODEC_STATELESS).
   • Cite verbatim from kernel drivers/media/platform/verisilicon/hantro_mpeg2.c::hantro_mpeg2_dec_copy_qtable — the kernel-side zigzag-to-raster permutation (so the libva backend doesn't double-permute).
   • Cite Baseline C verbatim payload from this document (SEQUENCE 12 bytes, PICTURE 32 bytes, QUANTISATION 256 bytes per frame).

3. Field mapping table (per Phase 2 phase2_iter1_situation.md Bug 2 detail):

   • 6 structural changes from old to new API documented.
   • Source-data extraction in current src/mpeg2.c is sound; only destination-control-struct shape and CIDs change.

4. Phase 7 verification harness:

   • Re-run all 5 Phase 1 boolean checks (with criterion #3 adjusted as above).
   • Compare the post-fix VIDIOC_S_EXT_CTRLS payload byte-by-byte against Baseline C's verbatim payload — exact match expected for SEQUENCE field values; PICTURE will differ on forward_ref_ts/backward_ref_ts (different timestamp source) and f_code (real values not defaults); QUANTISATION should match exactly for the same fixture.

5. Mpv-criterion-3 follow-up (deferred):

   • File a follow-up task to investigate why mpv-vaapi-copy filters MPEG-2 out and how to override. Out of iter1 scope.

Phase 3 → Phase 4 close

Phase 3 baselines all four green. Phase 2 Bug 1 + Bug 2 + Bug 3 confirmed empirically. Phase 1 criterion #3 needs a minor wording adjustment (mpv → ffmpeg-direct anchor) — proposed text above; locks with Phase 4 plan if approved. Phase 4 can proceed with the contract-anchored diff scope.