Opened 4 years ago

Closed 3 years ago

#8665 closed defect (invalid)

Infinite Loop Concatenating Two Videos

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

Description

When concatenating two videos, the process never completes. The output file continues to grow in size until file space runs out.

Commit Causing the Endless Loop
Verified the issue started in this commit.
commit 3ad5d4df9ce794d3eeb0f526c5f3e446bf97c616
Date: Fri Aug 30 13:28:17 2019 -0400

Last Working Commit
commit 85386c36e331d1387a3ac0f322e3774c1b55dc26
Date: Sun Sep 8 10:47:38 2019 +0200

I am providing two example videos I am using, in case there is something specific to the videos I am attempting to concatenate. The videos I am concatenating were created from an audio file and a still image.

How to reproduce:

ffmpeg -loglevel fatal -i 3272_segment_0.mp4 -i 3272_segment_1.mp4 -filter_complex \
    "[0:v] [0:a] [1:v] [1:a] concat=n=2:v=1:a=1 [v] [a]" \
    -map [v] -map [a] -vcodec libx264 -ar 48000 -acodec aac 3272.mp4

Video Segments Creation
The videos used in the previous command are "Picture in a Picture" videos. This was done using an overlay. Each of the videos in the "Picture in a Picture" were created by using a still image and an audio file.

An example is below of how the video was created using a still image and an audio file.

ffmpeg -loop 1 -i silhouette.png -i 3272_segment_0_background.webm -c:v libx264 -tune stillimage -c:a aac -b:a 192k -pix_fmt yuv420p -shortest 3272_segment_0.mp4
ffmpeg -loop 1 -i silhouette.png -i 3272_segment_0_overlay.webm -c:v libx264 -tune stillimage -c:a aac -b:a 192k -pix_fmt yuv420p -shortest 3272_segment_1.mp4

FFmpeg Version Information

ffmpeg -v 9 -loglevel 99 -i
ffmpeg version N-97739-g876cfa67f3 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 7 (Ubuntu 7.5.0-3ubuntu1~18.04)
  configuration: --prefix=/home/dreedy/ffmpeg_build --pkg-config-flags=--static --extra-cflags=-I/home/dreedy/ffmpeg_build/include --extra-ldflags=-L/home/dreedy/ffmpeg_build/lib --extra-libs=-lpthread --bindir=/home/dreedy/bin --enable-ffprobe --enable-gpl --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-nonfree
  libavutil      56. 44.100 / 56. 44.100
  libavcodec     58. 83.100 / 58. 83.100
  libavformat    58. 43.100 / 58. 43.100
  libavdevice    58.  9.103 / 58.  9.103
  libavfilter     7. 80.100 /  7. 80.100
  libswscale      5.  6.101 /  5.  6.101
  libswresample   3.  6.100 /  3.  6.100
  libpostproc    55.  6.100 / 55.  6.100
Splitting the commandline.
Reading option '-v' ... matched as option 'v' (set logging level) with argument '9'.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) with argument '99'.
Reading option '-i' ...Missing argument for option 'i'.
Error splitting the argument list: Invalid argument

I've wondered if the issue of concatenating the videos is caused by the way the two videos I am attempting to concatenate were created. So I have provided the additional steps on how those were created.

If you need any additional information, let me know and I will be happy to include it.

Attachments (2)

3272_segment_0.mp4 (106.7 KB ) - added by dreedy 4 years ago.
3272_segment_1.mp4 (109.7 KB ) - added by dreedy 4 years ago.

Download all attachments as: .zip

Change History (5)

by dreedy, 4 years ago

Attachment: 3272_segment_0.mp4 added

by dreedy, 4 years ago

Attachment: 3272_segment_1.mp4 added

comment:1 by kepstin, 4 years ago

When filing an issue like this, please always include the complete output of the failing ffmpeg command, at a reasonable log level. Why are you using -loglevel fatal? Don't do that! It's hiding a warning that ffmpeg is printing when running the command you provided!

Here's the interesting part of the output with -v verbose:

[graph 0 input from stream 0:0 @ 0x5613bdadd3c0] w:640 h:480 pixfmt:yuv420p tb:1/14336 fr:14/1 sar:0/1
[graph_0_in_0_1 @ 0x5613bdaddd40] tb:1/48000 samplefmt:fltp samplerate:48000 chlayout:0x4
[graph 0 input from stream 1:0 @ 0x5613bdadee00] w:640 h:480 pixfmt:yuv420p tb:1/12800 fr:25/1 sar:0/1
[graph_0_in_1_1 @ 0x5613bdadfb00] tb:1/48000 samplefmt:fltp samplerate:48000 chlayout:0x4
[Parsed_concat_0 @ 0x5613bdad9700] Video inputs have different frame rates, output will be VFR
[mp4 @ 0x5613bd495d40] Frame rate very high for a muxer not efficiently supporting it.
Please consider specifying a lower framerate, a different muxer or -vsync 2

Your two videos have different framerates and timebases. (This means they were not created with the commands you stated - since if the commands you stated were used, both videos would be 25fps.) This triggers the new logic in the concat filter, which sets the output framerate to VFR. The old ffmpeg version would have set the output framerate to the first video's framerate (14 here), resulting in dropped frames and "Past duration 0.879982 too large" messages when it got to the higher framerate section.

The problem itself appears to be an issue with how the mp4 muxer (or ffmpeg cli? not sure.) handles an output video stream that's marked as VFR. It might be an existing problem that was only exposed due to the changes to the concat filter.

Anyways, adding "-vsync 2" as the ffmpeg warning message recommends appears to work around the issue. Using a different output container (mkv for example) also works.

Depending on your use case, it might be a better idea to convert the video to constant framerate by adding an "fps" filter after concat rather than generate a VFR video. Or you could make sure all your inputs have matching framerate.

Last edited 4 years ago by kepstin (previous) (diff)

comment:2 by Elon Musk, 3 years ago

Priority: importantnormal
Status: newopen

comment:3 by Carl Eugen Hoyos, 3 years ago

Component: ffmpegundetermined
Resolution: invalid
Status: openclosed

If there is an issue - I don't think there is one, see comment:1 - it is a duplicate of some mov-related ticket.

Note: See TracTickets for help on using tickets.