After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 786175 - glupload/glsink: Missing draining support
glupload/glsink: Missing draining support
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.13.x
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 786051
Blocks:
 
 
Reported: 2017-08-11 20:08 UTC by Nicolas Dufresne (ndufresne)
Modified: 2018-11-03 11:59 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nicolas Dufresne (ndufresne) 2017-08-11 20:08:02 UTC
V4L2 in it's archaism requires that all buffers produced are returned before the driver can re-allocate buffers (renegotiate the frame size). This problem is solved by draining (returning back) all buffers when an allocation or drain query passes buy. This has been implemented properly in kmssink. The following pipeline currently fails on the first renegotiation:

  gst-launch-1.0 v4l2src io-mode=dmabuf ! glimagesink

This work is not trivial and may require few iteration. My plan is to move the EGLImage cache inside the glupload object (needed anyway as the current cache with qdata is not thread safe). This will also clearing the cache when an allocation query, or a drain query is received.

That will help, but won't be sufficient, as the glupload element simply attach the imported buffer to a new buffer (it's half pass-through). We'll need to make sure that it runs in return a downstream allocation query. glvideoconvert would need to do the same when running asynchronously (sync fence) and finally the sinks themself need to copy their render buffer for potential redraws during the process. I think all this should be condition (e.g. sink can check if the render buffer has a parent buffer).
Comment 1 Julien Isorce 2017-09-11 07:59:27 UTC
Title should be "Incomplete drain support for the 'import dmabuf into EGLImage' path".

For others cases like EGLimage from texture I believe the following is enough: https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/gstglimagesink.c#n1086 (ex: omxh264dec ! glimagesink)
Comment 2 Nicolas Dufresne (ndufresne) 2018-03-26 17:49:10 UTC
(In reply to Julien Isorce from comment #1)
> Title should be "Incomplete drain support for the 'import dmabuf into
> EGLImage' path".
> 
> For others cases like EGLimage from texture I believe the following is
> enough:
> https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/
> gstglimagesink.c#n1086 (ex: omxh264dec ! glimagesink)

-base now, and it's using the wrong trigger. Using drain query is discourage and also much slower then allocation query.
Comment 3 Nicolas Dufresne (ndufresne) 2018-03-26 17:49:52 UTC
I forgot, also this code only works if you have glimagesink, you need support for draining everywhere buffers are kept.
Comment 4 GStreamer system administrator 2018-11-03 11:59:09 UTC
-- 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-base/issues/376.