GNOME Bugzilla – Bug 328491
Sending FLUSH_START blocks in GstCollectPads
Last modified: 2006-02-06 21:34:37 UTC
To reproduce: Consider a GstCollectPads based-element (e.g. muxer) whose pads are being fed by various task-based elements, say GstQueue in sequel. Very likely, all but one of these tasks are always kept waiting in gst_collect_pads_chain as the one-element queue (for the pad) has a buffer. Now consider a FLUSH_START going through the pipeling (e.g. part of FLUSHing seek); it arrives at GstQueue, which forwards the event to unblock its task (if needed). GstCollectPads ignores this, keeps the task waiting, after which GstQueue tries to gst_pad_pause_task(), which blocks the event'ing thread. Also, if any of the "feeding" tasks does stop, the "imbalance" keeps GstCollectPads waiting, blocking the pipeline.
Created attachment 58051 [details] [review] Possible patch. Resolves bug by letting GstCollectPads respond to FLUSH_START/STOP (by stopping to collect and unblock tasks in chain functions).
Created attachment 58052 [details] [review] Possible patch (alternative) This patch does roughly the same as the previous, though: - it releases blocked tasks (and re-starts) one-by-one, rather than all at once - as a disadvantage, it is a bit more "invasive" in GstCollectData
Fixed in CVS HEAD.