gst_clock_wait_for_sync(), gst_clock_is_synced() and gst_clock_set_synced()
plus a signal to asynchronously wait for the clock to be synced.
This can be used by clocks to signal that they need initial synchronization
before they can report any time, and that this synchronization can also get
completely lost at some point. Network clocks, like the GStreamer
netclientclock, NTP or PTP clocks are examples for clocks where this is useful
to have as they can't report any time at all before they're synced.
https://bugzilla.gnome.org/show_bug.cgi?id=749391
There are gstmemory's available that operate in two memory domains
and need to ensure consistent access between these domains.
Imagine a scenario where e.g. the GLMemory is mapped twice in both
the GPU and the CPU domain. On unmap or a subsequent map, it would
like to ensure that the most recent data is available in the memory
domain requested. Either by flushing the writes and/or initiating a
DMA transfer. Without knowing which domain is being unmapped, the
memory does not know where the most recent data is to transfer to
the other memory domain.
Note: this still does not allow downgrading a memory map.
https://bugzilla.gnome.org/show_bug.cgi?id=750319
Now that locking exclusively dows not always succeed, we need to signal
the failure case from gst_memory_init.
Rather than introducing an API or funcionality change to gst_memory_init,
workaround by checking exclusivity in the calling code.
https://bugzilla.gnome.org/show_bug.cgi?id=750172
gst_memory_lock (mem, WRITE | EXCLUSIVE);
gst_memory_lock (mem, WRITE | EXCLUSIVE);
Succeeds when the part-miniobject.txt design doc suggests that this should fail:
"A gst_mini_object_lock() can fail when a WRITE lock is requested and
the exclusive counter is > 1. Indeed a GstMiniObject object with an
exclusive counter 1 is locked EXCLUSIVELY by at least 2 objects and is
therefore not writable."
https://bugzilla.gnome.org/show_bug.cgi?id=750172
DllMain should not be relied on for anything except storing the DLL handle.
It should also not be defined for static builds, but doing so is not
straightforward and is mostly harmless, so let's just add a comment about that
for now.
GstFlagSet is a new type designed for negotiating sets
of boolean capabilities flags, consisting of a 32-bit
flags bitfield and 32-bit mask field. The mask field
indicates which of the flags bits an element needs to have
as specific values, and which it doesn't care about.
This allows efficient negotiation of arrays of boolean
capabilities.
The standard serialisation format is FLAGS:MASK, with
flags and mask fields expressed in hexadecimal, however
GstFlagSet has a gst_register_flagset() function, which
associates a new GstFlagSet derived type with an existing
GFlags gtype. When serializing a GstFlagSet with an
associated set of GFlags, it also serializes a human-readable
form of the flags for easier debugging.
It is possible to parse a GFlags style serialisation of a
flagset, without the hex portion on the front. ie,
+flag1/flag2/flag3+flag4, to indicate that
flag1 & flag4 must be set, and flag2/flag3 must be unset,
and any other flags are don't-care.
https://bugzilla.gnome.org/show_bug.cgi?id=746373
The old gst_object_has_ancestor will call the new code. This establishes the
symetry with the new gst_object_has_as_parent.
API: gst_object_has_as_ancestor()
Ensure iterator is advanced. The current list iteration code only
advances the iterator (walk) if a match is found, which results
in an infinite loop when more than one entry exists in the list.
https://bugzilla.gnome.org/show_bug.cgi?id=748321
In order to support some types of protected streams (such as those
protected using DASH Common Encryption) some per-buffer information
needs to be passed between elements.
This commit adds a GstMeta type called GstProtectionMeta that allows
protection specific information to be added to a GstBuffer. An example
of its usage is qtdemux providing information to each output sample
that enables a downstream element to decrypt it.
This commit adds a utility function to select a supported protection
system from the installed Decryption elements found in the registry.
The gst_protection_select_system function that takes an array of
identifiers and searches the registry for a element of klass Decryptor that
supports one or more of the supplied identifiers. If multiple elements
are found, the one with the highest rank is selected.
This commit adds a unit test for the gst_protection_select_system
function that adds a fake Decryptor element to the registry and then
checks that it can correctly be selected by the utility function.
This commit adds a unit test for GstProtectionMeta that creates
GstProtectionMeta and adds & removes it from a buffer and performs some
simple reference count checks.
API: gst_buffer_add_protection_meta()
API: gst_buffer_get_protection_meta()
API: gst_protection_select_system()
API: gst_protection_meta_api_get_type()
API: gst_protection_meta_get_info()
https://bugzilla.gnome.org/show_bug.cgi?id=705991
In order for a decrypter element to decrypt media protected using a
specific protection system, it first needs all the protection system
specific information necessary (E.g. information on how to acquire
the decryption keys) for that stream.
The GST_EVENT_PROTECTION defined in this commit enables this information
to be passed from elements that extract it (e.g. qtdemux, dashdemux) to
elements that use it (E.g. a decrypter element).
API: GST_EVENT_PROTECTION
API: gst_event_new_protection()
API: gst_event_parse_protection()
https://bugzilla.gnome.org/show_bug.cgi?id=705991
When idle probe runs directly from the gst_pad_add_probe() function
we need to make sure that no data flow happens as idle probe
is a blocking probe. The idle probe will prevent that any
buffer, bufferlist or serialized events and queries are not
flowing while it is running.
https://bugzilla.gnome.org/show_bug.cgi?id=747852
When a bin changes states upwards, and a child fails to change,
any child that was already switched will not be reset to its
original state, leaving its state inconsistent with the bin,
which does not change state due to the failure.
If the state change was from NULL to READY, it means that deleting
this bin will cause those children to be deleted while not in
NULL state, which is a Bad Thing. For other upward changes, it
is less of a problem, as a subsequent switch back to NULL will
cause an actual downwards change on those inconsistent elements,
albeit from the "wrong" state.
We now reset state to the original one when a child fails.
Includes unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=747610
An element that performs decryption does not naturally fit within any
of the existing element factory class types. It is useful to be able
to easily get a list of all elements that support decryption so that
a union can be computed between the protection systems that have a
supported decryptor and the allowed protection systems for a particular
stream.
This commit adds a new GST_ELEMENT_FACTORY_TYPE_DECRYPTOR and its
associated string identifier "Decryptor". It also adds
GST_ELEMENT_FACTORY_TYPE_DECRYPTOR to GST_ELEMENT_FACTORY_TYPE_DECODABLE
so that uridecodebin can auto-plug a decryption element.
https://bugzilla.gnome.org/show_bug.cgi?id=705991
Use case: we want to block the source pad of a leaky queue and
drop the buffer that causes the block. If we return PROBE_DROP
then the buffer gets dropped, but we get called again. If we
return PROBE_OK we can't easily drop the buffer. If we just
replace the item into the GstPadProbeInfo structure with NULL,
GStreamer will push a NULL buffer to the next element when we
unblock the pad probe. This patch ensures it doesn't do that.
https://bugzilla.gnome.org/show_bug.cgi?id=734342
Also skip gst_pipeline_get_clock() and gst_pipeline_set_clock() from the
bindings as they are confused with gst_element_*_clock().
API: gst_pipeline_get_pipeline_clock()
https://bugzilla.gnome.org/show_bug.cgi?id=744442
Only print interesting caps features, don't
append (memory:SystemMemory) to all caps,
which makes them much more unwieldy and
harder to read. Also use internal function
to get caps features so that our printing
has no side effects on the caps.
https://bugzilla.gnome.org/show_bug.cgi?id=746809
Don't unwrap strings that start but don't finish with a double quote. If a
string is delimited by two quotes we unescape them and any special characters
in the middle (like \" or \\). If the first character or the last character
aren't a quote we assume it's part of an unescaped string.
Moved some deserialize_string unit tests because we don't try to unwrap strings
missing that second quote anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=688625
Do not do any checks for the start/stop in the new
gst_segment_to_running_time_full() method, we can let this be done by
the more capable gst_segment_clip() method. This allows us to remove the
enum of results and only return the sign of the calculated running-time.
We need to put the old clipping checks in the old
gst_segment_to_running_time() still because they work slightly
differently than the _clip methods.
See https://bugzilla.gnome.org/show_bug.cgi?id=740575
Add a clip argument to gst_segment_to_running_time_full() to disable
the checks against the segment boundaries. This makes it possible to
generate an extrapolated running-time for timestamps outside of the
segment.
See https://bugzilla.gnome.org/show_bug.cgi?id=740575
Add a helper method to get a running-time with a little more features
such as detecting if the value was before or after the segment and
negative running-time.
API: gst_segment_to_running_time_full()
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=740575
The position in the segment is relative to the start but the offset
isn't, so subtract the start from the position when setting the offset.
Add unit test for this as well.
gstbuffer.c:522:58: error: implicit conversion from enumeration type 'GstBufferFlags' to
different enumeration type 'GstBufferCopyFlags' [-Werror,-Wenum-conversion]
if (!gst_buffer_copy_into (copy, (GstBuffer *) buffer, flags, 0, -1))
~~~~~~~~~~~~~~~~~~~~ ^~~~~
gstbuffer.c:534:46: error: implicit conversion from enumeration type 'GstBufferCopyFlags' to
different enumeration type 'GstBufferFlags' [-Werror,-Wenum-conversion]
return gst_buffer_copy_with_flags (buffer, GST_BUFFER_COPY_ALL);
~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~~
./gstbuffer.h:433:31: note: expanded from macro 'GST_BUFFER_COPY_ALL'
...((GstBufferCopyFlags)(GST_BUFFER_COPY_METADATA | GST_BUFFER_COPY_MEMORY))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Don't stop the pool in set_config(). Instead, let the controlling
element manage it. Most of the time, when an active pool is being
configured is because the caps didn't change.
https://bugzilla.gnome.org/show_bug.cgi?id=745377
A variant of gst_buffer_copy that forces the underlying memory
to be copied.
This is added to avoid adding an extra reference to a GstMemory
that might belong to a bufferpool that is trying to be drained.
The use case is when the buffer copying is done to release the
old buffer and all its resources.
https://bugzilla.gnome.org/show_bug.cgi?id=745287
Shouldn't take the lock while unreferencing messages, because that may cause
more messages to be sent, which will try to take the lock and cause the app to
hang.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=728777
gst_bin_sync_children_states() will iterate over all the elements of a bin and
sync their states with the state of the bin. This is useful when adding many
elements to a bin and would otherwise have to call
gst_element_sync_state_with_parent() on each and every one of them.
https://bugzilla.gnome.org/show_bug.cgi?id=745042
Instead of always shortening the __FILE__ path, even if the
log message is not actually printed, which might happen if
the log level is activated but the category is not, only
shorten the path if we're actually going to output it and
if it looks like it needs shortening. Log handlers had no
guarantee that they would get a name instead of a path
anyway on any architecture, so it shouldn't be a problem.
https://bugzilla.gnome.org/show_bug.cgi?id=745213
A single unlinked pad can make the latency query fail across the
pipeline, which is probably not desirable. Instead, we return a default
anything goes value.
Perhaps we should also be emitting a gst_message_new_latency() when a
PLAYING element has one of its pads linked.
https://bugzilla.gnome.org/show_bug.cgi?id=745197
This reverts commit 1911554cff.
This breaks the functionality of GST_PAD_FLAG_NEED_PARENT, the reason for this
flag is that if a pad is removed from a running element, you don't want
functions (such as chain or event) to be called on the pad without a parent set.
This can happen if you remove a request or sometimes pad from a running element.
I don't see the code that caused this in tsdemux, but if it needs to unset
the flag on remove, it should do it itself and then make sure that the parent
exists in any pad function.
Revive message in dispose handler before we signal the bus thread,
otherwise the bus thread might be woken up and unref the message
before we had a chance to revive it yet.
Async message delivery (where the posting thread gets blocked
until the message has been processed and/or freed) was pretty
much completely broken.
For one, don't use GMutex implementation details to check
whether a mutex has been initialized or not, esp. not
implementation details that don't hold true any more with
newer GLib versions where atomic ops and futexes are used
(spotted by Josep Torras). This led to async message
delivery no longer blocking with newer GLib versions on
Linux.
Secondly, after async delivery don't free mutex/GCond
embedded inside the just-freed message structure.
Use a new (private) mini object flag to signal GstMessage
that the message being freed is part of an async delivery
on the bus so that the dispose handler can keep the message
alive and the bus can free it once it's done cleaning up
stuff.
If an element implements wrongly the URI query and set the uri to NULL and if
the element calls gst_pad_create_stream_id at some point, it will lead to crash
as the uri is not supposed to be NULL in the gst_pad_create_stream_id_internal
function.
https://bugzilla.gnome.org/show_bug.cgi?id=744520
Before we just took the values from the first pad that succeded the query,
now we accumulate the results of every sinkpad properly and return that
result.
