videodecoder: do not deactivate the bufferpool, just unref

Videodecoder does late renegotiation, it will wait for the next
buffer before renegotiating its caps and bufferpool. It might happen
that downstream element switched from passthrough to non-passthrough
and sent a reconfigure upstream (that caused this renegotiation).
This downstream element will ask the video sink below for the bufferpool
with an allocation query and will get the same bufferpool that
videodecoder is holding, too.

When renegotiating, if videodecoder deactivates its bufferpool it
might be deactivating the bufferpool that some element downstream
is using and cause the pipeline to fail.

https://bugzilla.gnome.org/show_bug.cgi?id=727498

diff --git a/gst-libs/gst/video/gstvideodecoder.c b/gst-libs/gst/video/gstvideodecoder.c
index 0c159a0..d9c1155 100644 (file)
--- a/gst-libs/gst/video/gstvideodecoder.c
+++ b/gst-libs/gst/video/gstvideodecoder.c
@@ -3250,7 +3250,12 @@ gst_video_decoder_negotiate_pool (GstVideoDecoder * decoder, GstCaps * caps)
   decoder->priv->params = params;
 
   if (decoder->priv->pool) {
-    gst_buffer_pool_set_active (decoder->priv->pool, FALSE);
+    /* do not set the bufferpool to inactive here, it will be done
+     * on its finalize function. As videodecoder do late renegotiation
+     * it might happen that some element downstream is already using this
+     * same bufferpool and deactivating it will make it fail.
+     * Happens when a downstream element changes from passthrough to
+     * non-passthrough and gets this same bufferpool to use */
     gst_object_unref (decoder->priv->pool);
   }
   decoder->priv->pool = pool;