GNOME Bugzilla – Bug 665525
[0.11] Pad with probe won't forward flush events even though it's not blocking yet
Last modified: 2012-02-18 20:16:21 UTC
Created attachment 202734 [details] [review] Patch to forward flush events when the pad has blocking probe but is not yet blocking. The following code doesn't seem right case GST_EVENT_FLUSH_START: GST_PAD_SET_FLUSHING (pad); if (G_UNLIKELY (GST_PAD_IS_BLOCKED (pad))) { /* flush start will have set the FLUSHING flag and will then * unlock all threads doing a GCond wait on the blocking pad. This * will typically unblock the STREAMING thread blocked on a pad. */ GST_LOG_OBJECT (pad, "Pad is blocked, not forwarding flush-start, " "doing block signal."); GST_PAD_BLOCK_BROADCAST (pad); goto flushed; } break; GST_PAD_IS_BLOCKED (pad) is true even if pad is not blocking yet, so the condition is signaled in vain. Changing the check to GST_PAD_IS_BLOCKING (pad) fixes it Same goes for FLUSH_STOP. Although I'm not sure how the pad could get blocked while being flushed.
This is intentional, as soon as a blocking probe is added, no new flush events go through. is this causing a particular problem for you? Why d you think this is wrong?
It deadlocks the pipeline. I have pipeline like this (example) [Element1] -> [Queue] -> [Sink] The sink is temporarily unable to render buffers so it's stalling the pipeline. The queue is full. I want to add downdstream block probe to element1 srcpad and flush the pipeline. I add the probe, but it is not invoked because the pipeline is taller because of the sink. That would normally be okay as I'm flushing the pipeline (seek), but in this case it won't work. The seek start will never get to the queue. It would get there once the probe starts blocking, but that doesn't happen because the pipeline is congested.
s/taller/stalled
s/seek start/flush start. sorry
Also a probe might be blocking, but it can also return PASS and DROP. So even though there is a BLOCK probe attached to pad it doesn't necessarily have to block it, does it?
Created attachment 202862 [details] [review] Add GST_PAD_PROBE_TYPE_BLOCKING The patch add new probe type GST_PAD_PROBE_TYPE_BLOCKING The probe has the type set it will be invoked for flush events and can return GST_PROBE_DROP that will prevent the flush event to be sent further down If the pad probe doesn't have GST_PAD_PROBE_TYPE_BLOCKING set the flush event is forwarded automatically (the probe won't be invoked for flush events)
Created attachment 202865 [details] [review] Add GST_PAD_PROBE_TYPE_HANDLE_FLUSH
Thanks, I renamed the move the event to match the other event types. commit 8e6b5f79bd0182e8582b8e18a97b095bd3c74b55 Author: Matej Knopp <matej.knopp@gmail.com> Date: Mon Dec 5 21:20:52 2011 +0100 Add GST_PAD_PROBE_TYPE_HANDLE_FLUSH