ffmpeg-v4l2-request-fourier: restore AV_CODEC_FLAG_LOW_DELAY in H.264 decoder

FFmpeg 8.x dropped the H.264 decoder's low_delay code path —
AV_CODEC_FLAG_LOW_DELAY no longer prevents h264_select_output_frame
from running the display-order DPB output queue.  The daedalus-v4l2
daemon's `ctx->flags |= AV_CODEC_FLAG_LOW_DELAY` at
daemon/src/decoder.c:202 has been a silent no-op since the SONAME
61→62 jump landed in reauktion/daedalus-v4l2 PR #16; on Firefox
YouTube this re-introduced the 2-1-4-3 B-frame pair-swap that PR
#12's daemon flag was supposed to prevent.

Fix lives in libavcodec, not the daemon: restore the documented
LOW_DELAY semantics so the daemon (and any other V4L2-stateless-
style consumer) keeps the one-frame-per-send_packet decode-order
output contract it already declares.

## Patch

0006-h264-restore-low-delay.patch touches libavcodec/h264_slice.c:

- h264_select_output_frame: early-exit when LOW_DELAY is set.
  Emit the just-decoded picture as next_output_pic, mirror the
  corruption / recovery-point tracking the main path performs,
  skip delayed_pic[] / POC reorder machinery entirely.

- h264_field_start: suppress the SPS-driven
  `has_b_frames = sps->num_reorder_frames` clobber when LOW_DELAY
  is set.  Without this the per-slice bitstream_restriction_flag
  re-pickup would reintroduce a nonzero reorder buffer mid-stream
  even after the daemon set has_b_frames=0 at avcodec_open2.

## Why not daemon-side

A daemon SPS-rewrite (`num_reorder_frames=0`) was considered but
rejected: it works only for the daemon's reconstructed SPS NAL,
not for any in-band SPS the daemon dlopens libavformat to parse
in other code paths.  Restoring documented FFmpeg flag semantics
is the smaller, more durable change and keeps the daemon
interface stable.

## Packaging

- PKGREL/pkgrel bump to 9.
- No new build-deps, no Depends change.
- Substitution arc cycles 6/7/8 unchanged.

## Refs

- reauktion/daedalus-v4l2#11 / #12 (LOW_DELAY half-measure on
  daemon side, originally landed against FFmpeg 7.x).
- daemon/src/decoder.c:202 (`ctx->flags |= AV_CODEC_FLAG_LOW_DELAY`
  for H.264 only — unchanged, but now actually has effect again).

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

@@ -1,3 +1,28 @@
+ffmpeg-v4l2-request-fourier (2:8.1+rfourier+gb57fbbe-9) bookworm trixie; urgency=medium
+
+  * Add 0006-h264-restore-low-delay.patch — restore the documented
+    AV_CODEC_FLAG_LOW_DELAY semantics in the H.264 decoder.  FFmpeg
+    8.x dropped the H.264 low_delay code path entirely; setting the
+    flag at avcodec_open2 no longer prevents the display-order DPB
+    output queue from running.  Visible on Firefox YouTube as the
+    2-1-4-3 B-frame pair-swap, re-introduced silently by the
+    SONAME 61→62 jump in daedalus-v4l2 PR #16.
+  * h264_select_output_frame: early-exit when LOW_DELAY is set;
+    emit the just-decoded picture as next_output_pic, mirror the
+    corruption / recovery-point tracking, skip delayed_pic[] and
+    the POC reorder machinery entirely.
+  * h264_field_start: suppress the SPS-driven
+    has_b_frames = sps->num_reorder_frames clobber when LOW_DELAY
+    is set — without this the per-slice bitstream_restriction_flag
+    re-pickup would reintroduce a nonzero reorder buffer mid-
+    stream.
+  * Restores the same one-frame-per-send_packet contract the
+    daedalus-v4l2 daemon's decoder.c already relies on (the flag
+    is set unconditionally for H.264).  No daemon side change.
+  * No SONAME change, no Depends change.
+
+ -- Markus Fritsche <mfritsche@reauktion.de>  Fri, 22 May 2026 13:30:00 +0000
+
 ffmpeg-v4l2-request-fourier (2:8.1+rfourier+gb57fbbe-8) bookworm trixie; urgency=medium
 
   * Add 0005-h264-deblock-luma-v-daedalus-fourier.patch —