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

Xavier Claessens xavier.claessens at collabora.com
Mon Oct 5 09:00:55 PDT 2015


Hi,

This sounds familiar indeed, but my fixes for the bugs I saw are all
included in the 1.6 release, so it must be something else or a more
recent regression.

On win32, GStreamer create its own internal child window to not mess up
with user's window. So it is normal it destroy that window when
finalizing the gl context, that won't destroy user's window.

Could you please send me the full backtrace (all threads)?

Regards,
Xavier Claessens.


Le lundi 05 octobre 2015 à 11:25 +0100, Nicolas Dufresne 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




More information about the gstreamer-devel mailing list