GNOME Bugzilla – Bug 745730
gl: Putting GstGLAllocator as first allocator in ALLOCATION query
Last modified: 2016-11-15 03:46:52 UTC
Currently GL elements are putting the GstGLAllocator as the first allocator in the ALLOCATION query. As long as the caps contain the GL caps feature that is completely ok, but otherwise not. What can happen otherwise is that the GL allocator is tried to be set on a GstVideoBufferPool or GstBufferPool, which then completely fails because GstGLAllocator can't use the normal GstAllocator::alloc() function. For sysmem caps, only allocators that work normally should be at the first position.
Situation here is the following: - glvideomixer configures its pool, min-buffers=0 - videotestsrc gets this pool and a corresponding allocator from the allocation query - videotestsrc tries to change the pool config (and deactivates the pool used by glvideomixer!), setting min-buffers=1. That fails because there is still one outstanding buffer - basesrc falls back to create a GstBufferPool and tries to use the GstGLAllocator on that - fails to allocate buffers when starting the new pool It also seems dangerous that glvideomixer provides its own pool to upstream. Its own pool can already be configured, and upstream might want to configure it differently. Especially all upstreams might want to configure it differently!
IMHO the way how pool sharing is implemented in glvideomixer does not make sense as is. There must be a different pool for every upstream as they might have different settings and would trip on each other otherwise.
Also seen by me, can't remember what pipeline would trigger this.(In reply to Sebastian Dröge (slomo) from comment #2) > IMHO the way how pool sharing is implemented in glvideomixer does not make > sense as is. There must be a different pool for every upstream as they might > have different settings and would trip on each other otherwise. Ok, I have patches that rewrite this pool sharing in another bug. I can remove the pool cache if you think it's preferred. Though, I only fixed it since I could not find a valid scenrio to make it break. https://bugzilla.gnome.org/show_bug.cgi?id=745705
That looks very related, but you didn't touch glvideomixer/glmixer :)
Workaround is btw to drop all ALLOCATION queries on the sinkpads of glvideomixer via a pad probe
The main part of this is fixed by bug #745705 now. What remains is that it's not a good idea to put the GL allocator into the beginning of the allocation query for sysmem caps because of the beforementioned reasons. Less critical now as it would only cause problems in special situations or error cases :)
This doens't seem like a problem anymore :) https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/gstglupload.c?id=dcc7ab25f3e6771fc15d44fc90fc4b2bde9f95d4#n321 Closing.