AudioBridge: Opus preskip not honoured — audio_gate shifts forward of video, AVPlayer stuck waitingToPlay

[hp561]

Summary

When an Opus source is routed through the FLAC bridge, the first decoded audio packet retains the Opus preskip pre-roll samples (typically ~312 samples @ 48kHz / ~80ms). The bridge does not consume `AV_PKT_DATA_SKIP_SAMPLES` packet side-data, so the first FLAC frames contain the pre-roll PCM, and the producer's audio gate opens at a forward-shifted PTS instead of aligning to zero.

Observed on real Apple TV 4K (3rd gen) playing an Opus-in-MKV source:

```
[HLSSegmentProducer] audio gate open: actual=153 target=... shift=153
[opus @ 0x...] Could not update timestamps for skipped samples.
[HLSSegmentProducer] video gate open: actual=0 anchorPts=125 ... shift=0
```

Audio shifted +153 (units in the audio muxer timebase), video shifted 0. AVPlayer fetches `seg0.mp4`, then never advances — sticks in `AVPlayerWaitingToMinimizeStallsReason` forever and never reaches `readyToPlay`.

Reproduction

1. Source: Opus in MKV, any 1080p HEVC video paired with stereo Opus audio.
2. Engine routes through the native HLS-fMP4 + FLAC bridge.
3. AVPlayer requests seg0, never seg1.

Suspected fix

In `AudioBridge`, on each decoded packet inspect `AV_PKT_DATA_SKIP_SAMPLES` side-data and discard the indicated leading samples before passing PCM to the FLAC encoder. This is the same mechanism FFmpeg's own muxers use to honour the Opus preskip header.

Alternative / simpler: read the codec's `initial_padding` from `AVCodecContext` after `avcodec_open2` and skip that many samples on the first decoded frame, regardless of side-data presence.

Happy to dig further or PR if useful. Tested against a public Opus-in-MKV sample (1080p HEVC + stereo Opus, 23.976fps).

[superuser404notfound]

Fixed in b8858b2. Root cause was the rebase target, not the data:

libavcodec's discard-samples path already trims preskip off the first decoded Opus frame, but it also advances frame.pts by the trimmed-sample count. AudioBridge was rebasing the FLAC encoder timeline from srcFrame.pts, so the forward-shifted frame pts propagated through and opened the audio gate at preskip-offset.

The fix captures packet.pts at feed() entry and rebases from that instead, so the first encoded FLAC sample lands at source-PTS=packet.pts regardless of any decoder-side pts adjustment. Works for any codec whose decoder advances pts during priming (Opus, AAC encoder delay), not just Opus.

Decided against the side-data-trim approach since libavcodec already trims the data correctly. The bug was purely on the pts side. If anyone ever sees audible preskip warm-up at start, that'd be the next layer to add.

Sodalite has picked up the bump. Thanks again for the precise repro.