GNOME Bugzilla – Bug 763732
glwindow: no video frame when use QT created window on X11
Last modified: 2016-11-15 05:42:42 UTC
Created attachment 324071 [details] [review] glwindow: fix no video frame when use QT created window on X11 When use glimagesink with QT, no video frame showed in the QWidget window, the whole window is in black. While version 1.4.5 is OK.
Review of attachment 324071 [details] [review]: 1. The code formatting isn't up to gstreamer style. Please run gst-indent before submitting your patches 2. When is this needed exactly? i.e. when are you calling gst_video_overlay_set_window_handle()? As a response to the need-window-handle message? or on your own? If on your own, at what state is the sink at (NULL, READY, PAUSED, PLAYING)?
I don't have gst-indent tool on my PC, i will try to re-edit this patch. I call gst_video_overlay_set_window_handle() when pipeline state is NULL on my own. I want to know if this issue is a glwindow issue or what is the correct way to us glimagesink with QT window.
FYI as above (In reply to Matthew Waters (ystreet00) from comment #1) > Review of attachment 324071 [details] [review] [review]: > > 1. The code formatting isn't up to gstreamer style. Please run gst-indent > before submitting your patches > 2. When is this needed exactly? i.e. when are you calling > gst_video_overlay_set_window_handle()? As a response to the > need-window-handle message? or on your own? If on your own, at what state > is the sink at (NULL, READY, PAUSED, PLAYING)?
Created attachment 324072 [details] [review] glwindow: fix no frame when use glimagesink with QT
I'm still not sold on why this is necessary, the videooverlay example in https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/tests/examples/gl/qt/videooverlay works with the current code. It even does what you do by setting the window handle on NULL.
(In reply to Matthew Waters (ystreet00) from comment #5) > I'm still not sold on why this is necessary, the videooverlay example in > https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/tests/examples/ > gl/qt/videooverlay works with the current code. It even does what you do by > setting the window handle on NULL. This example also cannot work on my platform (i.Mx6Q). Only show white window. When pipeline state is NULL, window_x11->internal_win_id has not created, set window handle will pass window_x11->internal_win_id to XResizeWindow and XReparentWindow. I think this is the root cause for my issue. But I don't know why it works on your platform
That's not quite how it works. Setting the window handle in state NULL means glimagesink doesn't have any glwindow instantiated. So, glimagesink stores the window handle from set_window_handle and sets it later when creating the actual glwindow. Can you attach an GST_DEBUG=glimagesink:6,glwindow*:6 log while running the above example to this bug please?
Created attachment 324079 [details] videooverlay test log This is the log of the QT videooverlay example
Everything looks normal in the log (this is without the patch right?). What happens if you keep the old XReparentWindow in set_window_handle() (i.e. don't comment it out)?. An interesting data point would be printing/inspecting the the attributes returned by xGetWindowAttributes on the parent window in both places (_set_window_handle() and _show()) and seeing if they make sense and are the same in both places.
Yes, this log is with out the patch. If I keep XReparentWindow in set_window_handle(), there is no frame either. I print the attrubutes, they are the same in both places. By the way, I found if add XMapWindow in set_window_handle() after XReparentWindow will also fix this problem. Does it make any sence?
Created attachment 324088 [details] The demo This is qt example videooverlay running result. If normal, there will be color bar frame.
What?? That makes no sense whatsoever...unless the writes aren't making it to the X server? Try adding an XSync (device, False) after XMapWindow in _show_window(). Another data point, GST_DEBUG=glwindow*:6, get the internal window handle from the debug line, "glwindow gstglwindow_x11.c:243:gst_gl_window_x11_create_window: gl window id: xxxxx" (without the 'd' at the end), and while that's running pass it into xwininfo -id xxxx and see what that says about the window (and maybe the parent window as well).
parent window is in glimagesink:6 debugging as new_window_id.
Thanks for your nice help. I am off work now and can not see the runnning result. What do you mean for "the writes aren't making it to the X server"?
As in, you're not seeing any output because the XMapWindow is being written to the request buffer but not being flushed and sent to the X server so the server isn't mapping the window.
(In reply to Matthew Waters (ystreet00) from comment #15) > As in, you're not seeing any output because the XMapWindow is being written > to the request buffer but not being flushed and sent to the X server so the > server isn't mapping the window. After add XSync (device, False) after XMapWindow in _show_window(), still cannot see the color bar and only white screen without my patch. Is there any other reason for this issue?
And what did xwinwinfo say?
(In reply to Matthew Waters (ystreet00) from comment #17) > And what did xwinwinfo say? root@imx6qpsabresd:~# xwininfo -id 27262978 xwininfo: Window id: 0x1a00002 "OpenGL renderer" Absolute upper-left X: 0 Absolute upper-left Y: 48 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 1024 Height: 720 Depth: 16 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x1a00001 (not installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +0+48 -0+48 -0-0 +0-0 -geometry 1024x720+0+0 root@imx6qpsabresd:~# xwininfo -id 23068676 xwininfo: Window id: 0x1600004 "GstVideoOverlay Qt demo" Absolute upper-left X: 0 Absolute upper-left Y: 48 Relative upper-left X: 0 Relative upper-left Y: 48 Width: 1024 Height: 720 Depth: 16 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x1600001 (not installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +0+48 -0+48 -0-0 +0-0 -geometry 1024x720+0-0
(In reply to Matthew Waters (ystreet00) from comment #17) > And what did xwinwinfo say? The first is internal window and the second one is parent window.
(In reply to Matthew Waters (ystreet00) from comment #17) > And what did xwinwinfo say? Hi Matthew, Any update for this issue?
Those xwininfo's look fine. The window's are being mapped which means they should be displayed, the fact that they're not indicates some bug lower in the stack. What Xorg, Qt, etc versions are you running? What are the values in attr (from XGetWindowAttributes) in _set_window_handle()?
Or, there's some subtle interaction between the GL driver and having the X11 window unparented and unmapped or parented and mapped to which requires looking into driver code.
Another problem I have with this patch as is that it effectively only ever calls XReparentWindow once on show() however there's a gtk example (https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/tests/examples/gl/gtk/switchvideooverlay) that allows switching the video overlay at runtime. granted it only currently works on X11 however moving the XReparentWindow call into show() will break that.
Closing as this seems to be a bug in a lower element of the stack.