GNOME Bugzilla – Bug 727498
videodecoder: deactivates downstream bufferpool
Last modified: 2014-04-07 08:15:02 UTC
In playbin, we end up with the following branch: videodecoder ! ... ! deinterlace ! ... ! videosink When changing from or to passthrough, deinterlace currently renegotiates and might discard or acquire a new bufferpool. When it changes from passthrough to non-passthrough it acquires a new bufferpool provided by the videosink. This same bufferpool is also being used by the videodecoder because it does a late renegotiation (only when the next buffer arrives) and when it renegotiates it will deactivate its current bufferpool before asking for another one. This bufferpool is the same that is being used by deinterlace and it will fail on the next buffer with FLUSHING when trying to get a buffer. To prevent this, videodecoder should not deactivate the buffer pool when renegotiating, it will be deactivated by itself when it is freed.
Created attachment 273483 [details] [review] 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.
Reproducible with file from https://bugzilla.gnome.org/show_bug.cgi?id=596772
commit 05e957106f7c23255e6cb908a547e7214a9f8540 Author: Thiago Santos <ts.santos@sisa.samsung.com> Date: Wed Apr 2 07:20:43 2014 -0300 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
Interesting, that means the sink is handing over active pool, hence a pool that cannot be configured. If max is not 0, that seems rather dangerous. We will have to dig into that at some point.
(In reply to comment #4) > Interesting, that means the sink is handing over active pool, hence a pool that > cannot be configured. If max is not 0, that seems rather dangerous. We will > have to dig into that at some point. Can you open a new bug about that problem so we don't forget?