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 747442 - tsdemux: lacks locking in the seeking code
tsdemux: lacks locking in the seeking code
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 735100
Blocks:
 
 
Reported: 2015-04-07 11:33 UTC by Vincent Penquerc'h
Modified: 2018-11-03 13:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Vincent Penquerc'h 2015-04-07 11:33:39 UTC 
+++ This bug was initially created as a clone of Bug #735100 +++

Comment from ocrete in the original bug:

Not specific to this patch, but it seems the whole tsdemux has no locking at all in the seeking code, so we shouldn't be surprised if seeking sometimes exhibits random behaviours...
Comment 1 Jan Schmidt 2016-11-15 14:14:36 UTC 
This comment only seems valid when operating in push mode. In pull mode, the base class will shut down streaming and acquire the stream lock before asking the sub-class to handle the seek.

In push mode, there's a potential problems because gst_ts_demux_do_seek() is called without the stream lock and could crash if the program / streams list changes simultaneously. 

There are more fundamental problems with that seek handling in push mode though, in that it modifies the state of the streams and segments and things as if the seek had already happened, when the event isn't sent upstream until after, and indeed may then remain pending for some time.
Comment 2 GStreamer system administrator 2018-11-03 13:33:27 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/gst-plugins-bad/issues/232.