GNOME Bugzilla – Bug 642373
[basetransform] Avoid too may pad allocs
Last modified: 2011-02-22 12:48:29 UTC
Everytime basetransform gets a buffer it does a pad-alloc downstream to check for caps renegotiation feedback, this happens even on passthrough mode. Now, take the following pipeline: videotestsrc ! ffmpegcolorspace ! videocrop ! videoscale ! ffmpegcolorspace ! fakesink What happens: 1) Videotestsrc pad-allocs its buffer, and pushes. 2) The first ffmpegcolorspace gets the buffer on its chain, and does a pad-alloc, discards the alloc'ed buffer as it is on passthrough and pushes the original buffer. 3) videocrop does the same 4) videoscale does the same 5) The second ffmpegcolorspace does the same 6) The sink renders the buffer As you can see, we have too many pad allocs hapenning here. I'm attaching a test application to show this problem. We can't simply stop basetransform from pad-alloc'ing (even on passthrough) because we probably rely on it for renegotiation scenarios, but we can try to make it smarter and get the "pad-allocs per buffer received" lower on the sink.
Created attachment 180891 [details] test application Test application that uses a custom sink to count the number of pad-allocs and buffers rendered.
Created attachment 180892 [details] [review] basetransform: Be smarter with pad allocs Avoid doing unnecessary pad-allocs when on passthrough mode. If multiple basetransform elements are on a pipeline, they would do a pad-alloc for each received buffer, each element would do this, so we would have lots of pad allocs on the pipeline for a single buffer being pushed through it. This patch attempts to reduce this amount by avoiding doing pad-allocs if the element has already done it after the last pushed buffer. So it will only be allowed to do a new pad-alloc after it has pushed a buffer, so we get 1x1 pad-alloc and buffer ratio
I don't think that behaviour is correct, just consider a case where you have to allocate multiple buffers before pushing the first one
How? Can basetransform receive a buffer and don't push one downstream? If upstream does a pad-alloc basetransform will pass it downstream just as before the patch. The patch avoids pad-alloc'ing when basetransform gets a buffer on its sinkpad.
Right, ignore my comment, sorry :)
Without looking too closely at the patch yet, could be related to bug #584465
Yes, it looks related. Though the solutions are different.
Comment on attachment 180892 [details] [review] basetransform: Be smarter with pad allocs Patch looks good to me. I don't see any breakage from it (tests and applications).
*** Bug 584465 has been marked as a duplicate of this bug. ***
Pushed. commit 83597767b169dd6c39a07b6144a650c1f098825a Author: Thiago Santos <thiago.sousa.santos@collabora.co.uk> Date: Mon Feb 14 18:05:09 2011 -0300 basetransform: Be smarter with pad allocs Avoid doing unnecessary pad-allocs when on passthrough mode. If multiple basetransform elements are on a pipeline, they would do a pad-alloc for each received buffer, each element would do this, so we would have lots of pad allocs on the pipeline for a single buffer being pushed through it. This patch attempts to reduce this amount by avoiding doing pad-allocs if the element has already done it after the last pushed buffer. So it will only be allowed to do a new pad-alloc after it has pushed a buffer, so we get 1x1 pad-alloc and buffer ratio https://bugzilla.gnome.org/show_bug.cgi?id=642373