[Bug 748344] bufferpool: in renegotation, bufferpool can be given to element while another one still uses it

[GStreamer (GNOME Bugzilla)]

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

--- Comment #2 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
With glimagesink from git master, this isn't an issue, since it does not do
pool caching any-more. This can already be solved by removing pool cache in
x(v)imagesink elements. I think this was introduced to limit the amount of
shared memory being allocated at the same time. Though, it has the side effect
that the second element cannot negotiate the right size, and may risk a
pipeline stall. I think it's safer to just drop that cache from these. Will
solve most use cases.

The remaining will be with element that can only have one pool (v4l2sink,
v4l2videoconvert, future v4l2videoencoder and possibly OMX stuff). In this
case, the most straightforward solution seems to not offer an already in use
pool. This mean that the element moving from passthrough to no-passthrough,
will be using a generic pool. To make this situation transitory, a mechanism
could be added so the element offering the pool can detect when a pool is no
longer in use upstream and suggest a reconfigure upstream.

It was also propose to add an extra API on top of the pool to be able to
transform ownship. This is complex and would require a lot of porting. It may
break ABI also. Adding a way to transfer the ownership does not solve the issue
that the newly negotiated pool may be too small for the new situation, leading
to pipeline stalls.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.