GNOME Bugzilla – Bug 534304
x(v)imagesink resets the window id when state changes from READY to NULL
Last modified: 2008-05-23 12:08:38 UTC
x(v)imagesink should keep the window id unless changed through the xoverlay interface. This leads to create a new window when restarting playing (if we don't catch the prepare_xwindow_id message on the bus). Should behave the same way as directdrawsink plugin for windows (keep consistency). The background for this change is that is not always possible to use the message bus in all applications.
What kind of app would that be? An app that can't listen on the bus is also one that can't catch end-of-stream or errors. By definition, transitioning an element through NULL makes it reset a bunch of internals. In my opinion, it would be equally fair to say that directdrawsink should reset the stored window handle, for consistency.
Well, I should not have said "not possible", but "not always convenient". I have integrated Gstreamer in a Qt application for handling rtp stream. Qt has already an event loop, so I can't use another main loop. What I have done so far is to regularely check on the bus if there are messages by polling. It works fine but I always react a bit late for the "prepare_xwindow_id", it then creates a new window and destroys it immediately after I have set the window id (quick flicker). However, I agree that by definition, we should reset everything in the state NULL. To solve my problem, I'll always set de win id before playing and not catch the message on the bus. For consistency, directdrawsink should then follow the same rules.
Ah right. You'll always have that trouble attempting to use the messages from XOverlay in the main thread. You need to use a sync_handler on the bus to catch the message in the thread it's being sent in - so that you can set the XID without racing. There's an example in http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gstxoverlay.html That method works for Qt apps equally well - you just have to watch the thread safety issues implicit in passing the XID to a background thread.
It's indeed what I need ! Thanks for your help. I think we can just close that problem report then.
Cool, thanks for confirming