Confirmed the 40-byte inflation is non-uniform — IDR slice has correct
size from VAAPI; only P/B slices are inflated. Real fix requires dynamic
rbsp_stop_bit detection or per-slice-type logic.
α-23 test (skip media_request_reinit): no change. HEVC still 06b2c5a0...
all-zero. Kernel printk still shows w=0 h=0 for libva.
Cumulative disproved mechanisms (iter17-iter19):
2. REINIT clears between S_EXT_CTRLS and QUEUE: DISPROVED (α-23)
3. Stale stack-local pointer: DISPROVED (α-21)
5. Silent partial failure via error_idx: DISPROVED (α-22)
1. request_fd mismatch: unlikely per strace evidence
Remaining:
4. ctrl_hdl mismatch — libva submits to one v4l2_ctrl_handler,
rkvdec reads from another.
iter20 candidate: kernel printk dumping &ctx->ctrl_hdl, per-ID
ctrl pointer, and *p_cur.p first bytes during rkvdec_hevc_run_preamble.
Comparing libva vs kdirect will pinpoint where the mismatch sits.
State at close: backend c1d4bb53... (iter15 stable). Fork tip 415688d.
5-codec anchors held. Diagnostic kernel 7.0-3 still running on fresnel.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
α-21 (heap-persist HEVC controls past IOC_QUEUE): hash unchanged.
-> Kernel does copy at S_EXT_CTRLS time, not deferred. Mechanism 3 dead.
α-22 (log error_idx after S_EXT_CTRLS): error_idx = count - 1 in BOTH
the working device-init batch AND the broken per-frame batch. Not
a failure indicator in this kernel version. Mechanism 5 dead.
Backend reverted to iter15 stable state c1d4bb53... All 5-codec
anchors preserved.
Remaining mechanisms (untested):
1. request_fd mismatch (unlikely; strace shows consistent fd)
2. REINIT clears controls between S_EXT_CTRLS and QUEUE (LEADING)
4. ctrl_hdl mismatch (libva submits to one, rkvdec reads from another)
iter17's empirical finding still stands as the campaign's strongest
narrowing: rkvdec sees zero SPS for libva, correct for kdirect. The
mechanism is between S_EXT_CTRLS submission and ctx->ctrl_hdl->p_cur
read, specific to libva's invocation pattern.
iter19 candidate (α-23): test mechanism 2 by disabling
media_request_reinit() in libva's RequestSyncSurface. If hashes
change, REINIT timing is the bug. Alternative (mechanism 4): kernel
printk that dumps &ctx->ctrl_hdl + per-request handler pointer,
comparing libva vs kdirect.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
DEFINITIVE FINDING via pr_info in rkvdec_hevc_run on RK3399:
libva HEVC: w=0 h=0 reorder=0 chroma=0 nal_unit_type=0 decode_flags=0x0
kdirect HEVC: w=1280 h=720 reorder=2 chroma=1 nal_unit_type=20 decode_flags=0x3
The kernel sees ALL-ZERO control structs for libva HEVC, but CORRECT values
for kdirect. Same kernel, same code path, same /dev/video1, same
rkvdec_hevc_run_preamble fetching v4l2_ctrl_find(ctx->ctrl_hdl,
HEVC_SPS)->p_cur.p.
This overturns iter11-iter15's "wire-byte search exhausted" conclusion.
The S_EXT_CTRLS payloads ARE byte-correct at the strace observer level,
but the kernel sees zeros. The bug is in the
S_EXT_CTRLS -> request -> ctx->ctrl_hdl path, specifically for libva.
Five mechanisms hypothesized:
1. request_fd mismatch
2. REINIT clears controls before QUEUE
3. Compound-control copy deferred until QUEUE -> stack-locals stale
4. ctrl_hdl mismatch (libva submits to one, rkvdec reads another)
5. error_idx silently fails
Key difference observed:
libva stores SPS/PPS/decode_params as STACK LOCALS in h265_set_controls
kdirect stores them in heap-allocated hwaccel_picture_private
Mechanism 3 (kernel defers compound-ctrl copy_from_user) is the leading
hypothesis. iter18 α-21: heap-allocate libva's HEVC control structs;
if Bug 5 fixes, apply same pattern to H.264 (Bug 4) and VP8 (Bug 6).
This is the strongest narrowing since iter5b-β.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Per iter16 close (Bug 4/5/6 confirmed kernel-side, libva byte-correct),
add a single pr_info at rkvdec_hevc_run entry dumping key state values
from run->sps / pps / slices_params[0] / decode_params. Build 7.0-3,
deploy, reboot, run libva-HEVC + kdirect-HEVC, diff dmesg output.
Outcome interpretations:
identical -> bug is in rkvdec assemble_hw_*/config_registers/HW path
different -> libva somehow leaks different struct contents via non-
ioctl path despite identical V4L2 ioctls
Build running on boltzmann via kernel-agent workflow; pkgrel 7.0-2 -> 7.0-3.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Applied iter14's α-16 OUTPUT byte verification to VP8. Result:
libva VP8 frame 1 OUTPUT dump: 300614 bytes
input IVF frame 1: 300624 bytes
diff with +10-byte offset (VP8 uncompressed header stripped by VAAPI
consumer client-side): 0 bytes differ.
Libva's VP8 OUTPUT bytes are byte-identical to the input frame minus
the 10-byte uncompressed header. Same correctness as iter14's HEVC
verification.
Cumulative finding: ALL THREE remaining campaign bugs (Bug 4 H.264
partial-fill, Bug 5 HEVC all-zero, Bug 6 VP8 partial) have:
- libva controls byte-equal to kdirect on rkvdec-read fields
- libva OUTPUT bitstream bytes byte-identical to input
- libva ioctl sequence structurally close to kdirect after iter15 α-19
But:
- VP9 + MPEG-2 work via the same libva backend on the same kernel.
- libva HEVC/H.264 hash to wrong output; kdirect HEVC/H.264 hash to
correct output. Same kernel.
Therefore Bug 4 + 5 + 6 are kernel-side rkvdec/hantro per-codec bugs
specific to libva's ioctl pattern. Per
feedback_libva_byte_correct_kernel_bug.md (saved iter14), libva-side
changes are confirmed inert for these bugs.
iter17 productive direction: kernel-side investigation via
kernel-agent workflow. Read rkvdec source, instrument via ftrace/
eBPF kprobe, compare kernel state evolution between libva-trigger
and kdirect-trigger for same bitstream.
No code changes in iter16. Substrate unchanged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase 3 ioctl-sequence diff identified missing S_FMT CAPTURE in libva
init (only G_FMT was being called, per iter5b-β's hantro-targeted
comment). α-19 added explicit S_FMT CAPTURE with NV12 + dims after
S_FMT OUTPUT, before CREATE_BUFS. strace confirms libva now emits
identical S_FMT CAPTURE call to kdirect:
S_FMT CAPTURE NV12 1280x720 -> sizeimage=1843200, bytesperline=1280
5-codec sweep on α-19 backend: byte-identical anchors. HEVC still
06b2c5a0... all-zero, H.264 still 71ac099b... partial. Wire correct,
behavior unchanged.
Cumulative iter8-iter15: 14 hypotheses eliminated for Bug 4 + 5. Libva
backend ioctl + payload sequence is now structurally equivalent to
kdirect's at every byte/field level rkvdec reads. Remaining diffs are
in allocation pattern (REQBUFS vs incremental CREATE_BUFS) and pool
sizes (libva 24+16, kdirect ~13+4) — high-risk to change without
clearer kernel evidence; VP9/MPEG-2 work with libva's pattern.
Bug 4 + 5 confirmed kernel-side rkvdec failures specific to HEVC +
H.264 paths on RK3399 that libva's pattern triggers and kdirect's
doesn't. Per-codec kernel-level investigation is the only productive
direction; route via kernel-agent.
α-19 ships as wire-correctness hygiene (zero regression). Backend
SHA c1d4bb53...
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
α-16 OUTPUT byte dump: libva HEVC frame 1 = 96893 bytes = 1 ANNEX-B
start code + 96890 byte IDR NAL with header 0x28 (nal_unit_type 20 =
IDR_N_LP, correct). Byte-compared against input file's raw HEVC
ANNEX-B stream (after VPS+SPS+PPS): 0 bytes differ over 96890 byte
overlap. The 1-byte tail diff is an inter-NAL boundary marker, not
slice payload.
Libva submits BYTE-IDENTICAL slice bytes as what the input contains
and what kdirect submits. Combined with iter11's wire-byte audit
showing every libva-vs-kdirect control diff is in a field rkvdec
ignores, AND iter12's RFC v2 substrate upgrade producing zero
codec-correctness change, AND iter13's DMA_BUF_IOCTL_SYNC ioctl
working but inert:
Cumulative iter8-iter14: 13 hypotheses eliminated. Libva backend
is empirically byte-correct on its side. Bug 4 + Bug 5 are
KERNEL-SIDE failures specific to how rkvdec processes the libva
ioctl sequence vs the kdirect sequence — NOT a libva backend bug.
iter15+ candidates:
- Full ioctl-sequence trace diff (libva vs kdirect, find first
divergence in syscall order/args).
- kernel-side rkvdec ftrace/eBPF kprobe instrumentation; route
via kernel-agent.
- Campaign close-out: VP9+MPEG-2 PASS direct, HEVC+H.264+VP8 narrowed
to kernel-side with byte-clean libva submission.
Backend SHA fa2098b6... 8 cumulative iter11-iter14 commits all ship
clean (wire-correctness, env-gated diagnostics, zero regression).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
α-17 implemented and deployed. strace confirms VIDIOC_EXPBUF +
DMA_BUF_IOCTL_SYNC(START|READ) before memcpy + END after, all returning 0.
The libva backend now follows the V4L2+dma-buf cache-sync contract
correctly. But 5-codec sweep hashes are byte-identical to anchors:
no Bug 4/5 movement.
Cache-sync hypothesis empirically falsified. Bug 4 + 5 are NOT a CPU
cache-coherency issue on the libva cached-mmap path.
Three consecutive PARTIAL closes (iter11 wire-byte, iter12 RFC v2,
iter13 cache-sync) confirms libva-backend-side hypothesis space for
Bug 4+5 is exhausted. The live source is kernel-side write-
completeness for HEVC and H.264 on RK3399 rkvdec — distinct from
cache visibility (γ dump iter8 already confirmed destination_data[]
post-DQBUF matches YUV output).
Backend SHA on fresnel: 9ba47002...
iter14 candidates:
α-16: OUTPUT byte dump (cheapest remaining)
kernel-side rkvdec audit (deepest; route via kernel-agent)
pivot to Bug 6 VP8 or campaign close-out documentation
α-17 itself is real wire-correctness progress even as a non-fix.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Boltzmann built linux-fresnel-fourier 7.0-2 in ~50 min (8-core native,
no distcc). Package sha 843fd4462a09b3d9... Deployed to fresnel:
sudo pacman -U clean. extlinux hook updated entry. sddm autologin as
mfritsche persisted. Reboot succeeded; fresnel up on new kernel
within 30s.
5-codec sweep post-reboot: all 5 hashes BYTE-IDENTICAL to pre-iter12
anchors. RFC v2's dma_resv fence machinery does NOT engage libva's
cached-mmap pixel readback path. Consistent with what
reference_dmabuf_resv_blocker.md memo always said: vaDeriveImage /
cached-mmap is the broken path; RFC v2 helps DRM_PRIME / compositor
paths.
Substrate state moved forward (kernel 7.0-1 -> 7.0-2 with RFC v2).
Memory entries updated:
reference_fresnel_kernel_substrate.md (pkg version + patch list)
feedback_rfc_v2_vb2_dma_resv_scope.md (NEW — scope clarification)
iter13 candidates ranked:
α-17: DMA_BUF_IOCTL_SYNC(START|END) in libva backend around image
read sites (~30 LOC).
α-18: switch libva image export to DRM_PRIME (larger refactor).
α-16: OUTPUT byte dump (deferred again).
α-17 is the natural follow-on — Figa's 2024 "userspace responsibility
for explicit sync" line directly addresses the libva-cached-mmap path.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
User signaled RFC v2 is prepared at boltzmann:~/v2-patch-work/v2-out/.
Three patches:
0001 media: videobuf2: add opt-in dma_resv producer fence helper
0002 media: hantro: attach dma_resv release fence at device_run
0003 media: rockchip-rga: attach dma_resv release fence at ...
v2 key change vs v1: attach moves from buf_queue to m2m device_run
(Dufresne's finite-time-contract concern). Build the kernel package
on boltzmann (~/src/kernel-agent-bootstrap/.../linux-fresnel-fourier/),
deploy to fresnel, reboot, retest.
sddm auto-login as mfritsche staged in /etc/sddm.conf.d/20-autologin.conf
on fresnel before reboot per user authorization.
Phase 0's α-16 OUTPUT-byte dump candidate parked; kernel substrate
upgrade takes precedence given RFC v2 is the long-stalled
reference_dmabuf_resv_blocker.md unblock.
Iter12 outcomes:
PASS = Bug 4/5 hashes shift toward kdirect after reboot.
PARTIAL = kernel upgraded cleanly, no regression, hashes unchanged.
Either outcome is valuable — substrate moves forward regardless.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After iter11 close, both Bug 4 (H.264 partial fill) and Bug 5 (HEVC
all-zero) share the same architectural pattern: libva control payloads
can be made byte-equivalent to kdirect for fields rkvdec consumes,
yet libva produces wrong output while kdirect succeeds.
Remaining unexamined surface = OUTPUT bitstream bytes (source_data
that the kernel reads). iter12 candidate α-16: extend γ infra to
dump source_data pre-QBUF, compare with kdirect.
If bytes match → both bugs are outside libva (kernel/HW state).
If bytes differ → narrow to bitstream-write divergence site.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
α-13 + α-14 changed two HEVC wire-byte fields to match kdirect
(sps_max_num_reorder_pics, decode_params IRAP|IDR flags). Output
unchanged (06b2c5a0... still all-zero). 5-codec regression sweep:
zero regression.
Cumulative iter11 eliminations: 4 fields (sps_max_num_reorder_pics,
sps_max_latency_increase_plus1, IRAP/IDR flags, num_entry_point_offsets)
all confirmed kernel-ignored on RK3399 per rkvdec-hevc.c grep.
Wire-byte landscape after iter11: every observable libva-vs-kdirect
HEVC control-payload diff is in a field rkvdec ignores. Bug 5 root
cause is NOT in S_EXT_CTRLS payload.
Same wall as Bug 4 / iter9: wire-byte search exhausted. Real cause is
in OUTPUT bitstream bytes the kernel reads. iter12 candidate: extend
γ infrastructure to dump source_data pre-QBUF, compare with kdirect
byte-by-byte. Bug 4 and Bug 5 likely both close via this same
instrumentation given the parallel structure.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Reviewer empirically read rkvdec-hevc.c on boltzmann kernel-agent
tree. sps_max_num_reorder_pics is NOT read by rkvdec. α-13 would
match kdirect's wire bytes but produce no behavioural change.
CRIT-2: num_entry_point_offsets (libva hardcoded 0 at h265.c:356,
kdirect 22 from slice header parse) + PPS UNIFORM_SPACING flag are
the live candidates. BBB HEVC uses WPP (ENTROPY_CODING_SYNC flag
set in PPS) not tiles; 22 entry points = 23 CTB rows for 720p with
32-pixel CTBs.
Decision: land α-13 as wire-correctness hygiene (matches kdirect,
no regression risk), then α-14 for the actual fix.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
iter10 closed negative at Phase 0 (Bommarito unreachable on RK3399).
Saved kernel build + reboot cycle by source-tree reachability check.
iter11 opens with Bug 5 (HEVC libva all-zero) as research target.
Replay iter8/iter9 methodology: deep strace HEVC libva vs kdirect,
decode V4L2_CID_STATELESS_HEVC_* control payload bytes, find the
diff that causes rkvdec to produce all-zero output for libva while
kdirect's submission produces correct decode.
In scope: src/h265.c (libva HEVC), Phase 3 strace + byte-decode.
Out of scope: ext_sps_st/lt_rps (VDPU381/383-only, not RK3399),
kernel patches until empirical evidence of a kernel-side gap.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Empirical reachability check on linux-fresnel-fourier 7.0-1 source tree
at boltzmann:~/src/kernel-agent-bootstrap/build/marfrit-packages/arch/.../linux-7.0/.
rkvdec_hevc_assemble_hw_rps() is defined in rkvdec-hevc-common.c:411 and
called ONLY from rkvdec-vdpu381-hevc.c:609 (RK3576) and
rkvdec-vdpu383-hevc.c:620 (RK3588). RK3399's variant_ops bind to
rockchip,rk3399-vdec and route HEVC through the older standalone
rkvdec-hevc.c, which does NOT call rkvdec_hevc_assemble_hw_rps.
Bommarito's May 13 patch is real and load-bearing on RK3588/3576,
but inert on RK3399 / fresnel. Not iter10 vehicle for Bug 5.
Saved a kernel build/reboot cycle by Phase-0 reachability check.
Memory rule candidate: before applying any upstream patch to fresnel's
kernel, verify the patched path is reachable from rockchip,rk3399-vdec.
mainline rkvdec has diverging per-variant code (VDPU381/383 vs RK3399
legacy).
iter10 candidate pivots:
- α-10: audit rkvdec-hevc.c (RK3399 legacy) for analogous OOB gaps;
same KUnit/KASAN methodology Bommarito used. Route via kernel-agent
per user directive.
- α-12: stay on Bug 4 H.264 (PPS deep diff / OUTPUT bitstream).
User directive registered: "consult kernel-agent for kernel work."
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
α-7 (monotonic timestamp counter) changed wire bytes but H.264 output
unchanged (71ac099b...). Confirms Phase 5 CRIT-1 prediction: VP9/MPEG-2
PASS via libva with the same v4l2_timeval_to_ns(&ref->timestamp)
pattern; therefore timestamp magnitude was never load-bearing.
5-codec regression sweep: all 4 non-H.264 anchors hold. Zero regression.
Cumulative state after iter8+iter9:
- 6 hypotheses eliminated (libva-readback, slot-binding, stale-residue,
constraint_set_flags, POC sentinel, reference_ts magnitude)
- libva-vs-kdirect H.264 wire-byte diff is now empirically zero
- α-2 + α-7 shipped as wire-payload hygiene cleanups (zero behavior
change but cleaner semantics)
iter10 candidate ranking:
1. α-8 OUTPUT bitstream byte dump (compare in-memory slice bytes)
2. α-9 untraced control diff (device-wide controls beyond DECODE_MODE
+ START_CODE)
3. Kernel-side investigation (rkvdec source dive for 16x32 partial-
decode signature)
4. Pivot to Bug 5 (HEVC) or Bug 6 (VP8)
Two more iterations of diminishing returns suggest either deeper
empirical work (OUTPUT-byte dump or kernel investigation) or pivot
to a different bug.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
VP9 (vp9.c:624) and MPEG-2 (mpeg2.c:150,156) use v4l2_timeval_to_ns
identically to H.264. Both PASS via libva with the same gettimeofday-
based giant ns values. If timestamp magnitude were the bug, VP9/MPEG-2
should also fail. They don't.
Reviewer flagged α-7 as low-probability fix and pointed to iter10
kernel-side investigation (M-A vb2_find_buffer_by_timestamp overflow)
if α-7 confirmed inert.
IMP-1: timestamp_counter should live in object_context not driver_data
to avoid multi-context collisions.
Decision: implement α-7 anyway as empirical confirmation (5 min) since
test cost is trivial. If α-7 fails as predicted, iter9 closes PARTIAL
with wire-byte search exhausted; iter10 candidates pivot to slice-data
encoding or kernel investigation.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase 0 deep-strace yielded a critical narrowing:
- Post-DPB DECODE_PARAMS bytes (512-559): IDENTICAL libva vs kdirect
- PPS: IDENTICAL
- SPS: identical except inert constraint_set_flags
- DPB[0] beyond reference_ts: IDENTICAL after α-2
The ONLY remaining wire-byte diff between libva (broken) and kdirect
(working) is reference_ts magnitude. libva uses gettimeofday giving
~1.78e18 ns; kdirect uses an internal counter giving ~10000 ns.
α-7 hypothesis: V4L2 stateless decoder (rkvdec) reference-resolution
fails for very large reference_ts values. Possible mechanisms:
M-A: vb2_find_buffer_by_timestamp truncates/overflows on giant values.
M-B: V4L2 framework transforms OUTPUT QBUF ts before storing on CAPTURE
but DPB.reference_ts left untransformed → mismatch.
M-C: gettimeofday + v4l2_timeval_to_ns produce slightly different ns
values than the kernel computes from the timeval QBUF.
Fix: ~10 LOC. Add timestamp_counter to driver_data; replace
gettimeofday in EndPicture with monotonic counter.
If α-7 works → iter9 PASS, Bug 4 closed.
If α-7 doesn't → iter9 PARTIAL, wire-byte search space effectively
exhausted.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sonnet-architect Phase 5b read rkvdec-h264.c end-to-end and confirmed:
constraint_set_flags is NEVER accessed by the driver. assemble_hw_pps()
reads only chroma_format_idc, bit_depth_*, log2_max_frame_num_minus4,
max_num_ref_frames, pic_order_cnt_type, log2_max_pic_order_cnt_lsb_minus4,
and dimension fields. rkvdec_h264_validate_sps() doesn't validate it.
CONSTRAINT_SET3_FLAG and PROFILE_IDC in the hardware PPS packet are
hardcoded constants (1 and 0xFF respectively), not propagated from the
incoming SPS.
α-1 will not unblock Bug 4. Plan-killer.
CRIT-2: ConstrainedBaseline 0x42 mapping is wrong (bit 6 reserved);
correct value 0x12 (bit 1 | bit 4) per H.264 §A.2.1.1.
IMP-1 redirects: DPB entry flags + POC fields are the next candidate.
rkvdec config_registers() reads dpb[i].flags ACTIVE/FIELD bits and
dpb[i].fields TOP/BOT bits. lookup_ref_buf_idx() substitutes destination
buffer as reference when ACTIVE missing — silent corruption matching
observed symptom.
IMP-2/3: full PPS byte comparison + close-criteria framing.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
γ dump confirms libva reads buffer correctly; the 16x32 patch and
stride-4 UV markers appear at YUV output exactly as in the dump.
IMP-1 memset-before-QBUF test: pre-zeroing buffer does NOT change output
(identical hash). The 512 bytes ARE deterministic kernel writes, not
stale residue.
Bug root cause: rkvdec accepts libva's H.264 decode request without
error flags but writes only 16x32 of luma-neutral data + stride-4 UV
scratch. Kernel decoded a tiny bit then stopped.
Phase 3 SPS diff: libva SPS.constraint_set_flags=0x00 vs kdirect's
0x02 — likely the kernel hint that triggers rkvdec's full decode path
for Main profile. Phase 4b α-1 fix: derive constraint_set_flags per
VAProfile in h264_set_controls. ~10 LOC. Phase 5b review required.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CRIT-1: request_log prepends prefix on every call; per-byte loop in γ
sketch would emit 32 prefix-only lines. Fix: snprintf buffered emit.
CRIT-2: γ dump block missing null guard on destination_data[]; the
plan's env-var check is outside the current_slot != NULL guard. Fix:
nest the dump inside the existing slot-null guard.
IMP-1: "stale residue from prior decode" not eliminated as alternative
explanation for the 16x32 patch. Add memset-zero-before-QBUF experiment
to Phase 7 to discriminate.
IMP-2: γ-first defensible but on IMP-1 grounds, not the
three-signature argument (which is weaker than stated).
IMP-3/4 placement clarifications. MIN-1/2/3 cosmetic.
5 mechanical amendments locked for Phase 6. γ-first strategy stands.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase 3 redefined Bug 4 to partial-fill (not inter race). Three distinct
per-codec signatures (VP9 correct, HEVC zero, H.264 partial-leak) can't
be explained by a single hypothesis. Phase 4 commits to γ first: a
~30 LOC env-gated diagnostic dump in RequestSyncSurface that fires
after CAPTURE DQBUF, prints first/last 32 bytes of each destination_data
plane and a non-zero-count of the first 1024 bytes.
γ definitively distinguishes "kernel didn't write" from "libva mis-reads"
from "slot binding wrong". Phase 4b targeted fix follows γ's outcome.
Out of scope: per-codec H.264 control-fill changes (gated on γ's
findings), VP9/VP8/HEVC/MPEG-2 paths, kernel patches.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase 3 strace + byte-level analysis on fresnel rkvdec. Findings:
1. Bug 4 is NOT inter-race-loss. The IDR keyframe itself fails through
libva (only 512 bytes of real Y data at top-left 16x32 region).
2. The 16x32 leak is structured real image content (smooth gradients,
neutral luma ~0x80) — kernel decoded one tile / one MB pair, then
stopped.
3. VP9 via libva WORKS through the same readback path (100% non-zero,
real image data). So the bug isn't generic DMA-BUF cache coherency.
4. HEVC fails via libva (all-zero, distinct from H.264 partial-fill).
5. OUTPUT sizeimage = 1MB (SOURCE_SIZE_MAX) is sufficient — BBB IDR is
only 6321 bytes. Not the bug.
6. Control payload diffs: SPS.constraint_set_flags = 0 vs kdirect's 2
(probably cosmetic); DECODE_PARAMS.dpb[0].bottom_field_order_cnt = 0
vs kdirect's 1 (load-bearing for POC).
Refined hypothesis: a specific H.264 control field libva sends causes
rkvdec to abort after partial decode. Phase 4 candidates: α fix POC
fields, β bump OUTPUT sizeimage, γ instrumentation dump, δ relative
timestamps.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
User pick at iter8 open. Carried unchanged through 5 iters (iter4..iter7);
keyframe partially decodes (frame-1 first 16 bytes = real chroma) while
inter frames return all-zero. Pass criterion: libva_h264 == kdirec_h264
== sw_h264 byte-identical for bbb_1080p30_h264.mp4 3-frame, including
inter frames.
In scope: src/h264.c, src/h264_slice_header.c, src/picture.c H.264 paths,
per-frame request_fd lifecycle. Out of scope: VP9/VP8/HEVC/MPEG-2, kernel
patches, performance, all other backlog items.
Substrate at iter8 open: fork tip 6df2159 (iter7), backend SHA 520507f6..,
kernel linux-fresnel-fourier 7.0-1, auto-detect picks rkvdec on every boot.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase 5 sonnet-architect found:
- CRIT-1: interface links connect IO entities (source/sink) to interfaces,
NOT directly to proc entity. Walk must use MEDIA_LNK_FL_INTERFACE_LINK
(1U<<28) to discriminate. Author verified at media.h:223-225.
- CRIT-2: source_id/sink_id ordering not guaranteed in link entries;
check both endpoints. Author verified media_v2_link struct at media.h:341-347.
- IMP-1: hantro decoder-proc (entity 17) distinct from encoder-proc
(entity 3) by function field. Algorithm correct by construction —
no encoder contamination possible.
- IMP-2: MEDIA_ENT_F_PROC_VIDEO_DECODER set on both rkvdec-proc
(rkvdec.c:1382) and hantro-dec-proc (hantro_drv.c).
- IMP-3: current 3-call ioctl pattern has spurious memset; new function
uses 2-call pattern (alloc all 3 arrays before second call).
- IMP-4/MIN-1/2/3: minor implementation notes.
All 5 substantive findings empirically verified against boltzmann's
linux-rockchip tree.
Phase 6 implementer pseudocode provided: walk entities → find decoder
proc → walk data links to collect IO entity neighbors → walk
interface links to find linked interface → resolve major:minor.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase 2 source-read found iter4-B1 conflates two sub-bugs:
- B1a: walk picks encoder when it should pick decoder. SMALL FIX
(~100-150 LOC). Add MEDIA_ENT_F_PROC_VIDEO_DECODER entity check
in find_video_node_via_topology; two-pass prefer rkvdec.
- B1b: multi-decoder routing (rkvdec for H.264/HEVC/VP9 + hantro
for MPEG-2/VP8 from one backend instance). Bigger arch fix
~200-400 LOC. DEFERRED.
iter7 ships B1a. Phase 1 criteria amended:
- Auto-detect always picks a decoder, never an encoder.
- Prefer rkvdec over hantro (rkvdec serves 3 of 5 codecs).
- 2 reboots verify stability.
- vainfo lists rkvdec's 3 codecs minimum.
- No regression on iter5b-β / iter6 state.
Phase 6 will use MEDIA_IOC_G_TOPOLOGY's entities+links arrays to
match V4L node entities to decoder-proc entities. Two-pass walk:
pass-1 rkvdec only, pass-2 any decoder.
Empirical baseline: on 2026-05-12 boot, /dev/media0=rkvdec (only
decoder), /dev/media1=hantro-vpu (encoder AND decoder both inside),
/dev/media2=uvc. Fix must skip encoder when accepting media1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Backend-only ~30-80 LOC. Walk media-topology entities (already partially
done at iter4 Commit Z); require at least one entity with function ==
MEDIA_ENT_F_PROC_VIDEO_DECODER. Eliminates the hantro encoder false-match
that breaks vainfo + ffmpeg-vaapi on every other reboot.
5 boolean Phase 1 criteria locked. No kernel work. No pixel-correctness
chasing. Quality-of-life delivery; removes per-session env-override
friction.
Predicted lowest-difficulty iteration since iter1. 2-3 hours wallclock.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase 3 Candidate K executed: H-D (slot rotation) ELIMINATED via
instrumented bind+read site logging. Slot v4l2_index matches at
BeginPicture and at vaGetImage for every surface; destination_data[0]
matches slot->map[0]. No rotation mismatch.
H-A/B/C/D all eliminated. H-E (kernel-side hantro VP8 partial-write)
confirmed by elimination. The libva backend submits correct controls,
correct slice bytes, correct slices_size, correct slot indices.
Kernel writes erratic partial content (per-frame Y plane transitions
at row 536, 24, ... — not a clean buffer-size truncation, not slot
rotation).
iter6 close PARTIAL: 5 of 6 Phase 1 criteria PASS; criterion 1
(libva_vp8 == kdirect) PARTIAL — kernel-side fix needed, out of
iter6's locked backend-only scope.
No patches landed. Fresnel substrate unchanged: fork tip 70196f8,
backend SHA 2c6ff82c... (identical to iter5b-β close).
Net deliverable: Phase 3 narrowing reduces Bug-6 hypothesis space
from 5 to 1. Future iter7+ (or kernel-agent campaign) picks up the
kernel-side investigation.
Pattern recognized: iter2 HEVC transitive PASS masked Bug 5;
iter3 VP8 transitive PASS masked Bug 6. Both surfaced under direct
verification post-iter5b-β. Transitive proofs against ONE artifact
(control payload) don't catch bugs in OTHER artifacts.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Empirical Phase 3 narrowing:
- H-A slice data corruption: ELIMINATED. SHA256 of libva-dumped slice 0
(300614 bytes) byte-identical to raw VP8 frame 0 from .webm at
offset 10..300624 (post-VP8-header).
- H-B slices_size wrong: ELIMINATED. slices_size = fp_size +
sum(dct_part_sizes) = 300614 exactly.
- H-C cache coherency: ELIMINATED. msync attempt yielded no output
change; VP9 uses same image.c path and works fine.
- Control payloads: byte-identical between libva and kdirect for VP8
keyframe (pre-Phase-2 finding).
Output pattern: erratic partial-write. Frame 0 Y plane has real
content rows 0-535, then 100% zero rows 536-719. UV plane real
rows 0-133, zero 134-359. Frame 1 Y plane real rows 0-23, zero
24-719. Per-frame transitions differ — not buffer-size truncation,
not slot rotation.
Remaining:
- H-D slot rotation (untested; needs instrumentation)
- H-E kernel-side hantro VP8 partial-write quirk (likely; needs
ftrace / kernel investigation)
iter5b-β did fix Bug 2 for VP8 (pre-β all-zero was format mismatch;
post-β real-but-partial content is a separate kernel-side issue).
Phase 3 hands off 4 candidate directions to user:
- K: continue H-D investigation (1-2h next session)
- L: pivot to H-E kernel-side work (multi-session)
- M: park Bug 6, pick different bug (Bug 4/5 or iter4-B1)
- N: close iter6 PARTIAL, defer Bug 6 to iter7+
Substrate unchanged; no regression. Backend SHA still 2c6ff82c....
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Empirical byte-diff of libva vs kdirect VP8 control payloads on
current substrate:
- Keyframe (payloads 0+1): BYTE-IDENTICAL (0 diffs / 1232 bytes)
- Inter frames: only 24 bytes diff at offset 1200-1223, which are
the 3 reference-frame timestamps. libva uses gettimeofday→ns
(large values), kdirect uses pts-derived (small). Both internally
consistent; kernel uses them as keys, absolute values don't matter.
Verdict: Bug 6 is NOT in vp8.c control generation. The bytes match.
With identical controls and same hardware, libva produces 0.4% pixel
match for keyframe — bug lives in slice-data path, bytesused, cache
coherency, or CAPTURE slot rotation.
5 hypotheses (H-A..H-E) for Phase 3 to narrow:
- H-A slice data corruption in libva path (picture.c memcpy)
- H-B slices_size wrong on OUTPUT QBUF
- H-C cache coherency on OUTPUT mmap before kernel DMA read
- H-D CAPTURE slot rotation mismatch
- H-E other (deeper kernel-side)
Pre-iter5b masked all of these via the OUTPUT format mismatch
producing all-zero output. β fixed format → kernel actually decodes →
underlying bug now visible.
iter3's transitive proof verified specific control fields. Did not
verify slice data, bytesused, cache state, or slot rotation. Same
pattern as iter2's HEVC transitive PASS missing Bug 5. Future
transitive PASS claims must enumerate non-verified artifacts.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two acts:
Act 1 (β alone): all 5 libva codecs returned all-zero. MPEG-2 was a
regression (pre-β it worked); HEVC was unchanged (kernel returns
DQBUF FLAG_ERROR pre AND post β — same Phase 3 baseline showed it).
Root cause: ffmpeg-vaapi-copy passes surfaces_count=0 to vaCreateContext
per iter6 context.c:262 comment; my β walk of surfaces_ids[] was a
no-op → destination_planes_count stayed 0 → surface_bind_slot no-op
→ all-zero readback.
Act 2 (Commit D): cache format-uniform CAPTURE geometry in driver_data;
walk surface_heap in CreateContext; lazy-fill in CreateSurfaces2 when
fmt_valid is set; invalidate in DestroyContext. Restores MPEG-2 to
pre-β state and unlocks VP9.
Per Phase 1 criteria: criterion 1 PARTIAL (VP9 of HEVC+VP9+VP8);
criteria 2-4 PASS.
Bug 5 (NEW): HEVC libva DQBUF FLAG_ERROR — pre-existing kernel
rejection; β's OUTPUT format fix didn't address it. Transitive proof
at iter2 verified control payload shape but kernel still rejects;
some other V4L2 protocol contract aspect differs from kdirect.
Bug 6 (NEW): VP8 libva produces non-zero output with real content
(74.8% zero + 256 unique bytes incl. keyframe pixels at `93 8e 8a 89...`)
but diverges from kdirect. Decode runs; output mismatch likely
slot-rotation or partial-fill bug.
VP9 is iter5b-β's only clean PASS. Architecture-wise β succeeded:
no α'-style failure mode possible (no in-CreateSurfaces2 destructive
teardown), and the CRIT-1+CRIT-2 fixes from Phase 5 v2 review held.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CRIT-1: context.c:64-66 video_format==NULL guard rejects every first
β CreateContext. β moves the probe from CreateSurfaces2 into
CreateContext itself, so the guard fires before any new logic runs.
Fix: remove guard, move CAPTURE probe to top of CreateContext.
CRIT-2: DestroyContext lacks request_pool_destroy. Empirical grep
shows only surface.c:220 (which β strips) calls it per-session.
Without amendment, second CreateContext gets pool->initialized=true
with stale slot pointers → QBUF EINVAL. Fix: add request_pool_destroy
to DestroyContext before REQBUFS(0). C3 (surface.c strip) and CRIT-2
fix MUST land together.
Plus IMP-1 (mplane assumption wrong for SUNXI_TILED_NV12) + IMP-2
(surface_reset_format_cache becomes dead under C7) + IMP-3 (error
recovery comment).
Phase 6 BLOCKED pending CRIT-1 + CRIT-2 fixes. Author confirmed
both at code level — Phase 5 caught what Phase 4 v2's surface read
missed ("DestroyContext teardown — no change needed" — wrong; was
incomplete).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
marfrit