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 785142 - basesrc: Sending eos maybe block for a small period or if pipeline is PAUSED
basesrc: Sending eos maybe block for a small period or if pipeline is PAUSED
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.13.x
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 752815
 
 
Reported: 2017-07-19 17:43 UTC by Nicolas Dufresne (ndufresne)
Modified: 2018-11-03 12:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Nicolas Dufresne (ndufresne) 2017-07-19 17:43:30 UTC 
While fixing bug #783301 I had to make a small thread-off. So now, instead of blocking forever in unpredictable condition, this call may block for a short period of time (or as long as the pipeline is paused).

This is a side effect of having to unlock/unlock_stop the source and not flushing downstream. This is needed to handle the case where we have udpsrc in the pipeline that isn't receiving data. In that case, the queued eos event would never be handled.

A possible solution would be to queue the EOS, and run the unlock/unlock_stop sequence asynchronously. Assuming we make sure the ref-count is done properly, and that we clearly the pending EOS is fully thread safe, I believe that gst_element_call_async() could be used. Obviously, large testing will be needed again.

We should probably have a look at bug #752815 while at it, as it seems fairly similar, at least at first sight.
Comment 1 GStreamer system administrator 2018-11-03 12:42:07 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/246.