If a ContentProtection element is present in an AdaptationSet element,
send Protection events on the source pad, so that qtdemux can use this
information to correctly generate its source caps for DASH CENC
encrypted streams.
This allows qtdemux to support CENC encrypted DASH streams where the
content protection specific information is carried in the MPD file
rather than in pssh boxes in the initialisation segments.
This commit adds a new function to the adaptivedemux base class to allow
a GstEvent to be queued for a stream. The queue of events are sent the
next time a buffer is pushed for that stream.
https://bugzilla.gnome.org/show_bug.cgi?id=705991
They require to get_proc_address some functions through the
platform specific {glX,egl}GetProcAddress rather than the default
GL library symbol lookup.
nvidia drivers return the exact version in glGstString (GL_VERSION)
we request on creation so start with the highest known version and
work our way down.
The previous approach of traversing the other_context weak ref tree was
1. Less performant
2. Incorrect for context destruction removing a link in the tree
Example of 2:
c1 = context_create (NULL)
c2 = context_create (c1)
c3 = context_create (c2)
context_can_share (c1, c3) == TRUE
context_destroy (c2)
unref (c2)
context_can_share (c1, c3) returns FALSE when it should be TRUE!
This does not remove the restriction that context sharedness can only
be tracked between GstGLContext's.
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)
