[gstreamer-bugs] [Bug 316248] linking two parallel chains hangs

[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=316248

  GStreamer | gstreamer (core) | Ver: HEAD CVS




------- Comment #10 from Stefan Kost (gstreamer, gtkdoc dev)  2007-05-21 20:00 UTC -------
I've investigated this further. The root-problem is that both tee and adder are
using gst_pad_proxy_getcaps(). Regarding gst_pad_proxy_getcaps() I wonder if
this should use gst_element_iterate_[src|sink}_pads() depending on
pad-direction rather that gst_element_iterate_pads(). I've tried it, but it
doesn't solve the problem.

After adding more logging to intersect_caps_func() I notices that it hangs when
calling gst_pad_peer_get_caps(). If I now look at the get_caps() function of
the elements in question (basetransform and queue) that again calls
gst_pad_peer_get_caps() and so it seems that the gst_pad_peer_get_caps() calls
comming from tee and adder hit each other.

When apply this change in queue and basetransform:
+  if (GST_OBJECT_TRYLOCK(otherpad)) {
+    GST_OBJECT_UNLOCK (otherpad);
    result = gst_pad_peer_get_caps (otherpad);
+  }
+  else {
+    result=NULL;
+    GST_WARNING ("  lock problem for link %s:%s and %s:%s",
+      GST_DEBUG_PAD_NAME (pad), GST_DEBUG_PAD_NAME (otherpad));
+  }

I does not lock anymore, but it loops forever. What totally puzzles me is that
I don't get the GST_WARNING() though.

Another attempt
-  result = gst_pad_peer_get_caps (otherpad);
+  {
+    GstPad *peerpad = GST_PAD_PEER (otherpad);
+    if(peerpad) {
+      result = gst_pad_get_caps (peerpad);
+    }
+    else result = NULL;
+  }
basically a nonblocking version of gst_pad_peer_get_caps(). As expected it does
not block, but neither does it terminate - it loops forever too.

Conclussion for tonight. We seem to need a token to detect the cycle and
somehow finish the negotiation for a subgraph, then try next branch and
backtrack if it fails.


-- 
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=316248.