[Bug 779181] gst_gl_window_eagl_new can be called multiple times in different threads, which can lead to deadlocks

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779181

--- Comment #4 from Matthew Waters (ystreet00) <ystreet00 at gmail.com> ---
The cocoa code doesn't use a singleton for this part, none of the
implementations do.

(In reply to Nick Kallen from comment #2)
> My pipeline is complicated because it changes dynamically in response to
> user input. I use async bins and in general I set things to playing before I
> add them to the pipeline because it seems to create noticable performance
> improvements. This works well in general.
> 
> However, if I used the same technique a startup and there is a gl-filter
> based source, I got this deadlock.
> 
> Here is the simplest I can reproduce
> 
> process start:
> 
> 1. create pipeline
> 2. set state playing

If you do this, you need to either
1. Proxy the context queries between elements
2. Have all the GL elements in the same pipeline before READY->PAUSED (or
NULL->READY for video sinks).

> wait for window to be available:

What does this mean?

> 3. create async bin "videotestsrc ! glupload"
> 4. set state playing

Side note, how do you deal with not-linked if glupload isn't linked to
anything?

> 5. create async bin " .... ! glimagesink"
> 6. set window handle
> 7. set state playing
> 6. add both to pipeline
> 
> then it deadlocks.
>
> In this case, the two async bins create their own gl contexts and their own
> dispatch queues. Then when they are linked together, they still have their
> own dispatch queues, which leads to the deadlock above.

That is definitely not surprising and completely unsupported. You need to have
glimagesink create the GL context as it is the element that is displaying the
stream and needs to perform winsys specific operations for that to happen.  To
perform what you're attempting by having a GL context being replaced by another
is a complicated endeavour.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.