Audio part of remux output file cannot seek

[Kirby Zhou]

Summary of the bug:

Remux video track and subtitle from 0.mkv with audio track from 1.avi, the audio of output file can not seek.

Remux

How to reproduce:

ffmpeg -report -i 0.mkv -i 1.avi -map 0:v:0 -map 1:a -map 0:s:0 -c copy -t 00:09:00 out-2.mkv
ffmpeg version N-95812-gd73f062706-tessus
downloade at ffmpeg.org
macOS 10.14.6

Player: IINA-1.0.4 MPV-0.30.0 VLC-3.0.7

Using any player above to play the out.mkv, seek to 04:00~06:00, the audio is silent.
If I remove "-map 0:s:0" from arguments, things go ok.
If I change "-t 00:09:00" to -t 00:07:00, things go ok.

ffmpeg-4.2.1 have this bug too.

Source files are too large to upload, and fragment of files and not reproduce the problem.
So I list the ed2k link here.

ed2k://|file|0.mkv|5294538706|b7ccd8150fd15541f3fc56fc505eed26|h=gcrld372utzzxxb
p4qg34svfpcotn3bg|/

ed2k://|file|1.avi|2527244288|5decf0aa486aadabfbb2156d3ba330d3|h=zlb2oofz3ez3pvu
7n7vot6v63dasaxb6|/

[Kirby Zhou]

BTW
mkvtoolnix can get correct output with the same source files

[Carl Eugen Hoyos]

Please use a sane file hoster.

[Kirby Zhou]

Any suggestion of hosting gigabyte size file?
I can not reproduce the bug with 10M file.

[mkver]

You can use upload your files ​here (select FFmpeg). if the files need to be split, then don't remux, but use a tool like dd.

[mkver]

Judging from the log this seems to be a duplicate of #6037. But in order to know for sure I need the source files.

[Kirby Zhou]

I uploaded 2 files, but no link returned to me?
Is it ok?

#] ffmpeg -report -i 0-frag.mkv -i 1-frag.avi -map 0:v:0 -map 1:a -map 0:s:0 -c copy -t 00:07:30 out-2.mkv -report

[mkver]

The files are ​here, don't worry. 1.avi is still lacking.

[Kirby Zhou]

I have got this message for 1-frag.avi for 3 times, but no file in your ftp view.

Your upload has completed. You may close the window now.
Thank you for helping out VideoLAN.
Alternatively, you can upload another file.

The file size is 188,743,680 bytes.

[mkver]

You may also use any other filehoster that doesn't require a registration.

[Kirby Zhou]

I uploaded to github.

​https://github.com/kirbyzhou/public

please combine the 4 files using dd or cat.

[mkver]

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.