We only need a display to negotiate dmabuf formats. Pass that
directly, instead of getting the display of the GL context as
we did so far.
With this,
GSK_RENDERER=vulkan GL_DISABLE=gl gtk4-demo --run video_player
still uses dmabufs.
Related: #7048
I just spent an hour trying to figure out why things don't work. And it
was an optional dependency hidden 3 layers deep in some meson file.
This really has to stop.
And because just like in GTK, GStreamer's dmabuf APIs are always
available (they will just fail on Windows etc), there's no need to have
any conditions.
The only difference is that the GStreamer media backend now requires
GStreamer 1.24.
When the cicp values coming out of GStreamer are unspecified, replace
them with the default cicp values for YUV video: 1/13/6.
We still may end up with unspecified values inside the params, because
GStreamer returns unspecified for primaries/tfs/matrices that aren't
supported by cicp.
See also https://github.com/AOMediaCodec/libavif/wiki/CICP#unspecified
fora similar discussion.
The later CICP changes made the cicp params we were setting unustable.
Set ones that work in the current state of git main. They are still
imperfect, but they reflect the current code.
Visual Studio (and possibly other non-GCC compilers) do not like
uses of #-preprocessor directives in macro usage (warning C5101: use of
preprocessor directive in function-like macro argument list is undefined
behavior is also shown), so fix the build by defining another macro
accordingly.
By implementing support for `GdkDmabufTextureBuilder` and
`GstVideoInfoDmaDrm`. This allows zero-copy video playback on Wayland
when paired with hardware video decoding.
Can be tested with `gtk4-demo --run=video_player`
1. Check GStreamer caps for premultiplied alpha and select
GdkMemoryFormat accordingly
2. Set a GdkMemoryFormat for GL textures
Fixes the video in widget-factory being treated as premultiplied when it
isn't.
Since we are making GdkGLContext call the core wgl*() functions directly
instead of via libepoxy, drop the workarounds that we needed for notifying
libepoxy that wglMakeCurrent() outside of GDK/GTK was called.
This way, we clean up the code, and as a result, we can use the GstGL
APIs like the other platforms to query what GL api that is to be used.
For ensuring that things work between different threads, we now call
gdk_gl_context_clear_current() in place of calling wglMakeCurrent(xxx,
NULL), so that we make sure that there is no current GL context on a
thread outside of GstGL's thread, which Windows does not like.
It does not make sense to sync and wait in the
same context, that is just a no-op. The intention
of this code clearly was to sync in the gst
context, and wait in the gdk one.
That also matches what the gtk sink implementation
in gstreamer does.
Those property features don't seem to be in use anywhere.
They are redundant since the docs cover the same information
and more. They also created unnecessary translation work.
Closes#4904
If we have GStreamer on macOS we likely have support for CGL to get an
OpenGL context we can use. This provides the missing pieces to get
accelerated video playback in gtk4-widget-factory working.
Make the "gl-context" property of the GstGLSink readable as well so that
we can query whether the GstGLContext sharing really succeeded. If it
did, then we proceed to playback our video using the glimagesink as we
did before. If it didn't, throw out the GtkGstSink we were creating, and
re-create the GtkGstSink without the "gl-context" property, meaning that
we won't be using the glimagesink in this case.
Add support to look for and use the EGL context in Windows if it was activated
instead of desktop OpenGL.
GstGL may have been built with or without EGL/libANGLE support, so if it were,
check in GstGL whether we have gst_gl_display_new_with_type() to create a
GstGLDisplay that is of the GST_GL_WINDOW_WIN32 type when we are using
Desktop OpenGL (WGL), otherwise we show messages indicating that envvars
need to be set to initialize GstGL properly.
Due to a bug in GstGL, the GstGLContext can only be set up successfully
if one of the following is true:
* An OpenGL 3.x or later emulator, such as Mesa is used (for WGL)
* The latest GstGL master is being used, at the time of writing (for
WGL)
* GTK, libepoxy and GstGL are all built only with WGL support (for WGL)
* EGL is being used in GTK at runtime
Special thanks to Matthew Waters for the help during the process.
Add support to share the WGL context in GDK with the WGL context in GStreamer,
so that we can also use OpenGL in the gstreamer media backend to playback
videos. For now OpenGL/ES is not supported for this under Windows.
The process of setting this up in Windows is a little bit more involved, as:
* The OpenGL support in GstGL requires a GL 4.1 Core context, but we may just
get the GL version from wglCreateContextAttribsARB() that we pass into the
attributes, which is 3.2 by default. So, try to ask for a 4.1 Core context
first if we are asking for anything less.
* There is only one GstDisplay available for Windows, so we just use
gst_gl_display_new().
* We must explicitly tell libepoxy that we are using wglMakeCurrent() outside
of libepoxy that is being used in GdkGL, otherwise we would end up crashing
as the GL/WGL function pointers would become invalid.
* We must also deactivate temporarily the underlying WGL context that was made
current by gdk_gl_context_make_current() so that when
gst_gl_display_create_context() calls wglShareLists(), we won't get bitten
by error 0xaa (resource busy), as some drivers don't handle this well when
the GL context is current in another thread.
For the last two points we make use of macros defined by the platforms that the
build is done for to help us carry out the necessary tasks as needed.
Thanks to Matthew Waters for the info on integrating GstGL and windowing
toolkits on Windows.
The memory pointed to by GstVideoFrame::plane_data becomes invalid after
unmapping causing the GBytes to point at some random memory if the
unmapping is not deferred until its destroy notify.
When the GStreamer buffer is backed by normal system memory this is not
a problem but if it is backed by e.g. an OpenGL texture, dmabuf or some
other hardware-specific memory this will otherwise cause interesting
problems.
We were leaking the GBytes for the image memory, which is a
noticeable memleak to anyone who's casually running a memory monitor.
Go KDE users!
Closes#1200
