After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 534304 - x(v)imagesink resets the window id when state changes from READY to NULL
x(v)imagesink resets the window id when state changes from READY to NULL
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.19
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-05-22 07:53 UTC by Etienne Barbier
Modified: 2008-05-23 12:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Etienne Barbier 2008-05-22 07:53:19 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.
Comment 1 Jan Schmidt 2008-05-22 10:24:31 UTC
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.
Comment 2 Etienne Barbier 2008-05-23 10:12:35 UTC
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.

Comment 3 Jan Schmidt 2008-05-23 11:02:53 UTC
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.
Comment 4 Etienne Barbier 2008-05-23 11:53:41 UTC
It's indeed what I need ! Thanks for your help.
I think we can just close that problem report then.
Comment 5 Jan Schmidt 2008-05-23 12:08:38 UTC
Cool, thanks for confirming