ffmpeg-v4l2-request-fourier: substitute H.264 IDCT 8×8 → daedalus-fourier #85
Reference in New Issue
Block a user
Delete Branch "claude-noether/marfrit-packages:noether/ffmpeg-fourier-idct8-daedalus"
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?
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_idct8instead offf_h264_idct8_add_neon.What
0004-h264-idct8-daedalus-fourier.patch(in both arch/ and debian/ ffmpeg-v4l2-request-fourier/). Extendslibavcodec/aarch64/h264_idct_daedalus.c(introduced by 0003) withff_h264_idct8_add_daedalusand adaedalus_recipe_dispatch_h264_idct8call; patcheslibavcodec/aarch64/h264dsp_init_aarch64.cto wirec->idct8_addto the new shim.arch/PKGBUILD+debian/build-deb.sh: append the new patch to the apply list; bump pkgrel/PKGREL to 7.d87239dpin already exposesdaedalus_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 (post-PR #78): 3040 frames decoded cleanly, avg_decode_us=3388 µs vs the pre-substitution ~4 ms baseline → no regression. 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 storageblock[r + 8*c]matches daedalus column-major convention).Scope NOT covered (deferred)
c->idct8_add4(inter 8×8-DCT macroblocks) stays on the in-tree NEON .S code; batched substitution withn_blocks>1lands later alongside the cycle-6 bulk-paths work.SONAME
Unchanged. libavcodec.so.62 / libavformat.so.62 / libavutil.so.60.
Refs