[gstreamer-bugs] [Bug 600797] New example illustrates texture sharing between glupload and Qt

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Tue Nov 17 00:29:54 PST 2009


https://bugzilla.gnome.org/show_bug.cgi?id=600797
  GStreamer | gst-plugins-gl | unspecified

--- Comment #3 from Andrey Nechypurenko <andreynech at gmail.com> 2009-11-17 08:29:52 UTC ---
(In reply to comment #2)
> commit 7c7b30da9b4ba58ccb6a245a889d4374ebdb9f6a
> Author: Andrey Nechypurenko <andreynech at 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?

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.




More information about the Gstreamer-bugs mailing list