If Mesa is built without X11 headers, building against Mesa EGL headers
requires a dependency on egl.pc, to define MESA_EGL_NO_X11_HEADERS.
This fixes a build error when compiling ext/qt/gstqtglutility.cc:
In file included from /usr/include/EGL/egl.h:39,
from /usr/include/gstreamer-1.0/gst/gl/egl/gstegl.h:44,
from ../gst-plugins-good-1.16.1/ext/qt/gstqtglutility.cc:43:
/usr/include/EGL/eglplatform.h:124:10: fatal error: X11/Xlib.h: No such file or directory
As of Qt >= 5.5, qmake do not link to opengl32 by default anymore. This commit adds opengl32.lib to the .pro
file so that the plugin can be build using QtCreator on Windows.
On other OSes, it's not possible to have qmake or the qt5 pkg-config
files and not have moc, and `moc` will not be in `PATH`, so this only
causes problems.
This was originally added for fixing conflicting definitions between
Android and Qt, but times have changed and now this breaks the build
on iOS:
[...]/OpenGLES.framework/Headers/ES3/gl.h:1006:48: error: unknown type name 'gst_qt_GLsync'
GL_API void GL_APIENTRY glGetSynciv (GLsync sync, GLenum pname, GLsizei bufSize, GLsizei* length, GLint* values) OPENGLES_DEPRECATED(ios(7.0, 12.0), tvos(9.0, 12.0));
^
../ext/qt/gstqtgl.h:49:16: note: expanded from macro 'GLsync'
#define GLsync gst_qt_GLsync
^
6 errors generated.
Instead, we simply avoid defining GLsync ourselves if we're using Qt.
Needs gnustl for C++ STL support, which is the GNU STL on Android API
19 and older, and is a wrapper for the llvm-libc++ STL on newer APIs.
QtGui C++ templates use GL functions, so GLESv2 is needed at link time
The android code path is slightly different than the EGLFS one,
so I added previously a HAVE_QT_ANDROID define for use with qmake.
Here I also add it in meson, although I expect nobody will ever use
meson to build this, as it's complicated.
it is perfectly legal to use the <module/class> style of includes with Qt
and it avoids the need for having the module's include dir in the include path
In 2018 khronos changed the gl header guards. If we don't detect
this properly we would end up with plenty of symbol redifinition
(since we would be importing twice the "same" header).
Instead detect if the "newer" header was already included and if
so define the "old" define to avoid this situation
Fixes#523
Otherwise there may be no valid typedef of GLsync.
...
/usr/include/gstreamer-1.0/gst/gl/gstglfuncs.h:93:24: note: in definition of macro 'GST_GL_EXT_FUNCTION'
ret (GSTGLAPI *name) args;
^~~~
/usr/include/gstreamer-1.0/gst/gl/glprototypes/sync.h:33:23: error: 'GLsync' has not been declared
(GLsync sync))
^~~~~~
...
https://bugzilla.gnome.org/show_bug.cgi?id=796879
Tested on linux with X11/wayland and semi-tested on Windows.
Windows crashes on item destruction however this is better than nothing.
Fix up some win32 build issues on the way with mismatched {} and
G_STMT_{START,END}
This reverts commit 47fd4d391e.
This patch is incorrect. It doesn't actually compile, and causes a crash
because the viv-fb window implementation needs a native EGL handle
to pass to fbCreateWindow, but the GstGLDisplayEGL handleis actually
an EGLDisplay now (and gets cast to the wrong type)
This simplifies the code a lot without any functional changes apart from
not closing the display connection. Closing the display connection is
not safe to do as it is shared between all other code in the same
process and no reference counting or anything happens at the platform
layer.
Move the package defines for GST_PLUGIN_DEFINE from the
command line into the source file to avoid quoting issues
(-DPACKAGE_NAME="foo" means the quotes won't actually make
it to the compiler and then it no longer gets a string constant).
This is useful for autoplay for example. With autoplay, it is necessary to
wait until the scene graph is fully set up. This signal is emitted once the
QML item node is ready. So, inside a connected slot, the pipeline's state
can be set to PLAYING to automatically start playback as soon as the QML
script is loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=786246
QML can destroy the video widget at any time, leaving
us with a dangling pointer. Use a lock and a proxy
object to cope with that, and block in the widget
destructor if there are ongoing calls into the widget.
