bin: If activating one pad failed error out early instead of trying to activate the...
authorSebastian Dröge <sebastian.droege@collabora.co.uk>
Mon, 18 Apr 2011 07:49:04 +0000 (09:49 +0200)
committerSebastian Dröge <sebastian.droege@collabora.co.uk>
Thu, 5 May 2011 10:30:05 +0000 (12:30 +0200)
If one pad fails to activate the complete activation process will fail
anyway and trying to activate the other pads only wastes time.

gst/gstbin.c

index 3007d48..920dc95 100644 (file)
@@ -2191,24 +2191,23 @@ unneeded:
 }
 
 /* gst_iterator_fold functions for pads_activate
- * Note how we don't stop the iterator when we fail an activation. This is
- * probably a FIXME since when one pad activation fails, we don't want to
- * continue our state change. */
+ * Stop the iterator if activating one pad failed. */
 static gboolean
 activate_pads (GstPad * pad, GValue * ret, gboolean * active)
 {
-  if (!gst_pad_set_active (pad, *active))
+  gboolean cont = TRUE;
+
+  if (!(cont = gst_pad_set_active (pad, *active)))
     g_value_set_boolean (ret, FALSE);
   else if (!*active)
     gst_pad_set_caps (pad, NULL);
 
   /* unref the object that was reffed for us by _fold */
   gst_object_unref (pad);
-  return TRUE;
+  return cont;
 }
 
-/* returns false on error or early cutout (will never happen because the fold
- * function always returns TRUE, see FIXME above) of the fold, true if all
+/* returns false on error or early cutout of the fold, true if all
  * pads in @iter were (de)activated successfully. */
 static gboolean
 iterator_activate_fold_with_resync (GstIterator * iter, gpointer user_data)