[FFmpeg-devel] [PATCH 1/2] avfilter: Implement graph_run_once_find_filter() in O(1)

Michael Niedermayer 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...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160527/12b0b327/attachment.sig>

More information about the ffmpeg-devel mailing list