GNOME Bugzilla – Bug 786133
qmlglsink: Retain the previous frame to avoid flickering artifacts
Last modified: 2018-11-03 15:21:26 UTC
With some GstGL uploaders - especially the ones based on DMABUF - it is possible that flickering artifacts can occur with qmlglsink. This happens because upstream writes into the dmabuf at the same time when the frame in that dmabuf is being painted on screen. By retaining the gstbuffer for one more frame, this is avoided, since the gstbuffer is not released back into the upstream dmabuf buffer pool until the frame is drawn. Note that glimagesink does something similar, which is why these flickering artifacts usually do not appear with that sink.
Created attachment 357362 [details] [review] qmlglsink flickering artifacts patch
Comment on attachment 357362 [details] [review] qmlglsink flickering artifacts patch Makes sense but probably means that we should signal that we need more buffers in the allocation query (propose_allocation vfunc).
Makes sense. However, I compared glimagesink and qmlglsink'S propose_allocation vfuncs, and both issue calls like: gst_query_add_allocation_pool (query, pool, size, 2, 0); Shouldn't this then be 3 instead 2 for both sinks?
In general, we try and let upstream account for the in-flight buffer, so I'd say two. Just as a reminder, this is of course a work around, it's not guaranteed it will always work. Long term solution would be to add a fence after the render, and wait for that fence before releasing.
(In reply to Nicolas Dufresne (stormer) from comment #4) > Just as a reminder, this is of course a work around, it's not guaranteed it > will always work. Long term solution would be to add a fence after the > render, and wait for that fence before releasing. This is true for both glimagesink and qmlglsink (with this patch applied), right? I propose this as a workaround until the fence functionality is stable in mesa. Perhaps some FIXME notes in both sinks as a reminder would be good.
Err, I correct myself - this is only temporary for dmabuf-based uploaders, since we can expect that eventually there will be fence support. This is not true of the Vivante direct texture uploader for example - we'll never have fences there. So, instead, let's combine them; use fences when possible, and have this extra buffer as a fallback.
GL Fences are stable. We already use them to wait for conversion to texture to complete before rendering them in a different GL Context. Right now, we place it after the conversion in the operation queue, but for out fence, the renderer need to place one later. Then it keeps the fence around, wait for the next buffer to arrive, queue it's rendering, and finally wait for the last-buffer fence before calling un-ref. This would work for any direct upload extensions, including Vivante, NV and DMABuf/EGLImage. The new DMA Fences mechanism is not needed to solve this issue in GL, but could of course simplify things a bit, as waiting for the fence is then left to the upstream pool to do.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/396.