#7963 closed defect (invalid)
Concat demuxer adds time to video duration
Reported by: | bgx90 | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | unspecified | Keywords: | concat |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
I concatenate some ts files with the concat demuxer and create a mkv file using stream copying with the following command:
ffmpeg -f concat -safe 0 -fflags +genpts -i file_list.txt -c copy output.mkv
The result is a playable mkv, but the duration is 8 seconds longer than the duration of the original ts stream. Also, the picture periodically freezes for a very small fraction of a second, but I don't detect any pause in the audio; I suspect these stutters are the source of the extra 8 seconds. I have tried the command without the +genpts flag as well, but there is no change in the resulting mkv.
Concatenating the ts files with the concat protocol results in an mkv with the correct duration and no pauses in the picture during playback.
This command works as expected:
ffmpeg -fflags +genpts -i "concat:$file_list" -c copy output.mkv
Running ffprobe -show_format -show_streams on both of the files and comparing the outputs shows only the following differences:
Concat demuxer mkv
duration=1449.811000 size=280861150 bit_rate=1549780
Concat protocol mkv
duration=1441.727000 size=280861151 bit_rate=1558470
I read in ticket 2801 that the concat demuxer needs the files to be split cleanly on keyframes. Could this problem be caused by bad splitting of the ts files?
I don't mind using the concat protocol instead of the concat demuxer. I only worry about the limit on command length. It was suggested in ticket 5686 that the cat command could be used in cases where the file list is too long and the concat protocol works but the concat demuxer does not. Is using the cat command to concatenate ts files and giving the resulting file as input to ffmpeg the same as using the concat protocol, or does the concat protocol do something more than just concatenating files as the cat command does?
Change History (3)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
Keywords: | demuxer protocol concatenate duration mkv removed |
---|---|
Resolution: | → invalid |
Status: | new → closed |
- For lots of transport streams (e.g. those originating from a TV broadcast) it is perfectly normal for there not to exist any point where you can split the files cleanly on keyframes (because when you split everything before the start of a keyframe for PID x, you cut in the middle of a packet of PID y; not to mention the PMT/PAT etc.). So the only splitting of a transport stream I'd call "bad" is when you split right through a transport stream packet.
- The concat protocol really does just what cat does (ok, it also provides seekability, but that's it).
comment:3 by , 5 years ago
Component: | ffmpeg → undetermined |
---|---|
Version: | 4.1 → unspecified |
Here are links to the reports from the commands I used. They were to big to attach.
concat demuxer with genpts flag
concat demuxer without genpts flag
concat protocol