[Bug 731525] multiple glimagesink elements aborts due to no XInitThreads.

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=731525
  GStreamer | gst-plugins-bad | git

Julien Isorce <julien.isorce> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |julien.isorce at gmail.com

--- Comment #1 from Julien Isorce <julien.isorce at gmail.com> 2014-06-12 07:20:22 UTC ---
Do you mean that "gst_gl_ensure_display" make them use the same GstGLDisplay
instance  ?

Maybe we could ensure thread safety ourself: renaming
"gst_gl_display_get_handle":
to "gst_gl_display_acquire_handle"  and adding "gst_gl_display_release_handle".

The caller would be responsible to release it when done.

The bad thing is that it adds a locking at client level, so 2 glXSwapBuffers
(x11_display_handle, window_handle) would never happen at the same time within
the same pipeline.
But I think it would be the same result with XInitThreads, plus it adds the
constrain to all pipelines. Anyway I guess at some point there is a locking
mechanism at server level if not using the same connection.
Good thing is that we avoid 1 and 2.

Also when using only one glimagesink, the same problem will happen when having
one one GLThread per streaming thread and having gleffects ! queue !
glimagesink.

In the end I would prefer to go for a solution where we have the hand on the
locking.

(Just a note, the glimage_sink->display_name is never used)

-- 
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.