Possible race in wayland_sync about gstreamer-media-sdk

[raj23]

Hi,

Thanks for pointing this out to us.
We would like to understand under what circumstances this will happen?

Thank you.

[phako]

Say you have the video running full screen and need touch events from that surface.
We get the display from the sink and register an event queue for wayland input events there and handle that in a separate thread (prepare_read etc.)

Due to parallelism, it can happen that the input thread calls wl_display_flush before the wait function clears its event queue, so attach/damage/commit will be sent to the server and the frame event will already be triggered by the queue clearing.

We have seen this with vaapisink but since your code is derived from that (and we will probably have to switch to it at some point) it should behave the same in that situation

Note, this is theoratical as we have seen it with vaapisink but we cannot run mfx stuff yet.

Btw, how are you handling generic bugfixes that happen(ed) to vaapi? Do you regular backsyncs of generic handling?

[raj23]

Thank you for the explanation. Yes I believe it will have the same behavior as vaapisink as the code is derived from that.

We don't handle the general bugfixes that happened to vaapi and we don't regularly backsync of generic handling. When we started this, we derived from gstreamer-vaapi but now our development to some extent is detached with gstreamer-vaapi and currently we in the mid of refactoring our codes. We couldn't make it public yet as the codebase is not stable.

[ishmael1985]

Hi Raj,

Can you please close this issue since a workaround has been found.

https://bugzilla.gnome.org/show_bug.cgi?id=772455