claude-noether
234a103084
Force libavcodec's H.264 decoder to emit frames in DECODE order (one frame per send_packet, no internal display-order reorder queue). Single-line addition: ctx->flags |= AV_CODEC_FLAG_LOW_DELAY before avcodec_open2, gated on codec_id == DAEDALUS_CODEC_H264. Closes daedalus-v4l2#11 part (2). Background ---------- PR #7's "parking design" approach to the H.264 display-reorder problem broke libva-v4l2-request-fourier's 1:1 CAPTURE-completion contract (see #9 + #10). After the revert, the visible "2 1 4 3" pair-swap regressed and the only path forward was to align the daemon's output ordering with what V4L2 stateless clients expect: **decode order, one CAPTURE buffer per OUTPUT slice, with display reorder pushed upstream to ffmpeg-vaapi's per-VAAPI-surface POC logic** (which it already does correctly for every real H.264 hardware decoder via VAPictureParameterBufferH264). How LOW_DELAY does this ----------------------- Inside libavcodec/h264dec.c, the flag sets h->low_delay = 1. h264_select_output_frame (h264_picture.c) emits the just-decoded picture immediately instead of routing through the display-order DPB output queue. DPB management for reference frames (short_ref / long_ref) is unaffected — B-frame decoding correctness is preserved; only the output buffering is bypassed. Skipped for VP9 / AV1 — those codecs don't reorder internally, so the flag would be a no-op but adds no value. Verified -------- On higgs (Pi CM5, 6.18.29+rpt-rpi-2712), test daemon hot-swapped into /usr/bin/daedalus_v4l2_daemon, mpv --hwdec=vaapi-copy --frames=300 against bbb_720p_h264.mp4: 311 REQ_DECODEs received, 308 successful "decoder: OK" responses (99.04% steady-state delivery — 3 lost at GOP boundaries, no compounding drift). mpv plays to its --frames cap and exits cleanly with "End of file". No "Unable to dequeue buffer", no "Failed to end picture decode", no "AVHWFramesContext: Failed to sync surface" — all the failures from #9 are gone. Builds clean against ffmpeg-v4l2-request-fourier libavcodec.
daemon/ — daedalus-v4l2 userspace decoder daemon
Userspace daemon that:
- Connects to the kernel module's chardev
- Receives bitstream + V4L2 control blobs
- Parses bitstream via dlopen'd FFmpeg
- Dispatches per-block work via
daedalus_dispatch_*from siblingdaedalus-fourier - Returns decoded frames to kernel
Status
Scaffold only. Phase 8.3 not yet started.
Build dependencies (planned)
- libdaedalus_core.a from sibling daedalus-fourier (static link)
- FFmpeg dev headers (for AVPacket/AVCodec interface types) + runtime FFmpeg .so (loaded via dlopen)
- libv4l2 (for V4L2 control struct definitions)
- pthread
Build (when implemented)
mkdir build && cd build
cmake .. -DDAEDALUS_FOURIER_DIR=/path/to/daedalus-fourier
make
Layout (planned)
CMakeLists.txtsrc/main.c— event loop, chardev connectionsrc/parser.c— FFmpeg dlopen wrapper + per-codec dispatchsrc/decode_vp9.c,src/decode_av1.c,src/decode_h264.c— per-codec block walkerssrc/frame_io.c— frame allocation, return to kernel
License
BSD-2-Clause (matches daedalus-fourier sibling).
Phase 8.3 starting point
A standalone program that:
- Opens a .ivf or .mp4
- Pulls codec packets via dlopen'd avformat
- Calls dlopen'd avcodec to parse (without decoding)
- Walks the block-level metadata
- Validates output structure
No kernel involvement yet — just confirm the parse path works.