marfrit-packages/debian/daedalus-v4l2/debian/changelog

daedalus-v4l2 (0.1.0+r39+g3bc0da1-1) bookworm trixie; urgency=medium

  * Bump to 3bc0da1 — picks up daedalus-v4l2 PR #15.  Per-frame
    `decoder: OK ...` log line gains `decode_us=N` (libavcodec
    send_packet + receive_frame wall-clock cost in microseconds).
    New `decoder stats` summary line every 60 decoded frames with
    codec, fps, avg decode_us, MBs/s throughput, B/MB bitrate.
  * Pure observability — no decode-path behaviour change.
    Establishes baseline metrics for the substitution work in
    daedalus-v4l2#11 step 2 (replacing libavcodec primitives with
    daedalus-fourier kernels one cycle at a time).
  * On Pi CM5 / bbb 720p H.264 baseline: ~4 ms decode_us / 24 fps
    / 90 K MBs/s — workload is well under 1 % of any single
    daedalus-fourier kernel's NEON ceiling.
  * Wire protocol unchanged.  No daedalus-v4l2-dkms bump needed.

 -- Markus Fritsche <mfritsche@reauktion.de>  Thu, 21 May 2026 18:30:00 +0000

daedalus-v4l2 (0.1.0+r37+g77e14e5-1) bookworm trixie; urgency=medium

  * Bump to 77e14e5 — picks up daedalus-v4l2 PRs #12 + #13.
  * #12 (LOW_DELAY half-measure): the daemon now sets
    AV_CODEC_FLAG_LOW_DELAY on the H.264 AVCodecContext so libavcodec
    emits frames in decode order ~99% of the time (a few stragglers
    at GOP boundaries when the stream's SPS num_reorder_frames
    overrides the flag).  Visible improvement vs the 2-1-4-3
    pair-swap on Firefox YouTube + mpv playback; not a permanent
    fix (see #11 for the architectural plan).
  * #13 (daedalus-fourier linkage): the daemon now pkg-config-links
    against the daedalus-fourier kernel library (marfrit/
    daedalus-fourier) and logs substrate availability at startup.
    No kernels dispatched yet — this is the build-time / link-time
    foundation for the H.264 daemon-rewrite plan in #11
    (substituting daedalus-fourier IDCT 4×4 / IDCT 8×8 / luma
    deblock primitives for libavcodec's per-MB pixel math, one
    cycle at a time, measuring CPU saved per substitution).
  * Build-deb.sh now fetches + builds + installs daedalus-fourier
    (pinned at d87239d, marfrit/daedalus-fourier PR #1) into a
    per-build temp prefix, then builds the daemon with
    PKG_CONFIG_PATH pointing at it.  daedalus-fourier is
    statically linked into the daemon binary, so the resulting
    .deb has no new runtime deps.  Requires libvulkan-dev +
    glslang-tools on the CI runner (the daedalus-fourier benches
    already needed those).
  * Wire protocol unchanged — DAEDALUS_PROTO_VERSION stays at 0.
    No daedalus-v4l2-dkms bump needed.

 -- Markus Fritsche <mfritsche@reauktion.de>  Thu, 21 May 2026 16:30:00 +0000

daedalus-v4l2 (0.1.0+r33+g5d8b436-1) bookworm trixie; urgency=medium

  * Bump to 5d8b436 — reverts daedalus-v4l2 PRs #7 + #8 (the parking
    design that broke libva-v4l2-request-fourier's 1:1 CAPTURE
    contract; see daedalus-v4l2#9 + #10).  After daemon-r28+g79256dc
    landed, mpv (--hwdec=vaapi-copy) failed pre-playing with
    "Unable to dequeue buffer: Resource temporarily unavailable" /
    "Failed to end picture decode" because the daemon parked CAPTURE
    buffers waiting for libavcodec to release H.264 B-frames in
    display order — violating the V4L2 stateless 1:1 contract.
    Firefox tolerated the mess (visible "2 1 4 3" pair-swap); mpv
    bailed.
  * This bump restores f0d4186-equivalent behaviour, plus PR #4
    (cosmetic H.264 DECODE_MODE / START_CODE menu controls).  PR #7
    + PR #8 wire-protocol additions (src_pts / output_src_pts /
    RESP_FRAME flags) are reverted — DAEDALUS_PROTO_VERSION drops
    back from 1 → 0.  Lock-step install with daedalus-v4l2-dkms
    0.1.0+r33+g5d8b436 REQUIRED.
  * Visible regression: H.264 B-frame streams in Firefox revert to
    the original "2 1 4 3 6 5" pair-swap visual.  The proper fix
    (concurrent in-flight requests in daemon + display-order reorder
    in libva-v4l2-request-fourier) is tracked at daedalus-v4l2#11.

 -- Markus Fritsche <mfritsche@reauktion.de>  Thu, 21 May 2026 14:50:00 +0000

daedalus-v4l2 (0.1.0+r28+g79256dc-1) bookworm trixie; urgency=medium

  * Bump to 79256dc — H.264 B-frame display reorder fix (closes
    daedalus-v4l2#6 + #4 menu controls).  Daemon side: the
    avcodec_send_packet → receive_frame loop now stamps pkt->pts =
    req->src_pts so libavcodec's display-ordered frame->pts identifies
    which OUTPUT bitstream's pixels each drained frame belongs to.
    chardev_client maintains a (src_pts → cookie) lookup table so the
    daemon can ship pixels to the cookie of the *originating*
    bitstream, not the cookie of whatever REQ triggered the
    receive_frame call.  Multiple RESP_FRAME messages per REQ_DECODE
    are now possible (one for the just-consumed src, one or more for
    drained pixels).
  * Wire-protocol bump (DAEDALUS_PROTO_VERSION 0 → 1): REQ_DECODE
    gains __u64 src_pts; RESP_FRAME gains __u32 flags +
    __u64 output_src_pts.  Daemon + kernel must install atomically
    (this package + daedalus-v4l2-dkms 0.1.0+r28+g79256dc).
  * Also subsumes 79256dc's predecessor 7ff2d89 — H.264 DECODE_MODE +
    START_CODE menu-control registration that retires the
    "Unable to set control(s) error_idx=2/2" warning libva-v4l2-
    request emitted on every context init.

 -- Markus Fritsche <mfritsche@reauktion.de>  Thu, 21 May 2026 12:00:00 +0000

daedalus-v4l2 (0.1.0+r24+gf0d4186-1) bookworm trixie; urgency=medium

  * Bump to f0d4186 — kernel per-ctx vb2 lock fix.  daedalus_queue_init
    was wiring src_vq->lock and dst_vq->lock to ctx->dev->m2m_lock (a
    device-wide mutex), serialising every vb2 ioctl across all
    concurrent clients of /dev/video0.  For Firefox (which spawns
    separate content + RDD + GPU processes that each open the device
    and run libva probe simultaneously), one libva session's
    S_FMT(OUTPUT_MPLANE) hit EBUSY while another was mid-streamon —
    Firefox VAAPI playback fell apart at startup.
  * Fix gives each open() its own ctx->vb_mutex; vb2 ioctls run
    independently per client.  Matches cedrus / rkvdec / hantro
    pattern.
  * Verified on higgs: Firefox YouTube playback engages VAAPI cleanly,
    sustained ~230 fps decode at 640x368 through the daedalus daemon,
    zero EBUSY in stderr or daemon journal.

 -- Markus Fritsche <mfritsche@reauktion.de>  Wed, 20 May 2026 23:00:00 +0000

daedalus-v4l2 (0.1.0+r22+g462aa4b-1) bookworm trixie; urgency=medium

  * Bump to 462aa4b — kernel-side fix for control-binding gap that
    closes the libva→daemon SPS/PPS pipeline.  Kernel device_run now
    calls v4l2_ctrl_request_setup() before reading ctrl->p_cur, so
    the daemon's daedalus_h264_meta block actually carries THIS
    request's V4L2 stateless H.264 control values instead of stale
    /default ones.  Pairs with libva-v4l2-request-fourier r382+gc1bb444
    (Fix 3 + Fix 4 from issue libva-v4l2-request-fourier#8).
  * After-fix on higgs (Pi CM5): ffmpeg -hwaccel vaapi -i h264.mp4
    produces unique decoded P-frames (per-frame fnv1a hashes differ)
    and zero "error while decoding MB" / "reference frames exceeds
    max" warnings.

 -- Markus Fritsche <mfritsche@reauktion.de>  Wed, 20 May 2026 22:00:00 +0000

daedalus-v4l2 (0.1.0+r20+g3dd0eb0-1) bookworm trixie; urgency=medium

  * Bump to 3dd0eb0 — DAEMON-PPS H.264 SPS/PPS NAL synthesiser.
    Daemon now reconstructs AnnexB SPS+PPS NAL units from the V4L2
    stateless H.264 control structs (forwarded by the kernel via
    a new struct daedalus_h264_meta block in REQ_DECODE) and
    prepends them to the slice bitstream before feeding libavcodec.
    Without this, ffmpeg -hwaccel vaapi on H.264 sources failed
    with "non-existing PPS 0 referenced" even after LIBVA-1/-2
    routing correctly delivered the request.
  * Wire protocol: new DAEDALUS_REQ_FLAG_H264_META bit + struct
    daedalus_h264_meta; daemon and kernel must be installed in
    lockstep (this package + daedalus-v4l2-dkms 0.1.0+r20+g3dd0eb0).
  * VP9 / AV1 paths unchanged.

 -- Markus Fritsche <mfritsche@reauktion.de>  Wed, 20 May 2026 21:00:00 +0000

daedalus-v4l2 (0.1.0+r18+g481279c-1) bookworm trixie; urgency=medium

  * Bump to 481279c.  Upstream landed the systemd unit + modules-load.d
    drop-in (packaging/systemd/daedalus-v4l2.{service,modules-load}).
  * Package now ships /lib/systemd/system/daedalus-v4l2.service and
    /usr/lib/modules-load.d/daedalus-v4l2.conf.
  * postinst: daemon-reload, enable the service, trigger
    systemd-modules-load, and start if /dev/daedalus-v4l2 is already
    present.  Operator no longer needs to remember the modprobe +
    systemctl-enable dance after install.
  * prerm/postrm: stop + disable + daemon-reload.

 -- Markus Fritsche <mfritsche@reauktion.de>  Wed, 20 May 2026 16:00:00 +0000

daedalus-v4l2 (0.1.0+r17+gf0cd29a-1) bookworm trixie; urgency=medium

  * Bump to f0cd29a alongside daedalus-v4l2-dkms.  No userspace
    change — the daemon binary in this release is bit-identical to
    the f55b2cd one (the f0cd29a commit only touches kernel/).  Bump
    keeps the userspace + DKMS pkgver lockstep so depmod /
    LIBVA_DRIVER_NAME selection stays correct on hosts that
    upgrade.

 -- Markus Fritsche <mfritsche@reauktion.de>  Tue, 20 May 2026 10:30:00 +0000

daedalus-v4l2 (0.1.0+r16+gf55b2cd-1) bookworm trixie; urgency=medium

  * Initial Debian packaging for the daedalus-v4l2 userspace daemon.
  * Pinned to f55b2cd (Phase 8.13 close): first commit where the full
    ffmpeg -hwaccel vaapi → libva-v4l2-request-fourier → /dev/video0
    → daemon path lands a pixel-correct decoded NV12 frame back in
    ffmpeg.
  * Codecs: VP9, AV1, H.264 (all via dlopen'd FFmpeg 7.1.3).
  * Capture formats: NV12M (2 plane), NV12 (1 plane, for libva),
    P010 (10-bit single plane).
  * Companion package: daedalus-v4l2-dkms (kernel module).

 -- Markus Fritsche <mfritsche@reauktion.de>  Mon, 18 May 2026 23:00:00 +0000