[gstreamer-bugs] [Bug 574289] [decodebin2] race in state change to PAUSED

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=574289

  GStreamer | gst-plugins-base | Ver: git




------- Comment #4 from Mark Nauwelaerts  2009-03-09 15:56 UTC -------
A slightly related race (exposing before fully ok), although not so deadlocky,
might be as follows, if I read/theorize things right.

Consider a typical demuxer with 1 video and 1 audio pad.
When the demuxer is added, no group exists yet.  Then video or audio pad is
connected, and a group is created, and taken along in the sequel.
If caps are not fixed yet, then caps_notify_group_cb will be connected.
This will delegate to pad_added_group_cb, and this one will start expose
machinery as soon as there are no more dynamic objects.  However, this does not
check whether the group is complete (probably yes) or all pads have blocked
(not so necessarily yes).  So, group and pads may be exposed before all has
blocked.
(which may or may not be by design and possibly need not be problematic, but
foregoes checks that are otherwise performed).

In the unlikely case there are more complex elements downstream from the
demuxer, e.g. no-more-pads emitting elements, nbdynamic count might loose track
and grouped pad-added or caps notify might expose (and deblock) before more
blocked pads will be added.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=574289.