fresnel-fourier/phase3_iter2_baseline.md

Iteration 2 — Phase 3 (baseline measurements)

Phase 3 baselines for iter2 HEVC, executed 2026-05-08 across two stages: (i) substrate-update verification after a rolling pacman -Syu userland upgrade, (ii) HEVC cross-validator re-anchor + Bug 1 pre-fix scratch test. All four baselines green; iter1 + T4 references hold byte-identical post-upgrade; HEVC contract anchor captured for Phase 4 transcription.

Per feedback_dev_process.md Phase 3 anti-fabrication: raw output leads, derived numbers anchor to visible tool invocations.

Substrate state at Phase 3 start

$ ssh fresnel 'uname -r; pacman -Q linux-eos-arm linux-eos-arm-headers libdrm qt6-base mesa chromium libva mpv ffmpeg-v4l2-request-git'
6.19.9-99-eos-arm
linux-eos-arm 6.19.9-99
linux-eos-arm-headers 7.0.3-1
libdrm 2.4.133-1
qt6-base 1:6.11.0-2
mesa 1:26.0.3-1
chromium 148.0.7778.96-1
libva 2.23.0-1
libva-utils 2.22.0-1
mpv 1:0.41.0-3
ffmpeg-v4l2-request-git 2:8.1.r123329.b57fbbe-2

The "scheduled for linux-7" upgrade landed as headers-only: linux-eos-arm-headers jumped from 6.19.9-99 → 7.0.3-1, but the kernel binary package linux-eos-arm stayed at 6.19.9-99 (the EOS-ARM repo hasn't published the matching kernel package yet). Running kernel unchanged. 71 packages upgraded total (qt6-base epoch bump, libdrm minor, chromium 147→148, KDE 26.04.1 batch, mkinitcpio 41-3, etc.).

OC DTB at /boot/dtbs/rockchip/rk3399-pinebook-pro.dtb was preserved (pre-upgrade snapshot at *.oc-backup-2026-05-08; sha256 b436ed029... unchanged after upgrade — pacman didn't touch it because linux-eos-arm itself wasn't in the upgrade queue).

eos-reboot-recommended package marker installed; mfritsche's Plasma session active throughout (tty1, no SDDM regression on this kernel boot). Reboot deferred — substrate verifies pre-reboot.

Device numbering this boot:

• rkvdec = /dev/video1 + /dev/media0 (HEVC + H.264)
• hantro-vpu-dec = /dev/video3 + /dev/media1 (MPEG-2)

Baseline A — substrate verified intact post-upgrade

Goal: re-run iter1 Phase 7 criterion 4 + 5 reference verifications post pacman -Syu. T4 H.264 + iter1 MPEG-2 reference hashes must match exactly. If divergent, substrate regression — investigate before iter2 proceeds.

Verbatim hash output:

H.264 +30s seek (rkvdec /dev/video1 + /dev/media0):
  /tmp/iter2_phase3_substrate/h264_hw/00000001.jpg
    f623d5f7a41697f67dd227275c6f1b21ffc257f65626d32fde8229357f8764c9
  /tmp/iter2_phase3_substrate/h264_hw/00000002.jpg
    7d7bc6f2146dda8b2d223bba622c4b9fbe9674181ff1e02afe286b620342e0a8
  /tmp/iter2_phase3_substrate/h264_sw/00000001.jpg
    f623d5f7a41697f67dd227275c6f1b21ffc257f65626d32fde8229357f8764c9
  /tmp/iter2_phase3_substrate/h264_sw/00000002.jpg
    7d7bc6f2146dda8b2d223bba622c4b9fbe9674181ff1e02afe286b620342e0a8

MPEG-2 +02s seek (hantro /dev/video3 + /dev/media1):
  /tmp/iter2_phase3_substrate/mpeg2_hw/00000001.jpg
    6e7873030dbf0403c67f35dd106ebef3c7909a0fd12433b82ad758e7fee9f092
  /tmp/iter2_phase3_substrate/mpeg2_hw/00000002.jpg
    ccc7ce08810d4a96e9ba7a19f4f95bbf6cc861bda9337604b5c668ad52bef7de
  /tmp/iter2_phase3_substrate/mpeg2_sw/00000001.jpg
    6e7873030dbf0403c67f35dd106ebef3c7909a0fd12433b82ad758e7fee9f092
  /tmp/iter2_phase3_substrate/mpeg2_sw/00000002.jpg
    ccc7ce08810d4a96e9ba7a19f4f95bbf6cc861bda9337604b5c668ad52bef7de

All 8 hashes match references exactly. T4 H.264 + iter1 MPEG-2 substrate intact post-upgrade. Userland upgrade did not regress kernel-side decode or DMA-BUF GL readback.

(Aside: mesa version reads 1:26.0.3-1 while the iter1 SDDM watchpoint history showed 26.0.3 → 26.0.5 upgrade on 2026-04-28. Either the 26.0.5 was rolled back from the repo without explicit pacman log entry, or the 04-28 entry recorded a bumped revision that resolved to the same 26.0.3 binary. Not iter2-relevant — references match exactly regardless.)

Baseline B — HEVC cross-validator verbatim contract anchor

Goal: extract the byte-level VIDIOC_S_EXT_CTRLS payload that ffmpeg-v4l2request submits per HEVC frame. This is the contract Phase 4 implementation must match.

Invocation:

strace -ff -tt -y -v -s 8192 -e trace=ioctl \
  -o /tmp/iter2_phase3/ffmpeg_v4l2req.strace \
  ffmpeg -hide_banner -loglevel error -hwaccel v4l2request \
    -i ~/fourier-test/bbb_720p10s_hevc.mp4 -frames:v 5 -f null -

ffmpeg exit 0; 5 frames decoded clean.

Per-frame submission shape (verbatim, frame 1):

ioctl(/dev/video1, VIDIOC_S_EXT_CTRLS,
  {ctrl_class=0xf010000 /* V4L2_CTRL_CLASS_CODEC_STATELESS */,
   count=5,
   controls=[
     {id=0xa40a90 /* V4L2_CID_STATELESS_HEVC_SPS */,            size=40,  ...},
     {id=0xa40a91 /* V4L2_CID_STATELESS_HEVC_PPS */,            size=64,  ...},
     {id=0xa40a92 /* V4L2_CID_STATELESS_HEVC_SLICE_PARAMS */,   size=N,   ...},
     {id=0xa40a93 /* V4L2_CID_STATELESS_HEVC_SCALING_MATRIX */, size=M,   ...},
     {id=0xa40a94 /* V4L2_CID_STATELESS_HEVC_DECODE_PARAMS */,  size=328, ...}
   ]}) = 0

Five controls per frame. Full 5-control batched submission ≠ Phase 2 prediction of "up to 6 with conditional ENTRY_POINT_OFFSETS / EXT_SPS_*"; the BBB fixture doesn't trigger the conditional ones.

SCALING_MATRIX is sent unconditionally for the BBB HEVC fixture — this updates Phase 2's "conditional on SPS scaling_list_enabled" assumption. FFmpeg gates SCALING_MATRIX on ctx->has_scaling_matrix derived from kernel VIDIOC_QUERY_EXT_CTRL at init (rather than on any per-frame VAAPI bit). For the libva backend, the equivalent is to query whether the kernel exposes the SCALING_MATRIX control via VIDIOC_QUERY_EXT_CTRL once at init and submit it conditionally on that probe. Phase 4 plan adjusts.

Init device-wide submissions (not in the per-frame batch, set once at decoder init):

• id=0xa40a95 (V4L2_CID_STATELESS_HEVC_DECODE_MODE) — 2 calls visible (one set, one query/confirm).
• id=0xa40a96 (V4L2_CID_STATELESS_HEVC_START_CODE) — 2 calls visible.

Verbatim SPS payload (40 bytes, frame 1; same across all frames since SPS is per-stream):

"\0\0\0\5\320\2\0\0\4\4\2\4\1\1\0\3\0\0\377\377\375\0\0\0\1\0\0\0\0\0\0\0\200\1\0\0\0\0\0\0"

Field-by-field decode (per <linux/v4l2-controls.h>:2096-2125, struct v4l2_ctrl_hevc_sps):

Bytes (LE)	Value	Field
\0	0	video_parameter_set_id
\0	0	seq_parameter_set_id
\0\5	0x0500 = 1280	pic_width_in_luma_samples
\320\2	0x02d0 = 720	pic_height_in_luma_samples
\0	0	bit_depth_luma_minus8 (8-bit)
\0	0	bit_depth_chroma_minus8
\4	4	log2_max_pic_order_cnt_lsb_minus4
\4	4	sps_max_dec_pic_buffering_minus1
\2	2	sps_max_num_reorder_pics
\4	4	sps_max_latency_increase_plus1
\1	1	log2_min_luma_coding_block_size_minus3
\1	1	log2_diff_max_min_luma_coding_block_size
\0	0	log2_min_luma_transform_block_size_minus2
\3	3	log2_diff_max_min_luma_transform_block_size
\0	0	max_transform_hierarchy_depth_inter
\0	0	max_transform_hierarchy_depth_intra
\377	0xFF	pcm_sample_bit_depth_luma_minus1 (PCM disabled, so default)
\377	0xFF	pcm_sample_bit_depth_chroma_minus1
\375	0xFD	log2_min_pcm_luma_coding_block_size_minus3
\0\0\0	0,0,0	log2_diff_max_min_pcm_luma_coding_block_size, num_short_term_ref_pic_sets, num_long_term_ref_pics_sps
\1	1	chroma_format_idc (4:2:0)
\0	0	sps_max_sub_layers_minus1
\0\0\0\0\0\0	0	reserved[6]
\200\1\0\0\0\0\0\0	0x180 = SAMPLE_ADAPTIVE_OFFSET (0x08) | STRONG_INTRA_SMOOTHING_ENABLED (0x100)	flags (u64)

So BBB-720p10s_hevc.mp4 has SAO + strong intra smoothing flagged, no PCM, no scaling-list-enabled in SPS-side flags. The unconditional SCALING_MATRIX submission therefore must be triggered by PPS-side flag or by FFmpeg's runtime probe — not bitstream-driven for SPS.

Verbatim PPS payload (64 bytes — v4l2_ctrl_hevc_pps, will field-decode in Phase 4 transcription).

Verbatim DECODE_PARAMS payload (328 bytes — v4l2_ctrl_hevc_decode_params, contains DPB array + POC info, will field-decode in Phase 4).

Verbatim SLICE_PARAMS payload (variable size N — dynamic-array of v4l2_ctrl_hevc_slice_params; likely 1 slice per frame for x265 ultrafast; size = sizeof(v4l2_ctrl_hevc_slice_params) * num_slices).

Verbatim SCALING_MATRIX payload (variable size M — v4l2_ctrl_hevc_scaling_matrix if scaling_list_data is present; will field-decode in Phase 4).

Raw strace files (gitignored): phase0_evidence/2026-05-08/iter2_phase3/ffmpeg_v4l2req.strace.*. Re-run incantation in this document.

ioctl frequency summary (verbatim):

60 ioctl(/dev/video1, VIDIOC_DQBUF
30 ioctl(/dev/video1, VIDIOC_QBUF
17 ioctl(/dev/video1, VIDIOC_S_EXT_CTRLS
17 ioctl(/dev/video1, VIDIOC_CREATE_BUFS
15 ioctl(/dev/video1, VIDIOC_QUERYBUF
11 ioctl(/dev/video1, VIDIOC_EXPBUF
 5 ioctl(/dev/video1, VIDIOC_QUERY_EXT_CTRL  (HEVC slice_params dynamic-array introspection)
 4 ioctl(/dev/media0, MEDIA_IOC_REQUEST_ALLOC  (request_fd pool of 4)
 4 MEDIA_REQUEST_IOC_REINIT × 3 fds + MEDIA_REQUEST_IOC_QUEUE × 3 fds

17 S_EXT_CTRLS = 2 init device-wide (DECODE_MODE + START_CODE) + 15 per-frame (probably 5 frames × 3 calls each? Or 1 batched per frame × 5 + 10 something else; actual layout is observed-counted, not split-aware — re-extract per-frame breakdown if Phase 6 needs it). Frequency summary is sufficient as an anchor.

Baseline C — slice-count probe (deferred)

Quick ffprobe examination of bbb_720p10s_hevc.mp4 confirms 1 video stream, hevc Main, 1280×720, 24 fps, 10s. Per-frame slice-count not directly extracted (would require a bitstream-filter pass like hevc_metadata to count slices per access unit). For x265 ultrafast preset on 720p, default is 1 slice per frame; assume that until Phase 6 verifies. If Phase 6 finds multi-slice frames, the libva backend's slice_params accumulation logic (Phase 2 Bug 4) handles up to 600 entries per frame per kernel UAPI advertising.

Baseline D — Bug 1 pre-fix scratch test (collateral safety)

Goal: apply Bug 1 fix (config.c break for HEVCMain) on a throwaway branch with h265.c + Bug 2 NOT applied, verify H.264 + MPEG-2 reference hashes hold post-rebuild + reinstall. Confirm no collateral damage from the trivial config.c change.

Patch applied:

@@ -68,6 +68,8 @@ VAStatus RequestCreateConfig(VADriverContextP context, VAProfile profile,
 		// submission time.
 		break;
 	case VAProfileHEVCMain:
+		// iter2 Phase 3 scratch — would break here in real fix
+		break;
 	default:
 		return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;

Build: clean. Install: clean.

Hash verification (post Bug 1 scratch, h265.c stays disabled):

H.264 +30s:
  HW frame 1: f623d5f7a41697f67dd227275c6f1b21ffc257f65626d32fde8229357f8764c9 (matches T4)
  HW frame 2: 7d7bc6f2146dda8b2d223bba622c4b9fbe9674181ff1e02afe286b620342e0a8 (matches T4)
MPEG-2 +02s:
  HW frame 1: 6e7873030dbf0403c67f35dd106ebef3c7909a0fd12433b82ad758e7fee9f092 (matches iter1)
  HW frame 2: ccc7ce08810d4a96e9ba7a19f4f95bbf6cc861bda9337604b5c668ad52bef7de (matches iter1)

Result: ✅ no collateral damage. Bug 1 fix in isolation does not regress H.264 or MPEG-2.

HEVC behavior with Bug 1 only (Bug 2 + Bug 3-6 not applied; h265.c still disabled):

[hevc] Task finished with error code: -5 (Input/output error)

libva trace verbatim:

[49437.712028] vaQueryConfigProfiles ret = VA_STATUS_SUCCESS
[49437.712059] va_TraceCreateConfig profile = 17, VAProfileHEVCMain
[49437.712118] vaCreateConfig ret = VA_STATUS_SUCCESS, success (no error)    <-- Bug 1 fix advances past this
[49437.712139] vaQuerySurfaceAttributes ret = VA_STATUS_SUCCESS
... (further surface attribute queries)
... (decode fails downstream because picture.c::codec_set_controls hits the
     case VAProfileHEVCMain: return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
     reject at line 204-206 — that's Bug 2, not yet patched in this scratch)

So Bug 1 alone advances vaCreateConfig to SUCCESS; the next failure is Bug 2's explicit reject at picture.c. Confirms Phase 2 prediction. Bug 2 fix requires h265_set_controls to exist (Bug 3-6: enable + rewrite), so Bug 2 lands together with the h265.c rewrite in Commit B (analogous to iter1 Commit B).

Scratch state cleaned: git checkout -- src/config.c && rebuild && reinstall. Master backend back; H.264 + MPEG-2 still pass; HEVC fails at vaCreateConfig (back to Baseline-A-equivalent state — Bug 1 not applied on master).

What Phase 3 confirms / refutes from Phase 2

Phase 2 claim	Phase 3 evidence	Status
Bug 1: config.c HEVCMain falls through to default → vaCreateConfig=12	Baseline D libva trace: pre-patch fails, post-patch SUCCESS	✅ confirmed
Bug 2: picture.c case VAProfileHEVCMain explicit UNSUPPORTED_PROFILE reject	Baseline D libva log: ffmpeg fails decode -5 (I/O error) post-Bug-1, before reaching h265.c (h265.c disabled)	✅ confirmed (effect observed, even though h265.c isn't enabled to dispatch)
Bug 3: h265.c uses staging-era CIDs that don't exist on modern kernels	Phase 2 source-read + test-compile already verified	✅ confirmed
Phase 2 prediction: per-frame batch has 6 controls	Baseline B verbatim: 5 controls (no ENTRY_POINT_OFFSETS for BBB fixture)	partially refuted: 5 not 6
Phase 2 prediction: SCALING_MATRIX is conditional on bitstream	Baseline B: SCALING_MATRIX always present in BBB's per-frame batch	refuted: FFmpeg gates on kernel-advertised control availability, not bitstream flag
Phase 2 prediction: slice_params is dynamic-array	Baseline B: SLICE_PARAMS variable-size (N entries × 1 slice/frame for x265 ultrafast)	✅ confirmed
Substrate intact post pacman -Syu (kernel didn't change)	Baseline A: T4 + iter1 hashes match exactly	✅ confirmed
linux-eos-arm kernel binary stays at 6.19.9-99 (only headers jump to 7.0.3)	pacman.log verifies; running uname -r confirms	✅ confirmed
OC DTB intact through upgrade	sha256 pre/post upgrade unchanged	✅ confirmed

Phase 4 plan inputs (updated)

Phase 4 plan should specify:

1. Diff scope (Phase 2 mostly correct; minor amendments below):

   • src/config.c:64-69 — add break; for VAProfileHEVCMain (3 lines, mirrors iter1).
   • src/picture.c:204-206 — replace explicit reject with dispatch to h265_set_controls().
   • src/h265.c — rewrite against new V4L2_CID_STATELESS_HEVC_* split API. Per-frame batch is 5 controls (SPS, PPS, SLICE_PARAMS dynamic-array, SCALING_MATRIX, DECODE_PARAMS). DECODE_MODE + START_CODE device-wide menus set once at init.
   • src/picture.c::codec_store_buffer (HEVC VASliceParameterBufferType case) — append-not-overwrite for slice_params accumulation.
   • src/surface.h::params.h265 — add slice_params array + count.
   • src/meson.build — uncomment h265.c (line 50) + h265.h (line 73).

2. SCALING_MATRIX gating (amended from Phase 2): query kernel via VIDIOC_QUERY_EXT_CTRL for V4L2_CID_STATELESS_HEVC_SCALING_MATRIX once at init; submit unconditionally per-frame if kernel advertises (matches FFmpeg ctx->has_scaling_matrix pattern). For BBB on RK3399, the kernel advertises it, so SCALING_MATRIX always in the batch.

3. Default scaling matrices if iqmatrix_set==false: per ISO/IEC 23008-2 Table 4-1 default scaling lists (4×4, 8×8, 16×16, 32×32 with separate luma/chroma variants). Phase 6 transcription from FFmpeg's default_scaling_list_intra / default_scaling_list_inter arrays in libavcodec/hevc.h — verify against Baseline B SCALING_MATRIX verbatim payload (all-default values for BBB fixture).

4. Contract anchor citations (per Phase 6 contract-before-code):

   • Linux mainline UAPI <linux/v4l2-controls.h>:2090-2300 for the 5+2 stateless HEVC control struct definitions and flag constants.
   • FFmpeg libavcodec/v4l2_request_hevc.c:505-565 (v4l2_request_hevc_queue_decode) for batched submission shape.
   • Phase 3 Baseline B verbatim 5-control payload (this document).
   • VAAPI <va/va_dec_hevc.h> for VAPictureParameterBufferHEVC, VASliceParameterBufferHEVC, VAIQMatrixBufferHEVC source field shapes.

5. Phase 7 verification harness: re-use iter1's 5-criterion shape, anchor on mpv --hwdec=vaapi --vo=image DMA-BUF GL path (cache-coherency-safe per memory feedback_rockchip_pixel_verify_path.md). HEVC fixture at +02s seek; HW vs SW byte-identical hashes for 2 distinct frames; iter1 MPEG-2 + T4 H.264 still match. Bonus: byte-compare post-fix S_EXT_CTRLS payload against Baseline B (per feedback_review_empirical_over_theoretical.md — empirical wins).

Open question for Phase 6 close

The iter2 fix-forward pattern from iter1 Commit D (header deletion completeness check via clean rebuild, not grep) applies to iter2's mpeg2-ctrls.h re-grep audit during Phase 6 (defensive — even though iter1 cleaned it up). Per feedback_header_deletion_check.md. iter2 does NOT delete include/hevc-ctrls.h (it's a thin shim, not a duplication header per Phase 2 Bug 7).

Phase 3 → Phase 4 close

All four baselines green. Substrate intact post-upgrade. HEVC contract anchor captured for Phase 4 transcription. Bug 1 scratch confirms collateral safety. Phase 4 can proceed; estimated h265.c rewrite ~250-400 lines (per Phase 2 estimate; Phase 3 confirms 5-control batch + dynamic-array slice_params + unconditional SCALING_MATRIX as the structural facts to plan against).