Document that "widget" property must be accessed from the
main thread (where GTK is running). This is the same for
state transition on these elements. It is very natural to
do so un GTK applications.
This is a "pseudo" base class. Basically it's a shared instance
and class structure and a shared set of function between the
two widget. It cannot have it's own type like normal base class
since the one instance will implement GtkGLArea while the other
implements GtkDrawingAreay. To workaround this, the parent instance
and class is a union of both.
https://bugzilla.gnome.org/show_bug.cgi?id=752441
I notice that if you stop the pipeline during a renegotiation
the upload may be NULL while an allocation query is being run.
In that scenario, returning FALSE to the allocation query is the
best thing.
Move back the default property at the same place they are in the
other sink. This helps when using a diff viewer to synchronized
this unfortunate copy paste.
https://bugzilla.gnome.org/show_bug.cgi?id=751104
In GTK dispose can be called before the last ref is reached. This
happens when you close the container window. The dispose will be
explicitly called, and destroyed notify will be fired. This patch
fixes this race by properly tracking the widget state.
In the sink, we now set the widget pointer to NULL, so the widget
will properly get created again if you set your pipeline to NULL
state after the widget was destroy, and set it back to PLAYING.
https://bugzilla.gnome.org/show_bug.cgi?id=751104
CMBlockBuffer offers a model similar to GstBuffer, as it can
consist of multiple non-consecutive memory blocks.
Prior to this change, what we were doing was:
1) Incorrect:
CMBlockBufferCreateWithMemoryBlock does not copy the data,
but we gst_buffer_unmap'd right away.
2) Inefficient:
If the GstBuffer consisted of non-contiguous memory blocks,
gst_buffer_map resulted in malloc / memcpy.
With this change, we construct a CMBlockBuffer out of individual mapped
GstMemory objects. CMBlockBuffer is made to retain the GstMemory
objects (through the use of CMBlockBufferCustomBlockSource), so the
original GstBuffer can be unref'd.
https://bugzilla.gnome.org/show_bug.cgi?id=751241
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
We only want to do a hard reset of the observations if we're working
with TIME segments in push mode. For BYTE segment we want to keep
the observations (in order to do seeks in push-mode).
When in push mode, we want to discard all previous observations from the
mpegtspacketizer when we get a DISCONT buffer.
This avoids trying to calculate bogus timestamps (estimating them using old
PCR observations).
We only do a hard reset in push-mode. In pull-mode we still need the observations
(in order to seek properly)
Checking for a parent is not enough, it must have a toplevel one.
If widget has no toplevel parent then add it in a GtkWindow, that
make it usable from gst-launch-1.0.
https://bugzilla.gnome.org/show_bug.cgi?id=751104
Added unit tests for all functions. Code coverage:
Overall coverage rate:
lines......: 83.8% (1941 of 2316 lines)
functions..: 100.0% (141 of 141 functions)
This is not public API, use g_assert() instead of
g_return_if_fail(), so that it's compiled out in
releases. It's only called from our code, with &foo.
This will deadlock if the main thread is the one who creates the GstGLContext.
All things we call from the main thread should be possible from any thread.
https://bugzilla.gnome.org/show_bug.cgi?id=751101
