Performance of trimming/resizing a video is much slower than the command line counterpart

[listix]

I was trying to rewrite a bash script I had and found that the command line version I was using is way faster compared to the script using python. This mkv file is 1.5GB big.

time ffmpeg -hide_banner -loglevel error -ss 12:12 \
        -i video.mkv \
        -t 1 \
        -an \
        -filter:v fps=23.976,scale=720:540:flags=lanczos \
        -y "output_manual.mp4"

________________________________________________________
Executed in  265.38 millis    fish           external
   usr time    1.13 secs      0.00 micros    1.13 secs
   sys time    0.14 secs    670.00 micros    0.14 secs

The code in python I used was:

stream = ffmpeg.trim(stream, start=start_time, duration=duration)
stream = ffmpeg.filter(stream, "framerate", 23.976)
stream = ffmpeg.filter(stream, "scale", width=720, height=540, flags="lanczos")
video_output = "output_python.mp4"
stream = ffmpeg.output(stream, video_output)
stream = ffmpeg.overwrite_output(stream)
print(stream.get_args())

which gives:

['-an', '-i', 'video.mkv', '-filter_complex', '[0]trim=duration=1.0:start=12\\\\:12[s0];[s0]framerate=23.976[s1];[s1]scale=flags=lanczos:height=540:width=720[s2]', '-map', '[s2]', 'output_python.mp4', '-y']

But that takes much longer. If I use those parameters and run it myself:

time ffmpeg -an -i video.mkv -filter_complex "[0]trim=duration=1.0:start=12\\\\:12[s0];[s0]framerate=23.976[s1];[s1]scale=flags=lanczos:height=540:width=720[s2]" -map [s2] output_code.mp4 -y

________________________________________________________
Executed in   12.88 secs    fish           external
   usr time  169.18 secs  788.00 micros  169.18 secs
   sys time    2.05 secs    0.00 micros    2.05 secs

There is about a 50x difference in speed. On top of that the sha1 of both files is different. Am I doing something blatantly wrong and noticing it?

[lucemia]

The 50x gap and the sha1 difference are two separate things, and neither is Python overhead.

The speed: trim filter vs -ss input option. Your shell version puts -ss 12:12 before -i, so ffmpeg seeks to that timestamp and decodes ~1 second. The Python version uses the trim filter instead, which is part of the filter graph — ffmpeg decodes every frame from 0 up to 12:12 and throws them away before the trim takes effect. That is the 50x.

-ss as an input option, plus -t on the output:

stream = ffmpeg.input(video_path, ss=start_time, t=duration)
stream = ffmpeg.filter(stream, "fps", 23.976)
stream = ffmpeg.filter(stream, "scale", width=720, height=540, flags="lanczos")
stream = ffmpeg.output(stream, "output_python.mp4", an=None)

which compiles to ffmpeg -ss 12:12 -t 1 -i video.mkv -filter_complex ... -an out.mp4 — the same shape as your fast command.

The sha1: framerate is not fps. Your shell command uses fps=23.976, which drops or duplicates frames. Your Python code uses filter(stream, "framerate", ...), which is a different filter — it interpolates, synthesising blended frames. Different output by design. Use fps to match.

Minor: an=None on input() emits -an before -i, making it an input option. It happens to do what you want here, but it belongs on output().

---

Unrelated to the above: I maintain typed-ffmpeg, a strongly typed FFmpeg wrapper that's still actively maintained, in case that's useful to you.

[listix]

That makes lots of sense. I thought I was going crazy. I will surely check your repo. Thank you for protecting my sanity.