reauktion/daedalus-v4l2
2
0
Fork 0
Code Issues 3 Pull Requests Actions Packages Projects Releases Wiki Activity

daemon: dlopen Kwiboo fork's soname 62 (FFmpeg 8.1 at /opt/fourier) #16

Merged
marfrit merged 1 commits from noether/daemon-dlopen-kwiboo-soname62 into main 2026-05-21 19:20:23 +00:00
Conversation 0 Commits 1 Files Changed 1
+24 -7
marfrit commented 2026-05-21 19:19:56 +00:00
Owner
Copy Link
Copy Source

First step on the daedalus-fourier substitution path (#11 step 2 — paths laid out at #11 (comment)).

Switches the daemon's runtime dlopen targets:

was (Debian stock 7.1.3) now (Kwiboo fork 8.1 / /opt/fourier)
libavformat .so.61 .so.62
libavcodec .so.61 .so.62
libavutil .so.59 .so.60

Why

The substitution arc needs daedalus-fourier kernel calls woven into libavcodec's H264DSPContext NEON init (replace ff_h264_idct_add_neon etc. with thunks calling daedalus_recipe_dispatch_h264_*). We can do that via patches in the ffmpeg-v4l2-request-fourier package source — which we own, in marfrit-packages, alongside the existing libudev-bypass and nv15-to-p010 patches. But that package builds the Kwiboo fork at soname 62 / /opt/fourier. The daemon currently dlopens soname 61 (Debian-stock + a separately-built +fourier2 patch that isn't in marfrit-packages source tree), so substitution patches there wouldn't reach the daemon.

Switching to soname 62 routes the daemon through the package we control.

Compat

  • /opt/fourier libs are already on every host running the daemon (hard build-dep of ffmpeg-v4l2-request-fourier). Firefox-fourier and mpv-fourier already dlopen them via the same path.
  • /etc/ld.so.conf.d/fourier.conf resolves the new sonames from /opt/fourier/lib via the ld cache; dlopen-by-soname works without LD_LIBRARY_PATH.
  • Build side: daemon's pkg_check_modules picks up libav*.pc from /opt/fourier/lib/pkgconfig when PKG_CONFIG_PATH includes that dir (build-deb.sh follow-up will set it).
  • API surface unchanged: avcodec_send_packet / receive_frame / AVCodecContext flags / AVFrame fields are stable between FFmpeg 7.1 and 8.1. Verified clean cross-compile on hertz.

Wire protocol

Unchanged. No daedalus-v4l2-dkms bump.

Next PRs (in order)

  1. ffmpeg-v4l2-request-fourier (in marfrit-packages): add patch 0003-daedalus-fourier-substitute-h264-idct4.patch that replaces ff_h264_idct_add_neon in libavcodec/aarch64/h264dsp_init_aarch64.c with a thunk calling daedalus_recipe_dispatch_h264_idct4.
  2. Repeat for IDCT 8×8, deblock luma-v, qpel mc20 — one kernel per PR for reviewability; bench delta + decode_us delta documented per substitution.
  3. marfrit-packages bump pulling daemon + substituted ffmpeg-v4l2-request-fourier together.
First step on the daedalus-fourier substitution path (#11 step 2 — paths laid out at https://git.reauktion.de/reauktion/daedalus-v4l2/issues/11#issuecomment-XXXX). Switches the daemon's runtime dlopen targets: | | was (Debian stock 7.1.3) | now (Kwiboo fork 8.1 / /opt/fourier) | |---|---|---| | libavformat | `.so.61` | `.so.62` | | libavcodec | `.so.61` | `.so.62` | | libavutil | `.so.59` | `.so.60` | ## Why The substitution arc needs daedalus-fourier kernel calls woven into libavcodec's `H264DSPContext` NEON init (replace `ff_h264_idct_add_neon` etc. with thunks calling `daedalus_recipe_dispatch_h264_*`). We can do that via patches in the `ffmpeg-v4l2-request-fourier` package source — which we own, in marfrit-packages, alongside the existing libudev-bypass and nv15-to-p010 patches. But that package builds the Kwiboo fork at soname 62 / /opt/fourier. The daemon currently dlopens soname 61 (Debian-stock + a separately-built `+fourier2` patch that isn't in `marfrit-packages` source tree), so substitution patches there wouldn't reach the daemon. Switching to soname 62 routes the daemon through the package we control. ## Compat - `/opt/fourier` libs are already on every host running the daemon (hard build-dep of `ffmpeg-v4l2-request-fourier`). Firefox-fourier and mpv-fourier already dlopen them via the same path. - `/etc/ld.so.conf.d/fourier.conf` resolves the new sonames from `/opt/fourier/lib` via the ld cache; dlopen-by-soname works without LD_LIBRARY_PATH. - Build side: daemon's `pkg_check_modules` picks up `libav*.pc` from `/opt/fourier/lib/pkgconfig` when `PKG_CONFIG_PATH` includes that dir (`build-deb.sh` follow-up will set it). - API surface unchanged: `avcodec_send_packet` / `receive_frame` / `AVCodecContext` flags / `AVFrame` fields are stable between FFmpeg 7.1 and 8.1. Verified clean cross-compile on hertz. ## Wire protocol Unchanged. No `daedalus-v4l2-dkms` bump. ## Next PRs (in order) 1. `ffmpeg-v4l2-request-fourier` (in marfrit-packages): add patch `0003-daedalus-fourier-substitute-h264-idct4.patch` that replaces `ff_h264_idct_add_neon` in `libavcodec/aarch64/h264dsp_init_aarch64.c` with a thunk calling `daedalus_recipe_dispatch_h264_idct4`. 2. Repeat for IDCT 8×8, deblock luma-v, qpel mc20 — one kernel per PR for reviewability; bench delta + `decode_us` delta documented per substitution. 3. `marfrit-packages` bump pulling daemon + substituted ffmpeg-v4l2-request-fourier together.
marfrit added 1 commit 2026-05-21 19:19:57 +00:00
daemon: dlopen Kwiboo fork's libavcodec.so.62 / libavformat.so.62 / libavutil.so.60 514da29a73 
Switch the daemon's runtime dlopen targets from Debian-stock soname
61/61/59 (FFmpeg 7.1.3) to the Kwiboo fourier fork's soname
62/62/60 (FFmpeg 8.1) installed at the /opt/fourier prefix.

Why
---
The substitution arc tracked at daedalus-v4l2#11 needs daedalus-
fourier kernel calls woven into libavcodec's H264DSPContext NEON
init (replacing ff_h264_idct_add_neon etc. with thunks calling
daedalus_recipe_dispatch_h264_*).  We do that via patches in the
ffmpeg-v4l2-request-fourier package source — which we own, in
marfrit-packages, alongside the existing libudev-bypass and
nv15-to-p010 patches.  But that package builds the Kwiboo fork at
soname 62 / /opt/fourier.  The daemon currently dlopens soname 61
(Debian-stock + a separately-built +fourier2 patch that isn't in
marfrit-packages' source tree), so substitution patches there
wouldn't reach the daemon.

Switching to soname 62 routes the daemon through the package we
control — first step toward landing daedalus-fourier kernel
substitution into the production decode path.

Compat
------
- /opt/fourier libs are already on every host running the daemon
  (hard build-dep of ffmpeg-v4l2-request-fourier).  Firefox-fourier
  and mpv-fourier already dlopen them via the same path.
- /etc/ld.so.conf.d/fourier.conf entry resolves the new sonames
  from /opt/fourier/lib via the ld cache; dlopen-by-soname works
  without LD_LIBRARY_PATH wrappers.
- Build-side: daemon's pkg_check_modules picks up libav*.pc from
  /opt/fourier/lib/pkgconfig when PKG_CONFIG_PATH includes that
  directory (build-deb.sh follow-up will set it).
- API surface unchanged: avcodec_send_packet / receive_frame /
  AVCodecContext flags / AVFrame fields are all stable between
  FFmpeg 7.1 and 8.1.  Verified clean cross-compile on hertz.

Wire protocol unchanged.  No kmod bump.

Next step (follow-up PRs)
-------------------------
1. ffmpeg-v4l2-request-fourier patch: add 0003-daedalus-fourier-
   substitute-h264-idct4.patch that replaces ff_h264_idct_add_neon
   in libavcodec/aarch64/h264dsp_init_aarch64.c with a thunk
   calling daedalus_recipe_dispatch_h264_idct4.
2. Repeat for IDCT 8×8, deblock luma-v, qpel mc20 (one kernel per
   PR for reviewability; bench delta + decode_us delta documented
   per substitution).
3. marfrit-packages bump to pick up the new daemon + the substituted
   fourier package.
marfrit merged commit 6e6dfa144d into main 2026-05-21 19:20:23 +00:00
marfrit deleted branch noether/daemon-dlopen-kwiboo-soname62 2026-05-21 19:20:23 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claude-noether (Claude (noether)) marfrit (Markus Fritsche)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: reauktion/daedalus-v4l2#16
Delete Branch "noether/daemon-dlopen-kwiboo-soname62"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?