GNOME Bugzilla – Bug 532944
collectpads: Has no special support for live streams
Last modified: 2015-01-01 17:37:26 UTC
Hi, GstCollectPads currently has no special support for live streams. With live streams it can easily happen, that you don't get any new buffers for a longer time. When using GstCollectPads this means, that the complete element will stall, no matter if other pads still get buffers or not, until the single live stream that has no new buffers finally gets one again. For this reason farsight currently has a liveadder element. A solution for this would be a timeout when collecting buffers, but this would probably be an ABI incompatible change (elements are expecting one non-NULL buffer for every pad).
Imho, GstCollectPads are not the right way to go for live, discontinuous streams. Because they completely ignore timestamps, and we have no guarantee that the first buffer to arrive on each pad matches exactly the buffers coming from the other pads. I'm pretty sure we could have a baseclass for smart/live mixer/muxer elements that could take parts of the GstCollectPads, but have a queue on each pad and then wait for some time or wait until all there is data on all pads for non-synced pipelines. And hide all the magic and provide the the buffers to mix/mux to some function. Or maybe do like the liveadder (which does the mixing in the chain function then keeps the mixed result in a queue to wait for more stuff to come in).
A timeout on pad collect could work but then we also need buffering on the pads that do receive data or else we would block them. It's probably, as said in Comment #1 not a good idea to use collectpads for this use case.
IMHO all these "muxing" scenarios should somehow be solved by a single element (and not by having something like adder and liveadder). For this collectpads has to be improved
*** This bug has been marked as a duplicate of bug 739010 ***