Periodic audio dropouts: add -max_interleave_delta 0 to the mux (copied Opus + subtitles) #19

New Issue

2026-06-21T18:07:17Z

Kessinen commented

2026-06-21 18:07:17 +00:00

Symptom: with pre-encoded Opus audio stream-copied (-c:a copy) and subtitles copied (-c:s copy), playback periodically cuts the audio. ffmpeg emits 'Non-monotonous DTS in output stream' / timestamp restarts during the mux.

Root cause (well-documented ffmpeg behavior): the muxer interleaves packets by timestamp and buffers the dense audio/video while waiting for the next packet of the SPARSE subtitle stream. That queue is bounded by max_interleave_delta (default 1,000,000 us = 1s); once the buffered span exceeds it, ffmpeg flushes packets regardless of order, producing the non-monotonous DTS / timestamp restarts. Some players resync on those by briefly dropping audio -> the periodic cutoffs. Stream-copying the audio (rather than re-encoding) is what exposes it, because timestamps are passed through as-is.

Candidate fix: add '-max_interleave_delta 0' to the encodeVideo ffmpeg command (the one doing -c:a copy + -c:s copy). 0 = buffer until there's a packet for every stream instead of flushing the dense audio on a sparse-subtitle gap. Trade-off: more buffering memory (fine here, audio is dense). Alternatives reported: -copytb 1, -fflags +igndts.

Do NOT 'fix' by re-encoding audio in ffmpeg: opusenc is required (ffmpeg libopus mis-handles 5.1 side channels). See SPEC.md / the audio-pipeline constraint.

Validation: needs testing against a real rip that exhibited the cutoff - ideally multichannel (5.1) audio + a subtitle track. Confirm the warnings disappear and playback audio is continuous (test in a player that was cutting out, e.g. the target playback device).

Refs:

ffmpeg-formats docs: max_interleave_delta (https://ffmpeg.org/ffmpeg-formats.html)
https://forum.videohelp.com/threads/390057-FFMpeg-non-monotonous-DTS-in-output-stream-error
https://forum.makemkv.com/forum/viewtopic.php?t=30905

Symptom: with pre-encoded Opus audio stream-copied (-c:a copy) and subtitles copied (-c:s copy), playback periodically cuts the audio. ffmpeg emits 'Non-monotonous DTS in output stream' / timestamp restarts during the mux. Root cause (well-documented ffmpeg behavior): the muxer interleaves packets by timestamp and buffers the dense audio/video while waiting for the next packet of the SPARSE subtitle stream. That queue is bounded by max_interleave_delta (default 1,000,000 us = 1s); once the buffered span exceeds it, ffmpeg flushes packets regardless of order, producing the non-monotonous DTS / timestamp restarts. Some players resync on those by briefly dropping audio -> the periodic cutoffs. Stream-copying the audio (rather than re-encoding) is what exposes it, because timestamps are passed through as-is. Candidate fix: add '-max_interleave_delta 0' to the encodeVideo ffmpeg command (the one doing -c:a copy + -c:s copy). 0 = buffer until there's a packet for every stream instead of flushing the dense audio on a sparse-subtitle gap. Trade-off: more buffering memory (fine here, audio is dense). Alternatives reported: -copytb 1, -fflags +igndts. Do NOT 'fix' by re-encoding audio in ffmpeg: opusenc is required (ffmpeg libopus mis-handles 5.1 side channels). See SPEC.md / the audio-pipeline constraint. Validation: needs testing against a real rip that exhibited the cutoff - ideally multichannel (5.1) audio + a subtitle track. Confirm the warnings disappear and playback audio is continuous (test in a player that was cutting out, e.g. the target playback device). Refs: - ffmpeg-formats docs: max_interleave_delta (https://ffmpeg.org/ffmpeg-formats.html) - https://forum.videohelp.com/threads/390057-FFMpeg-non-monotonous-DTS-in-output-stream-error - https://forum.makemkv.com/forum/viewtopic.php?t=30905

Kessinen added the bug label 2026-06-21 18:07:17 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Kessinen/av1dae#19