mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-29 05:01:23 +00:00
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
This commit is contained in:
parent
169166d0a2
commit
05e957106f
1 changed files with 6 additions and 1 deletions
|
@ -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;
|
||||
|
|
Loading…
Reference in a new issue