GNOME Bugzilla – Bug 687899
queue event handling broken with unlinked queue and sticky events
Last modified: 2012-12-12 16:34:01 UTC
Created attachment 228438 [details] [review]
patch and test case
Segment seeking seems to be broken in 1.0 when you use decodebin with a file having audio and video but only audio or video are linked.
Seems to be a bug in queue, which returns FALSE in gst_queue_sink_event for sticky events while as far as I understand it, it should fail at the next gst_pad_push so that upstream can see that the queue is NOT_LINKED and aggregate properly.
Test case and proposed fix attached.
Review of attachment 228438 [details] [review]:
@@ +781,3 @@
+ if (!GST_EVENT_IS_STICKY (event) ||
+ GST_EVENT_TYPE (event) == GST_EVENT_EOS)
+ goto out_flushing;
Shouldn't this be a better label? It's not flushing, it's an error... having different debug output for that would be useful.
Other than that this looks good to me
Author: Alessandro Decina <firstname.lastname@example.org>
Date: Mon Oct 29 12:08:31 2012 +0000
queue: don't fail in _sink_event for sticky events
Implement the same behaviour as gst_pad_push_event when pushing sticky events
fails, that is don't fail immediately but fail when data flow resumes and upstream
can aggregate properly.
This fixes segment seeks with decodebin and unlinked audio or video branches.
Hrm, this does not bode well for CAPS events when downstream flow was not-negotiated, does it? (nor did it before, of course, just wondering)
What do you mean exactly? I guess CAPS should clear ->srcresult and try to renegotiate?
(In reply to comment #4)
> What do you mean exactly? I guess CAPS should clear ->srcresult and try to
Alessandro, Tim? Anything that needs to be done here or should be done?