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.
As long as we can create a GL context, pass one to
gstreamer. This at least gets us GL textures with
the ngl renderer, the previous code was arbitrarily
refusing that.
GModule requires the .so file extension on macOS for historic reasons.
However Meson defaults to .dylib for modules, so we need to override
it to get the correct extension.
Fixes#3645.
Visual Studio 2013 is just shy of being sufficiently C99-compliant to
build GTK master, as it did not support snprintf() in its CRT
implementation.
Use g_snprintf() to cover for this.
...for at least WGL, since we are not allowed to use wglMakeCurrent(),
which is eventually called by gdk_gl_context_make_current() to share WGL
contexts across different threads, which will cause a crash.
This means, we cannot enable WGL in the gstreamer media backend 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.
This gracefully disable ffmpeg, gstreamer, cups and cloudprint optional
dependencies when they are not available, while still giving full
control to distributors using -Dauto_features=enabled.
Visual Studio does not allow decorating functions with '__declspec (dllexport)'
if a prototype exists and is not decorated with '__declspec (dllexport)' as
well, so we cannot just decorate g_io_module_[load|unload|query] in the various
module sources with G_MODULE_EXPORT because the prototypes of these functions
have been marked with _GLIB_EXTERN, which equates to 'extern' unless overridden
Fix this by overriding _GLIB_EXTERN with the appropriate visibility flag, as we
have used to define _GDK_EXTERN. Unfortunately, we can't just use _GDK_EXTERN
G_MODULE_EXPORT as they may have not been defined yet for our use
Do this across the board for all modules, even if they are not buildable on
Visual Studio nor Windows, for consistency's sake.
We need to override _GLIB_EXTERN to export the required symbols for the
GIO module on Visual Studio, so that the media modules can be
successfully loaded.
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
This way, we can support external libraries providing implementations of
GtkMediaFile.
We also add a media backend called 'nomedia' that can be enabled to not
compile any support for GtkMediaFile. This is useful when people want to
statically compile GTK into an application that does not use media.
For now, this option is the default.
We also support a new environment variable GTK_MEDIA that allows
selecting the implementation to use.
GTK_MEDIA=help can be used to get info about the available
implementations.
