ffmpeg performance with hundreds of cuts (atrim)

user_1018887 0
Viewed 320

I have audio files (think ~2h) where I want to cut out a lot of pieces out of it (500+) and a ffmpeg command like this one:

['ffmpeg', '-i', 'pipe:', '-filter_complex', 
'[0]atrim=end=30.69:start=0.0[s0];
 [0]atrim=end=34.31:start=31.18[s1];
 [0]atrim=end=38.65:start=34.43[s2]; 
 (... hundreds more)
 [s37][s38][s39][s40][s41]concat=a=1:n=42:v=0[s42]', '-map', '[s42]']

Stream mapping built with ffmpeg-python:

  Stream #0:0 (mp3float) -> atrim
  (... hundreds more)
  Stream #0:0 (mp3float) -> atrim
  concat -> Stream #0:0 (libmp3lame)

Now this works as expected but it takes locally something like 10mins for the files I have and when I deploy it to some server in the cloud it takes something like an hour. It definitely depends on the machine obviously and I definitely scale there the speed but I'd also like to know if there's a way to speed up the processing with ffmpeg itself.

Thanks for any pointers!

ffmpeg audio python
1 Answers

Why do you feed your files to ffmpeg via a pipe? If you provide the input by path, ffmpeg will be enabled to seek within the file and quickly skip over the fragments that must be dropped, whereas with pipe input it has no choice but scan the entire input sequentially.

Besides, when using file inputs, you can take advantage of the concat demuxer with stream copy, saving significantly on decoding and re-encoding.

For your example the input to the concat demuxer should be something like below (note that the same file name is used for different fragments):

cut.ffconcat

ffconcat version 1.0

file input.mp3
inpoint 0.0
outpoint 30.69

file input.mp3
inpoint 31.18
outpoint 34.31

...

ffmpeg command line:

ffmpeg -i cut.ffconcat -codec copy cut.mp3

In my experiment (250 5-second segments cut from a 42 minute long mp3 file) the runtime difference was more than 3x: the concat demuxer + stream copy approach took 36 seconds vs 110 seconds of your atrim + concat filters solution.

Note, however, that the cutting accuracy may be worse when utilizing the concat demuxer approach (I suspect that it will cut only at the audio frame boundaries).

user_63941380
Related