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 <mich...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
