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.
1. Need set use-default-fbo to qquickwindow during set property
to support change render target on the fly.
2. Calculate qmlglsrc refresh frame rate in qtglwindow
https://bugzilla.gnome.org/show_bug.cgi?id=774035
When start qmlglsink app, it will set NULL buffer to GstQSGTexture
in which case that qt_context_ will be a random value and cause
gst_gl_context_activate() fail.
https://bugzilla.gnome.org/show_bug.cgi?id=770925
Compiler would complain about include directory that didn't
exist because QPA_INCLUDE_PATH gets subst-ed regardless
(and if it didn't we'd have just an empty -I argument).
https://bugzilla.gnome.org/show_bug.cgi?id=767553
The current state of c++ ABI's on Window's and Gst's/Qt's conflicting
mingw builds means that we cannot use mingw for building the qt plugin.
Instead, a qmake .pro file is provided that is expected to be used with the
msvc binaries provided by Qt like so:
(with the PATH environment variable containing the path to the qt biniaries
and PKG_CONFIG_PATH containing the path to GStreamer modules)
cd /path/to/sources/gst-plugins-bad/ext/qt
qmake -tp vc
Then open the resulting VS project and build the library. Then
cp debug/libgstqtsink.dll /path/to/prefix/lib/gstreamer-1.0/libgstqtsink.cll
https://bugzilla.gnome.org/show_bug.cgi?id=761260
We don't directly link to GL in the element, though we use GL headers.
For this reason we need to include the proper GL headers path. This
prevent this element from using a different GL header then libgstgl.
The base class is useful for having multiple backing memory types other
than the default. e.g. IOSurface, EGLImage, dmabuf?
The PBO transfer logic is now inside GstGLMemoryPBO which uses GstGLBuffer
to manage the PBO memory.
This also moves the format utility functions into their own file.
The scene graph can be initialized when the we receive window handle change
notification and so we will not receive a scenegraph initialization
notification. Initialize ourself in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=758337
They require to get_proc_address some functions through the
platform specific {glX,egl}GetProcAddress rather than the default
GL library symbol lookup.
Very much in the same spirit as the Gtk GL sink
Two things are provided
1. A QQuickItem subclass that renders out RGBA filled GstGLMemory
buffers that is instantiated from qml.
2. A sink element that will push buffers into (1)
To use
1. Declare the GstGLVideoItem in qml with an appropriate
objectName property set.
2. Get the aforementioned GstGLVideoItem from qml using something like
QQmlApplicationEngine engine;
engine.load(QUrl(QStringLiteral("qrc:/main.qml")));
QObject *rootObject = engine.rootObjects().first();
QQuickItem *videoItem = rootObject->findChild<QQuickItem *> ("videoItem");
3. Set the videoItem on the sink
https://bugzilla.gnome.org/show_bug.cgi?id=752185
