marfrit
bece7b7016
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>
fresnel-fourier
TL;DR
Peer campaign to libva-multiplanar, targeting fresnel (Pinebook Pro / Rockchip RK3399) instead of ohm (PineTab2 / RK3566). Same deliverable shape — make libva-v4l2-request-fourier work end-to-end, for production VA-API consumers — but on a different SoC with a different (and broader) V4L2 decoder surface.
The libva backend fork itself (libva-v4l2-request-fourier) is shared: it lives at ../libva-multiplanar/libva-v4l2-request-fourier/. This campaign does not nest a second copy. Code-side work that turns out to be RK3399-specific lands either as #ifdef/runtime-detected paths inside that fork's master or, if scope diverges sharply, on a feature branch — Phase 2 source-read of each iteration decides.
Origin
libva-multiplanar reached iter5-close on 2026-05-05 with the ohm path solid: hantro (rk3568-vpu DT compatible) decodes H.264 to NV12 dmabufs end-to-end, three iterations of bugs fixed, mpv --hwdec=vaapi smooth, firefox-fourier RDD-sandboxed Firefox engages the backend without MOZ_DISABLE_RDD_SANDBOX=1, chromium-fourier 149 confirmed as the regression-check consumer.
That campaign's README explicitly names fresnel (RK3399) and ampere/boltzmann (RK3588) as "future iterations after ohm path is solid" (libva-multiplanar/README.md:87). fresnel-fourier is the formal peer campaign for the RK3399 leg of that promise.
Topology choice (LOCKED 2026-05-07): peer campaign, not child of libva-multiplanar. Each runs its own 8(+1) phase loop. Cross-link only — fresnel-fourier results do not gate libva-multiplanar's Phase 8 close (which already happened iteration-by-iteration on ohm).
Hardware target
fresnel — Pinebook Pro laptop. See reference_fresnel_kernel_constraints.md for the custom-OC-kernel discipline (don't let pacman -Syu clobber the OC DTB) and project_fresnel.md for fleet placement.
| Property | Value |
|---|---|
| SoC | Rockchip RK3399 (2× Cortex-A72 + 4× Cortex-A53) |
| GPU | Mali-T860 MP4 (Midgard, panfrost) |
| Decoder block 1 | rkvdec (/dev/video3) — H.264 + HEVC + VP9 |
| Decoder block 2 | hantro-vpu-dec (rk3399-vpu-dec, /dev/video5) — MPEG-2 + VP8 (RK3399 hantro does not advertise H.264; corrected 2026-05-07 from empirical V4L2 enumeration — see phase0_evidence/2026-05-07/v4l2_inventory_findings.md) |
| Encoder block | hantro-vpu-enc (/dev/video4) — JPEG only |
| OS | EndeavourOS-ARM (Arch derivative; same pacman + marfrit-packages mechanism as ohm) |
| Kernel | linux-eos-arm 6.19.9-99 — CONFIG_FTRACE=y, CONFIG_FUNCTION_TRACER=y, CONFIG_DYNAMIC_FTRACE=y, CONFIG_TRACING=y verified 2026-05-07. No rebuild needed for trace work. |
The decode-side surface area is genuinely broader than ohm. ohm has hantro (H.264 + MPEG-2 + VP8) and an rkvdec block whose mainline rkvdec2/vdpu346 driver isn't merged. fresnel has hantro (MPEG-2 + VP8 only — empirical, see correction note in the table above) plus a fully-driven mainline rkvdec covering H.264 + HEVC + VP9. So this campaign exercises codecs (HEVC, VP9) the libva-v4l2-request-fourier fork has never run on real hardware to date, and there is exactly one decoder bind for H.264 (rkvdec) — no two-block routing decision.
GPU side: panfrost on Mali-T860 (Midgard) is a different generation than ohm's Mali-G52 (Bifrost). KWin / Mesa / panfrost stack regressions or wins on T860 are not assumed to track G52 — the kwin-fourier verdict from fourier_attribution doesn't transfer for free.
Scope (LOCKED 2026-05-07 in phase0_findings.md)
In scope:
- libva-v4l2-request-fourier backend exercised on fresnel V4L2 decode nodes (
rkvdec+hantro-vpu-dec). - Codecs: everything decode-capable — H.264 + HEVC + VP9 (via rkvdec) + MPEG-2 + VP8 (via hantro-vpu-dec). This is the explicit broadening from libva-multiplanar's H.264-first locked scope.
- Test consumers:
vainfo,mpv --hwdec=vaapi, Firefox viamedia.ffmpeg.vaapi.enabled, chromium-fourier 149 (regression check). - Phase 1 success criterion (matching libva-multiplanar): boolean correctness — "libva accepted + providing access to hardware decoder for each codec." Performance metrics deferred.
- Phase 0 task 1: recover fresnel from the SDDM greeter crash-loop (per
~/.claude/plans/dynamic-forging-piglet.md). Recovery is bookkept as substrate work inside this campaign, not as a separate prereq.
Out of scope:
- Front-end libva (API library). Backend only.
- Other hardware (ohm + ampere/boltzmann are libva-multiplanar's iterations).
- AV1 (no decoder block on RK3399 supports it).
- Performance metrics — fresnel CPU/GPU benchmarking is a separate iteration after correctness lands.
cros-codecsRust replacement (peruser_stance_rust.md).- Bootlin / Collabora upstreaming default-deferred (per
feedback_no_upstream.md). Same discipline as libva-multiplanar. - KWin / panfrost / Mali-T860 work — orthogonal until proven otherwise; a parallel
kwin-fourier-fresnelcampaign would be a separate decision.
Process
8(+1) phase loop per feedback_dev_process.md. Phase 0 substrate is in phase0_findings.md. Phase 5 review uses the sonnet-architect subagent pattern (Plan with model: sonnet).
In-session-acquired data discipline per feedback_replicate_baseline_first.md: libva-multiplanar's ohm-side measurements are reference history, not threshold sources for fresnel-fourier cells.
Predecessor work this campaign builds on
../libva-multiplanar/— five closed iterations on ohm. Read in order:README.md— current state, codec scope, file map.phase8_iteration5_close.md— most recent close. The iter5-end backend is the substrate fresnel-fourier starts from.phase0_findings.md(andphase0_findings_iter[2-5].md) — locked-scope precedent for codec breadth and consumer matrix on ohm; useful frame-of-reference when locking fresnel-side scope.phase8_iteration1_close.md— iter1 surface-export DMA-BUF lifecycle race + multi-resolution cache + 64-pitch alignment bugs. Likely re-surface candidates on RK3399.
../libva-multiplanar/libva-v4l2-request-fourier/— the fork itself. 12 commits ahead of bootlin tip plus iter1..iter5 work.git logfor the actual landing record.~/.claude/plans/dynamic-forging-piglet.md— fresnel SDDM greeter crash diagnosis + recovery plan. Phase 0 task 1 picks up from here.~/src/fourier_attribution/— ohm-only attribution matrix. The chromium-fourier WHEAT-but-fragile verdict and Cell E (vanilla Chromium 149 control) item are ohm-side context, not fresnel data.
External reference (carry-over from libva-multiplanar):
- Mozilla bug 1833354 / 1965646 (Firefox HW decode on RK35xx via libva-v4l2-request).
- Bootlin upstream
bootlin/libva-v4l2-request— dormant since 2021. - Linux kernel
drivers/staging/media/rkvdec/— RK3399 rkvdec H.264/HEVC/VP9 control protocol reference. - Linux kernel
drivers/media/platform/verisilicon/hantro_*— RK3399-vpu-dec MPEG-2/H.264/VP8 control protocol reference.
Repository layout
~/src/fresnel-fourier/ <- this campaign (its own git repo)
├── README.md <- this file
├── phase0_findings.md <- locked research question + Phase 0 work list
├── (worklist.md, phase[2-8]*.md as phases land)
└── (the libva fork is NOT here — see ../libva-multiplanar/libva-v4l2-request-fourier/)
The campaign repo and the fork repo stay separate. fresnel-fourier commits its findings here; code changes to the backend land on the fork's master (or a branch named per the iteration if scope diverges from libva-multiplanar's ohm-side master).
Operator-facing repo URL: git.reauktion.de/marfrit/fresnel-fourier — created empty during scaffolding, no push until first iteration finds something worth publishing.
Non-upstreaming default
Inherited from libva-multiplanar / feedback_no_upstream.md. Patches must be aligned to upstream in syntax and semantics; PR/MR/bug-report only on explicit operator instruction.
Build infrastructure
distcc/cross-build path is the existing fleet: aarch64crosscompiler LXD on data, tesla LXD on hertz, dcc1 on dcw3. See reference_distcc_kernel_builds.md for invocation. Per the locked Phase 0 answer for libva-multiplanar (item 9), no distcc for libva builds — libva is small and links fast, hand-build on fresnel directly. Same default applies here unless a specific reason emerges.
For chromium-fourier 149 / firefox-fourier rebuilds against fresnel-side findings, the boltzmann LXD container path from libva-multiplanar iter3 is reusable.