Problem is that unreffing the EGLImage/SHM Buffer while holding the
images_mutex lock may deadlock when a new buffer is advertised and
an attempt is made to lock the images_mutex there.
The advertisement of the new image/buffer is performed in the
WPEContextThread and the blocking dispatch when unreffing wants to run
something on the WPEContextThread however images_mutex has already been
locked by the destructor.
Delay unreffing images/buffers outside of images_mutex and instead just
clear the relevant fields within the lock.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1843>
As waiting for the load to be finished is specific to the WebView, it should be
done from our WPEView, not from the WPEContextThread. This fixes issues where
multiple wpesrc elements are created in sequence. Without this patch the first
view might receive erroneous buffer notifications.
Fixes#1386
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1568>
The WPEThreaded view is now split in 2 classes:
- WPEContextThread handles the persistent WebKit thread, where all WebKit API
calls should be handled.
- WPEView: is created from the WPEContextThread. It handles the WebView and
maintains the public interface on which wpesrc relies. This is the facade for
the WebView, basically. It takes care of dispatching API calls into the context
thread.
With these fixes it is now possible to create (and reuse) mutlple wpesrc
elements during the application lifetime.
Fixes#1372
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1484>
Receiving the WEBKIT_LOAD_COMMITTED event doesn't actually
mean we have committed an SHM buffer / image yet.
As this is the condition we are interested in, check it
instead.
Also wrap g_cond_wait in a loop for extra correctness points.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1476>
The previous version of the SHM export support still required a valid
EGLDisplay. The upcoming WPEBackend-FDO 1.8.x aims to remove this requirement,
hence allowing wpesrc to be used without GPU.
Starting from WPEBackend-FDO 1.6.x, software rendering support is available.
This features allows wpesrc to be used on machines without GPU, and/or for
testing purpose. To enable it, set the `LIBGL_ALWAYS_SOFTWARE=true` environment
variable and make sure `video/x-raw, format=BGRA` caps are negotiated by the
wpesrc element.
If the mutex is locked while running frameComplete there is a potential deadlock
bound to happen when we get a new exported images from the backend.
Fixes#1101
When WPEBackend-fdo >= 1.3.0 is detected, the threaded view now relies on the
wpe_fdo_egl_exported_image API instead of the EGLImageKHR-based API which is
going to be deprecated in 2.26. The GLib sources created by the view now use the
default priority as well, the custom priority is no longer required.
Including gl.h from WPEThreadedView.h leads to GST_LEVEL_DEFAULT detected as
redefined. The proposed fix is to include config.h from the CPP implementation
file and disable gl.h inclusion in the header, by using forward declarations.
The wpe element is used to produce a video texture representing a web page
rendered off-screen by WPE. This element can be used to overlay HTML on top of
another video stream for instance.
