GNOME Bugzilla – Bug 600797
New example illustrates texture sharing between glupload and Qt
Last modified: 2010-02-09 11:20:38 UTC
Created attachment 146990 [details] Example source code This example illustrates how to integrate Gstreamer GL plugin with Qt. In particular it uses glupload with fakesink elements to create texture with decoded video frame. This texture is shared with QGLWidget derived class, which paints a cube with video texture on each face. To compile the example, include and library paths might be adjusted in .pro file according to your installation of the gstreamer and corresponding development files. Most probably, the adjustments will be necessary on Windows. To run the example simply start executable file after compilation. If there is no command line arguments provided, then videotestsrc element will be used to generate video. The following pipeline will be created in this case: videotestsrc ! video/x-raw-yuv, width=640, height=480, framerate=(fraction)30/1 ! glupload ! fakesink sync=1 It is also possible to provide the video file name as a first command line parameter, i.e. ./qglwtextureshare myvideo.ogv . In this case, the following pipeline will be executed: filesrc location=myvideo.ogv ! decodebin2 ! glupload ! fakesink sync=1 In rare cases, the application crashes on startup. I've seen it only on Windows so far. Trying to start the example again usually works for me. I did not find the reasons for this crash yet. This example is tested on WindowsXP and Debian Testing (squeeze).
Created attachment 147290 [details] [review] build a real patch instead of a zipped dir On linux I had to comment //#include <GL/glxew.h> in glcontextid.h in order to avoid a comilation error about X conflicting declaration and redefinition ( QMake version 2.01a Using Qt version 4.4.0 in /usr/local/Trolltech/Qt-4.4.0/lib ) Anyway, this is the error I got: ./qglwtextureshare No video file specified. Using video test source. Starting gst pipeline (<unknown>:4756): GStreamer-CRITICAL **: gst_mini_object_unref: assertion `mini_object->refcount > 0' failed and the cube is white. Have you tested it again on linux after made it work on win32 ? Could you attach your glxinfo output, maybe my env is more restrictive. I will try to find some times to debug it.
commit 7c7b30da9b4ba58ccb6a245a889d4374ebdb9f6a Author: Andrey Nechypurenko <andreynech@gmail.com> Date: Mon Nov 16 10:24:38 2009 +0100 add new example illustrates texture sharing between glupload and Qt fix #600797
(In reply to comment #2) > commit 7c7b30da9b4ba58ccb6a245a889d4374ebdb9f6a > Author: Andrey Nechypurenko <andreynech@gmail.com> > Date: Mon Nov 16 10:24:38 2009 +0100 > > add new example illustrates texture sharing between glupload and Qt > > fix #600797 Hi, I've seen that you introduce mutexes with comment that frame could be changed while painting. Could you please explain how it could happen? Please take in account that QGLRenderer::newFrame() slot is connected with Qt::QueuedConnection flag within GstThread constructor. So this method will always be called from one thread (the main thread). The video frame itself is also picked up from the notification queue and will be used for painting until the new one will arrive. Only after arrival of the new frame, the old one will be placed in the queue to "return" this frame back to gstreamer. So as I understand until the frame is "returned" it would not be used by gstreamer. That is why I could not see any reasons for additional synchronization with mutexes. In addition, I fixed a couple of things in the example which improve stability during start-up and shutdown. Should I submit patches?
Hi, please submit it but please from git and not from the last zip you submit. Especially about shutdown ! About the mutexes I introduces: the paintGL method is called when the window needs to be redraw, for example when you call updateGL, ok in this case no need the mutex. But if the paintGL is called from another thread (I think it can't happen in our case) but nothing prevent us from someone ask the window to be redraw from the pipeline thread for example. Well, this is not the main pb I fixed i know, but I fixed another thing, it's about the first frame which was undifined (not initialized to NULL), and you called frame->width on it, that why sometimes you got weird sizes. (and sometimes a sigsev)
(In reply to comment #4) > Hi, please submit it but please from git and not from the last zip you submit. > Especially about shutdown ! Ok, I'll do it within next couple of days. > About the mutexes I introduces: > the paintGL method is called when the window needs to be redraw, for example > when you call updateGL, ok in this case no need the mutex. Right. > But if the paintGL is called from another thread (I think it can't happen in > our case) but nothing prevent us from someone ask the window to be redraw from > the pipeline thread for example. According to Qt documentation, it is not safe to call UI-related functionality from threads other then main. The right (Qt) way to trigger for example repaint from another thread is to send queued signal (this is what we are doing). Otherwise it would be just a bug. So I would suggest to remove mutex. I actually tested it and it works fine. > Well, this is not the main pb I fixed i know, > but I fixed another thing, it's about the first frame which was undifined (not > initialized to NULL), and you called frame->width on it, that why sometimes you > got weird sizes. (and sometimes a sigsev) Right, I've seen it also. Somehow I overlooked this initialization problem. Thank you for the fix.
(In reply to comment #5) > According to Qt documentation, it is not safe to call UI-related functionality > from threads other then main. The right (Qt) way to trigger for example repaint > from another thread is to send queued signal (this is what we are doing). > Otherwise it would be just a bug. So I would suggest to remove mutex. I > actually tested it and it works fine. > Right, ok.
commit 188b3bf03ba5ae5be81480ce75177dd234f892cd Author: Julien Isorce <julien.isorce@gmail.com> Date: Tue Nov 17 23:16:43 2009 +0100 qglwtextureshare example: avoid a lock when painting see comment #5 from bug #600797 >In addition, I fixed a couple of things in the example which improve stability >during start-up and shutdown. Should I submit patches? Yes and please create an other bug for it