From 05e957106f7c23255e6cb908a547e7214a9f8540 Mon Sep 17 00:00:00 2001 From: Thiago Santos Date: Wed, 2 Apr 2014 07:20:43 -0300 Subject: [PATCH] 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 --- gst-libs/gst/video/gstvideodecoder.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/gst-libs/gst/video/gstvideodecoder.c b/gst-libs/gst/video/gstvideodecoder.c index 0c159a0abb..d9c1155d6d 100644 --- 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;