GNOME Bugzilla – Bug 725640
context share not stable in Linux + catalyst
Last modified: 2014-03-11 05:34:23 UTC
Created attachment 270869 [details] [review] a temp hack to let glimagesink create shared context Hello, I'm using Qt graphicsScene (draw overlay items) and gst-plugins-gl(draw background) together, and this is the mail original posted :http://lists.freedesktop.org/archives/gstreamer-devel/2014-March/046610.html I found that application random locked when using context share, maybe its a misused code by me or a driver bug. I attach a demo to test this. hopes someone can point out the misused code, or a better solution. if this is a driver bug, maybe we can makes the glimagesink context completely replaceable, that we can deliver any opengl callback to user controlled thread, to avoid thread problem in driver. this demo works as following: Qt part: drawBackground opengl callback create gstreamer pipeline, receive texture through glimagesink's clientDrawCallback Gst part: videotestsrc - > glimagesink , with gst_gl_context_x11_create_context hacked, to create share context from Qt GL thread. you need to patch gst-plugins-gl source . the patch is rebased on 5d4ef5 a better demo may use GstGLFilter->other-context property to create share context, but I'm facing a problem that texture used by GstGLFilter never freed (I'll post another demo here) , so I made a hack ,that glimagesink also create share context.
Created attachment 270870 [details] sources of demo1 simply qmake -pro;qmake;make should work if gstreamer installed into default location
What's the big picture of this? Do you actually need to draw over top of the video? If so, you might need to take a look at the overpainting example here http://qt-project.org/doc/qt-5.0/qtopengl/overpainting.html Otherwise, you can use the videooverlay interface to display your video in a QWidget. See gst-plugins-base/tests/examples/overlay/qt-videooverlay.cpp replacing xvimagesink with glimagesink.
(In reply to comment #0) > Hi, not sure what you are trying to do but in the mean time we have not this https://bugzilla.gnome.org/show_bug.cgi?id=723674 you could also have a look at http://cgit.freedesktop.org/gstreamer/gst-plugins-gl/tree/tests/examples/qt/qglwtextureshare
(In reply to comment #2) > What's the big picture of this? sorry for the unclear question. the demo code and patch is a test to confirm passing texture between shared context is not stable. to make the pipeline simpler ,I tried to make glimagesink also create share context( likes GstGLFilter other-context property). >Do you actually need to draw over top of the video? > If so, you might need to take a look at the overpainting example here > http://qt-project.org/doc/qt-5.0/qtopengl/overpainting.html I am trying to use OpenGL painting over gst-gl processed video , the overpainting example is helpful (and this is the way demo do),but the problem is , I must pass the texture back from gstreamer to qt thread (I think the clientDrawCallback is the only way.) but this leads random lock (the demo code is for comfirming this) > Otherwise, you can use the videooverlay interface to display your video in a > QWidget. See gst-plugins-base/tests/examples/overlay/qt-videooverlay.cpp > replacing xvimagesink with glimagesink. I think this is not what I'm trying to do , I must draw other stuff over gstreamer,but the demo is not. Thank you for help!
(In reply to comment #4) > (In reply to comment #2) > > What's the big picture of this? > > sorry for the unclear question. the demo code and patch is a test to confirm > passing texture > between shared context is not stable. to make the pipeline simpler ,I tried to > make glimagesink > also create share context( likes GstGLFilter other-context property). You can now pass a GstGLContext to glimagesink (in git master). And you can wrap an existing context in a GstGLContext. > >Do you actually need to draw over top of the video? > > If so, you might need to take a look at the overpainting example here > > http://qt-project.org/doc/qt-5.0/qtopengl/overpainting.html > > I am trying to use OpenGL painting over gst-gl processed video , the > overpainting example > is helpful (and this is the way demo do),but the problem is , I must pass the > texture back from gstreamer to qt thread > (I think the clientDrawCallback is the only way.) but this leads random lock > (the demo code is for comfirming this) The other way is to use a glfilter ! fakesink/appsink pipeline and grab the texture using the standard gst_video_{meta,frame}_map. See gst-plugins-gl/tests/examples/qt/qglwtextureshare for that example. This route allows you to keep a reference to the GstBuffer containing the GL texture so that it doesn't disappear while you are using it. If you want to check if context sharing is supported on your setup, there's a couple of tests available in gst-plugins-gl/tests/check/libs/gstglcontext that you can run. To run them, cd to gst-plugins-gl/tests/check/ and run make libs/gstglcontext.check. (make help for some more invocations that are available).
(In reply to comment #3) > (In reply to comment #0) > > > > Hi, not sure what you are trying to do but in the mean time we have not this > https://bugzilla.gnome.org/show_bug.cgi?id=723674 you could also have a look at > http://cgit.freedesktop.org/gstreamer/gst-plugins-gl/tree/tests/examples/qt/qglwtextureshare Thanks, the qglwtextureshare example is helpful, Its usage scenario is similar to mine, use fakesink is better than my implementation. but I can still see the "texture not release " problem.print out the shared texture, you can found it always increase. after a while ,everything is lagging then app crashes. maybe this is another bug (should I fill another one ?). with Matthew Waters's suggestion, I prefer to use glimagesink other-context , seems that works with texture released correctly.
> See gst-plugins-gl/tests/examples/qt/qglwtextureshare for that example. This route > allows you to keep a reference to the GstBuffer containing the GL texture so > that it doesn't disappear while you are using it. I tried this example , but maybe there is still some bug (maybe fakesink)? texture still not released and then app crashes (I use gstreamer/plugin-base 1.2.3 plugin-gl git). > > If you want to check if context sharing is supported on your setup, there's a > couple of tests available in gst-plugins-gl/tests/check/libs/gstglcontext that > you can run. To run them, cd to gst-plugins-gl/tests/check/ and run make > libs/gstglcontext.check. (make help for some more invocations that are > available). I compared the code path between mine and qglwtextureshare, finally I found this: // We need to unset Qt context before initializing gst-gl plugin. // Otherwise the attempt to share gst-gl context with Qt will fail. I tried the same in my temp hacked code, no random lock any more. so I think this is the trick. (In reply to comment #5) > You can now pass a GstGLContext to glimagesink (in git master). And you can > wrap an existing context in a GstGLContext. Greate, I tried this and it worked! I used other-context property to share, and clien-draw-callback to receive texture , so there's two window opened (one created by gst-gl and another is Qt) drawing. if swap buffer in both,sometimes window overlapping leads render stopped in both , switch between them some times may resume. disable swapping in gst context helped.but I think this is not gst-gl bug(maybe X11 or driver?). maybe this bug can be closed.