XOverlay lost after setting playbin state to Null

Ralph ralph.gucwa at racelogic.co.uk
Fri Dec 23 01:50:52 PST 2011

Stefan Sauer wrote
> On 11/28/2011 06:25 PM, Ralph wrote:
>>> you could do a set_locked_state(TRUE) on the videosink (to avoid it
>>> going down), then goto READY, change uri, go back to PAUSED,
>>> set_locked_state(FALSE), go to PLAYING 
>> IT WORKS!!!
>> Fantastic, thank you very much.
> Good to know. This could mean that you don't properly handle the
> element-message to bind the overlay to the window handle or that the
> sink is buggy.
> Stefan

Well... The solution with locking the videosink is not perfect, sometimes it
works, but in some situations it freezes the whole application when changing
the playbin state from PAUSED to READY.  This always happens when I try to
preview a sequence of files very quickly, read duration of each file, etc. 
When I use locking, and switch between the files too fast, it freezes the
entire application.  Changing the file once every 10 seconds usually works,
but not always.  I have tested it with both dshowvideosink and d3dvideosink
and when I don't use videosink locking, a new video window is opened.
This is how I bind the window handle to the video sink:
      Gst.Interfaces.XOverlayAdapter overlayAdapter = new
      overlayAdapter.XwindowId = (ulong)window.Handle;
I think that's the standard way of doing this, are ther any others? 
Avoiding to lock the videosink would solve lots of problems.

View this message in context: http://gstreamer-devel.966125.n4.nabble.com/XOverlay-lost-after-setting-playbin-state-to-NULL-or-READY-tp4115442p4227998.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.

More information about the gstreamer-devel mailing list