GNOME Bugzilla – Bug 715138
xvimagesink 1.2 ignores resize events when used on a QWidget
Last modified: 2014-01-15 10:07:42 UTC
I have a xvimagesink that is bound to a QWidget with gst_video_overlay_set_window_handle(). Since GStreamer version 1.2 the video displayed on the QWidget is not resized together with the QWidget anymore. I have to call gst_video_overlay_set_render_rectangle() to adjust the video size every time the QWidget is resized. If I replace xvimagesink with ximagesink or if I use xvimagesink 1.0.10, everything works like expected. Peter
This would be a regression over 1.0 and should be fixed
Can you provide a testcase for this?
Created attachment 265523 [details] Test case for non working GstVideoOverlay resizing on a QWidget
Comment on attachment 265523 [details] Test case for non working GstVideoOverlay resizing on a QWidget To build it run: qmake make You will get two executables, OverlayTest-0.10 and OverlayTest-1.2. OverlayTest-0.10 is build against GStreamer 0.10, resizing works like expected. OverlayTest-1.2 is build against GStreamer 1.2, resizing does not work for me.
After a while looking at the gst source, I noticed part of the documentation mentioning problems with initialization sequence when using an external window. Copying and adapting the suggested source code to your test case fixes the issue for me. I'll attach the fixed main.cpp for your reference. Essentially, you've got to attach the window at the right time, and you get a bus message to let you know when that time comes. So I'll close this as notabug, since I don't think fixing this to allow any timing is really possible, and the intended behavior actually works when doing things in that order.
Created attachment 265915 [details] The hacked version, which works This version works (all other events, such as expose, pointer motion, etc, were also borked with the original main.cpp).
Well, if it is really not a bug, then the documentation at [1] (section "Two basic usage scenarios", first paragraph) should be fixed too. [1] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gstvideooverlay.html
Which part do you think needs updating there or is not clear?
The first paragraph in section "Two basic usage scenarios": "...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_video_overlay_set_window_handle() directly with the XID or native window handle, before starting up the pipeline." That is exactly what my (not-working) test app does: It creates a xvimagesink, creates a QWidget to render the video on, calls gst_video_overlay_set_window_handle() directly with the window handle and then starts up the GStreamer pipeline. As discussed above, since 1.2 resizing is not working anymore. Vincent wrote he won't fix that and suggested to use the approach described in the second paragraph. So the first paragraph should be removed, I guess.
For reference, the documentation I was refering to was the GstOverlay one: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gstvideooverlay.html This has the nice bit of code I used in your test case.
Just to clarify: There are "Two basic usage scenarios" described in the docs. The first one I use in my test app which is not working (anymore) and yours, Vincent, which is working. My suggestion was to remove the not-working usage scenario from the documentation.
Just to clarify: There are "Two basic usage scenarios" described in the docs. The first one I use in my test app which is not working (anymore) and the second one that you, Vincent, used to make the test app work. My suggestion was to remove the not-working usage scenario from the documentation.
I agree with the op that the most "basic usage scenario" to create the sink initially and set the external xid via the GstOverlay interface before setting the pipeline to PLAYING used to work once (only tested against gst-0.10) and now (git master) does no longer. It sounds strange that this might be *really* intentional! This scenario is still a valid one and should be still supported. We use it too and can confirm, that now no more xevents are caught by the xevent listener thread.
Created attachment 266300 [details] [review] 0001-xvimagesink-don-t-recreate-xvcontext.patch Assuming that this is *really* a regression and not intentional -- this patch fixes the issue for me. Calling gst_xvimagesink_set_window_handle() before having started the pipeline lead to the creation of a xvcontext. Then upon GST_STATE_CHANGE_NULL_TO_READY in _open() a new xvcontext is created and overwrites the first. This somehow breaks event propagation to the xevent thread.
Yes this indeed looks like a bug, the "simple case" from the documentation is supposed to work.
Ah, I see. Seems good to me.
Ack, patch looks good. commit ae4338bd35d8aee3ecf1e5f5e24a5a51e914881d Author: Holger Kaelberer <hk@getslash.de> Date: Tue Jan 14 23:07:34 2014 +0100 xvimagesink: don't recreate xvcontext A xvcontext can be created early in gst_xvimagesink_set_window_handle(). In this case don't recreate, i.e. overwrite it in gst_xvimagesink_open(). Otherwise XEvents won't be handled in the xevent listener thread. Fixes a regression when setting the window handle on the sink in the very beginning before changing its state. https://bugzilla.gnome.org/show_bug.cgi?id=715138