[FFmpeg-trac] #8394(undetermined:closed): Audio part of remux output file cannot seek

[FFmpeg]

#8394: Audio part of remux output file cannot seek
-------------------------------------+-------------------------------------
             Reporter:  kirbyzhou    |                    Owner:
                 Type:  defect       |                   Status:  closed
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  git-master   |               Resolution:  duplicate
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Changes (by mkver):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 Duplicate of #6037: The subtitle track selected for copying is very sparse
 (it's a forced subtitle track) and has only two packets. This makes ffmpeg
 behave very weird: It searches the first input file until it has found a
 packet for all streams from that file that are needed for muxing or until
 the muxing queue is longer than the time given by max_interleave_delta
 (defaulting to 10s); If the latter condition is fulfilled, a packet is
 output immediately. Given that the subtitle track is so spare, the muxing
 queue will be filled until it has 10s, then a packet from it is output,
 bringing the length of the muxing queue down to something less than 10s,
 then another video packet (from the first input file!) is read (in search
 for a subtitle packet, of course!), bringing the length of the queue above
 max_interleave_delta again, so that another packet (from the video stream)
 is output.

 This only changes when a subtitle packet is finally encountered (with
 timestamp 2:05.667): The muxing queue is nearly 10s long at this point
 (the last video packet already output was at 1:55.657). Now the second
 file is read and (surprise, surprise!) the timestamps of the newly read
 packets are very low, so that the length of the muxing queue is very long
 after consuming a new audio packet. This means that the packet with the
 lowest timestamp (namely the newly read audio packet from the second input
 file) will now be output. This is repeated until the audio stream from the
 second file has caught up with the other tracks.

 Then we have 10s of properly interleaved video and audio, closed by the
 subtitle packet. At this point, everything goes haywire again: The first
 file is without success searched for a subtitle packet until the muxing
 queue is longer than 10s again, at which point a video packet will be
 output. This goes on until the second subtitle packet is found, by which
 time audio catches up with the other tracks and we have 10s of properly
 interleaved audio and video again until the subtitle packet is output and
 everything goes haywire again...

 Use -max_interleave_delta 0 (as an output option) to disable any length
 limitation for the muxing queue. But beware: This may (and in this case
 will) consume lots of memory.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/8394#comment:11>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker