sicd + sic-agent -> 0.2.1-1 against sic tag v0.2.1 (tarball sha 0efe5acc…). The daemon fix: it
no longer blocks the stdin pump after the child exits, so sic calls with a never-EOFing stdin
(non-interactive callers holding the pipe open) return promptly instead of hanging to a timeout.
Client unchanged. Pre-flight built (debian amd64 + arch verifysource).
Bumps sicd + sic-agent (arch PKGBUILDs, debian build-deb.sh, both changelogs) to
0.2.0-1 against sic tag v0.2.0 (tarball sha fe0569013da5...). New tarball verified
building all four packages locally (debian amd64 debs + arch verifysource) before push.
What 0.2.0 ships (source git.reauktion.de/marfrit/sic @ 4fcd851):
* Nested targets: sic host/hop1/hop2 cmd peels incus/docker/pct container hops,
resolved via /etc/sic/hosts.toml, built as a netstring onion.
* argv boundaries preserved end to end (length-framed [][]byte, never space-split)
-- the founding guarantee: sic host touch 'a b' stays ONE file.
* Daemon dual-reads v1 and v2 (first-byte dispatch), so pre-0.2.0 clients keep
working during the staged rollout.
* Client forwards stdin AFTER the frame (fixes the v0.1.0 zero-byte trap), ssh -T
binary-safe, exit status inherited.
* Hardened + reviewed (bullpen 964/970): outer-length cap before alloc, per-element
and byte caps, explicit canonical argc (empty "" args representable).
Also removes continue-on-error from the four sic CI jobs (sicd/sic-agent x arch/debian)
so a broken build fails the workflow loudly instead of silently producing nothing --
the reason the sic jobs went unnoticed as never-succeeding since 2026-07-19.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The package was referenced in memory as already published but never
actually existed in this repo or on packages.reauktion.de — only an
unpublished Arch build was staged on hertz. Adds real PKGBUILD +
dpkg-deb packaging (cert committed alongside, no upstream tarball)
and wires both into build.yml following the lmcp/aish dual-arch +
debian publish pattern.
PR #112 bumped PKGVER/UPSTREAM_TAG to 1.2.4 but left LMCP_TARBALL_SHA256 at the
1.2.3 hash, so the sha256 -c check failed on the v1.2.4 tarball and lmcp-debian
errored. Update the pinned hash to the v1.2.4 archive.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The 1.2.4 changelog was bumped but build-deb.sh still pinned PKGVER=1.2.3 /
UPSTREAM_TAG=v1.2.3, so check-already-published saw 1.2.3 in the pool and the
lmcp-debian job skipped without publishing 1.2.4. Bump both so the .deb builds
against the v1.2.4 tag.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Ships marfrit/lmcp v1.2.4: shell/shell_bg kills the whole process group on
timeout/cancel (no orphans) + new kill_job/list_jobs tools. Updates arch
PKGBUILD (pkgver + sha256) and debian changelog.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The 0016 patch declared ff_h264_set_mb_inspect_cb in h264dec.h and
defined it in h264_mb.c, but didn't touch libavcodec/libavcodec.v.
FFmpeg's default version script exports only `av_*`, `avcodec_*`,
`avpriv_*`, and `avsubtitle_free`; everything else is hidden as LOCAL
behind a `*` glob. Result: `nm -D libavcodec.so.62 | grep
ff_h264_set_mb_inspect_cb` returned nothing → dlsym() returned NULL.
Static-link CLI consumer (daedalus_decode_h264) was unaffected
because static linking doesn't care about symbol visibility. The
daedalus-v4l2 daemon shadow_decoder path (PR-Q3a.1) dlopens
libavcodec.so.62 and resolves the callback via dlsym — that needs
the symbol exported.
Fix: add ff_h264_set_mb_inspect_cb to the global list in
libavcodec/libavcodec.v. Single-line addition to the 0016 patch.
Mirrored across the arch/ + debian/ patch trees.
PKGREL bump 14 → 15, changelog entry added (debian side). PKGBUILD
pkgrel bumped on arch side too. No behaviour change to the decode
path: the callback is still opt-in via the H264Context function
pointer; only consumers that have explicitly installed a callback
pay the one-load-one-branch cost per MB.
dejavu-check: this is fixing the existing 0016 observation-hook to
actually work as a dlsym intercept (the architectural shape the
patch was designed for). NOT adding new per-kernel substitution.
Same shape, same patch number, same intent. Just hiding/exporting
plumbing.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Companion to 0016 (PR #106). Adds a coefficient side buffer in
H264Context, populated at the start of ff_h264_hl_decode_mb with a
single memcpy from sl->mb BEFORE IDCT-add zeros it. The existing
post-pixel-work callback (still in 0016) can now read:
- h->mb_inspect_coeffs = pre-IDCT coefficients (this patch)
- h->cur_pic.f->data = post-pixel-work pre-deblock reconstruction
and derive P = pixels − IDCT(C) for daedalus-decoder's frame-major
dispatch in PR-A3+.
Memcpy gated on (h->mb_inspect_cb != NULL). Zero cost when no
consumer is registered. Side buffer = 16 * 48 int16 = 1536 bytes
(matches the 8-bit half of sl->mb's int16_t[16 * 48 * 2] declared
size; high-bit-depth uses the upper half — not preserved here since
the daedalus-decoder consumer is 8-bit-only).
Single-threaded decode assumed at the consumer side
(avctx->thread_count = 1). Multi-slice / multi-threaded streams
would race on the single side buffer — explicit limitation of the
inspection mechanism, future extension would put per-slice buffers
in H264SliceContext.
Verified: patches 0016 + 0017 apply cleanly and build in sequence
against the Kwiboo v4l2-request-n8.1 fork at the pinned commit
b57fbbe5. ff_h264_set_mb_inspect_cb symbol exported as before.
Wired into arch PKGBUILD + debian build-deb.sh patch sequence.
pkgrel bumped 13 → 14.
Refs reauktion/daedalus-decoder!14 (PR-A2 callback wiring complete,
PR-A3 coefficient extraction is the next consumer).
Adds 0016-h264-mb-inspect-callback.patch to the FFmpeg fork. Adds an
opt-in callback fired by ff_h264_hl_decode_mb after the existing
pixel work, for tools that need per-MB visibility into H.264 decode.
API:
typedef void (*ff_h264_mb_inspect_cb)(void *opaque,
const struct H264Context *h,
int mb_x, int mb_y);
void ff_h264_set_mb_inspect_cb(AVCodecContext *avctx,
ff_h264_mb_inspect_cb cb, void *opaque);
Two new fields appended to H264Context (internal struct, declared in
h264dec.h not h264.h, no ABI surface to non-libavcodec callers).
Callback fires post-pixel-work for every MB in coded order; receives
const H264Context* so it can inspect any state (slice ctx via
h->slice_ctx, reconstructed pixels via h->cur_pic.f->data[plane],
etc.).
Default (cb==NULL): zero behaviour change, one load + one branch per
MB in the decoder hot path.
Shape distinction: per-MB observation, NOT per-kernel function-pointer
hijack (the 0003-0014 substitution-arc pattern that PR #105 reverted
+ daedalus-fourier PR #37's measurement-correction architecturally
retired). Per-block synchronous Vulkan dispatch from libavcodec is
non-competitive; per-MB CPU-side observation feeding a per-frame
daedalus-decoder batch submit is the right shape (frame-major UMA
dispatch verdict, memory: dejavu).
Used by:
- daedalus-decoder/tools/daedalus_decode_h264 (PR-A1b, follow-up)
- future daedalus-v4l2 daemon refactor
Wired into arch PKGBUILD source[] + prepare() and debian build-deb.sh
patch sequence. pkgrel bumped 12 → 13.
Refs reauktion/daedalus-decoder!12.
Reverts the no_qpu → qpu-capable ctx flip that landed via patch 0014
(marfrit-packages PR #104).
PR #104 was justified by daedalus-fourier PR #36's "QPU 4.30x faster
than CPU NEON" bench result. That number was a measurement artifact:
v3d_runner.read_spv() did a bare cwd-relative fopen() with no path
search, so when the bench was run from the source dir (as in PR #36),
the SPVs at $builddir/v3d_*.spv were not found, every QPU dispatch
returned -1 fast, and the bench loop timed the failure path.
daedalus-fourier PR #37 fixes the SPV search + bench preflight.
Corrected numbers on hertz (Pi 5 V3D 7.1):
kernel CPU ns/op QPU ns/op winner
IDCT 4x4 luma 10.75 217.63 CPU 20.24x
IDCT 8x8 luma 29.69 785.94 CPU 26.47x
Deblock luma_v 17.63 467.42 CPU 26.51x
Deblock luma_h 38.30 498.53 CPU 13.02x
qpel mc20 (8x8) 30.17 1300.44 CPU 43.10x
qpel mc02 (8x8) 17.69 1363.40 CPU 77.08x
qpel mc22 (8x8) 71.60 1948.37 CPU 27.21x
1080p sum: CPU 5.57 ms vs QPU 123.54 ms — QPU 22x SLOWER.
Until daedalus QPU dispatch overhead is actually competitive (separate
multi-task effort tracked on the daedalus-fourier side), libavcodec.so
substitution must stay on daedalus_ctx_create_no_qpu() so the host
processes (firefox-fourier RDD, mpv-fourier, daedalus_v4l2_daemon)
don't pessimize their H.264 decode path.
Adds 0015-h264-ctx-revert-to-no-qpu.patch (2-line revert of patch 0014)
to both arch PKGBUILD and debian build-deb.sh. Both pkgrel bumped
11 → 12. Refs reauktion/daedalus-fourier!37.
(Renumbered from 0013 — PR #102 landed 0013-h264-deblock-chroma-intra
while this PR was open, so the next free slot is 0014.)
Patches 0003 (IDCT 4x4) and 0007 (qpel mc20) created the libavcodec.so
process-global daedalus_ctx via daedalus_ctx_create_no_qpu(). Rationale
at the time: cycle 6/9 had only CPU NEON paths, so a QPU-capable ctx
would have meant pointless Vulkan init in every host process.
Two things changed since:
1. Every H.264 hot-path primitive now has a V3D7 compute shader.
IDCT 4x4/8x8 + 8 deblock variants (luma+chroma × V+H × inter+intra)
+ 30 qpel positions. See daedalus-fourier PRs #28-#35.
2. Dispatch overhead has been hammered down — buffer pool in
v3d_runner + persistent command buffer. daedalus-fourier PR #36
bench on hertz (Pi 5 V3D 7.1, 30 iters x 5 warmup):
1080p worst-case sum (IDCT4 + deblock luma + qpel mc22):
CPU NEON only: 5.57 ms
QPU only: 1.30 ms (CPU/QPU sum ratio = 4.30x)
PR #10's CPU-4x-faster-than-QPU verdict (which justified the original
no_qpu ctx choice) is reversed by ~17x.
This commit adds 0014-h264-ctx-qpu-capable.patch which flips both H.264
TUs (h264_idct_daedalus.c, h264_qpel_daedalus.c) from
daedalus_ctx_create_no_qpu() to daedalus_ctx_create().
daedalus_ctx_create() probes for a usable Vulkan device and falls back
to no_qpu mode if unavailable, so this is safe on hosts without V3D
(x86 build runners, Debian aarch64 builders without renderD, etc.).
Hosts WITH V3D (Pi 5 deployment targets) now route the H.264 hot-path
through V3D compute instead of CPU NEON.
Wired into both arch PKGBUILD (source[] + prepare()) and debian
build-deb.sh; both pkgrel bumped 10 → 11.
Refs reauktion/daedalus-fourier!36.
Substitutes c->v_loop_filter_chroma_intra and c->h_loop_filter_chroma_intra
with daedalus wrappers in the bit_depth=8 / chroma_format_idc<=1 (4:2:0)
branch. 4:2:2 stays on the in-tree NEON path (the daedalus chroma intra
dispatch is 4:2:0-only).
The fourier dispatches were exposed in PR #11 (DEFINE_INTRA_DISPATCH
macro generates the public daedalus_dispatch_h264_deblock_chroma_*_intra
symbols + recipe wrappers).
Re-architects the chroma init: v_loop_filter_chroma_intra was previously
assigned unconditionally to the NEON variant (which works for both 4:2:0
and 4:2:2). We now assign it INSIDE both branches of the chroma_format_idc
conditional — 4:2:0 picks daedalus, 4:2:2 keeps NEON. No regression for
4:2:2 streams.
Same NEON-to-NEON via recipe shape as 0010 luma intra.
Closes the deblock substitution layer for the 4:2:0 / 8-bit hot path:
- 0005 luma_v non-intra ✓
- 0008 luma_h non-intra ✓
- 0009 chroma_v / chroma_h non-intra ✓
- 0010 luma_v / luma_h intra ✓
- 0013 chroma_v / chroma_h intra ✓
All 8 deblock variants for the common 4:2:0 path now route through
daedalus. 4:2:2 chroma + the chroma422 mbaff variants stay on in-tree
NEON.
Verified the patch applies cleanly on top of 0001-0012 against the
pinned upstream commit b57fbbe5 on hertz.
Closes the H.264 qpel substitution. Extends 0007 (which routed only
mc20 put_) to ALL 15 useful positions in BOTH the put_ and avg_
tables, skipping mc00 (integer copy / pointer-only fast path).
29 substitutions total: 14 new put_ + 15 avg_. Each wraps a single
daedalus_recipe_dispatch_h264_qpel_{avg_,}mcXY call (the dispatches
landed in daedalus-fourier PRs #15-#20). Collapsed via a single
DEFINE_QPEL_WRAPPER macro on the libavcodec shim side so the diff
is uniform.
All recipe-table entries route AUTO to CPU NEON — no QPU shaders
for any qpel position other than mc20 yet. Plumbing-only
NEON-to-NEON via the daedalus recipe layer; bit-exact against
the in-tree ff_*_h264_qpel8_*_neon path (each daedalus dispatch is
already bit-exact-gated by the corresponding fourier PR's test).
16x16 qpel tables ([0][...]) stay on the in-tree NEON. daedalus
only exposes 8x8 today; 16x16 substitution can land once fourier
provides those variants.
Verified the patch applies cleanly on top of 0001-0011 against the
pinned upstream commit b57fbbe5 on hertz.
Substitutes H264DSPContext.chroma_dc_dequant_idct in the 4:2:0 /
bit_depth=8 init path with a wrapper that composes the daedalus
chroma DC Hadamard primitive (daedalus-fourier PR #25) with the
qmul scaling FFmpeg's reference does in one fused function
(h264idct_template.c::ff_h264_chroma_dc_dequant_idct).
Algorithm per H.264 §8.5.11.1 / §8.5.11.2:
1. Extract 4 DCs from the scattered positions in the per-MB
coefficient buffer (stride=32, xStride=16)
2. 2x2 Hadamard transform (daedalus primitive)
3. qmul scale + >> 7, write back to original positions
Bit-exact against ff_h264_chroma_dc_dequant_idct_8_c. The Hadamard
itself is gated by the fourier PR #23 7-case test suite (including
the H·H = 4·I algebraic invariant), and the public-API parity
test added in PR #25 confirms the src/ symbol matches the test ref.
4:2:2 chroma stays on the in-tree ff_h264_chroma422_dc_dequant_idct_c
path — same chroma_format_idc<=1 gating shape as 0009 chroma deblock.
Pin bump: _daedalus_fourier_commit / DAEDALUS_FOURIER_COMMIT bumped
to b9f9ff2a (post-PR #25) so the build picks up the public
daedalus_h264_chroma_dc_hadamard_2x2 symbol.
Verified the patch applies cleanly on top of 0001-0010 against the
pinned upstream commit b57fbbe5 on hertz.
Adds the bS=4 intra-strength variants of the already-substituted
luma_v / luma_h deblock (0005, 0008). Intra MBs and certain
inter-MB edges (4x4 transform boundaries inside an Intra_NxN
neighbour) force boundary strength to 4 per H.264 §8.7.2.1.
H264DSPContext.v_loop_filter_luma_intra →
daedalus_recipe_dispatch_h264_deblock_luma_v_intra
H264DSPContext.h_loop_filter_luma_intra →
daedalus_recipe_dispatch_h264_deblock_luma_h_intra
Both kernels landed in daedalus-fourier PR #11. Recipe → CPU NEON
(no intra QPU shaders yet); plumbing-only NEON-to-NEON via daedalus.
Signature differs from bS<4: no tc0 argument. Wrapper passes
daedalus_h264_deblock_meta with alpha/beta set; tc0[] is ignored by
the intra dispatch (bS=4 hardcodes the strength).
Chroma intra variants are deferred to a follow-up because the chroma
init has a 4:2:0 / 4:2:2 split (chroma_format_idc gating) — the
daedalus dispatch is 4:2:0-only and needs explicit conditional
substitution to avoid running on 4:2:2 chroma.
Verified the patch applies cleanly on top of 0001-0009 against the
pinned upstream commit b57fbbe5 on hertz.
Chroma siblings of 0005 (luma_v) and 0008 (luma_h). Same
NEON-to-NEON pattern via the daedalus recipe layer:
H264DSPContext.v_loop_filter_chroma →
daedalus_recipe_dispatch_h264_deblock_chroma_v
H264DSPContext.h_loop_filter_chroma →
daedalus_recipe_dispatch_h264_deblock_chroma_h
Both kernels landed in daedalus-fourier PR #10. Recipe table routes
AUTO to CPU NEON (no chroma QPU shaders yet), so this is plumbing-
only and stays bit-exact against the in-tree NEON.
Intra chroma (bS=4) loop filters remain on in-tree NEON;
daedalus_h264_deblock_meta covers the non-intra (bS<4) path.
Verified the patch applies cleanly on top of 0001-0008 against the
pinned upstream commit b57fbbe5 on hertz. Wires the new patch into
both arch/PKGBUILD and debian/build-deb.sh.
Adds patch 0008 to the substitution arc, mirroring 0005's V variant
for H.264 non-intra bS<4 horizontal luma deblock.
H264DSPContext.h_loop_filter_luma →
daedalus_recipe_dispatch_h264_deblock_luma_h
The H kernel was added to daedalus-fourier in PR #9 (vendored
ff_h264_h_loop_filter_luma_neon, wired through the same CPU-dispatch
pattern as V). Recipe table routes AUTO to CPU NEON (no QPU shader
for H yet), so this is a NEON-to-NEON substitution via the daedalus
recipe layer — same shape as 0005.
The libavcodec.so ctx remains no-QPU (daedalus_ctx_create_no_qpu),
matching the existing 0003/0004/0005/0007 patches. Higher-cycle
QPU init waits for a feature-flag gating change in a separate PR.
Intra (bS=4) h_loop_filter_luma_intra stays on the in-tree NEON .S
code; daedalus_h264_deblock_meta covers the non-intra path only.
A follow-up can route intra once daedalus-fourier exposes the
intra-h dispatch (the kernel already exists internally per fourier
PR #11).
Wires the new patch into both arch/PKGBUILD and debian/build-deb.sh
sequences. Verified the patch applies cleanly on top of 0001-0007
against the pinned upstream commit b57fbbe5 on hertz.
aish is an AI-augmented conversational shell in LuaJIT 2.x with FFI
bindings to libcurl, GNU readline, and libc — no C extensions, no
build step. Source-of-truth: git.reauktion.de/marfrit/aish, tag v0.1.0
(tarball sha256 9ebc3939e028832e39391ae33efacb5ec9bcd99d123cbc8ca1cd6ca9a640b5b5).
The arch and debian recipes mirror the lmcp pattern (pure-Lua any-arch
package, no makefile, install copies modules directly):
arch/aish/PKGBUILD — depends=(luajit readline curl)
debian/aish/build-deb.sh — pure dpkg-deb, SOURCE_DATE_EPOCH pinned
debian/aish/debian/{control,changelog,copyright}
Install layout, matching what main.lua's script-dir-relative package.path
expects after the wrapper execs `luajit /usr/share/lua/5.1/aish/main.lua`:
/usr/bin/aish ← bin/aish wrapper
/usr/share/lua/5.1/aish/{main,broker,context,executor,history,
mcp,renderer,repl,router,safety,secrets}.lua
/usr/share/lua/5.1/aish/ffi/{curl,libc,pty,readline}.lua
/usr/share/lua/5.1/aish/vendor/dkjson.lua
/usr/share/doc/aish/{README.md,LICENSE,examples/config.lua}
CI: two new jobs in .gitea/workflows/build.yml at the end of file.
aish-any chains needs:lmcp-debian (parallel-DAG with claude-his-any,
serialized via the shared arch-aarch64 runner — avoids needless wait
through the unrelated fourier stack). aish-debian chains needs:aish-any.
Both invoke the standard check-already-published.sh fast-skip on no-
change pushes.
Sonnet review (per feedback_reviews_use_sonnet.md + bugfix-process
step 4): no blockers. Folded in two findings before commit: switched
needs: from mpv-fourier-aarch64 to lmcp-debian (cleaner DAG, faster
cold-build wall clock), removed the dead Build-Depends: debhelper-
compat line from debian/aish/debian/control (build-deb.sh doesn't
use debhelper).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Arch: version 147→148, drop enable_nacl (removed upstream), fix
nv12-external-oes patch context for 148 (base/numerics/safe_conversions.h
include removed upstream). Header comment updated: native build fiction →
cross-compile reality.
Debian: new build-deb.sh that assembles .deb from pre-built artifacts
on CT 220 (data). Same binary artifacts as the Arch package, launcher at
/usr/bin/chromium-fourier (no Conflicts with stock chromium on Debian).
Both packages published to packages.reauktion.de:
- Arch: marfrit/aarch64/chromium-fourier 1:148.0.7778.178-1
- Debian: trixie+bookworm/main/arm64 chromium-fourier 1:148.0.7778.178-1
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
H264QpelContext.put_h264_qpel_pixels_tab[1][2] (8x8 luma horizontal
half-pel, 6-tap "put" — the canonical representative of the H.264
luma motion-compensation family) now dispatches through
daedalus_recipe_dispatch_h264_qpel_mc20 instead of
ff_put_h264_qpel8_mc20_neon.
Cycle 9 of the daedalus-v4l2#11 step 2 substitution arc; closes the
4-cycle libavcodec.so substitution sequence:
cycle 6 (PR #76) H.264 IDCT 4x4 done
cycle 7 (PR #85) H.264 IDCT 8x8 done
cycle 8 (PR #86) H.264 luma-v deblock done
cycle 9 (this) H.264 qpel mc20
Bumps daedalus-fourier pin d87239d → 209a421 (PR #2 — public API
gains daedalus_recipe_dispatch_h264_qpel_mc20 +
DAEDALUS_KERNEL_H264_QPEL_MC20).
Verdict per docs/k9_h264qpel_mc20.md: CPU NEON. Per-block 7.6 ns at
131 Mblock/s gives 135× margin over 30 fps 1080p; QPU dispatch floor
at ~250 ns makes any V3D shader strictly worse. Substitution is
plumbing-only — same daedalus_ctx_create_no_qpu pthread_once shape
the cycles 6/7/8 shims already own (kept SEPARATE from the H264DSP
shim's ctx because H264QPEL is its own libavcodec Makefile module
and link order does not guarantee a single .o owns the ctx symbol;
one extra ~µs init per process, paid lazily on first MC call).
Other H.264 luma MC variants (mc02, mc11, mc22 etc.) and the 16x16
size tier stay on the in-tree NEON .S code per the cycle-9 phase-1
rationale (mc20 8x8 is representative; remaining variants would
multiply recipe-lookup overhead without changing the substrate
verdict).
Bit-exact against ff_put_h264_qpel8_mc20_neon (daedalus-fourier
cycle 9 green; 10000/10000 random blocks bit-exact, M3 = 131 Mblock/s).
No SONAME change, no Depends change. PKGREL 9 → 10.
Refs reauktion/daedalus-v4l2#11 — substitution arc step 2 cycle 9.
Picks up reauktion/daedalus-v4l2 PR #20 (closes#19): wire-protocol
cap DAEDALUS_PROTO_MAX_PAYLOAD raised from 64 KiB to 1 MiB.
DAEDALUS_MAX_BITSTREAM follows; daedalus_fill_output_fmt now reports
OUTPUT_MPLANE sizeimage = ~1 MiB.
Fixes the Firefox YouTube avc1 SW-fallback observed on higgs when
any H.264 slice exceeded 64 KiB (routine on 720p+ streams).
libva-v4l2-request-fourier's S_FMT-driven OUTPUT-pool resize was
clamping back to 65484 and Firefox lost the slice; now the kernel
honours the larger sizeimage.
Both packages bumped to 0.1.0+r45+g872eec5-1:
- daedalus-v4l2 (daemon): r43 -> r45. Daemon-side allocations
are dynamic, so the only growth is one ~1 MiB read buffer per
daemon process at startup.
- daedalus-v4l2-dkms (kernel module): r33 -> r45. Skips the
daemon-only bumps r37/r39/r41/r43 (no kernel/include change in
that range) and lands the PROTO_MAX_PAYLOAD bump.
LOCK-STEP INSTALL REQUIRED: effective cap is min(kernel, daemon).
A stale kernel with a new daemon (or vice versa) still rejects
>64 KiB payloads. apt/pacman should pick both up in one
transaction since they share the same upstream pin.
Wire-protocol value-only change in include/daedalus_v4l2_proto.h;
struct layout unchanged. DAEDALUS_PROTO_VERSION stays at 0.
Picks up reauktion/daedalus-v4l2 PR #18 (closes#17): daemon drops
degenerate (<4 byte) bitstreams at REQ_DECODE entry instead of
letting avcodec_send_packet emit AVERROR_INVALIDDATA, replies
RESP_FRAME NO_FRAME so libva's V4L2 surface pool stays alive.
Fixes the Firefox YouTube avc1 pause→resume regression observed on
higgs: libva-v4l2-request-fourier flushes a 3-byte stub into
OUTPUT_MPLANE at the pause boundary; the old daemon path turned
that into a decode failure, Firefox marked H.264-via-VAAPI as
broken for the session, and routed every subsequent frame to
libmozavcodec SW. After this bump the daemon logs 'tiny bitstream
3 bytes — dropping as no-op' and the next real REQ_DECODE
proceeds normally.
Wire protocol unchanged. daedalus-v4l2-dkms bump not needed.
FFmpeg 8.x dropped the H.264 decoder's low_delay code path —
AV_CODEC_FLAG_LOW_DELAY no longer prevents h264_select_output_frame
from running the display-order DPB output queue. The daedalus-v4l2
daemon's `ctx->flags |= AV_CODEC_FLAG_LOW_DELAY` at
daemon/src/decoder.c:202 has been a silent no-op since the SONAME
61→62 jump landed in reauktion/daedalus-v4l2 PR #16; on Firefox
YouTube this re-introduced the 2-1-4-3 B-frame pair-swap that PR
#12's daemon flag was supposed to prevent.
Fix lives in libavcodec, not the daemon: restore the documented
LOW_DELAY semantics so the daemon (and any other V4L2-stateless-
style consumer) keeps the one-frame-per-send_packet decode-order
output contract it already declares.
## Patch
0006-h264-restore-low-delay.patch touches libavcodec/h264_slice.c:
- h264_select_output_frame: early-exit when LOW_DELAY is set.
Emit the just-decoded picture as next_output_pic, mirror the
corruption / recovery-point tracking the main path performs,
skip delayed_pic[] / POC reorder machinery entirely.
- h264_field_start: suppress the SPS-driven
`has_b_frames = sps->num_reorder_frames` clobber when LOW_DELAY
is set. Without this the per-slice bitstream_restriction_flag
re-pickup would reintroduce a nonzero reorder buffer mid-stream
even after the daemon set has_b_frames=0 at avcodec_open2.
## Why not daemon-side
A daemon SPS-rewrite (`num_reorder_frames=0`) was considered but
rejected: it works only for the daemon's reconstructed SPS NAL,
not for any in-band SPS the daemon dlopens libavformat to parse
in other code paths. Restoring documented FFmpeg flag semantics
is the smaller, more durable change and keeps the daemon
interface stable.
## Packaging
- PKGREL/pkgrel bump to 9.
- No new build-deps, no Depends change.
- Substitution arc cycles 6/7/8 unchanged.
## Refs
- reauktion/daedalus-v4l2#11 / #12 (LOW_DELAY half-measure on
daemon side, originally landed against FFmpeg 7.x).
- daemon/src/decoder.c:202 (`ctx->flags |= AV_CODEC_FLAG_LOW_DELAY`
for H.264 only — unchanged, but now actually has effect again).
Cycle 8 of the libavcodec.so substitution arc (reauktion/daedalus-v4l2#11
step 2). H264DSPContext.v_loop_filter_luma — non-intra bS<4 vertical
luma deblock, called per macroblock-row edge from the slice deblock
loop in libavcodec/h264_loopfilter.c — now dispatches through
daedalus_recipe_dispatch_h264_deblock_luma_v instead of
ff_h264_v_loop_filter_luma_neon.
## What
- Add 0005-h264-deblock-luma-v-daedalus-fourier.patch (in both arch/
and debian/ ffmpeg-v4l2-request-fourier/). Extends
libavcodec/aarch64/h264_idct_daedalus.c with
ff_h264_v_loop_filter_luma_daedalus (constructs a
daedalus_h264_deblock_meta from FFmpeg's (alpha, beta, tc0[4]) and
calls daedalus_recipe_dispatch_h264_deblock_luma_v with n_edges=1).
Patches libavcodec/aarch64/h264dsp_init_aarch64.c to wire
c->v_loop_filter_luma to the new shim.
- arch/PKGBUILD + debian/build-deb.sh: append patch + bump pkgrel/PKGREL
to 8.
- No new build-deps, no Depends change, no daedalus-fourier rev — the
d87239d pin already exposes daedalus_recipe_dispatch_h264_deblock_luma_v.
## Why
Cycle 8 is marked "CPU primary; QPU opportunistic" in the daedalus-
fourier API docstring. Per the hybrid substrate philosophy
("if there's a coprocessor, use it") we eventually want the QPU
opportunism active here. But the libavcodec.so context is
process-global and shared with cycles 6/7 via pthread_once, and it
uses daedalus_ctx_create_no_qpu deliberately to avoid implicit
Vulkan init in arbitrary host processes (Firefox content, mpv-fourier,
ffmpeg-fourier CLI, ...). Switching to daedalus_ctx_create here
without a feature flag would be a footgun.
So cycle 8 lands as plumbing-only NEON-by-recipe substitution for
now; opportunistic QPU enablement is a separate follow-up that adds
a DAEDALUS_FOURIER_ENABLE_QPU env var or equivalent.
## Scope NOT covered
- Intra (bS=4) loop filter c->v_loop_filter_luma_intra — daedalus's
daedalus_h264_deblock_meta only covers the non-intra path.
- Horizontal-edge variant c->h_loop_filter_luma — separate kernel
(not yet in daedalus-fourier API).
- Chroma loop filters — separate kernels.
- Bulk batching — single-edge dispatch wastes the kernel's n_edges>1
amortization. Same caveat as cycles 6/7; follow-up.
- QPU opportunism — see "Why" above.
## SONAME
Unchanged. libavcodec.so.62 / libavformat.so.62 / libavutil.so.60.
## Refs
- reauktion/daedalus-v4l2 issue #11: reauktion/daedalus-v4l2#11
- marfrit-packages PR #76 (cycle 6 IDCT 4×4)
- marfrit-packages PR #85 (cycle 7 IDCT 8×8)
- marfrit/daedalus-fourier cycle 8 close (deblock luma-v NEON green)
Cycle 7 of the libavcodec.so substitution arc (reauktion/daedalus-v4l2#11
step 2). H264DSPContext.idct8_add — called per 8×8 block from the
High-profile intra-8×8-DCT decode path in libavcodec/h264_mb.c — now
dispatches through daedalus_recipe_dispatch_h264_idct8 instead of
ff_h264_idct8_add_neon.
## What
- Add 0004-h264-idct8-daedalus-fourier.patch (in both arch/ and debian/
ffmpeg-v4l2-request-fourier/). Extends libavcodec/aarch64/
h264_idct_daedalus.c (introduced by 0003) with ff_h264_idct8_add_daedalus
and a daedalus_recipe_dispatch_h264_idct8 call; patches
libavcodec/aarch64/h264dsp_init_aarch64.c to wire c->idct8_add to
the new shim.
- arch/PKGBUILD + debian/build-deb.sh: append the new patch to the
apply list; bump pkgrel/PKGREL to 7.
- No new build-deps, no Depends change, no daedalus-fourier rev — the
d87239d pin already exposes daedalus_recipe_dispatch_h264_idct8.
## Why
The recipe layer picks the substrate; for cycle 7 (H.264 IDCT 8×8)
the recipe is CPU NEON, so this is effectively a NEON-to-NEON
substitution layered on top of cycle 6. Production validation of
cycle 6 on higgs Firefox YouTube: 3040 frames decoded cleanly,
avg_decode_us=3388 (no regression vs the pre-substitution ~4 ms
baseline). Cycle 7 inherits the same shim's pthread_once context.
Bit-exact against ff_h264_idct8_add_neon (daedalus-fourier cycle 7
green; FFmpeg 8×8 block storage block[r + 8*c] matches daedalus
column-major convention).
## Scope NOT covered (deferred)
- Bulk c->idct8_add4 (inter 8×8-DCT macroblocks) stays on the
in-tree NEON .S code; batched substitution with n_blocks>1 lands
later alongside the cycle-6 bulk-paths work.
- High-bit-depth (10-bit) path untouched.
- Cycles 8/9 — separate PRs.
## SONAME
Unchanged. libavcodec.so.62 / libavformat.so.62 / libavutil.so.60.
## Refs
- reauktion/daedalus-v4l2 issue #11 (substitution arc): reauktion/daedalus-v4l2#11
- marfrit-packages PR #76 (cycle 6 IDCT 4×4)
- marfrit-packages PR #78 (libxml2 ABI-skew workaround)
- marfrit/daedalus-fourier cycle 7 close (H.264 IDCT 8×8 NEON green)
The Gitea debian-aarch64 runner has been upgraded past Debian trixie
and now ships libxml2 ≥ 2.14 (SONAME 16) while higgs (and any other
trixie target) still has libxml2 2.12 (SONAME 2). -5 built cleanly,
but on higgs the daedalus-v4l2 daemon's dlopen of libavformat.so.62
fails:
dlopen(libavformat.so.62): libxml2.so.16:
cannot open shared object file: No such file or directory
Drop --enable-libxml2 from the Debian configure invocation; remove
the libxml2 entry from Depends; remove libxml2-dev from the CI
build-deps. FFmpeg's libxml2-backed DASH demuxer is unused on the
Fourier fleet — daedalus-v4l2 daemon feeds AVPackets straight to
avcodec_send_packet (no demux); mpv-fourier uses ytdlp + mpv's own
stream code; firefox-fourier uses gecko-media's DASH demux.
Bumps PKGREL 5 → 6. No source code or substitution-patch change.
Mirrors the libva trixie/runner ABI-skew workaround pattern
(marfrit-packages PR #62).
Arch PKGBUILD unaffected — Arch runner + Arch consumers both
rolling, libxml2 SONAMEs match.
After this lands, re-deploy on higgs via:
sudo apt update && sudo apt install -y ffmpeg-v4l2-request-fourier
sudo systemctl restart daedalus-v4l2
PR #76 (H.264 IDCT 4×4 daedalus-fourier substitution) was merged but
the resulting .deb was not actually built: an orphan
ffmpeg-v4l2-request-fourier_8.1+rfourier+gb57fbbe-4_arm64.deb (dated
2026-05-19, no matching source commit in main) sat in the apt pool.
.gitea/scripts/check-already-published.sh's debian branch compares
`dpkg --compare-versions $pool_ver ge $source_full` — pool -4
≥ source -3, so CI's skip-check emitted skip=1 and short-circuited
the build. The ffmpeg-v4l2-request-debian Action reported success
without actually publishing.
Bump source PKGREL past -4 so the next CI run sees source >= pool
and proceeds to build + publish.
No source code change beyond PKGREL + changelog. Arch side
unaffected (its skip-check is exact-URL-match, not pool-head-ge).
First cycle of the libavcodec.so substitution arc (reauktion/daedalus-v4l2#11
step 2). H264DSPContext.idct_add — called per 4×4 block from the
intra-4×4 decode path in libavcodec/h264_mb.c — now dispatches through
daedalus_recipe_dispatch_h264_idct4 instead of ff_h264_idct_add_neon.
## What
- Add 0003-h264-idct4-daedalus-fourier.patch (in both arch/ and
debian/ ffmpeg-v4l2-request-fourier/). Creates
libavcodec/aarch64/h264_idct_daedalus.c (ff_h264_idct_add_daedalus
shim + lazy pthread_once context init via
daedalus_ctx_create_no_qpu), patches
libavcodec/aarch64/h264dsp_init_aarch64.c to wire c->idct_add to
the shim, adds the new .o to libavcodec/aarch64/Makefile.
- arch/PKGBUILD + debian/build-deb.sh: fetch + build
daedalus-fourier (pinned at d87239d — lockstep with the
daedalus-v4l2 daemon's inline build) with
-DCMAKE_POSITION_INDEPENDENT_CODE=ON into a per-build temp prefix,
then pass --extra-cflags=-I.../include --extra-ldflags=-L.../lib
--extra-libs="-ldaedalus_core -lvulkan -lpthread" to FFmpeg
configure. daedalus_core.a is static-linked into libavcodec.so.62.
- debian/control Depends gains libvulkan1 (daedalus_core PUBLIC-links
Vulkan::Vulkan for the queryable QPU substrate; the no-QPU
constructor still works at runtime but the loader needs
libvulkan.so.1 present to dlopen libavcodec.so.62).
- arch/PKGBUILD depends gains vulkan-icd-loader, makedepends gains
cmake / ninja / vulkan-headers.
## Why
The recipe layer picks the substrate; for cycle 6 (H.264 IDCT 4×4)
the recipe is CPU NEON, so this is effectively a NEON-to-NEON
substitution with one extra dispatch call and recipe-table lookup.
The point of this first cycle isn't perf wins — it's plumbing. Once
the path is wired and stable, follow-up patches batch through the
bulk paths (idct_add16 / idct_add16intra / idct_add8) and stack
cycles 7/8/9 (IDCT 8×8, luma-v deblock, qpel mc20).
Bit-exact against ff_h264_idct_add_neon (daedalus-fourier cycle 6
green; FFmpeg's 4×4 block storage matches daedalus's column-major
convention).
## Scope NOT covered
- Bulk paths (idct_add16 / idct_add16intra / idct_add8) — most IDCT
4×4 calls in real H.264 streams go through these, not the per-
block c->idct_add path; intra-4×4-only macroblocks are a minority.
Batched substitution lands in a follow-up.
- High-bit-depth (10-bit) path — not touched; 8-bit only.
- Cycles 7/8/9 — separate PRs.
## SONAME
Unchanged. libavcodec.so.62 / libavformat.so.62 / libavutil.so.60.
No daedalus-v4l2-dkms or daedalus-v4l2 bump required.
## Refs
- reauktion/daedalus-v4l2 issue #11 (substitution arc): reauktion/daedalus-v4l2#11
- marfrit/daedalus-fourier cycle 6 close (H.264 IDCT 4×4 NEON green)
Daemon-only bump (no daedalus-v4l2-dkms change needed; PROTO_VERSION
stays at 0).
#12 (LOW_DELAY half-measure): daemon sets AV_CODEC_FLAG_LOW_DELAY on
the H.264 AVCodecContext so libavcodec emits frames in decode order
~99% of the time (a few stragglers at GOP boundaries when the
stream's SPS num_reorder_frames overrides the flag). Visible
improvement vs the 2-1-4-3 pair-swap on Firefox + mpv playback;
not the permanent fix — see daedalus-v4l2#11 for the architectural
plan to substitute daedalus-fourier kernels for libavcodec's
pixel math one cycle at a time.
#13 (daedalus-fourier linkage): daemon now pkg-config-links against
the daedalus-fourier kernel library (marfrit/daedalus-fourier) and
logs substrate availability at startup. No kernels dispatched yet
— this is the build-time foundation for the substitution work.
build-deb.sh updated to fetch + build + install daedalus-fourier
(pinned at d87239d, marfrit/daedalus-fourier PR #1) into a per-
build temp prefix before invoking the daemon's cmake, exposing it
via PKG_CONFIG_PATH. Static-linked, so the resulting .deb has no
new runtime deps. Requires libvulkan-dev + glslang-tools on the
CI runner.
Arch PKGBUILD bumped to the same upstream commit but Arch packaging
for daedalus-fourier itself is a follow-up; until that lands the
Arch build expects daedalus-fourier installed by the user (AUR-style).
Debian-side is end-to-end self-contained via build-deb.sh.
Refs:
* reauktion/daedalus-v4l2#12
* reauktion/daedalus-v4l2#13
* reauktion/daedalus-v4l2#11
* marfrit/daedalus-fourier#1
Lock-step downgrade of both packages to the revert tip of
daedalus-v4l2 (PR #10 closed PRs #7 + #8). After
0.1.0+r28+g79256dc-1 / 0.1.0+r30+g6ffe92b-1 landed in production,
mpv (--hwdec=vaapi-copy) failed pre-playing with "Unable to dequeue
buffer: Resource temporarily unavailable" because the daemon
parked CAPTURE buffers waiting for libavcodec's display-order
reorder, violating libva's V4L2 stateless 1:1 contract. See
daedalus-v4l2#9 for the diagnostic, #10 for the revert PR.
DAEDALUS_PROTO_VERSION drops 1 → 0; install both .debs in the same
apt transaction. Userspace ABI returns to the f0d4186-equivalent
behaviour, plus PR #4 (cosmetic H.264 menu controls). The
daedalus-v4l2-dkms #64 multi-kernel postinst behaviour stays in
build-deb.sh.
Visible regression: H.264 B-frame streams in Firefox return to the
"2 1 4 3 6 5" pair-swap visual. Proper fix (concurrent in-flight
requests in daemon + display-order reorder moved into libva-v4l2-
request-fourier) tracked at daedalus-v4l2#11.
Refs:
* reauktion/daedalus-v4l2#9
* reauktion/daedalus-v4l2#10 (merged)
* reauktion/daedalus-v4l2#11
Kernel-only bump. Fixes the hard-reboot regression introduced by
the daedalus-v4l2#7 split-completion design and observed on higgs
(Pi CM5) during the first mpv vaapi-copy playback of 720p H.264:
device_run now removes src + dst from m2m_ctx's rdy_queue at the
moment it picks them up, not at buf_done time. Without this, a
parked dst_buf (waiting for libavcodec's display-order release)
stayed in the rdy_queue and got re-picked by the next device_run
after SRC_CONSUMED's job_finish released the scheduler — two
inflight entries on the same vb2_buffer, later HAS_PIXELS calls
list_del on an already-detached list_head, panic.
DAEDALUS_PROTO_VERSION stays at 1 — daemon (userspace
daedalus-v4l2) need NOT bump in lockstep with this DKMS update.
The existing daedalus-v4l2 0.1.0+r28+g79256dc is wire-compatible
with daedalus-v4l2-dkms 0.1.0+r30+g6ffe92b.
Refs:
* reauktion/daedalus-v4l2#8
Bumps both Arch PKGBUILD and Debian build-deb.sh pins to PR #16 —
codec_store_buffer + request_pool_resize transparent OUTPUT-pool grow
on a mid-session resolution upshift overrun. Picks up the frame-
survival path that supersedes #13's drop-and-recreate fallback.
Dual-pin per feedback_marfrit_packages_dual_pin so both Arch and
Debian repos see check-already-published.sh report a new version.
Lock-step bump of both packages to daedalus-v4l2#7 + #4. PROTO_VERSION
bumps 0 → 1 at the daemon ↔ kernel chardev wire: REQ_DECODE adds
__u64 src_pts (the OUTPUT vb2 timestamp); RESP_FRAME adds __u32 flags
(HAS_PIXELS / SRC_CONSUMED) + __u64 output_src_pts (= frame->pts on
drain). Both .debs must be installed atomically or the chardev
handshake rejects the version mismatch.
* daedalus-v4l2: daemon's send_packet → receive_frame loop now
stamps pkt->pts = req->src_pts and looks up the cookie for each
drained frame via frame->pts. chardev_client emits multiple
RESP_FRAME messages per REQ_DECODE when libavcodec's display-
order DPB releases an earlier frame on receipt of a later
bitstream — fixes the "2 1 4 3 6 5" pair-swap on H.264 streams
with B-frames.
* daedalus-v4l2-dkms: kernel device_run mirrors src_buf timestamp
into REQ_DECODE.src_pts. Completion path splits HAS_PIXELS /
SRC_CONSUMED: src is released as soon as send_packet succeeds
(so the m2m scheduler moves on), dst stays parked until the
matching frame is drained later. TIMESTAMP_COPY's auto src→dst
pairing no longer applies once lifecycles decouple — dst is
stamped explicitly from inflight->src_pts at HAS_PIXELS time.
* daedalus-v4l2-dkms also carries forward the -2 multi-kernel
postinst fix (#64) from the prior PKGREL. PKGREL resets to 1 on
the new upstream pin.
The daedalus-v4l2#4 H.264 DECODE_MODE + START_CODE menu controls (a
cosmetic warning fix that PR landed alongside #7) is also subsumed —
"Unable to set control(s) error_idx=2/2" no longer fires.
Refs:
* reauktion/daedalus-v4l2#7
* reauktion/daedalus-v4l2#4
* reauktion/daedalus-v4l2#6
Bumps both the Arch PKGBUILD and the Debian build-deb.sh pins to PR
#14 merge — codec_store_buffer bounds-checks for VASliceDataBufferType.
Picks up the SIGSEGV fix for mpv --hwdec=vaapi-copy on resolution
upshift mid-stream (issue #13).
Dual-pin so check-already-published.sh detects both pool ABIs as
needing a fresh build.
Previously dkms autoinstall ran only against $(uname -r), so installing
the package on kernel A and rebooting into separately-installed kernel B
left /lib/modules/B/updates/dkms/ empty. /dev/daedalus-v4l2 absent,
daedalus daemon nothing to talk to, browser/VAAPI silently falling back
to software with no obvious diagnostic for the user.
Now we enumerate every /lib/modules/*/build that resolves to a real
directory (i.e. headers are actually installed for that kernel) and run
'dkms autoinstall -k <kver>' for each. Per-kernel verify; aggregated
warning only for the kernels that didn't build.
Tested locally: enumeration filters dangling /build symlinks correctly
(2 kernels installed, 1 has headers → only that one is built against).
Bumps PKGREL 1 → 2. Closes#64.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Upstream PR #3 — kernel per-context vb2_queue lock so concurrent
clients of /dev/video0 don't serialise on a device-wide mutex.
Pi 5 Firefox VAAPI playback (RDD + content + GPU processes each
opening the device) now works without S_FMT EBUSY collisions.
Verified on higgs: YouTube playback engages daedalus at sustained
~230 fps decode through the libavcodec dlopen path, ~7× headroom
over the 30fps@1080p Pi 5 Fourier target.
Both packages: pkgver 0.1.0.r24.f0d4186, pkgrel reset to 1.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Bumps both Arch (PKGBUILD) and Debian (build-deb.sh) sides in one commit
this time — following the dual-pin lesson from PR #53.
77f9236 = libva PR #12 merge: src/av1.{c,h} implements av1_set_controls
mapping VAPictureParameterBufferAV1 onto struct v4l2_ctrl_av1_sequence,
queued via S_EXT_CTRLS as V4L2_CID_STATELESS_AV1_SEQUENCE. The
daedalus_v4l2 daemon track will consume the ctrl to synthesise an
OBU_SEQUENCE_HEADER and prepend it to the slice bitstream, so libdav1d
can parse the OUTPUT buffer that ffmpeg-vaapi delivers without the
sequence header.
Until the daemon-side OBU synth lands (issue #11 operator track), the
SEQUENCE ctrl is just sitting in the request unused. Harmless on the
RK3588 vpu981 hardware path (vpu981 parses OBU bytes directly, ignores
the ctrl payload).
pkgver: r382.c1bb444 -> r386.77f9236 (commit count 382 -> 386, two new
upstream commits: 9fa18f2 av1 + 77f9236 merge).
pkgrel: 1 (fresh pkgver, no rebuild-only iteration).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Upstream PR #2 landed the one-line kernel fix that was the missing
half of issue libva-v4l2-request-fourier#8: device_run now calls
v4l2_ctrl_request_setup() before reading ctrl->p_cur, so the
daedalus_h264_meta the daemon receives reflects the in-flight
media_request's bound H.264 stateless control values instead of
stale/default ones.
Pairs with libva-v4l2-request-fourier 1.0.0+r382+gc1bb444 (max_num_
ref_frames fallback + Fix 4 instrumentation that exposed the
control-binding gap in the first place).
Effect on Pi 5 / CM5 hosts (higgs): ffmpeg -hwaccel vaapi against
H.264 sources now produces actual decoded content (per-frame
fnv1a hashes differ, zero MB-decode errors) instead of the
constant 0x6a6a05c5 "best-effort give-up" hash and cascading
decode warnings.
Both packages: pkgver 0.1.0.r22.462aa4b, pkgrel reset to 1.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
PR #52 bumped only arch/libva-v4l2-request-fourier/PKGBUILD; the
sibling debian/libva-v4l2-request-fourier/build-deb.sh has its own
parallel UPSTREAM_COMMIT + PKGVER + PKGREL pin that I missed.
Result: the libva-v4l2-request-fourier-debian CI job ran post-merge,
check-already-published.sh saw the .deb-side filename derived from
build-deb.sh (libva-v4l2-request-fourier_1.0.0+r380+g9898331-1_arm64.deb)
was already in the pool, returned skip=1, and the job short-circuited.
trixie repo Packages still advertises r380 instead of r382.
This bump catches build-deb.sh up to the same pin (c1bb444) so the
next merge triggers the build + reprepro publish path.
No code change beyond the three pinned variables + the comment block.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Upstream PR #1 landed daemon-side synthesis of H.264 SPS/PPS NAL
units from the V4L2 stateless control structs. This bumps the
package pin so both the userspace daemon and the kernel module
pick up the change in lockstep (wire protocol grew a new
DAEDALUS_REQ_FLAG_H264_META bit + struct daedalus_h264_meta —
kernel and daemon MUST match).
Effect on Pi 5 / CM5 hosts (higgs): ffmpeg -hwaccel vaapi against
H.264 sources will actually decode through the daedalus daemon
instead of failing with "non-existing PPS 0 referenced".
Both arch + debian packages: pkgver 0.1.0.r20.3dd0eb0 (count from
git rev-list), pkgrel reset to 1 (new upstream pin).
VP9 / AV1 paths unchanged.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Follow-up to libva PR #7 (merged as 9898331). Without that commit,
H.264/VP9/AV1 profiles never got advertised on Pi 5 mixed deploys
(rpi-hevc-dec primary + daedalus_v4l2 alt) because the profile-
enumeration probe in any_fd_supports_output_format only walked
rkvdec / hantro / rpi-hevc-dec / vpu981 fds. ffmpeg vaapi -i
h264_test.mp4 on higgs bailed with "No support for codec h264
profile 578" before the LIBVA-1 per-codec dispatch could even fire.
9898331 extends the fds[] from 5 to 6 with video_fd_daedalus as
the 6th slot (HAVE_DAEDALUS_V4L2-gated, -1 fallback otherwise).
Effect on higgs once this lands: vainfo lists VP9Profile0 +
AV1Profile0 + H264* alongside HEVCMain, and ffmpeg -hwaccel vaapi
-i h264_test.mp4 routes through the daedalus daemon (via 'd' kind
in request_switch_device_for_profile).
Both packages: pkgver 1.0.0.r380.9898331 (count from rev-list),
pkgrel reset to 1 (new upstream pin). Backward-compatible on
RK3399/3588 — the new fd slot is gated by HAVE_DAEDALUS_V4L2 *and*
video_fd_daedalus >= 0, both false in those deployments.
Companion to the prior LIBVA-{1,ABI} bumps that landed in marfrit-
packages PRs #43, #44. Together they close the Pi 5 stack: boot ->
modules-load.d loads daedalus_v4l2 -> daedalus-v4l2.service starts
daemon -> libva opens both decoders -> ffmpeg -hwaccel vaapi
enumerates all codecs from both -> routes per-codec.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Closes task #134 work.
PR #44 showed the cross-distro ABI hazard for `libva-v4l2-request-fourier-debian`: building on Arch (libva 2.23) produced `__vaDriverInit_1_23`, which trixies libva 2.22 runtime cant bind. Same hazard applies to other fourier-debian jobs that link against debian-native libs.
**Moved from runs-on: arch-aarch64 → debian-aarch64:**
- ffmpeg-v4l2-request-debian
- mpv-fourier-debian
- daedalus-v4l2-debian
- daedalus-v4l2-dkms-debian
**Left alone (arch=all, no native compile against debian libs):**
- lmcp-debian
- claude-his-debian
Depends on PR #46 (label vs name fix) being merged so `debian-aarch64` actually routes to bohr.
Reviewed-on: #47
Two follow-ups to PR #44 (which landed the libva-dev ABI pin):
- `051da5e` switch runs-on from arch-aarch64 → debian-aarch64-bohr
- `5feab57` fix runner label: actrunner-debian-aarch64-bohr (label name mismatch in 051da5e)
**Squash on merge** to keep main history clean.
Co-authored-by: Markus Fritsche <mfritsche@reauktion.de>
Reviewed-on: #45
Co-authored-by: Claude (noether) <claude@reauktion.de>
Co-committed-by: Claude (noether) <claude@reauktion.de>
Claude (noether)
marfrit
claude-noether