Include gst/gl.h instead of specific headers to prevent such problems also in
the future.
In file included from ../../../../gst-libs/gst/gl/gl.h:47:0,
from ../../../../gst-libs/gst/gl/gstglbasememory.h:137,
from ../../../../gst-libs/gst/gl/gstglmemory.h:29,
from cluttershare.c:39:
../../../../gst-libs/gst/gl/gstglmemorypbo.h:51:20: error: field ‘mem’ has incomplete type
GstGLMemory mem;
^
../../../../gst-libs/gst/gl/gstglmemorypbo.h:124:24: error: field ‘parent’ has incomplete type
GstGLMemoryAllocator parent;
^
../../../../gst-libs/gst/gl/gstglmemorypbo.h:134:29: error: field ‘parent_class’ has incomplete type
GstGLMemoryAllocatorClass parent_class;
^
First, use top_builddir, otherwise it fails in out-of-source builds.
Second, link to the libtool archive directly to let make understand
the dependency.
One may not have an GstGLContext available or current in the thread where one
would need to update the shader. Support this by signalling create-shader
whenever the one-shot 'update-shader' is set to TRUE.
Implemented with videotestsrc ! glshader ! glupload ! gtkglsink
Errors on an invalid shader compilation are ignored however any error
provided by the glsl compiler is printed to stdout.
When g_option_context_parse fails, context and error variables are not getting free'd
which results in memory leaks. Free'ing the same.
And replacing g_error_free with g_clear_error, which checks if the error being passed
is not NULL and sets the variable to NULL on free'ing.
https://bugzilla.gnome.org/show_bug.cgi?id=753854
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
The variables to store face values are only needed if they will be used to
control the volume. Which isn't the default to avoid potentially being very
loud accidentally. Only create variables when needed.
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
An example app that takes video URIs as command line arguments and switches
between them seamlessly one after the other using compositor and audiomixer.
Both audio-video and video-only media files are valid inputs, but mixing files
of both types in a single invocation is cumbersome to support, and hence does
not work. The example attempts to keep the audio stream moving along perfectly,
and duplicates video frames where necessary to cover gaps in the video
timestamps using the 'ignore-eos' videoaggregator pad property.
Ensuring seamless (and mostly-glitch-free) switching is harder than it sounds,
and hence the example contains plenty of pad probes and running time
calculations to make things work.
The GPtrArray play_queue contains items that are being played back, have been
prepared for playback, and will be played back in the future. The queue itself
is mutable besides the first two items (playing and prepared). The item that has
been prepared should not be edited or removed since it has been prepared in
advance to be activated immediately on the current item's EOS.
The example also has support for switching to the next item in the queue
prematurely; see the --switch-after/-s flag to the application.
Note: the output video is hard-coded at 1280x720, and input video is scaled as
needed to fit this size. Set OUTPUT_VIDEO_WIDTH/HEIGHT to change this.
https://bugzilla.gnome.org/show_bug.cgi?id=748947
g_object_get() returns a ref, gtk_container_add() only ref_sink().
That mean we still need to unref afterward. This leak was hiding
a reference bug previously present.
If 95% of the code of an example app consists of GObject
code, maybe that's defeating the point a little. So just
remove a lot of that and trim down the example to the
absolute minimum. Also removes the last remaining GPL3
licensed code in -bad.
Using NSApp directly seems to confuse something, as the compiler
was expecting an id<NSFileManagerDelegate>. Switched to using
[NSApplication sharedApplication], and specified the delegate
protocol on the window class as well.
Similar to https://bugzilla.gnome.org/show_bug.cgi?id=738740
The GPL3 license header was copy'n'pasted from a
neighbouring source file by mistake, the original
code was not GPL3 licensed, but fell under the
default GStreamer license, which is LGPLv2+.
https://bugzilla.gnome.org/show_bug.cgi?id=685655
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
Serves no purpose, is not even hooked up to the
build system, has hard coded file names and paths,
and can easily be replaced with a gst-launch line.
https://bugzilla.gnome.org/show_bug.cgi?id=739844
We need to pass the X11 display to GstGL or else it will
use its own X11 Display pointer, and the GL Context won't get shared
correctly on newer X servers
1. glcontextid function is replaced by gstreamer gst_gl_context_new_wrapped .
2. call gst_init before gst_gl_display_new , seems gst_gl_display_new depends
on gst_allocator_register , which only worked after gst_init called
3. flush gstreamer OpenGL context before using shared texture, fix
flicker problem.
https://bugzilla.gnome.org/show_bug.cgi?id=735566
It was previously a mix and match of both variants, introducing just too much
confusion.
The prefix are from now on:
* GstMpegts for structures and type names (and not GstMpegTs)
* gst_mpegts_ for functions (and not gst_mpeg_ts_)
* GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_)
* GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_)
The rationale for chosing that is:
* the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts)
* the namespace is one word under Gst
* it's shorter (yah)
The reshape property was never used.
Replace the draw property with a signal.
Based on patch by Mathieu Duponchelle <mathieu.duponchelle@epitech.eu>
https://bugzilla.gnome.org/show_bug.cgi?id=704507
