marfrit
dbf01eddb8
Toolchain plumbing for the upcoming daedalus-decoder shadow-mode
path. Production behaviour is unchanged.
What lands here:
1. CMake links libdaedalus_decoder via pkg-config. Static archive,
so no .so dependency change in the daemon's link map.
2. ffmpeg_loader resolves ff_h264_set_mb_inspect_cb NULL-tolerantly.
Stock libavcodec lacks the symbol (logged as INFO at startup);
the marfrit-packages ffmpeg-v4l2-request-fourier fork's 0016
patch exports it. The shadow path activates only when both
env DAEDALUS_SHADOW_MODE=1 AND the symbol resolves.
3. New shadow_decoder.[ch] module:
- shadow_decoder_create() gates on env + symbol presence,
returns NULL in production state (the common case).
- shadow_decoder_install_cb() registers a per-MB callback on
the H.264 AVCodecContext; lazily-created daedalus_decoder
context will pick up dimensions from the first AVFrame.
- shadow_decoder_on_frame() logs per-frame MB-observed count.
Every entry point is NULL-safe so decoder.c stays clean of
conditionals.
4. decoder.{c,h} grow a `struct shadow_decoder *shadow` field on
daedalus_decoder. Install hook fires once per H.264 codec open;
frame hook fires after each successful avcodec_receive_frame.
PR-Q3a.1 scope ENDS here. The callback just counts MBs; no
daedalus_decoder_append_mb or flush_frame yet. Real-coeffs / edges
extraction needs the patched FFmpeg source-tree headers
(DAEDALUS_FFMPEG_SRC) to introspect H264Context internals — that
lands in PR-Q3a.2.
dejavu-check: this path is daedalus-decoder's frame-major UMA
dispatch architecture (one cmdbuf per frame, one submit) running
alongside libavcodec's reference decode for validation. It is NOT
per-kernel libavcodec function-pointer substitution. No new
libavcodec patches; the existing 0016 callback is the only intercept
point.
Verified on hertz:
- Build: clean, libdaedalus_decoder.a linked.
- Disabled state (env unset OR symbol absent): no shadow log
lines, daemon init continues normally, INFO logs
"libavcodec lacks ff_h264_set_mb_inspect_cb (stock build,
no daedalus-fourier 0016 patch) — shadow-mode unavailable".
- Enabled state would require ffmpeg-v4l2-request-fourier .deb
rebuilt with patches 0016/0017 deployed to hertz (current .deb
release 10 predates them). That's a deployment task, separate
from this PR.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
daedalus-v4l2
V4L2 stateless decoder for the Raspberry Pi 5 / CM5, backed by the
daedalus-fourier kernel library (VP9 + AV1 CDEF + H.264 video
decode kernels on VideoCore VII compute + ARM NEON).
Status: scaffold (2026-05-18). Architecture locked per daedalus-fourier session memory; implementation not yet begun.
What this is
Sibling repo to daedalus-fourier (the kernel library; cycles 1-9 closed).
A two-piece userspace + kernel-module stack that exposes a V4L2
stateless decoder interface (/dev/videoNN) so that
libva-v4l2-request-fourier → firefox-fourier /
chromium-fourier can drive it the same way they drive existing
hardware-decode pipelines on Pi 5 / RK3588.
+-----------------------------------------------------------+
| firefox-fourier / chromium-fourier (existing) |
+-----------------------------------------------------------+
| VA-API |
+-----------------------------------------------------------+
| libva-v4l2-request-fourier (existing, sibling project) |
+-----------------------------------------------------------+
| V4L2 stateless ioctl uAPI |
+-----------------------------------------------------------+
| daedalus-v4l2 kernel module (`kernel/`) |
| - registers /dev/videoNN |
| - parses V4L2 stateless ioctls (VP9/AV1/H.264 controls) |
| - forwards bitstream + controls to userspace daemon |
| via chardev or netlink |
+-----------------------------------------------------------+
| daedalus-v4l2 userspace daemon (`daemon/`) |
| - takes bitstream blobs + per-slice controls |
| - drives FFmpeg parsers via dlopen (Option γ) |
| - dispatches per-block ops via daedalus-fourier |
| public API (daedalus_dispatch_*) |
| - posts decoded frames back to kernel module |
+-----------------------------------------------------------+
| daedalus-fourier kernel library (sibling project) |
| - exports include/daedalus.h public API |
| - per-kernel CPU NEON + opportunistic V3D QPU dispatch |
| - 9 closed cycles across VP9, AV1 CDEF, H.264 |
+-----------------------------------------------------------+
| V3D 7.1 (Mesa userspace v3dv) + ARM NEON (BCM2712) |
+-----------------------------------------------------------+
Why this architecture (Option B + γ + sibling)
Locked by user 2026-05-18 from 3 options in
daedalus-fourier/docs/phase8_scoping.md:
- Option B over A (userspace v4l2loopback): real
/dev/videoNN, proper DRM PRIME / dmabuf for browser zero-copy. - Option γ: dlopen FFmpeg as parser at runtime. No vendoring, fastest to v1.
- Sibling repo: per
project_consumer_targetconvention, V4L2-side work lives outside daedalus-fourier so the kernel-library has a clean API boundary.
Status
Initial scaffold only. See docs/architecture.md for the
deeper design and docs/roadmap.md for the
sub-phase breakdown.
Repo layout
kernel/— Linux kernel module (V4L2 device registration + ioctl handling + userspace chardev bridge). Out-of-tree.daemon/— userspace decoder daemon (linkslibdaedalus_core.afrom sibling daedalus-fourier; uses dlopen for FFmpeg parser).include/— shared headers between kernel and daemon.docs/— architecture + roadmap.
License
Kernel module: GPLv2 (required for kernel-tree compatibility). Userspace daemon: BSD-2-Clause (matches daedalus-fourier).