#10248 closed enhancement (needs_more_info)

large filtergraph yields abysmal performance

Reported by: mldwrp Owned by:
Priority: important Component: ffmpeg
Version: 4.3.5 Keywords: performance, filter_complex, filters
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

This looks like either a bug in design or some configuration mistake: a large filtergraph (I'm stiching small pieces of several streams together, the filtergapth is > 200KB) makes the process run for like 60 hours (with the [correct] result just over 200MB).

You're welcome to examine the offending filtergraph here: https://gist.githubusercontent.com/costa/14aff290d6b30edf131500fc6823147b/raw/37520d452df8ded3649899adf90d0204f8a9f75d/ffmpeg-filtergraph-script

I'm willing to try things if you have any clue, so, any help is greatly appreciated.

p.s. if you're wondering how this filtergraph is generated, see the Ruby FFmpeg-micro-engine gem: https://rubygems.org/gems/ffmprb

Change History (3)

comment:1 by mldwrp, 13 months ago

p.p.s. Why I think it's something that should be fairly easy to fix, and not a general performance issue: I've given the process an overpowered runtime, and it didn't seem CPU, memory or I/O bound — except for one core going at 100% — so, it looked like some control plane sync hotspot bug to me.

comment:2 by Elon Musk, 11 months ago

Using slow aevalsrc, use anullsrc instead to generate silence.

Using bunch of filters like trim and setpts, to do some kind of timeline processing.

Note that probably whole filtergraph is a non optimized mess, like filtering same input and producing same output over and over again just to add more filters in later steps to produce something else.

Also no explanation what is this mess supposed trying to archive.

comment:3 by Elon Musk, 10 months ago

Resolution: needs_more_info
Status: newclosed
Note: See TracTickets for help on using tickets.