GNOME Bugzilla – Bug 797100
aggregator: allocation query management makes buffering suboptimal when using dynamic/live pipelines
Last modified: 2018-11-03 12:48:02 UTC
Since we implemented downstream allocation negotiation support in Bug 746529, reconfiguring videoaggregator/compositor blocks downstream on the allocation query (basically until the queued data has been processed) meaning that no further data processing can happen meanwhile. That makes queuing way less effective and in NLE/Pitivi for example it leads to bad "perfs". We should find a way to make renegotiation happen as soon as required and not block that way downstream.
A property for this could be added, or we could document that an identity with drop-allocations=true should be placed right after the compositor in such situations. Both seem more like a hack than anything else though.
(In reply to Sebastian Dröge (slomo) from comment #1) > A property for this could be added, or we could document that an identity > with drop-allocations=true should be placed right after the compositor in > such situations. > > Both seem more like a hack than anything else though. Right, sounds like a hack to me, probably a useful one but I wonder if we could mitigate the drawback of that solution. Maybe behind a property we could try to figure out if the previous allocation query result can be reused and do so if it is the case? Dropping the query all together otherwise. If it is the first negotiation, always do the query. I have not looked deeper into how that could be done yet.
The trade-off is the following. If you are using a downstream allocation, it's possible you'll be holding on a dead object by using it's pool. I don't think we have a mechanism to know right now if the downstream element have changed. It comes back to the "pool reclaiming" problem. Also, if the new downstream offer a pool that works in zero copy and you were not yet operating that way, you also endup in sub-optimal situation if you skip allocation. Though, if the caps haven't change, and you already have an optimal allocation, the serialized query is particularly harmful. That of course does not prevent that we may have a bug in the new allocation code that may be making everything worst (e.g. sink pad can't queue while src pad thread is blocked).
In the aggregator design, the only way a sub-class can prevent an allocation query is to not to call set_src_caps() needlessly. The problem is that the caps may change without a need for re-allocation.
Ok, looking deeper, the allocation is really dummy. As soon as we get a reconfigure event from downstream, we will call set_src_caps() again, which will run a new allocation query. Adding code to skip this if the caps haven't changed (trading off the details I mention) will greatly improve performance. I'm pretty sure the caps aren't changing often in GES use case (and most use cases in fact). Holding on downstream allocation is only an issue for V4L2 and OMX, which only have 1 set of allocated buffers.
I didn't find any videoaggregator specific code involved.
(In reply to Nicolas Dufresne (ndufresne) from comment #5) > As soon as we get a reconfigure event from downstream, we will call > set_src_caps() again, which will run a new allocation query. This is required however to catch the "downstream element is dead" case you mention above. When relinking you get a reconfigure event from downstream, then can query again and possibly get a reply from e.g. a new sink element.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/310.