GNOME Bugzilla – Bug 314146
adder and audioconvert spend too much time negottiating caps
Last modified: 2005-11-30 15:36:59 UTC
when creating the following pipeline: filesrc -- mad -- audioconvert --- adder -- alsasink filesrc -- mad -- audioconvert | ... filesrc -- mad -- audioconvert | filesrc -- mad -- audioconvert -/ gstreamer spends an unrealistically long time negotiating the caps, persumably between the audioconvert and the adder elements. the probably cause of the problem is that all the caps are very open, for alsasink, adder and audioconvert, and the caps functions return a very wide range of options all the time, resuling in a bouncing back-and-forth of the negotiation. it also seems that the increase in CPU time spent in the negotiation increases exponentially with the increase in the number of sources. the following are figures for a 5 sec mp3 file as filesrc (the same file for all the soruces): 1 source: real 0m6.497s user 0m1.237s sys 0m0.015s 2 sources: real 0m8.747s user 0m3.369s sys 0m0.020s 3 sources: real 0m11.948s user 0m6.438s sys 0m0.012s 4 sources: real 0m15.424s user 0m10.448s sys 0m0.023s it's visible that for 4 sources, more than 8 seconds are spent just for the negitiation. when profiling a sample application, it turns out that most of time time spent is in the list operations of capabilities lists, which remain queried all the time, and remain long for qute a long time. what would be a way to force certain caps on these elements? say one could force alsasink and the src of adder to be a say audio/x-raw-float (44.1KHz, 2 channels), and this could be propagated backwards to the audioconverts. this would prevent the long caps-negogiation from happening.
Created attachment 51100 [details] a sample application demonstrating the issue
see the related bug in the LiveSupport bug database: http://bugs.campware.org/view.php?id=1229
I got the tip that I should use gst_element_link_filtered() instead of simple gst_element_link(), and that would reduce the negotiation time. while it indeed does so, all is still tooo slow. my results are the following (see the attached source code example): changing: gst_element_link(adder, sink); gst_bin_add_many(GST_BIN(pipeline), adder, sink, NULL); to: gst_element_link_filtered(adder, sink, caps); gst_bin_add_many(GST_BIN(pipeline), adder, sink, NULL); reduces the user CPU time for 4 sources from 10+ seconds to about 5: real 0m9.752s user 0m4.806s sys 0m0.019s furthermore changing: gst_element_link(converter[i], adder); to: gst_element_link_filtered(converter[i], adder, caps); has a marginal effect (4.8 sec -> 4.6 sec): real 0m9.561s user 0m4.602s sys 0m0.011s while filtering the decoder -> converter link as well by a set capability reduces the user time to 2 seconds: real 0m7.008s user 0m2.083s sys 0m0.012s (but then, there's no real need for the converter, is there?) but this is all too long still, waiting almost 2 seconds for the playing to start.
Created attachment 51372 [details] a sample with gst_element_link_filtered() calls
I also tried to call gst_pad_perform_negotiate() for some links, but it always returns false. it seems that negotiation can not be forced to made, it will always happen at the first call to gst_bin_iterate(). my idea was to force link negotiation before the chains are build up totally, so that there are not that long chains to traverse during the negotiation. as the adder element expects all sources to be of the same audio format, I expected to force the same format on all elements plugged in to the adder, one-by-one. this way, all negotiation is done on shorter chains, and then everything is just added together at the end.
Created attachment 51375 [details] [review] patch adding a 'caps' property to the adder element this patch adds a 'caps' property to the adder element, which, if specified will force the adder to use and enforce that GstCaps on all pads. this makes negotiation a lot faster.
Akos, do you still care about this bug? Obviously our focus is on 0.10 now.
naturaly not, I'm in the process of migrating to 0.9 myself..