You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(hls): prime mp4 moov with a parsed audio packet on backward-seek muxer restart (#92)
Under +delay_moov the mp4 muxer writes moov lazily on the first
av_write_frame(ctx, nil). For AC-3/E-AC-3/TrueHD the audio sample entry
(dac3/dec3/dmlp) can only be built from a PARSED audio packet, so a first
moov flush that fires video-only errors -22 "Cannot write moov atom
before EAC3 packets parsed", the segment cut fails, the muxer wedges, and
the segment is retried forever (AVPlayer 503 -> forever-loading spinner).
On a mid-file backward seek that lands out of the segment cache the
producer tears down and rebuilds a fresh muxer at the restart segment; if
that muxer's first moov flush (a #64 RAM-cap interim flush, or the first
segment cut) fires before any audio packet is written, it hits this.
AAC never triggers it (its sample entry needs no parsed packet).
Fix:
- Latch audioPacketWritten once the first audio packet is written.
- Gate the #64 RAM-cap interim flushPendingFragment() on that latch,
scoped via codec_id to the codecs whose sample entry needs a parsed
packet (AC-3/E-AC-3/TrueHD) so AAC keeps its full RAM-cap bound.
- In the video-leads-audio case, proactively flush on the first audio
packet so moov is emitted with a parsed audio packet present.
The first segment cut is intentionally left unguarded: if audio never
arrives, moov must still be attempted (fail-as-before) rather than being
deferred forever, which would convert the wedge into a permanent stall.
Audio routing/placement is untouched, so no audio-dropout regression.
0 commit comments