Tell an overlay that it has been exposed. This will redraw the current frame in the drawable even if the pipeline is PAUSED.
This will post a "have-window-handle" element message on the bus.
Tell an overlay that it should handle events from the window system. These events are forwarded upstream as navigation events. In some window system, events are not propagated in the window hierarchy if a client is listening for them. This method allows you to disable events handling completely from the #GstVideoOverlay.
This will post a "prepare-window-handle" element message on the bus to give applications an opportunity to call gstvideo.video_overlay.VideoOverlay.setWindowHandle before a plugin creates its own window.
Configure a subregion as a video target within the window set by gstvideo.video_overlay.VideoOverlay.setWindowHandle. If this is not used or not supported the video will fill the area of the window set as the overlay to 100%. By specifying the rectangle, the video can be overlayed to a specific region of that window only. After setting the new rectangle one should call gstvideo.video_overlay.VideoOverlay.expose to force a redraw. To unset the region pass -1 for the width and height parameters.
This will call the video overlay's set_window_handle method. You should use this method to tell to an overlay to display video output to a specific window (e.g. an XWindow on X11). Passing 0 as the handle will tell the overlay to stop using that window and create an internal one.
This helper shall be used by classes implementing the #GstVideoOverlay interface that want the render rectangle to be controllable using properties. This helper will parse and set the render rectangle calling gstvideo.video_overlay.VideoOverlay.setRenderRectangle.
The #GstVideoOverlay interface is used for 2 main purposes :
Using the Window created by the video sink is probably the simplest scenario, in some cases, though, it might not be flexible enough for application developers if they need to catch events such as mouse moves and button clicks.
Setting a specific Window identifier on the video sink element is the most flexible solution but it has some issues. Indeed the application needs to set its Window identifier at the right time to avoid internal Window creation from the video sink element. To solve this issue a #GstMessage is posted on the bus to inform the application that it should set the Window identifier immediately. Here is an example on how to do that correctly:
Two basic usage scenarios
There are two basic usage scenarios: in the simplest case, the application uses #playbin or #playsink or 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 gstvideo.video_overlay.VideoOverlay.setWindowHandle directly with the XID or native window handle, before starting up the pipeline. As #playbin and #playsink implement the video overlay interface and proxy it transparently to the actual video sink even if it is created later, this case also applies when using these elements.
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. This is usually the case when an element such as #autovideosink is used. In this case, the video sink element itself is created asynchronously from a GStreamer streaming thread some time after the pipeline has been started up. When that happens, however, the video sink will need to know right then whether to render onto an already existing application window or whether to create its own window. This is when it posts a prepare-window-handle message, and that is also why this message needs to be handled in a sync bus handler which will be called from the streaming thread directly (because the video sink will need an answer right then).
As response to the prepare-window-handle element message in the bus sync handler, the application may use gstvideo.video_overlay.VideoOverlay.setWindowHandle to tell the video sink to render onto an existing window surface. At this point the application should already have obtained the window handle / XID, so it just needs to set it. It is generally not advisable to call any GUI toolkit functions or window system functions from the streaming thread in which the prepare-window-handle message is handled, because most GUI toolkits and windowing systems are not thread-safe at all and a lot of care would be required to co-ordinate the toolkit and window system calls of the different threads (Gtk+ users please note: prior to Gtk+ 2.18 GDK_WINDOW_XID was just a simple structure access, so generally fine to do within the bus sync handler; this macro was changed to a function call in Gtk+ 2.18 and later, which is likely to cause problems when called from a sync handler; see below for a better approach without GDK_WINDOW_XID used in the callback).
GstVideoOverlay and Gtk+
GstVideoOverlay and Qt