Properly separate files as we will not have only one single base class
for all elements as we used to with 0.10, but the same way it is done
with ladspa, we subclass GstAudioFilter, GstBaseSource etc...
https://bugzilla.gnome.org/show_bug.cgi?id=678207
it's exposed in public API so hiding it in an AC_DEFINE for config.h only
works when building libgstgl itself. Attempting to use libgstgl (especially
on egl platforms) will throw a compilation error.
The plugin doesn't need the wayland-scanner package to be built
or run, it only needs the wayland-scanner program during compile time.
When cross-compiling, build systems might not have the wayland-scanner
package for the target system as it is a developer's tool, while it should
still be possible to use wayland-scanner from the host system.
This patch fixes it by not requiring the wayland-scanner package but
just the binary itself.
Note that the check is done outside of the PKG_CHECK_MODULES
as it doesn't work inside of it.
https://bugzilla.gnome.org/show_bug.cgi?id=752688
Just check whether LATM is defined which is only available
in 2.7 and later. Allows us to simplify the configure check
a little and we can get rid of some hackish workarounds for
problems with earlier version headers.
It's useful enough already to be used in other elements for audio aggregation,
let's give people the opportunity to use it and give it some API testing.
https://bugzilla.gnome.org/show_bug.cgi?id=760733
GCC automatically disable redundance warnings for system headers. As
soon as we start using a non-system installed mesa, we would start
having issues. The test for both wasn't setting any flags, so it would
work but then fail at runtime.
This is being fixed by disabling in the code (where needed only) that
GCC warning. The test is also fixed to avoid the false positive we had.
The videoframe-audiolevel element acts like a synchronized audio/video "level"
element. For each video frame, it posts a level-style message containing the
RMS value of the corresponding audio frames. This element needs both video and
audio to pass through it. Furthermore, it needs a queue after its video
source.
https://bugzilla.gnome.org/show_bug.cgi?id=748259
New subclass with a similar behaviour as the old liveadder, but
a slightly different API as the latency is in nanoseconds, not
milliseconds. Also, the new liveadder has a effective latency that
is latency + output-buffer-duration. In practice, just setting a non-zero
latency with the new audiomixer gives you the right behavior in 99% of the
cases.
The alsamidisrc element allows to get input event from ALSA MIDI
sequencer devices, and possibly convert them to sound using some
downstream element like fluiddec.
https://bugzilla.gnome.org/show_bug.cgi?id=738687
Instead of checking for the gstreamer-video-1.0 package is installed,
just assume it is since we already check for the -base dependency.
With this replace the GST_VIDEO_* variables in makefiles and directly
link with libgstvideo.
https://bugzilla.gnome.org/show_bug.cgi?id=753820
Some distributions store OpenCV files in /usr/share/opencv and some others
(and default when building from source) install them in
/usr/share/OpenCV. Support both to find cascade files.
https://bugzilla.gnome.org/show_bug.cgi?id=753651
First check for Qt build tools in the host_bins directory
from the Qt5Core pkg-config file. This fixes the situation
where both Qt4 and Qt5 are installed but the global moc/uic/etc.
are the Qt4 version, which would result in build failures.
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
On fedora 22, the output of cpp inserts extra debug comments, which
makes our regexp for the faad2 version check fail. This in turn causes
it to compile with the wrong arguments passed which then causes stack
corruption and crashes.
Fix this by only checking for the version (which should be by itself on
a single line). This is potentially less safe, it might be possible that
a similar string would appear in a later version in the header file.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=748571
* Checks for opencv2 headers only, not for legacy opencv1 headers
* Checks for every opencv2 header that the implementation needs,
not just highgui_c.h
https://bugzilla.gnome.org/show_bug.cgi?id=725163
This API has been deprecated for eternities and microsoft
stopped shipping the headers in 2010 accoding to wikipedia,
so let's just remove it and focus on bringing the plugins
based on the newer APIs up to snuff.
Removes the use of NSOpenGL* variety and functions. Any Cocoa
specific functions that took/returned a NSOpenGL* object now
take/return the CGL equivalents.
gmyth seems to be unmaintained upstream, and no one has asked
for this to be ported for a very long time, so let's just
remove it. Neither debian nor Fedora seem to ship libgmyth
any longer, and in any case it's most likely deprecated by
the UPnP support in MythTV.
This reverts commit 15394aa705.
The latest release (v1.1) does not have pkg-config support
yet, so this plugin won't be built with the latest release.
Cerbero uses the latest release, so this makes cerbero
builds fail, which expect the plugin to be built.
We can re-commit this once there's a release that includes
pkg-config support.
A context can create a GLsync object that can be waited on in order
to ensure that GL resources created in one context are able to be
used in another shared context without any chance of reading invalid
data.
This meta would be placed on buffers that are known to cross from
one context to another. The receiving element would then wait
on the sync object to ensure that the data to be used is complete.
If configure finds GL + GLES2 but the user passes --enable-gles2 and
the two GL API's cannot be built against together, configure was still
allowing the desktop GL stack to be built.
Until gcc and GNUStep properly support Objective-C blocks and other
"new" features of Objective-C we can't properly support them without
making the code much more ugly.
https://bugzilla.gnome.org/show_bug.cgi?id=739152
The part of the configure.ac that consist to check if we
can include both GL and GLES2 at the same time is failing.
Indeed, in the case NEED_GLES2=yes and NEED_OPENGL=auto,
HAVE_OPENGL variable is updated whereas it should be HAVE_GL
variable that has to be updated (HAVE_OPENGL variable is not
used in the rest of the configure.ac).
https://bugzilla.gnome.org/show_bug.cgi?id=739348
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Benjamin GAIGNARD <benjamin.gaignard@linaro.org>
Replace the hardcoded -lpthread in most of the places with $PTHREAD_LIBS. For
openh264 also add $PTHREAD_LIBS to OPENH264_LIBS until upstream ships a .pc
file.
OpenJPEG 2.0 API uses stdcall on W32 by default. This prevents normal
autoconf library macros from finding its functions.
A more compatible check is to acutally link a program that includes a
real header.
https://bugzilla.gnome.org/show_bug.cgi?id=733487
Otherwise those checks may fail at configure time if they contain extra
include paths, while at build time they are included, potentially causing
incompatible typedefs between system GL headers and gstreamer compatibility
prototypes.
https://bugzilla.gnome.org/show_bug.cgi?id=733248
They should be handled in tandem, in case any EGL provider could require some
CFLAGS and set them (possibly once moved to prefer pkg-config files),
such as for a custom header location.
Clang will only give a warning for the redefinition of typedef GLenum.
Since master is build with -Werror this will result in a build failure
later in the gl plugin. Add -Werror to the test, so the test result is as
expected. This will allow the gl plugins to build.
https://bugzilla.gnome.org//show_bug.cgi?id=731692
