filter_complex very slow when stitching together many fragments

[Stefan]

Summary of the bug:

complex_filter turns very slow when splicing a long video into parts and re-assembling them using complex_filter.

The script contains 894 parts which are taken from one input video and assembled into a new one. When I run the command as shown, it starts with less .01x realtime speed and very slowly goes up to around .1x. It keeps climbing, but only very slowly. I noticed ffmpeg also doesn't use all the cores anymore (only around 1.5 cores).

When I take less of those 894 parts, e.g. only 300, ffmpeg is noticeably faster. With less than 100 parts, it runs in more than realtime as I expect it to.

How is this explained? I can see no logical reason for this behavior, processing speed should stay high even with many fragments (they are not getting shorter, there are just fewer of them).

It really hinders my video editing of large videos using ffmpeg, so I think this is an actual bug.

How to reproduce:

% ffmpeg  -y -i winograd2-amp.mkv -filter_complex_script script.txt -map [outv] -map [outa] winograd2-amp-cut.mkv

with this file: https://botcompany.de/files/1400345/complex-script.txt

ffmpeg version 3.4.6-0ubuntu0.18.04.1
built with gcc 7 (Ubuntu 7.3.0-16ubuntu3)

I can provide the input .mkv on request.

[Carl Eugen Hoyos]

Why do you believe that there is an issue that can be fixed in FFmpeg?

[Carl Eugen Hoyos]

And please test current FFmpeg git head, nothing else is supported here.

[Stefan]

@cehoyos Because it shouldn't be that slow. Why is a processing operation that usually runs in ~1.6x speed suddenly running at .12x or less when I basically do the same operation on a longer video?

What do you mean with "needs_more_info"? Do you need the original video?

[Carl Eugen Hoyos]

Please test current FFmpeg git head and provide not only the command line you tested but the command line together with the complete, uncut console output.

[Elon Musk]

Missing info about input codecs of input file.