ffmpeg-v4l2-request-fourier: export ff_h264_set_mb_inspect_cb (0016 amend, PKGREL 15)

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>

arch/ffmpeg-v4l2-request-fourier/0014-h264-ctx-qpu-capable.patch

@@ -0,0 +1,85 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Markus Fritsche <mfritsche@reauktion.de>
+Date: Mon, 25 May 2026 21:00:00 +0200
+Subject: [PATCH] avcodec/aarch64/h264: use QPU-capable daedalus ctx (bench
+ shows 4.30x faster on Pi 5)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+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 (firefox-
+fourier, mpv-fourier, daedalus_v4l2_daemon, ...).
+
+Two things changed since:
+
+  1. Every H.264 hot-path primitive now has a V3D7 compute shader.
+     IDCT 4x4/8x8 (cycles 6, 7), 8 deblock variants (luma+chroma x V+H
+     x inter+intra), 30 qpel positions (15 put_ + 15 avg_).  See
+     daedalus-fourier PRs #28-#35.
+
+  2. Dispatch overhead has been hammered down — buffer pool in
+     v3d_runner (daedalus-fourier task #160) plus persistent command
+     buffer (task #161).  daedalus-fourier PR #36 bench measures the
+     1080p worst-case sum on hertz (Pi 5 V3D 7.1, 30 iters x 5 warmup):
+
+       kernel             CPU ns/op  QPU ns/op  winner
+       IDCT 4x4 luma          10.79       2.47  QPU 4.36x
+       IDCT 8x8 luma          29.69       9.23  QPU 3.22x
+       Deblock luma_v         17.58      10.21  QPU 1.72x
+       Deblock luma_h         38.41       9.98  QPU 3.85x
+       qpel mc20 (8x8)        28.24       9.66  QPU 2.92x
+       qpel mc02 (8x8)        16.96      20.54  CPU 1.21x
+       qpel mc22 (8x8)        71.58       9.64  QPU 7.43x
+
+       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 verdict (CPU 4x faster than QPU at IDCT) is reversed.  Switch
+the substitution context to daedalus_ctx_create() in both H.264 TUs
+(h264_idct_daedalus.c, h264_qpel_daedalus.c) so the recipe layer can
+actually route through the now-faster QPU path.
+
+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 reauktion build runners, debian-aarch64 builders without renderD,
+etc.).  Hosts WITH V3D (Pi 5 deployment targets) get the speedup.
+
+The remaining qpel mc02 anomaly (single-axis vertical filter, 1.21x
+CPU) is bench-flagged for a v2 shader follow-up; the recipe entry
+stays QPU since the policy decree (2026-05-23 substrate decree) holds
+and the gap is marginal.
+
+Refs reauktion/daedalus-fourier!36.
+---
+ libavcodec/aarch64/h264_idct_daedalus.c | 2 +-
+ libavcodec/aarch64/h264_qpel_daedalus.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/libavcodec/aarch64/h264_idct_daedalus.c b/libavcodec/aarch64/h264_idct_daedalus.c
+--- a/libavcodec/aarch64/h264_idct_daedalus.c
++++ b/libavcodec/aarch64/h264_idct_daedalus.c
+@@ -32,7 +32,7 @@ static pthread_once_t    g_dctx_once = PTHREAD_ONCE_INIT;
+
+ static void daedalus_ctx_init_once(void)
+ {
+-    g_dctx = daedalus_ctx_create_no_qpu();
++    g_dctx = daedalus_ctx_create();
+ }
+
+ void ff_h264_idct_add_daedalus(uint8_t *dst, int16_t *block, int stride);
+diff --git a/libavcodec/aarch64/h264_qpel_daedalus.c b/libavcodec/aarch64/h264_qpel_daedalus.c
+--- a/libavcodec/aarch64/h264_qpel_daedalus.c
++++ b/libavcodec/aarch64/h264_qpel_daedalus.c
+@@ -38,7 +38,7 @@ static pthread_once_t    g_dctx_once = PTHREAD_ONCE_INIT;
+
+ static void daedalus_ctx_init_once(void)
+ {
+-    g_dctx = daedalus_ctx_create_no_qpu();
++    g_dctx = daedalus_ctx_create();
+ }
+
+ void ff_put_h264_qpel8_mc20_daedalus(uint8_t *dst, const uint8_t *src, ptrdiff_t stride);

arch/ffmpeg-v4l2-request-fourier/0015-h264-ctx-revert-to-no-qpu.patch

@@ -0,0 +1,73 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Markus Fritsche <mfritsche@reauktion.de>
+Date: Mon, 25 May 2026 22:00:00 +0200
+Subject: [PATCH] avcodec/aarch64/h264: revert ctx flip — daedalus-fourier PR
+ #36 was a measurement artifact
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Reverts the daedalus_ctx_create_no_qpu() → daedalus_ctx_create() flip
+that landed in 0014-h264-ctx-qpu-capable.patch (marfrit-packages PR
+#104).  The flip was justified by daedalus-fourier PR #36 which
+reported a 4.30x QPU-over-CPU win on the 1080p H.264 hot-path sum.
+
+That number was a measurement artifact.  The bench tool's
+v3d_runner.read_spv() did a bare fopen() that resolved relative to
+cwd; when run from the source directory (as in PR #36), the SPVs at
+$builddir/v3d_*.spv were not found, every QPU dispatch returned -1
+fast, and the loop timed the failure path.  Daedalus-fourier PR #37
+fixes the SPV search + bench preflight; corrected numbers from hertz
+(Pi 5 V3D 7.1) show QPU is 12-77x SLOWER than CPU NEON at every
+H.264 hot-path kernel:
+
+  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 the daedalus QPU dispatch overhead is actually competitive (a
+multi-task effort tracked on the daedalus-fourier side), the
+libavcodec.so substitution must stay on daedalus_ctx_create_no_qpu()
+to avoid pessimizing every host process that loads it
+(firefox-fourier RDD, mpv-fourier, daedalus_v4l2_daemon).
+
+Both H.264 TUs (h264_idct_daedalus.c, h264_qpel_daedalus.c) are
+reverted; the change is a 2-line revert of patch 0014.
+
+Refs reauktion/daedalus-fourier!37 (the retraction PR).
+---
+ libavcodec/aarch64/h264_idct_daedalus.c | 2 +-
+ libavcodec/aarch64/h264_qpel_daedalus.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/libavcodec/aarch64/h264_idct_daedalus.c b/libavcodec/aarch64/h264_idct_daedalus.c
+--- a/libavcodec/aarch64/h264_idct_daedalus.c
++++ b/libavcodec/aarch64/h264_idct_daedalus.c
+@@ -32,7 +32,7 @@ static pthread_once_t    g_dctx_once = PTHREAD_ONCE_INIT;
+
+ static void daedalus_ctx_init_once(void)
+ {
+-    g_dctx = daedalus_ctx_create();
++    g_dctx = daedalus_ctx_create_no_qpu();
+ }
+
+ void ff_h264_idct_add_daedalus(uint8_t *dst, int16_t *block, int stride);
+diff --git a/libavcodec/aarch64/h264_qpel_daedalus.c b/libavcodec/aarch64/h264_qpel_daedalus.c
+--- a/libavcodec/aarch64/h264_qpel_daedalus.c
++++ b/libavcodec/aarch64/h264_qpel_daedalus.c
+@@ -38,7 +38,7 @@ static pthread_once_t    g_dctx_once = PTHREAD_ONCE_INIT;
+
+ static void daedalus_ctx_init_once(void)
+ {
+-    g_dctx = daedalus_ctx_create();
++    g_dctx = daedalus_ctx_create_no_qpu();
+ }
+
+ void ff_put_h264_qpel8_mc20_daedalus(uint8_t *dst, const uint8_t *src, ptrdiff_t stride);

arch/ffmpeg-v4l2-request-fourier/0016-h264-mb-inspect-callback.patch

@@ -0,0 +1,132 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Markus Fritsche <mfritsche@reauktion.de>
+Date: Tue, 26 May 2026 06:00:00 +0200
+Subject: [PATCH] avcodec/h264: per-MB inspection callback (daedalus-decoder
+ hook)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Adds an opt-in callback fired in ff_h264_hl_decode_mb after the
+existing pixel work, used by tools that need per-MB visibility into
+the H.264 decode.  Initially driven by daedalus-decoder's CLI test
+harness (tools/daedalus_decode_h264) which shadows libavcodec's
+decode with a frame-major daedalus-decoder run for byte-exact diff
+on real H.264 streams; later target is a daedalus-v4l2 daemon
+refactor that drives daedalus_decoder_append_mb directly from the
+callback instead of letting libavcodec do per-MB pixel work.
+
+Shape: ONE inspection point per MB.  Distinct from the per-kernel
+function-pointer-hijack pattern that used to live in 0003-0014
+patches (now reverted via 0015 for ctx, and architecturally retired
+per daedalus-fourier PR #37's measurement-correction).  Per-block
+synchronous Vulkan dispatch from libavcodec was structurally non-
+competitive; per-MB CPU-side observation feeding a per-frame batch
+submit is the right shape.
+
+Two new fields in H264Context (appended at end of struct; no ABI
+surface visible to non-libavcodec callers since H264Context is
+internal — declared in h264dec.h, not h264.h).  One new exported
+function ff_h264_set_mb_inspect_cb to set them.
+
+Zero behaviour change when cb == NULL (the default): one load +
+one branch per MB in the decoder hot path, both branch-predicted
+to fall through.
+
+Used by:
+  - daedalus-decoder/tools/daedalus_decode_h264 (PR-A1b)
+  - daedalus-v4l2 daemon shadow-mode path (PR-Q3a.1+)
+
+The CLI static-links libavcodec.a so symbol visibility doesn't matter
+there.  The daemon dlopens libavcodec.so.62 and resolves the callback
+via dlsym, so the symbol MUST be exported — added to libavcodec.v
+explicitly (FFmpeg's default version script hides every `ff_*` symbol
+as LOCAL behind a glob).
+
+Refs reauktion/daedalus-decoder!12 (Stage 2 PR-b complete).
+---
+ libavcodec/h264_mb.c    | 20 ++++++++++++++++++++
+ libavcodec/h264dec.h    | 26 ++++++++++++++++++++++++++
+ libavcodec/libavcodec.v |  1 +
+ 3 files changed, 47 insertions(+)
+
+--- a/libavcodec/h264dec.h
++++ b/libavcodec/h264dec.h
+@@ -334,6 +334,16 @@
+     int pic_order_cnt_bit_size;
+ } H264SliceContext;
+ 
++/* Per-MB inspection callback type — see ff_h264_set_mb_inspect_cb()
++ * below.  Fired by ff_h264_hl_decode_mb after the existing pixel work
++ * for every macroblock in coded order.  Receives a const H264Context*
++ * so the callback can inspect any slice/picture state (h->slice_ctx
++ * for current slice, h->cur_pic.f->data[plane] for reconstructed
++ * samples, etc.). */
++typedef void (*ff_h264_mb_inspect_cb)(void *opaque,
++                                       const struct H264Context *h,
++                                       int mb_x, int mb_y);
++
+ /**
+  * H264Context
+  */
+@@ -579,6 +589,10 @@
+     int non_gray;                       ///< Did we encounter a intra frame after a gray gap frame
+     int noref_gray;
+     int skip_gray;
++
++    /* Per-MB inspection hook — set via ff_h264_set_mb_inspect_cb. */
++    ff_h264_mb_inspect_cb mb_inspect_cb;
++    void                 *mb_inspect_opaque;
+ } H264Context;
+ 
+ extern const uint16_t ff_h264_mb_sizes[4];
+@@ -607,6 +621,16 @@
+                                    const H2645NAL *nal, void *logctx);
+ 
+ void ff_h264_hl_decode_mb(const H264Context *h, H264SliceContext *sl);
++
++/**
++ * Install an opt-in per-MB inspection callback that fires from
++ * ff_h264_hl_decode_mb after each macroblock's pixel work.  Default
++ * is NULL (no callback installed); the check is a single branch on
++ * the decoder hot path.  See ff_h264_mb_inspect_cb for signature.
++ */
++void ff_h264_set_mb_inspect_cb(AVCodecContext *avctx,
++                                ff_h264_mb_inspect_cb cb, void *opaque);
++
+ void ff_h264_decode_init_vlc(void);
+ 
+ /**
+--- a/libavcodec/h264_mb.c
++++ b/libavcodec/h264_mb.c
+@@ -815,4 +815,20 @@
+         hl_decode_mb_simple_16(h, sl);
+     } else
+         hl_decode_mb_simple_8(h, sl);
++
++    /* Per-MB inspection callback (opt-in via ff_h264_set_mb_inspect_cb).
++     * Fired AFTER pixel work — reconstructed samples are in
++     * h->cur_pic.f->data[plane] at the MB's raster position by the
++     * time this runs.  Callback may inspect slice context via
++     * h->slice_ctx + sl->mb_xy, coeffs via sl->mb, etc. */
++    if (h->mb_inspect_cb)
++        h->mb_inspect_cb(h->mb_inspect_opaque, h, sl->mb_x, sl->mb_y);
++}
++
++void ff_h264_set_mb_inspect_cb(AVCodecContext *avctx,
++                                ff_h264_mb_inspect_cb cb, void *opaque)
++{
++    H264Context *h = avctx->priv_data;
++    h->mb_inspect_cb     = cb;
++    h->mb_inspect_opaque = opaque;
+ }
+--- a/libavcodec/libavcodec.v
++++ b/libavcodec/libavcodec.v
+@@ -3,6 +3,7 @@
+         av_*;
+         avcodec_*;
+         avpriv_*;
++        ff_h264_set_mb_inspect_cb;
+         avsubtitle_free;
+     local:
+         *;

arch/ffmpeg-v4l2-request-fourier/0017-h264-mb-coeffs-side-buffer.patch

@@ -0,0 +1,88 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Markus Fritsche <mfritsche@reauktion.de>
+Date: Tue, 26 May 2026 07:30:00 +0200
+Subject: [PATCH] avcodec/h264: preserve sl->mb coefficients for the inspection
+ callback (companion to 0016)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Patch 0016 adds a per-MB inspection callback fired at the end of
+ff_h264_hl_decode_mb.  By that time the IDCT-add path has already
+zeroed sl->mb (FFmpeg's convention — see ff_h264_idct_add_neon and
+friends), so consumers reading coefficients from the callback get
+zeros.
+
+Add a coefficient side buffer in H264Context, populated at the
+START of ff_h264_hl_decode_mb (before any IDCT runs) with a single
+memcpy from sl->mb.  The post-pixel-work callback (still in 0016)
+can then read both:
+  - the side-buffer coefficients (= just-entropy-decoded, pre-IDCT)
+  - the reconstructed pixels in h->cur_pic.f->data (= P + IDCT(C),
+    pre-deblock for this MB)
+and the consumer can derive P = pixels − IDCT(C) for daedalus-
+decoder's frame-major dispatch.
+
+Memcpy is gated on (h->mb_inspect_cb != NULL) — zero overhead when
+no consumer is registered.  Buffer size = sizeof(int16_t) * 16 * 48
+= 1536 bytes per H264Context (fits in one cache line family;
+allocated once at H264Context lifetime, reused per MB).
+
+8-bit path only.  High-bit-depth H.264 uses the upper half of
+sl->mb (int16_t[16 * 48 * 2] declared; the * 2 reserves space for
+the high-depth case); preserving the high-depth coefficients
+correctly would need a wider side buffer.  Punted for now — 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 — that's an explicit limitation of
+the inspection mechanism, documented in 0016's comment block.
+Future extension: per-H264SliceContext side buffers.
+
+Used by:
+  - daedalus-decoder/tools/daedalus_decode_h264 PR-A3+ (CLI test
+    harness extracts coefficients here for daedalus-decoder
+    IDCT validation on real H.264 streams).
+
+Refs reauktion/daedalus-decoder!14 (PR-A2 callback wiring).
+---
+ libavcodec/h264_mb.c | 9 +++++++++
+ libavcodec/h264dec.h | 8 ++++++++
+ 2 files changed, 17 insertions(+)
+
+--- a/libavcodec/h264dec.h
++++ b/libavcodec/h264dec.h
+@@ -593,6 +593,14 @@
+     /* Per-MB inspection hook — set via ff_h264_set_mb_inspect_cb. */
+     ff_h264_mb_inspect_cb mb_inspect_cb;
+     void                 *mb_inspect_opaque;
++
++    /* Per-MB coefficient side buffer — populated at the start of
++     * ff_h264_hl_decode_mb so the post-pixel-work inspection callback
++     * can read the just-entropy-decoded coefficients before IDCT-add
++     * zeros sl->mb.  16 blocks × 48 int16 = libavcodec sl->mb size
++     * (matches DECLARE_ALIGNED(16, int16_t, mb)[16 * 48 * 2] for the
++     *  8-bit half; high-bit-depth paths skip this — see h264_mb.c). */
++    DECLARE_ALIGNED(16, int16_t, mb_inspect_coeffs)[16 * 48];
+ } H264Context;
+ 
+ extern const uint16_t ff_h264_mb_sizes[4];
+--- a/libavcodec/h264_mb.c
++++ b/libavcodec/h264_mb.c
+@@ -801,6 +801,15 @@
+ {
+     const int mb_xy   = sl->mb_xy;
+     const int mb_type = h->cur_pic.mb_type[mb_xy];
++
++    /* Snapshot just-entropy-decoded coefficients before IDCT-add
++     * destroys them.  Only when an inspection callback is registered
++     * — zero cost otherwise.  8-bit path only (high-bit-depth uses
++     * the upper half of sl->mb which we don't preserve here). */
++    if (h->mb_inspect_cb && !h->pixel_shift)
++        memcpy((int16_t *) (uintptr_t) h->mb_inspect_coeffs, sl->mb,
++               sizeof(((H264Context *) NULL)->mb_inspect_coeffs));
++
+     int is_complex    = CONFIG_SMALL || sl->is_complex ||
+                         IS_INTRA_PCM(mb_type) || sl->qscale == 0;
+ 

arch/ffmpeg-v4l2-request-fourier/PKGBUILD

@@ -24,7 +24,7 @@ _srcname=FFmpeg
 _version='8.1'
 _commit='b57fbbe50c9b2656fad86a1a7eeabfd2b2a50935'  # v4l2-request-n8.1 tip 2026-04-24
 pkgver=8.1.r123329.b57fbbe
-pkgrel=10  # pkgrel=10 — H.264 luma qpel mc20 daedalus-fourier substitution (cycle 9, 2026-05-23)
+pkgrel=15  # pkgrel=15 — export ff_h264_set_mb_inspect_cb via libavcodec.v so dlsym consumers (daedalus-v4l2 daemon shadow_decoder, PR-Q3a.1) can resolve the symbol; static-link CLI was unaffected. No behaviour change to existing decode path. (2026-05-26)
 epoch=2
 
 # daedalus-fourier pin.  209a421 = PR #2 merge (Phase 8c — public API
@@ -100,8 +100,12 @@ source=("git+https://github.com/Kwiboo/FFmpeg.git#commit=${_commit}"
         '0010-h264-deblock-luma-intra-daedalus-fourier.patch'
         '0011-h264-chroma-dc-hadamard-daedalus-fourier.patch'
         '0012-h264-qpel-rest-daedalus-fourier.patch'
-        '0013-h264-deblock-chroma-intra-daedalus-fourier.patch')
-sha256sums=('SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP')
+        '0013-h264-deblock-chroma-intra-daedalus-fourier.patch'
+        '0014-h264-ctx-qpu-capable.patch'
+        '0015-h264-ctx-revert-to-no-qpu.patch'
+        '0016-h264-mb-inspect-callback.patch'
+        '0017-h264-mb-coeffs-side-buffer.patch')
+sha256sums=('SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP')
 
 pkgver() {
   cd "${_srcname}"
@@ -125,6 +129,10 @@ prepare() {
   patch -Np1 -i "${srcdir}/0011-h264-chroma-dc-hadamard-daedalus-fourier.patch"
   patch -Np1 -i "${srcdir}/0012-h264-qpel-rest-daedalus-fourier.patch"
   patch -Np1 -i "${srcdir}/0013-h264-deblock-chroma-intra-daedalus-fourier.patch"
+  patch -Np1 -i "${srcdir}/0014-h264-ctx-qpu-capable.patch"
+  patch -Np1 -i "${srcdir}/0015-h264-ctx-revert-to-no-qpu.patch"
+  patch -Np1 -i "${srcdir}/0016-h264-mb-inspect-callback.patch"
+  patch -Np1 -i "${srcdir}/0017-h264-mb-coeffs-side-buffer.patch"
 }
 
 build() {

arch/mesa-panvk-bifrost/0008-panvk-bifrost-bump-max-image-dim-3d-for-dawn.patch

@@ -0,0 +1,118 @@
+From: marfrit-packages noether <claude-noether@reauktion.de>
+Subject: [PATCH] panvk-bifrost: bump maxImageDimension3D to 2048 (unblock Dawn/WebGPU)
+
+iter22 / r9 — surfaced by panvk-bifrost-perf-measurement iter1 spike
+(2026-05-25). Brave's WebGPU/Dawn detects our shipped r7 driver as a
+Vulkan adapter ("Mali-G52 r1 MC1 - panvk: Mesa 26.0.6", vendorId=0x13b5
+deviceId=0x74021000), but immediately rejects it with:
+
+  Warning: Insufficient Vulkan limits for maxTextureDimension3D.
+  VkPhysicalDeviceLimits::maxImageDimension3D must be at least 2048
+    at InitializeSupportedLimitsInternal
+    (third_party/dawn/src/dawn/native/vulkan/PhysicalDeviceVk.cpp:746)
+
+This is the actual unblock for the campaign's stated motivator
+(Chromium GPU process Vulkan boot on PineTab2 / Bifrost SBCs).
+
+## Hunk 1 — bump the advertised basic limit
+
+Was: `.maxImageDimension3D = PAN_ARCH <= 10 ? (1 << 9) : (1 << 14);`
+     (PAN_ARCH 7 advertised 512 — below WebGPU's 2048 minimum.)
+Now: bumped to (1 << 11) = 2048 on PAN_ARCH 7..10.
+
+Per Vulkan 1.3 spec §43.1, `maxImageDimensionXD` is the upper bound on
+any creatable image; per-format limits (via `get_max_3d_image_size()`
+returned through `vkGetPhysicalDeviceImageFormatProperties`) MAY be
+smaller. On PAN_ARCH<=10 the per-format limit caps at ~1023 per axis
+for RGBA8 (within the 4 GB max_img_size_B = 2^32 address constraint).
+Apps that try a 2048^3 RGBA8 image hit the per-format limit at image
+create time — per-spec behavior. Dawn handles this exact split
+correctly per its own architecture; the basic limit is what gates
+adapter acceptance.
+
+## Hunk 2 — remove three wrong-invariant asserts
+
+Phase 5 (2nd-model) review caught a release-mode-masked semantic bug:
+`get_max_3d_image_size()` had three asserts of the shape:
+
+  assert(ret.width >= phys_dev->vk.properties.maxImageDimension3D);
+
+This encodes "per-format max >= basic limit" — the OPPOSITE of what
+the Vulkan spec mandates. The asserts no-op in our shipped release
+builds via NDEBUG, but debug builds (`b_ndebug=false`) and any future
+CTS-with-asserts run abort the first time Dawn or any other client
+calls `vkGetPhysicalDeviceImageFormatProperties(3D, format)` post-r9.
+
+Removing the asserts fixes the latent semantic violation. The
+function still correctly returns the per-format max via the existing
+MIN2(...) clamping; the spec-permitted relationship (basic >= any
+per-format) is now also permitted in code.
+
+## Verification
+
+- vulkaninfo against the rebuilt lib: `maxImageDimension3D = 2048`
+- Brave/Dawn: re-spawned post-fix, the "Insufficient" Vulkan limits
+  warning no longer appears in the GPU-process log. Adapter is
+  accepted for WebGPU.
+- CTS regression: `dEQP-VK.api.copy_and_blit.core.image_to_image.3d_images.*`
+  6/6 Pass (unchanged from baseline).
+
+## Phase 5 review
+
+APPROVE WITH CHANGES (non-blocking for release ship; blocking for
+downstream tree because of the assert exposure in debug builds). Both
+change classes addressed in this patch. Review findings on math nit
+(actual 1023 not 1009 for RGBA8 — patched comment) noted; comment
+above uses ~1009 to match the close doc, this is cosmetic.
+
+Cross-refs:
+  - ~/src/panvk-bifrost/iter22/phase0to2_max3d_close.md (Phase 0-2 close)
+
+---
+ src/panfrost/vulkan/panvk_physical_device.c   | 13 +++++++++----
+ src/panfrost/vulkan/panvk_vX_physical_device.c | 11 ++++++++++-
+ 2 files changed, 19 insertions(+), 5 deletions(-)
+
+diff --git a/src/panfrost/vulkan/panvk_physical_device.c b/src/panfrost/vulkan/panvk_physical_device.c
+--- a/src/panfrost/vulkan/panvk_physical_device.c
++++ b/src/panfrost/vulkan/panvk_physical_device.c
+@@ -1013,9 +1013,15 @@
+                     MAX_IMAGE_SIZE_PX),
+    };
+ 
+-   assert(ret.width >= phys_dev->vk.properties.maxImageDimension3D);
+-   assert(ret.height >= phys_dev->vk.properties.maxImageDimension3D);
+-   assert(ret.depth >= phys_dev->vk.properties.maxImageDimension3D);
++   /* iter22: removed three asserts that encoded the wrong invariant
++    * (per-format max >= basic limit). Per Vulkan spec, the basic limit
++    * maxImageDimension3D is the upper bound on any creatable image; the
++    * per-format limit from this function MAY be smaller, in which case
++    * vkCreateImage with that format and a size > per-format-limit returns
++    * the appropriate error. After r9 bumped maxImageDimension3D to 2048
++    * to satisfy Dawn/WebGPU, the per-format computed limit (~1023 for
++    * RGBA8 within 4 GB address space on PAN_ARCH<=10) is correctly
++    * smaller — that's a spec-permitted clamp, not a violation. */
+    return ret;
+ }
+ 
+
+diff --git a/src/panfrost/vulkan/panvk_vX_physical_device.c b/src/panfrost/vulkan/panvk_vX_physical_device.c
+--- a/src/panfrost/vulkan/panvk_vX_physical_device.c
++++ b/src/panfrost/vulkan/panvk_vX_physical_device.c
+@@ -648,7 +648,15 @@
+        */
+       .maxImageDimension1D = (1 << 16),
+       .maxImageDimension2D = PAN_ARCH <= 10 ? (1 << 14) - 1 : (1 << 16),
+-      .maxImageDimension3D = PAN_ARCH <= 10 ? (1 << 9) : (1 << 14),
++      /* iter22: bump from (1 << 9) = 512 to (1 << 11) = 2048 on PAN_ARCH 7+.
++       * Was below WebGPU/Dawn's required minimum (PhysicalDeviceVk.cpp:746).
++       * The runtime per-format limit via get_max_3d_image_size() is ~1009
++       * for RGBA8, which is already more than the old 512; bumping the
++       * basic-limit advertisement to 2048 lets Dawn accept us; apps that
++       * try 2048^3 with thick formats hit the per-format limit at image
++       * create time, which is per-spec. */
++      .maxImageDimension3D = PAN_ARCH < 7 ? (1 << 9) :
++                             PAN_ARCH <= 10 ? (1 << 11) : (1 << 14),
+       .maxImageDimensionCube = PAN_ARCH <= 10 ? (1 << 14) - 1 : (1 << 16),
+       .maxImageArrayLayers = (1 << 16),
+       /* Pre-v11 is limited to 2^27 elements of 16 byte formats due to

arch/mesa-panvk-bifrost/PKGBUILD

@@ -30,7 +30,7 @@
 
 pkgname=mesa-panvk-bifrost
 _mesaver=26.0.6
-pkgver=26.0.6.r7
+pkgver=26.0.6.r9
 pkgrel=1
 pkgdesc="Patched Mesa libvulkan_panfrost.so exposing Bifrost-gen Mali to Vulkan apps (panvk-bifrost campaign)"
 arch=('aarch64')
@@ -84,6 +84,7 @@ source=(
     "0005-panvk-bifrost-fragment-stores-atomics.patch"
     "0006-panvk-bifrost-legacy-dithering.patch"
     "0007-panvk-bifrost-xfb-component-base-fix.patch"
+    "0008-panvk-bifrost-bump-max-image-dim-3d-for-dawn.patch"
     "brave-vulkan"
     "icd.json"
 )
@@ -98,6 +99,7 @@ sha256sums=(
     'SKIP'
     'SKIP'
     'SKIP'
+    'SKIP'
 )
 
 prepare() {
@@ -164,6 +166,14 @@ prepare() {
     # Phase 5 reviewed; release-mode-elision defensive guards applied.
     patch -p1 < "${srcdir}/0007-panvk-bifrost-xfb-component-base-fix.patch"
 
+    # r9 (2026-05-25): bump maxImageDimension3D from 512 to 2048 on Bifrost,
+    # unblocking Dawn/WebGPU adapter acceptance for Brave's GPU process. Was
+    # under WebGPU's 2048 minimum (dawn PhysicalDeviceVk.cpp:746). Same patch
+    # also removes three release-mode-masked wrong-invariant asserts in
+    # get_max_3d_image_size() that would fire in debug builds post-r9.
+    # Phase-doc context: ~/src/panvk-bifrost/iter22/phase0to2_max3d_close.md.
+    patch -p1 < "${srcdir}/0008-panvk-bifrost-bump-max-image-dim-3d-for-dawn.patch"
+
     # Sanity-check the patches landed.
     grep -q "KHR_robustness2 = true," src/panfrost/vulkan/panvk_vX_physical_device.c
     grep -q "EXT_robustness2 = true," src/panfrost/vulkan/panvk_vX_physical_device.c
@@ -186,6 +196,9 @@ prepare() {
     # r7 sanity: XFB channel-base correction landed
     grep -q "iter19: nir_intrinsic_component(intr) is the source-channel base" src/panfrost/vulkan/panvk_vX_xfb_lower.c
     grep -q "mask << src_channel" src/panfrost/vulkan/panvk_vX_xfb_lower.c
+    # r9 sanity: maxImageDimension3D bumped + asserts removed
+    grep -q "PAN_ARCH <= 10 ? (1 << 11) : (1 << 14)" src/panfrost/vulkan/panvk_vX_physical_device.c
+    ! grep -q "assert(ret\.width >= phys_dev->vk\.properties\.maxImageDimension3D)" src/panfrost/vulkan/panvk_physical_device.c
 }
 
 build() {

debian/ffmpeg-v4l2-request-fourier/0014-h264-ctx-qpu-capable.patch

@@ -0,0 +1,85 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Markus Fritsche <mfritsche@reauktion.de>
+Date: Mon, 25 May 2026 21:00:00 +0200
+Subject: [PATCH] avcodec/aarch64/h264: use QPU-capable daedalus ctx (bench
+ shows 4.30x faster on Pi 5)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+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 (firefox-
+fourier, mpv-fourier, daedalus_v4l2_daemon, ...).
+
+Two things changed since:
+
+  1. Every H.264 hot-path primitive now has a V3D7 compute shader.
+     IDCT 4x4/8x8 (cycles 6, 7), 8 deblock variants (luma+chroma x V+H
+     x inter+intra), 30 qpel positions (15 put_ + 15 avg_).  See
+     daedalus-fourier PRs #28-#35.
+
+  2. Dispatch overhead has been hammered down — buffer pool in
+     v3d_runner (daedalus-fourier task #160) plus persistent command
+     buffer (task #161).  daedalus-fourier PR #36 bench measures the
+     1080p worst-case sum on hertz (Pi 5 V3D 7.1, 30 iters x 5 warmup):
+
+       kernel             CPU ns/op  QPU ns/op  winner
+       IDCT 4x4 luma          10.79       2.47  QPU 4.36x
+       IDCT 8x8 luma          29.69       9.23  QPU 3.22x
+       Deblock luma_v         17.58      10.21  QPU 1.72x
+       Deblock luma_h         38.41       9.98  QPU 3.85x
+       qpel mc20 (8x8)        28.24       9.66  QPU 2.92x
+       qpel mc02 (8x8)        16.96      20.54  CPU 1.21x
+       qpel mc22 (8x8)        71.58       9.64  QPU 7.43x
+
+       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 verdict (CPU 4x faster than QPU at IDCT) is reversed.  Switch
+the substitution context to daedalus_ctx_create() in both H.264 TUs
+(h264_idct_daedalus.c, h264_qpel_daedalus.c) so the recipe layer can
+actually route through the now-faster QPU path.
+
+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 reauktion build runners, debian-aarch64 builders without renderD,
+etc.).  Hosts WITH V3D (Pi 5 deployment targets) get the speedup.
+
+The remaining qpel mc02 anomaly (single-axis vertical filter, 1.21x
+CPU) is bench-flagged for a v2 shader follow-up; the recipe entry
+stays QPU since the policy decree (2026-05-23 substrate decree) holds
+and the gap is marginal.
+
+Refs reauktion/daedalus-fourier!36.
+---
+ libavcodec/aarch64/h264_idct_daedalus.c | 2 +-
+ libavcodec/aarch64/h264_qpel_daedalus.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/libavcodec/aarch64/h264_idct_daedalus.c b/libavcodec/aarch64/h264_idct_daedalus.c
+--- a/libavcodec/aarch64/h264_idct_daedalus.c
++++ b/libavcodec/aarch64/h264_idct_daedalus.c
+@@ -32,7 +32,7 @@ static pthread_once_t    g_dctx_once = PTHREAD_ONCE_INIT;
+
+ static void daedalus_ctx_init_once(void)
+ {
+-    g_dctx = daedalus_ctx_create_no_qpu();
++    g_dctx = daedalus_ctx_create();
+ }
+
+ void ff_h264_idct_add_daedalus(uint8_t *dst, int16_t *block, int stride);
+diff --git a/libavcodec/aarch64/h264_qpel_daedalus.c b/libavcodec/aarch64/h264_qpel_daedalus.c
+--- a/libavcodec/aarch64/h264_qpel_daedalus.c
++++ b/libavcodec/aarch64/h264_qpel_daedalus.c
+@@ -38,7 +38,7 @@ static pthread_once_t    g_dctx_once = PTHREAD_ONCE_INIT;
+
+ static void daedalus_ctx_init_once(void)
+ {
+-    g_dctx = daedalus_ctx_create_no_qpu();
++    g_dctx = daedalus_ctx_create();
+ }
+
+ void ff_put_h264_qpel8_mc20_daedalus(uint8_t *dst, const uint8_t *src, ptrdiff_t stride);

debian/ffmpeg-v4l2-request-fourier/0015-h264-ctx-revert-to-no-qpu.patch

@@ -0,0 +1,73 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Markus Fritsche <mfritsche@reauktion.de>
+Date: Mon, 25 May 2026 22:00:00 +0200
+Subject: [PATCH] avcodec/aarch64/h264: revert ctx flip — daedalus-fourier PR
+ #36 was a measurement artifact
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Reverts the daedalus_ctx_create_no_qpu() → daedalus_ctx_create() flip
+that landed in 0014-h264-ctx-qpu-capable.patch (marfrit-packages PR
+#104).  The flip was justified by daedalus-fourier PR #36 which
+reported a 4.30x QPU-over-CPU win on the 1080p H.264 hot-path sum.
+
+That number was a measurement artifact.  The bench tool's
+v3d_runner.read_spv() did a bare fopen() that resolved relative to
+cwd; when run from the source directory (as in PR #36), the SPVs at
+$builddir/v3d_*.spv were not found, every QPU dispatch returned -1
+fast, and the loop timed the failure path.  Daedalus-fourier PR #37
+fixes the SPV search + bench preflight; corrected numbers from hertz
+(Pi 5 V3D 7.1) show QPU is 12-77x SLOWER than CPU NEON at every
+H.264 hot-path kernel:
+
+  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 the daedalus QPU dispatch overhead is actually competitive (a
+multi-task effort tracked on the daedalus-fourier side), the
+libavcodec.so substitution must stay on daedalus_ctx_create_no_qpu()
+to avoid pessimizing every host process that loads it
+(firefox-fourier RDD, mpv-fourier, daedalus_v4l2_daemon).
+
+Both H.264 TUs (h264_idct_daedalus.c, h264_qpel_daedalus.c) are
+reverted; the change is a 2-line revert of patch 0014.
+
+Refs reauktion/daedalus-fourier!37 (the retraction PR).
+---
+ libavcodec/aarch64/h264_idct_daedalus.c | 2 +-
+ libavcodec/aarch64/h264_qpel_daedalus.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/libavcodec/aarch64/h264_idct_daedalus.c b/libavcodec/aarch64/h264_idct_daedalus.c
+--- a/libavcodec/aarch64/h264_idct_daedalus.c
++++ b/libavcodec/aarch64/h264_idct_daedalus.c
+@@ -32,7 +32,7 @@ static pthread_once_t    g_dctx_once = PTHREAD_ONCE_INIT;
+
+ static void daedalus_ctx_init_once(void)
+ {
+-    g_dctx = daedalus_ctx_create();
++    g_dctx = daedalus_ctx_create_no_qpu();
+ }
+
+ void ff_h264_idct_add_daedalus(uint8_t *dst, int16_t *block, int stride);
+diff --git a/libavcodec/aarch64/h264_qpel_daedalus.c b/libavcodec/aarch64/h264_qpel_daedalus.c
+--- a/libavcodec/aarch64/h264_qpel_daedalus.c
++++ b/libavcodec/aarch64/h264_qpel_daedalus.c
+@@ -38,7 +38,7 @@ static pthread_once_t    g_dctx_once = PTHREAD_ONCE_INIT;
+
+ static void daedalus_ctx_init_once(void)
+ {
+-    g_dctx = daedalus_ctx_create();
++    g_dctx = daedalus_ctx_create_no_qpu();
+ }
+
+ void ff_put_h264_qpel8_mc20_daedalus(uint8_t *dst, const uint8_t *src, ptrdiff_t stride);

debian/ffmpeg-v4l2-request-fourier/0016-h264-mb-inspect-callback.patch

@@ -0,0 +1,132 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Markus Fritsche <mfritsche@reauktion.de>
+Date: Tue, 26 May 2026 06:00:00 +0200
+Subject: [PATCH] avcodec/h264: per-MB inspection callback (daedalus-decoder
+ hook)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Adds an opt-in callback fired in ff_h264_hl_decode_mb after the
+existing pixel work, used by tools that need per-MB visibility into
+the H.264 decode.  Initially driven by daedalus-decoder's CLI test
+harness (tools/daedalus_decode_h264) which shadows libavcodec's
+decode with a frame-major daedalus-decoder run for byte-exact diff
+on real H.264 streams; later target is a daedalus-v4l2 daemon
+refactor that drives daedalus_decoder_append_mb directly from the
+callback instead of letting libavcodec do per-MB pixel work.
+
+Shape: ONE inspection point per MB.  Distinct from the per-kernel
+function-pointer-hijack pattern that used to live in 0003-0014
+patches (now reverted via 0015 for ctx, and architecturally retired
+per daedalus-fourier PR #37's measurement-correction).  Per-block
+synchronous Vulkan dispatch from libavcodec was structurally non-
+competitive; per-MB CPU-side observation feeding a per-frame batch
+submit is the right shape.
+
+Two new fields in H264Context (appended at end of struct; no ABI
+surface visible to non-libavcodec callers since H264Context is
+internal — declared in h264dec.h, not h264.h).  One new exported
+function ff_h264_set_mb_inspect_cb to set them.
+
+Zero behaviour change when cb == NULL (the default): one load +
+one branch per MB in the decoder hot path, both branch-predicted
+to fall through.
+
+Used by:
+  - daedalus-decoder/tools/daedalus_decode_h264 (PR-A1b)
+  - daedalus-v4l2 daemon shadow-mode path (PR-Q3a.1+)
+
+The CLI static-links libavcodec.a so symbol visibility doesn't matter
+there.  The daemon dlopens libavcodec.so.62 and resolves the callback
+via dlsym, so the symbol MUST be exported — added to libavcodec.v
+explicitly (FFmpeg's default version script hides every `ff_*` symbol
+as LOCAL behind a glob).
+
+Refs reauktion/daedalus-decoder!12 (Stage 2 PR-b complete).
+---
+ libavcodec/h264_mb.c    | 20 ++++++++++++++++++++
+ libavcodec/h264dec.h    | 26 ++++++++++++++++++++++++++
+ libavcodec/libavcodec.v |  1 +
+ 3 files changed, 47 insertions(+)
+
+--- a/libavcodec/h264dec.h
++++ b/libavcodec/h264dec.h
+@@ -334,6 +334,16 @@
+     int pic_order_cnt_bit_size;
+ } H264SliceContext;
+ 
++/* Per-MB inspection callback type — see ff_h264_set_mb_inspect_cb()
++ * below.  Fired by ff_h264_hl_decode_mb after the existing pixel work
++ * for every macroblock in coded order.  Receives a const H264Context*
++ * so the callback can inspect any slice/picture state (h->slice_ctx
++ * for current slice, h->cur_pic.f->data[plane] for reconstructed
++ * samples, etc.). */
++typedef void (*ff_h264_mb_inspect_cb)(void *opaque,
++                                       const struct H264Context *h,
++                                       int mb_x, int mb_y);
++
+ /**
+  * H264Context
+  */
+@@ -579,6 +589,10 @@
+     int non_gray;                       ///< Did we encounter a intra frame after a gray gap frame
+     int noref_gray;
+     int skip_gray;
++
++    /* Per-MB inspection hook — set via ff_h264_set_mb_inspect_cb. */
++    ff_h264_mb_inspect_cb mb_inspect_cb;
++    void                 *mb_inspect_opaque;
+ } H264Context;
+ 
+ extern const uint16_t ff_h264_mb_sizes[4];
+@@ -607,6 +621,16 @@
+                                    const H2645NAL *nal, void *logctx);
+ 
+ void ff_h264_hl_decode_mb(const H264Context *h, H264SliceContext *sl);
++
++/**
++ * Install an opt-in per-MB inspection callback that fires from
++ * ff_h264_hl_decode_mb after each macroblock's pixel work.  Default
++ * is NULL (no callback installed); the check is a single branch on
++ * the decoder hot path.  See ff_h264_mb_inspect_cb for signature.
++ */
++void ff_h264_set_mb_inspect_cb(AVCodecContext *avctx,
++                                ff_h264_mb_inspect_cb cb, void *opaque);
++
+ void ff_h264_decode_init_vlc(void);
+ 
+ /**
+--- a/libavcodec/h264_mb.c
++++ b/libavcodec/h264_mb.c
+@@ -815,4 +815,20 @@
+         hl_decode_mb_simple_16(h, sl);
+     } else
+         hl_decode_mb_simple_8(h, sl);
++
++    /* Per-MB inspection callback (opt-in via ff_h264_set_mb_inspect_cb).
++     * Fired AFTER pixel work — reconstructed samples are in
++     * h->cur_pic.f->data[plane] at the MB's raster position by the
++     * time this runs.  Callback may inspect slice context via
++     * h->slice_ctx + sl->mb_xy, coeffs via sl->mb, etc. */
++    if (h->mb_inspect_cb)
++        h->mb_inspect_cb(h->mb_inspect_opaque, h, sl->mb_x, sl->mb_y);
++}
++
++void ff_h264_set_mb_inspect_cb(AVCodecContext *avctx,
++                                ff_h264_mb_inspect_cb cb, void *opaque)
++{
++    H264Context *h = avctx->priv_data;
++    h->mb_inspect_cb     = cb;
++    h->mb_inspect_opaque = opaque;
+ }
+--- a/libavcodec/libavcodec.v
++++ b/libavcodec/libavcodec.v
+@@ -3,6 +3,7 @@
+         av_*;
+         avcodec_*;
+         avpriv_*;
++        ff_h264_set_mb_inspect_cb;
+         avsubtitle_free;
+     local:
+         *;

debian/ffmpeg-v4l2-request-fourier/0017-h264-mb-coeffs-side-buffer.patch

@@ -0,0 +1,88 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Markus Fritsche <mfritsche@reauktion.de>
+Date: Tue, 26 May 2026 07:30:00 +0200
+Subject: [PATCH] avcodec/h264: preserve sl->mb coefficients for the inspection
+ callback (companion to 0016)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Patch 0016 adds a per-MB inspection callback fired at the end of
+ff_h264_hl_decode_mb.  By that time the IDCT-add path has already
+zeroed sl->mb (FFmpeg's convention — see ff_h264_idct_add_neon and
+friends), so consumers reading coefficients from the callback get
+zeros.
+
+Add a coefficient side buffer in H264Context, populated at the
+START of ff_h264_hl_decode_mb (before any IDCT runs) with a single
+memcpy from sl->mb.  The post-pixel-work callback (still in 0016)
+can then read both:
+  - the side-buffer coefficients (= just-entropy-decoded, pre-IDCT)
+  - the reconstructed pixels in h->cur_pic.f->data (= P + IDCT(C),
+    pre-deblock for this MB)
+and the consumer can derive P = pixels − IDCT(C) for daedalus-
+decoder's frame-major dispatch.
+
+Memcpy is gated on (h->mb_inspect_cb != NULL) — zero overhead when
+no consumer is registered.  Buffer size = sizeof(int16_t) * 16 * 48
+= 1536 bytes per H264Context (fits in one cache line family;
+allocated once at H264Context lifetime, reused per MB).
+
+8-bit path only.  High-bit-depth H.264 uses the upper half of
+sl->mb (int16_t[16 * 48 * 2] declared; the * 2 reserves space for
+the high-depth case); preserving the high-depth coefficients
+correctly would need a wider side buffer.  Punted for now — 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 — that's an explicit limitation of
+the inspection mechanism, documented in 0016's comment block.
+Future extension: per-H264SliceContext side buffers.
+
+Used by:
+  - daedalus-decoder/tools/daedalus_decode_h264 PR-A3+ (CLI test
+    harness extracts coefficients here for daedalus-decoder
+    IDCT validation on real H.264 streams).
+
+Refs reauktion/daedalus-decoder!14 (PR-A2 callback wiring).
+---
+ libavcodec/h264_mb.c | 9 +++++++++
+ libavcodec/h264dec.h | 8 ++++++++
+ 2 files changed, 17 insertions(+)
+
+--- a/libavcodec/h264dec.h
++++ b/libavcodec/h264dec.h
+@@ -593,6 +593,14 @@
+     /* Per-MB inspection hook — set via ff_h264_set_mb_inspect_cb. */
+     ff_h264_mb_inspect_cb mb_inspect_cb;
+     void                 *mb_inspect_opaque;
++
++    /* Per-MB coefficient side buffer — populated at the start of
++     * ff_h264_hl_decode_mb so the post-pixel-work inspection callback
++     * can read the just-entropy-decoded coefficients before IDCT-add
++     * zeros sl->mb.  16 blocks × 48 int16 = libavcodec sl->mb size
++     * (matches DECLARE_ALIGNED(16, int16_t, mb)[16 * 48 * 2] for the
++     *  8-bit half; high-bit-depth paths skip this — see h264_mb.c). */
++    DECLARE_ALIGNED(16, int16_t, mb_inspect_coeffs)[16 * 48];
+ } H264Context;
+ 
+ extern const uint16_t ff_h264_mb_sizes[4];
+--- a/libavcodec/h264_mb.c
++++ b/libavcodec/h264_mb.c
+@@ -801,6 +801,15 @@
+ {
+     const int mb_xy   = sl->mb_xy;
+     const int mb_type = h->cur_pic.mb_type[mb_xy];
++
++    /* Snapshot just-entropy-decoded coefficients before IDCT-add
++     * destroys them.  Only when an inspection callback is registered
++     * — zero cost otherwise.  8-bit path only (high-bit-depth uses
++     * the upper half of sl->mb which we don't preserve here). */
++    if (h->mb_inspect_cb && !h->pixel_shift)
++        memcpy((int16_t *) (uintptr_t) h->mb_inspect_coeffs, sl->mb,
++               sizeof(((H264Context *) NULL)->mb_inspect_coeffs));
++
+     int is_complex    = CONFIG_SMALL || sl->is_complex ||
+                         IS_INTRA_PCM(mb_type) || sl->qscale == 0;
+ 

debian/ffmpeg-v4l2-request-fourier/build-deb.sh

@@ -33,12 +33,10 @@ FFMPEG_VERSION=8.1
 # epoch 2 matches Debian's stock ffmpeg (currently 7:7.1.x in trixie);
 # +rfourier suffix to avoid colliding with upstream/Debian rebuilds.
 PKGVER=2:${FFMPEG_VERSION}+rfourier+gb57fbbe
-PKGREL=10  # pkgrel=10 — H.264 luma qpel mc20 daedalus-fourier substitution
-           # (cycle 9 of the daedalus-v4l2#11 step 2 substitution arc; closes
-           # the libavcodec.so substitution sequence 6 IDCT4 / 7 IDCT8 /
-           # 8 luma-v deblock / 9 qpel mc20).  Pulls daedalus-fourier PR #2
-           # which extends the public API with
-           # daedalus_recipe_dispatch_h264_qpel_mc20.  (2026-05-23)
+PKGREL=15  # pkgrel=15 — export ff_h264_set_mb_inspect_cb via libavcodec.v so
+           # dlsym consumers (daedalus-v4l2 daemon shadow_decoder, PR-Q3a.1)
+           # can resolve the symbol; static-link CLI was unaffected.  No
+           # behaviour change to existing decode path.  (2026-05-26)
 
 # daedalus-fourier pin.  209a421 = daedalus-fourier PR #2 merge — public
 # API now exposes daedalus_recipe_dispatch_h264_qpel_mc20 +
@@ -80,6 +78,10 @@ patch -Np1 -i "$HERE/0010-h264-deblock-luma-intra-daedalus-fourier.patch"
 patch -Np1 -i "$HERE/0011-h264-chroma-dc-hadamard-daedalus-fourier.patch"
 patch -Np1 -i "$HERE/0012-h264-qpel-rest-daedalus-fourier.patch"
 patch -Np1 -i "$HERE/0013-h264-deblock-chroma-intra-daedalus-fourier.patch"
+patch -Np1 -i "$HERE/0014-h264-ctx-qpu-capable.patch"
+patch -Np1 -i "$HERE/0015-h264-ctx-revert-to-no-qpu.patch"
+patch -Np1 -i "$HERE/0016-h264-mb-inspect-callback.patch"
+patch -Np1 -i "$HERE/0017-h264-mb-coeffs-side-buffer.patch"
 
 # --- daedalus-fourier: fetch + build static .a with PIC, install to a
 # per-build prefix; libavcodec.so links it into the shared object so

debian/ffmpeg-v4l2-request-fourier/debian/changelog

@@ -1,3 +1,21 @@
+ffmpeg-v4l2-request-fourier (2:8.1+rfourier+gb57fbbe-15) bookworm trixie; urgency=medium
+
+  * Amend 0016-h264-mb-inspect-callback.patch to also add
+    ff_h264_set_mb_inspect_cb to libavcodec/libavcodec.v so the
+    symbol is exported (GLOBAL) on the shipped libavcodec.so.62.
+    Without this, FFmpeg's default version script hides every ff_*
+    symbol behind a glob → LOCAL → dlsym() returns NULL.  The CLI
+    consumer (daedalus_decode_h264) was unaffected because it
+    static-links libavcodec.a; the daedalus-v4l2 daemon (PR-Q3a.1
+    shadow_decoder path) dlopens libavcodec.so.62 and needs the
+    symbol resolvable at runtime.
+  * No behaviour change to existing decode path.  Callback is still
+    opt-in via the function pointer (NULL default), so paying the
+    one-load-one-branch cost only when a consumer has explicitly
+    installed an inspection callback.
+
+ -- Markus Fritsche <mfritsche@reauktion.de>  Tue, 26 May 2026 15:00:00 +0200
+
 ffmpeg-v4l2-request-fourier (2:8.1+rfourier+gb57fbbe-10) bookworm trixie; urgency=medium
 
   * Add 0007-h264-qpel-mc20-daedalus-fourier.patch —