gst-plugins-bad issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues2019-07-20T15:31:51Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/910waylandsink: Finish implementation and related library2019-07-20T15:31:51ZNicolas Dufresnewaylandsink: Finish implementation and related libraryI've spend a day looking into the state of waylandsink, trying to get the right feature set of GstVideoOverlay and could not. The problem biggest issue is that to implement VideoOverlay properly we would need to know the surface size. Unlike other protocol, the surface size cannot be queried. In fact, the surface size entirely depends on the content, and there is no way to know if there is any content in the provided window.
This information is crucial, because there is no implicit clipping of the video subsurface within the same application. That basically means that as of today's implementation, it is rather easy to get the video to fall outside of your window. And worst. In other implementation, the clipping is left to the windowing system, basically if we want to do right clipping, we pass a render rectangle that is bigger then the window.
That basically means, we want want to turn waylandsink in something more serious, we need a mechanism to set the window size. This information is often known by the application or when a toplevel surface is used (through the configure event). When this work started, a wayland library was added. It currently exist and support context sharing and atomic resize. But as this is not exported, it is completely useless.
1. Shall we expose this unstable API starting form 1.17 ?
I looked at the interface, despite that it is missing a window size, the suggested API is quite coherent with how Wayland works.
2. Or, shall we simply implement it through properties and action signals ?
We can pretty much do everything though action signal, except that that some simple things (like the context name) in the normal API we endup with complicated things (like a read-only property, or a action signal getter).
cc @gkiagia @danielsI've spend a day looking into the state of waylandsink, trying to get the right feature set of GstVideoOverlay and could not. The problem biggest issue is that to implement VideoOverlay properly we would need to know the surface size. Unlike other protocol, the surface size cannot be queried. In fact, the surface size entirely depends on the content, and there is no way to know if there is any content in the provided window.
This information is crucial, because there is no implicit clipping of the video subsurface within the same application. That basically means that as of today's implementation, it is rather easy to get the video to fall outside of your window. And worst. In other implementation, the clipping is left to the windowing system, basically if we want to do right clipping, we pass a render rectangle that is bigger then the window.
That basically means, we want want to turn waylandsink in something more serious, we need a mechanism to set the window size. This information is often known by the application or when a toplevel surface is used (through the configure event). When this work started, a wayland library was added. It currently exist and support context sharing and atomic resize. But as this is not exported, it is completely useless.
1. Shall we expose this unstable API starting form 1.17 ?
I looked at the interface, despite that it is missing a window size, the suggested API is quite coherent with how Wayland works.
2. Or, shall we simply implement it through properties and action signals ?
We can pretty much do everything though action signal, except that that some simple things (like the context name) in the normal API we endup with complicated things (like a read-only property, or a action signal getter).
cc @gkiagia @daniels1.17Nicolas DufresneNicolas Dufresnehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/608tests: libs/player test_play_media_info failure2019-02-17T18:42:05ZBugzilla Migration Usertests: libs/player test_play_media_info failure## Submitted by Edward Hervey `@bilboed`
**[Link to original bug (#787374)](https://bugzilla.gnome.org/show_bug.cgi?id=787374)**
## Description
Created attachment 359283
GST_DEBUG Log of failure
libs/player.c:753:F:general:test_play_media_info:0: 'GPOINTER_TO_INT (state.test_data)' (2) is not equal to '1' (1)
The "problem" is that more than one media info update gets emitted (because some information gets updated after a while, like bitrates).
**Attachment 359283**, "GST_DEBUG Log of failure":
[log](/uploads/79b63a6de70e9397ce1d967b2e4e2b75/log)
Depends on: #394.## Submitted by Edward Hervey `@bilboed`
**[Link to original bug (#787374)](https://bugzilla.gnome.org/show_bug.cgi?id=787374)**
## Description
Created attachment 359283
GST_DEBUG Log of failure
libs/player.c:753:F:general:test_play_media_info:0: 'GPOINTER_TO_INT (state.test_data)' (2) is not equal to '1' (1)
The "problem" is that more than one media info update gets emitted (because some information gets updated after a while, like bitrates).
**Attachment 359283**, "GST_DEBUG Log of failure":
[log](/uploads/79b63a6de70e9397ce1d967b2e4e2b75/log)
Depends on: #394.1.17Bugzilla