Opened 3 years ago

Closed 3 years ago

#8394 closed defect (duplicate)

Audio part of remux output file cannot seek

Reported by: Kirby Zhou Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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|/

Attachments (4)

ffmpeg-20191123-001109.log.zip (996.0 KB ) - added by Kirby Zhou 3 years ago.
ffmpeg-20191123-094241.log.zip (775.9 KB ) - added by Kirby Zhou 3 years ago.
screen_of_upload.jpeg (102.6 KB ) - added by Kirby Zhou 3 years ago.
screen_of_upload2.jpg (105.6 KB ) - added by Kirby Zhou 3 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 by Kirby Zhou, 3 years ago

BTW
mkvtoolnix can get correct output with the same source files

comment:2 by Carl Eugen Hoyos, 3 years ago

Component: ffmpegundetermined

Please use a sane file hoster.

comment:3 by Kirby Zhou, 3 years ago

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

Last edited 3 years ago by Kirby Zhou (previous) (diff)

by Kirby Zhou, 3 years ago

comment:4 by mkver, 3 years ago

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.

Last edited 3 years ago by mkver (previous) (diff)

comment:5 by mkver, 3 years ago

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

comment:6 by Kirby Zhou, 3 years ago

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

by Kirby Zhou, 3 years ago

by Kirby Zhou, 3 years ago

Attachment: screen_of_upload.jpeg added

comment:7 by mkver, 3 years ago

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

by Kirby Zhou, 3 years ago

Attachment: screen_of_upload2.jpg added

comment:8 by Kirby Zhou, 3 years ago

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.

comment:9 by mkver, 3 years ago

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

comment:10 by Kirby Zhou, 3 years ago

I uploaded to github.

https://github.com/kirbyzhou/public

please combine the 4 files using dd or cat.

comment:11 by mkver, 3 years ago

Resolution: duplicate
Status: newclosed

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.

Note: See TracTickets for help on using tickets.