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 734058 - basesrc: pad task started before start_complete when seeking
basesrc: pad task started before start_complete when seeking
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.x
Other All
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-07-31 15:48 UTC by Andrew Oakley
Modified: 2018-11-03 12:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Simple test case (3.37 KB, text/plain)
2014-07-31 15:48 UTC, Andrew Oakley
  Details
Test sending event to the element (3.42 KB, text/x-csrc)
2017-07-04 16:30 UTC, Nicolas Dufresne (ndufresne)
  Details
basesrc: Queue pending seeks if not started yet (1.18 KB, patch)
2017-07-04 16:34 UTC, Nicolas Dufresne (ndufresne)
none Details | Review

Description Andrew Oakley 2014-07-31 15:48:58 UTC
Created attachment 282178 [details]
Simple test case

To reproduce this you need to:
* create a basesrc based source element
* gst_base_src_set_async(src, TRUE)
* gst_element_set_state(src, GST_STATE_PLAYING)
* send a seek event at the pad

The task is now started without having called gst_base_src_start_complete.  This means resource allocation in the start callback may not be complete.

It isn't clear what the plugin could do to handle this other than return failure from the fill function (or similar).  Blocking in the fill function at this point leads to deadlocks.

Looking around gstbasesrc.c it appears there are other ways to trigger this issue.  I suspect that some checks for GST_BASE_SRC_IS_STARTED are required with appropriate locking.

A test case is attached - it shouldn't assert.
Comment 1 Nicolas Dufresne (ndufresne) 2017-07-04 16:29:37 UTC
You test is incorrect though. You should send the seek event to your pipeline, or the src element, not directly to the pad. Receiving a seek on a pad before the start has completed is unexpected.

The bug remains of course, but the fix won't work with by-passing the Bin/Element hierarchy.
Comment 2 Nicolas Dufresne (ndufresne) 2017-07-04 16:30:42 UTC
Created attachment 354892 [details]
Test sending event to the element

This test sends the event to the element, properly doing a seek on ready. Still display the issue, fix coming.
Comment 3 Nicolas Dufresne (ndufresne) 2017-07-04 16:34:32 UTC
Created attachment 354893 [details] [review]
basesrc: Queue pending seeks if not started yet

When async start is enables, we should queue pending seeks to avoid
early start of the streaming thread.
Comment 4 Nicolas Dufresne (ndufresne) 2017-07-04 16:39:39 UTC
That being said, Maybe receiving a seek the initial tested way exist, I'd change the test to use a pipeline and send the seek to the pipeline to see what happens. It's not clear if the seek will fail or cause the same issue.
Comment 5 GStreamer system administrator 2018-11-03 12:21:57 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/70.