GNOME Bugzilla – Bug 745705
glfilter: GLBuffer pool may have two owners
Last modified: 2015-03-07 01:15:51 UTC
glfilter can do passthrough, but not in-place. Though, the propose_allocation query behaves like if we are doing in-place by chaining the allocation query. So if you have a pipeline like this: src ! glfilter ! glimagesink The glimagesink pool will be used twice. Since glimagesink do pool caching, the same pool is returned each time. Which mean src and filter are now ownner of the pool. If I dynamically remove filter, src is still using the glpool, but filter will have called gst_buffer_pool_set_active(pool, FALSE) on it. This turns the pool into flushing state, and makes src thread quit.
Created attachment 298666 [details] [review] [PATCH] glimagesink: Only cache pool, don't manage it GLImage does not use any kind of internal pool. There was some remaining code and comment stating that it was managing the pool, and it was in fact setting the active state when doing to ready state. * Only create the pool if requested and in propose_allocation * Cache the pool to avoid reallocation on spurious reconfigure * Don't try to deactivate the pool (we don't own it) https://bugzilla.gnome.org/show_bug.cgi?id=745705 --- ext/gl/gstglimagesink.c | 99 +++++++++++++++++-------------------------------- 1 file changed, 35 insertions(+), 64 deletions(-)
Created attachment 298667 [details] [review] [PATCH] glfilter: Don't chain downstream pool Chaining a downstream pool would lead to two owner of the same pool. In dynamic pipeline, if one owner is removed from the pipeline the pool will be stopped, and the rest of the pipeline will fail since the pool will now be flushing. Also fix proposed pool caching, filter->pool was never set, never unrefed. https://bugzilla.gnome.org/show_bug.cgi?id=745705 --- gst-libs/gst/gl/gstglfilter.c | 82 +++++++++++++++++-------------------------- 1 file changed, 33 insertions(+), 49 deletions(-)
GLMixer was also having similar issue. Except that since there should be multiple upstream pool, caching on the mixer object is not right. The actual copy pasted caching code was picking the downstream pool. commit 2d5d2eabef8023fadb355ba286b0ff89eede8c83 Author: Nicolas Dufresne <nicolas.dufresne@collabora.com> Date: Fri Mar 6 20:11:00 2015 -0500 glmixer: Don't share our downstream pool with upstream Pool cannot have multiple owner. This can lead to spurious pool was flushing error. https://bugzilla.gnome.org/show_bug.cgi?id=74570 commit 7a3b34de7922f6c05a15615292c1317adc86db03 Author: Nicolas Dufresne <nicolas.dufresne@collabora.com> Date: Thu Mar 5 16:28:36 2015 -0500 glfilter: Don't chain downstream pool Chaining a downstream pool would lead to two owner of the same pool. In dynamic pipeline, if one owner is removed from the pipeline the pool will be stopped, and the rest of the pipeline will fail since the pool will now be flushing. Also fix proposed pool caching, filter->pool was never set, never unrefed. https://bugzilla.gnome.org/show_bug.cgi?id=745705 commit fb4d7694255206ceaa81d8e7ff2a6ee3aa08c19a Author: Nicolas Dufresne <nicolas.dufresne@collabora.com> Date: Thu Mar 5 15:49:50 2015 -0500 glimagesink: Only cache pool, don't manage it GLImage does not use any kind of internal pool. There was some remaining code and comment stating that it was managing the pool, and it was in fact setting the active state when doing to ready state. * Only create the pool if requested and in propose_allocation * Cache the pool to avoid reallocation on spurious reconfigure * Don't try to deactivate the pool (we don't own it) https://bugzilla.gnome.org/show_bug.cgi?id=745705