XOverlay behaviour change ?
Locked
 
|
Hello
In my python/gtk/gstreamer based application (www.advene.org), I embed a xvimagesink (on linux with gtk 2.20)/ximagesink (on macos x with gtk 2.18) in a gtk.Socket, calling set_xwindow_id after the gtk.Socket is realized. It worked alright with gst-plugins-good 0.10.21. However, since the upgrade to 0.10.22, the behaviour changed: the image is not displayed until the window has received an expose event (basically, I hide and show the window). I had a quick look at the git logs, but did not find anything that seemed relevant. Has there been a change in the xoverlay API that I should be aware of ? And if not, are there any hints to help me debug this issue? Thanks Olivier ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
Olivier Aubert wrote:
> Hello > > In my python/gtk/gstreamer based application (www.advene.org), I embed a > xvimagesink (on linux with gtk 2.20)/ximagesink (on macos x with gtk > 2.18) in a gtk.Socket, calling set_xwindow_id after the gtk.Socket is > realized. > You should call set_xwindow_id() in reply to the "prepare-xwindow-id" element message on the gstreamer bus. Anything else is sheer luck :) The GstXOverlay docs have examples. Stefan > It worked alright with gst-plugins-good 0.10.21. However, since the > upgrade to 0.10.22, the behaviour changed: the image is not displayed > until the window has received an expose event (basically, I hide and > show the window). > > I had a quick look at the git logs, but did not find anything that > seemed relevant. Has there been a change in the xoverlay API that I > should be aware of ? And if not, are there any hints to help me debug > this issue? > > Thanks > Olivier > > > ------------------------------------------------------------------------------ > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: XOverlay behaviour change ?
|
|
Hi Stefan
Thanks for the answer, but this is not the root of the cause since I also tried this approach and the behaviour is identical. And anyway, directly using set_xwindow_id is mentioned in the XOverlay doc (this specific information was added on january 2010 by Tim, so I assume that it is correct): >From gst-libs/gst/interfaces/xoverlay.c : * There are two basic usage scenarios: in the simplest case, the application * knows exactly what particular element is used for video output, which is * usually the case when the application creates the videosink to use * (e.g. #xvimagesink, #ximagesink, etc.) itself; in this case, the application * can just create the videosink element, create and realize the window to * render the video on and then call gst_x_overlay_set_xwindow_id() directly * with the XID or native window handle, before starting up the pipeline. * * In the other and more common case, the application does not know in advance * what GStreamer video sink element will be used for video output. * [...use prepare-xwindow-id...] I am in the first case (instanciating exactly the sink I need), and calling set_xwindow_id after my embedding widget is realized. Olivier On Wed, 2010-05-12 at 18:49 +0300, Stefan Kost wrote: > Olivier Aubert wrote: > > Hello > > > > In my python/gtk/gstreamer based application (www.advene.org), I embed a > > xvimagesink (on linux with gtk 2.20)/ximagesink (on macos x with gtk > > 2.18) in a gtk.Socket, calling set_xwindow_id after the gtk.Socket is > > realized. > > > You should call set_xwindow_id() in reply to the "prepare-xwindow-id" > element message on the gstreamer bus. Anything else is sheer luck :) The > GstXOverlay docs have examples. > > Stefan > > It worked alright with gst-plugins-good 0.10.21. However, since the > > upgrade to 0.10.22, the behaviour changed: the image is not displayed > > until the window has received an expose event (basically, I hide and > > show the window). > > > > I had a quick look at the git logs, but did not find anything that > > seemed relevant. Has there been a change in the xoverlay API that I > > should be aware of ? And if not, are there any hints to help me debug > > this issue? > > > > Thanks > > Olivier > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > gstreamer-devel mailing list > > [hidden email] > > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: XOverlay behaviour change ?
|
|
2010/5/12 Olivier Aubert <[hidden email]>
Hi Stefan Thanks for bringing this up Olivier. I have the same issue in my program, although interestingly glimagesink does _not_ suffer from this behavior.
-- Tristan Matthews email: [hidden email] web: http://tristanswork.blogspot.com ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: XOverlay behaviour change ?
|
|
In reply to this post by Olivier Aubert-2
On Wed, 2010-05-12 at 16:03 +0200, Olivier Aubert wrote:
> In my python/gtk/gstreamer based application (www.advene.org), I embed a > xvimagesink (on linux with gtk 2.20)/ximagesink (on macos x with gtk > 2.18) in a gtk.Socket, calling set_xwindow_id after the gtk.Socket is > realized. > > It worked alright with gst-plugins-good 0.10.21. However, since the > upgrade to 0.10.22, the behaviour changed: the image is not displayed > until the window has received an expose event (basically, I hide and > show the window). > > I had a quick look at the git logs, but did not find anything that > seemed relevant. Has there been a change in the xoverlay API that I > should be aware of ? And if not, are there any hints to help me debug > this issue? Do you have a minimal test application that demonstrates the problem? Are you sure it's the -good upgrade that broke things, and not a Gtk+ upgrade or a gst-plugins-base upgrade (esp. given that ximagesink/xvimagesink/GstXOverlay are in -base)? Cheers -Tim ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
In reply to this post by Olivier Aubert-2
Am 12.05.2010 19:18, schrieb Olivier Aubert:
> Hi Stefan > > Thanks for the answer, but this is not the root of the cause since I > also tried this approach and the behaviour is identical. And anyway, > directly using set_xwindow_id is mentioned in the XOverlay doc (this > specific information was added on january 2010 by Tim, so I assume that > it is correct): > >>From gst-libs/gst/interfaces/xoverlay.c : > * There are two basic usage scenarios: in the simplest case, the application > * knows exactly what particular element is used for video output, which is > * usually the case when the application creates the videosink to use > * (e.g. #xvimagesink, #ximagesink, etc.) itself; in this case, the application > * can just create the videosink element, create and realize the window to > * render the video on and then call gst_x_overlay_set_xwindow_id() directly > * with the XID or native window handle, before starting up the pipeline. > * > * In the other and more common case, the application does not know in advance > * what GStreamer video sink element will be used for video output. > * [...use prepare-xwindow-id...] > > I am in the first case (instanciating exactly the sink I need), and > calling set_xwindow_id after my embedding widget is realized. Having a small example would indeed be good. I am not sure about the gtkplug usage (I never used that myself), is the widget on the other side of it realized too. Maybe you could just open a bug for the issue, add your example, and/or debug logs with and with out the extra expose() call. Also please tell which properties on xvimagesink you have changed from the defaults. Stefan > > Olivier > > On Wed, 2010-05-12 at 18:49 +0300, Stefan Kost wrote: >> Olivier Aubert wrote: >>> Hello >>> >>> In my python/gtk/gstreamer based application (www.advene.org), I embed a >>> xvimagesink (on linux with gtk 2.20)/ximagesink (on macos x with gtk >>> 2.18) in a gtk.Socket, calling set_xwindow_id after the gtk.Socket is >>> realized. >>> >> You should call set_xwindow_id() in reply to the "prepare-xwindow-id" >> element message on the gstreamer bus. Anything else is sheer luck :) The >> GstXOverlay docs have examples. >> >> Stefan >>> It worked alright with gst-plugins-good 0.10.21. However, since the >>> upgrade to 0.10.22, the behaviour changed: the image is not displayed >>> until the window has received an expose event (basically, I hide and >>> show the window). >>> >>> I had a quick look at the git logs, but did not find anything that >>> seemed relevant. Has there been a change in the xoverlay API that I >>> should be aware of ? And if not, are there any hints to help me debug >>> this issue? >>> >>> Thanks >>> Olivier >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> gstreamer-devel mailing list >>> [hidden email] >>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel >>> > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: XOverlay behaviour change ?
|
|
In reply to this post by Tim-Philipp Müller-2
Hello
A quick followup on this issue: I managed to find a workaround by calling sink.expose() (mapping of gst_x_overlay_expose) just after calling set_xwindow_id. I still do not fully understand the issue though, since I did not manage to get a minimal application demonstrating it, it runs with no problem. Had there not been a confirmation of the same issue from Tristan Matthews, I would think it was only a bug on my side. I will try to find some time to get a test application exhibiting the issue. As for Tim's questions: yes, it can be a -good upgrade (from .28 to .29) that is the cause, since it was upgraded at the same time as -base. But I am fairly sure it is not a gtk upgrade, since I run 2.20 on linux and 2.18 on MacOSX, and both showed the issue after upgrading gstreamer. Regards, Olivier On Thu, 2010-05-13 at 15:24 +0100, Tim-Philipp Müller wrote: > On Wed, 2010-05-12 at 16:03 +0200, Olivier Aubert wrote: > > > In my python/gtk/gstreamer based application (www.advene.org), I embed a > > xvimagesink (on linux with gtk 2.20)/ximagesink (on macos x with gtk > > 2.18) in a gtk.Socket, calling set_xwindow_id after the gtk.Socket is > > realized. > > > > It worked alright with gst-plugins-good 0.10.21. However, since the > > upgrade to 0.10.22, the behaviour changed: the image is not displayed > > until the window has received an expose event (basically, I hide and > > show the window). > > > > I had a quick look at the git logs, but did not find anything that > > seemed relevant. Has there been a change in the xoverlay API that I > > should be aware of ? And if not, are there any hints to help me debug > > this issue? > > Do you have a minimal test application that demonstrates the problem? > > Are you sure it's the -good upgrade that broke things, and not a Gtk+ > upgrade or a gst-plugins-base upgrade (esp. given that > ximagesink/xvimagesink/GstXOverlay are in -base)? > > Cheers > -Tim > > > ------------------------------------------------------------------------------ > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |