[FFmpeg-devel] [PATCH 1/2] avfilter: Implement graph_run_once_find_filter() in O(1)
michael at niedermayer.cc
Fri May 27 16:26:56 CEST 2016
On Fri, May 27, 2016 at 03:37:49PM +0200, Nicolas George wrote:
> Le nonidi 9 prairial, an CCXXIV, Michael Niedermayer a écrit :
> > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> > ---
> > libavfilter/avfilter.c | 53 +++++++++++++++++++++++++++++++++++++------
> > libavfilter/avfilter.h | 8 +++++++
> > libavfilter/avfiltergraph.c | 31 ++++++++++++-------------
> > 3 files changed, 68 insertions(+), 24 deletions(-)
> Is there any point to the series? Do you know of people using huge graphs
> where it makes a difference?
ATM with 10 filters this is 100 times slower than 1 filter
with 100 filters its 10000 times slower than 1 filter
with 1000 fiters its 1000000 times slower than 1 filter
no i dont know if someone uses it with 1000 filters, probably not
but i wouldnt expect such behavior from a generic filter framework
> It conflicts hugely with my efforts to remove recursiveness from
> filter_frame() (which is now working for normal filtering but is not yet
> completed with regard to EOF and error propagation, but it I stumbled on a
> lot of unexpected pitfalls).
> My plan was to get that working, then simplify the user API (with regard to
> multiple outputs), and only then optimize the scheduling for large graphs.
well, if that patch is incovenient for your work ATM we can drop it.
But i do want this fixed at some point
i am alergic to code thats by a factor of "~n" slower than what can
reasonable easy be done (unless n is somehow bounded and its just
init code or otherwise irrelevant)
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much as the living from the
dead. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel