You cannot directly concatenate video segments with different playback speeds because FFmpeg requires identical stream parameters, including frame rate and duration, for the concat demuxer. To solve this error, you must first normalize the temporal properties of each clip by adjusting their speed while simultaneously scaling their frame rates or padding them to a common standard before merging them into a single file.
Understanding the Concatenation Constraint
The core issue arises from how FFmpeg handles the
concat protocol. When you attempt to join two files, the decoder expects the streams to be seamless continuations of one another. If one clip is sped up (e.g., 2x) and the other is normal (1x), their underlying timestamps, frame counts, and often their frame rates differ significantly. The concat demuxer does not perform real-time resampling during the joining process; it simply stitches together the binary data of the streams. Therefore, if the headers indicate different durations per frame or different total frame counts that do not align with a continuous timeline, the operation fails with a parameter mismatch error.
To fix this, you must preprocess each segment so that they share a uniform time base. This involves ensuring that both clips have the same resolution, codec, pixel format, and crucially, the same frame rate. Speed changes alter the effective frame rate relative to wall-clock time, so explicit normalization is required.
Step-by-Step Solution
The most robust method is to use the
setpts filter for speed adjustment and the
fps filter to enforce a common frame rate. Follow these steps to prepare your clips.
First, determine the target frame rate. A standard like
30 or
60 FPS works best for compatibility. Let us assume we want a final output of 30 FPS.
For the first clip, which might be at its native speed, apply the following command to ensure it matches the target frame rate:
ffmpeg -i input_slow.mp4 -vf "fps=30,scale=iw:ih" -c:a copy normalized_slow.mp4
This command forces the video stream to 30 frames per second. The
scaled=iw:ih part ensures the aspect ratio is preserved without changing dimensions, which is critical for concatenation.
Next, handle the fast clip. Suppose you want to play it at 2x speed. You need to adjust the presentation timestamp (
PTS) and then match the frame rate:
ffmpeg -i input_fast.mp4 -vf "setpts=0.5*PTS,fps=30,scale=iw:ih" -c:a copy normalized_fast.mp4
Here,
setpts=0.5*PTS doubles the speed. Note that speeding up video also speeds up audio if included in the video filter chain, but since we used
-c:a copy, the audio remains untouched. You will likely need to speed up the audio separately using
atempo to maintain lip-sync.
Once both
normalized_slow.mp4 and
normalized_fast.mp4 are created, they should have identical video parameters. Verify this by checking the output of
ffprobe on both files. They must show the same width, height, pixel format (e.g.,
yuv420p), and frame rate.
Now, create a text file named
list.txt containing the paths to your normalized clips:
file 'normalized_slow.mp4'
file 'normalized_fast.mp4'
Finally, run the concat command:
ffmpeg -f concat -safe 0 -i list.txt -c copy output_final.mp4
The
-c copy flag tells FFmpeg to copy the streams directly without re-encoding, which is fast and preserves quality. If you encounter errors here, double-check that the audio codecs are also identical between the two normalized files. If the audio was copied, ensure both original files had the same audio codec (e.g., AAC). If they differed, you may need to re-encode the audio for both clips to a common codec before concatenation.
For more complex editing tasks involving overlays, you might find
Adding Green Video Overlay with FFmpeg: Define Interval helpful for understanding how to manage timing across multiple layers.
Handling Audio Desync
A common pitfall when changing video speed is audio desynchronization. The
setpts filter only affects video timestamps. If you sped up the video by half, your audio is now twice as long as the video visually suggests. To fix this, apply the
atempo filter to the audio stream during the normalization phase.
For the fast clip, modify the previous command to include audio processing:
ffmpeg -i input_fast.mp4 -vf "setpts=0.5*PTS,fps=30" -af "atempo=2.0" -c:v libx264 -c:a aac normalized_fast_synced.mp4
By using
atempo=2.0, the audio is also doubled in speed, keeping it in sync with the accelerated video. Ensure that the
atempo value is the inverse of the
setpts multiplier. If
setpts is 0.5 (2x speed),
atempo should be 2.0.
If you are scripting this process in Python, remember that argument parsing can sometimes strip quotes unexpectedly. For those dealing with programmatic concatenation, see
Unable to Concatenate Videos using FFmpeg Python for best practices on handling subprocess calls.
Alternative Approaches
If the standard concat demuxer proves too restrictive due to minor metadata mismatches, consider using the filtergraph
concat filter instead. This method is more flexible regarding some stream parameters but requires re-encoding, which takes longer.
ffmpeg -i slow.mp4 -i fast.mp4 -filter_complex "[0:v][0:a][1:v][1:a]concat=n=2:v=1:a=1[outv][outa]" -map "[outv]" -map "[outa]" output.mp4
This approach merges the streams within the filter graph itself. However, it still demands that the input streams have compatible resolutions and pixel formats. It is generally slower than the demuxer approach but can resolve issues where file headers are slightly inconsistent despite identical visual content.
Frequently Asked Questions
Why does my concatenated video have black gaps?
Black gaps usually indicate that the timestamps of the second clip do not start immediately after the first clip ends. Ensure that you are using the
concat demuxer correctly and that your
list.txt file points to properly normalized clips with no trailing silence or video black frames.
Can I concatenate videos with different resolutions?
No, the standard concat demuxer requires identical resolution, pixel format, and codec settings. You must scale all inputs to the same resolution using the
scale filter during the normalization step before attempting to join them.
What if I get an "Invalid data found" error?
This error often occurs when the concat demuxer encounters malformed headers or mismatched stream indices. Re-encode both clips to a standard codec like H.264 and AAC with consistent parameters to eliminate header inconsistencies.
How do I check if my clips are compatible?
Use
ffprobe on both files and compare the output lines for
Stream #...: Video and
Stream #...: Audio. Look for matching values in width, height, r_frame_rate, codec_name, and sample_rate.
Is there a way to avoid re-encoding entirely?
Yes, if you normalize the clips using
-c copy and ensure they already share the exact same codec, resolution, and frame rate, you can concatenate without re-encoding. However, speed adjustments typically require re-encoding to change the PTS structure effectively.