glimagesink : lockup when using overlay and going back to ready state

[philippe renon]

Hi,
>From the bt and looking at the code a bit, it looks like the sink thinks it owns the window.
Resizing the window also _sometimes_ leads to a lockup. Bt shows that the sink wants to resize the windows when it should only take the resizing into account (and not apply it).
I tried to look at the code to see how the sink knows whether it owns the window or not but could not find anything obvious (must be subtle...).
Other sinks, like the d3d image sink for instance, have a boolean flag that make it explicit whether the sink owns the windows (and can/should destroy it, etc...) or not.
Cheers,Philippe.
 


     Le Lundi 5 octobre 2015 12h25, Nicolas Dufresne <nicolas.dufresne at collabora.com> a écrit :
   
 

 Le lundi 05 octobre 2015 à 07:15 +0000, philippe renon a écrit :
> It was reproduced on a post 1.6.0 master compiled under Windows
> 7/MingW. Overlay window is provided by a Qt 5.4.1 app. Pipeline runs
> fine otherwise.
> 
> Here are some back traces taken during the lockup:
> 
> Thread 1 is locked while finalizing the gl context.
> Thread 22 is locked while trying to destroy a window (!?!)
> Thread 21 is waiting for nav event (which is, I guess, ok).

Hi,

my colleague (in CC) have hit this issue recently, I think he'll be
able to provide what he found. Please keep him in CC as he's on on this
mailing list. This is specific to Windows and we could not find enough
information to be able to solve this issue completely.

cheers,
Nicolas

 
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151005/a2256c17/attachment.html>