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
This interface is needed to be able to embed waylandsink into
other wayland surfaces. Due to the special nature of wayland,
GstVideoOverlay is not enough for this job.
Before:
GST_GL_PLATFORM=cocoa GST_GL_WINDOW=cocoa
gst-launch-1.0 videotestsrc ! glimagesink
After:
GST_GL_PLATFORM=cgl GST_GL_WINDOW=cocoa
gst-launch-1.0 videotestsrc ! glimagesink
but still pass --enable-cocoa to configure script
because currently it can only be used with cocoa API.
We could later have cgl/gstglcontext_cgl.h that manages
a CGLContextObj directly and cocoa/gstglcontext_cocoa.h
would just wrap it.
So that it could be used with other Apple's window APIs.
https://bugzilla.gnome.org/show_bug.cgi?id=729245
This commit makes the loading of the GModules threadsafe, and
always first tries to load the symbol for the GL library that
is selected for the current context. Only then it falls back
to looking into the current module (NULL), and only as a last
resort the context specific function (e.g. eglGetProcAddress())
is called.
Also add configure parameters to select the names of the library
modules instead of using the defaults, and let the defaults be
independent of the G_MODULE_SUFFIX.
https://bugzilla.gnome.org/show_bug.cgi?id=728753
There is also an i386 version of iOS, which is for the simulator.
Better use our already existing HAVE_IOS check instead of relying
on the host triplet.
nettle is used by newer versions of gnutls, while older versions of gnutls
used libgcrypt. Support both for now as not every distro has nettle yet.
nettle is preferred as it is more efficient to use and much smaller.
Maybe testing the version is clearer, but testing for < 5 is not
enough, my version is 5.4 and does not yet have those new enums.
If you git blame to this and have a version > 5.4 that does not
either, please feel free to join along and bump the version.
Generate win32/common/config.h-new directly from config.h.in,
using shell variables in configure and some hard-coded information.
Change top-level makefile so that 'make win32-update' copies the
generated file to win32/common/config.h, which we keep in source
control. It's kept in source control so that the git tree is
buildable from VS.
This change is similar to the one recently applied to GStreamer
and gst-plugins-good. The previous config.h file in -bad was in
pretty bad shape, so unlike core and base, I didn't attempt to
leave it strictly the same, but fixed it as necessary. Needs
testing I cannot do myself.
https://bugzilla.gnome.org/show_bug.cgi?id=569015
including the following supports and fixes:
* Create DirectFB surfaces from GstBufferPool
* Add NV12 pixel format support
* Don't use the cursor in the exclusive mode
- EnableCusor() can be only used when the administrative mode is set
in DirectFB 1.6.0 and later.
* Support multiple plane rendering for planar color formats
- This accommodates the chroma plane offsets of the framebuffer
in planar formats.
* Invoke SetConfiguration regardless of video mode setting in setcaps()
- SetConfiguration() method should be invoked regardless of
the result of gst_dfbvideosink_get_best_vmode(), since the two are
unrelated.
* Disable DirectFB signal handler
- "--dfb:no-sighandler" option is passed to DirectFBInit().
This prevents DirectFB from trying to kill the process and allows
GStreamer's termination sequence to proceed normally.
https://bugzilla.gnome.org/show_bug.cgi?id=703520
Serves as an example of usage of the new mpegts library from an
application.
Will parse/dump all sections received on a bus.
Usage is ./tsparse <any gst-launch line using tsdemux or tsparse>
Examples:
./tsparse file:///some/mpegtsfile ! tsparse ! fakesink
./tsparse dvb://CHANNEL ! tsparse ! fakesink
./tsparse playbin uri=dvb://CHANNEL
./tsparse playbin uri=file:///some/mpegtsfile
...
https://bugzilla.gnome.org/show_bug.cgi?id=702724
Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section
Information as well as descriptors for usage by plugins and applications.
This replaces entirely the old GstStructure-based system for conveying
mpeg-ts information to applications and other plugins.
Parsing and validation is done on a "when-needed" basis. This ensures
the minimal overhead for elements and applications creating and using
sections and descriptors.
Since all information is made available, this also allows applications
to parse custom sections and descriptors.
Right now the library is targeted towards parsing, but the structures
could be used in the future to allow applications to create and inject
sections and descriptors (for usage by various mpeg-ts elements).
https://bugzilla.gnome.org/show_bug.cgi?id=702724
