After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 687899 - queue event handling broken with unlinked queue and sticky events
queue event handling broken with unlinked queue and sticky events
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Mac OS
: Normal normal
: 1.1.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-11-08 06:39 UTC by Alessandro Decina
Modified: 2012-12-12 16:34 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
patch and test case (3.93 KB, patch)
2012-11-08 06:39 UTC, Alessandro Decina 		needs-work Details | Review

Description Alessandro Decina 2012-11-08 06:39:34 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.
Comment 1 Sebastian Dröge (slomo) 2012-11-09 10:31:16 UTC 
Review of attachment 228438 [details] [review]:

::: plugins/elements/gstqueue.c
@@ +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
Comment 2 Alessandro Decina 2012-11-09 17:44:26 UTC 
commit c257b19eadbff97fac93a163f3d59b07491ffb27
Author: Alessandro Decina <alessandro.d@gmail.com>
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.
    Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=687899
Comment 3 Tim-Philipp Müller 2012-11-09 18:00:55 UTC 
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)
Comment 4 Alessandro Decina 2012-11-10 10:31:14 UTC 
What do you mean exactly? I guess CAPS should clear ->srcresult and try to renegotiate?
Comment 5 Sebastian Dröge (slomo) 2012-12-12 16:34:01 UTC 
(In reply to comment #4)
> What do you mean exactly? I guess CAPS should clear ->srcresult and try to
> renegotiate?

Alessandro, Tim? Anything that needs to be done here or should be done?