Follow up of 7130230ddb
Provide the memory implementation the GstMapInfo that will be used to
map/unmap the memory. This allows the memory implementation to use
some scratch space in GstMapInfo to e.g. track different map/unmap
behaviour or store extra implementation defined data about the map
in use.
https://bugzilla.gnome.org/show_bug.cgi?id=750319
This overrides the default latency handling and configures the specified
latency instead of the minimum latency that was returned from the LATENCY
query.
https://bugzilla.gnome.org/show_bug.cgi?id=750782
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.
Add GST_SEEK_FLAG_TRICKMODE_KEY_UNITS and
GST_SEEK_FLAG_TRICKMODE_NO_AUDIO, and rename GST_SEEK_FLAG_SKIP
to GST_SEEK_FLAG_TRICKMODE (with backwards compat define).
Do the same for the corresponding SEGMENT flags.
https://bugzilla.gnome.org/show_bug.cgi?id=735666
Make host IPs in square brackets store only the IP, i.e. strip the brackets.
Strip leading whitespace characters in URIs.
Fail parsing when host part does not match any valid formats from RFC3986.
https://bugzilla.gnome.org/show_bug.cgi?id=743195
The problem was that the macro was always used with 'ret' as the defaultval
argument.
This would result in the macro eventually expanding to
if (G_UNLIKELY (ret != ret && ret != GST_FLOW_OK))
... ret != ret will always fail, and therefore we'd never call the
following line.
Instead of that, store the previous value locally for comparision
Add domain checks for the input values, and a variable precision
calculation that loops if necessary to ensure we never overflow
accumulators and then silently produce garbage results.
Make the (non-public) linear regression function available for
unit testing by putting it in a separate source file the test
can include. Add a unit test that the new regression function
produces sensible results for several inputs taken from real-world
captures.
gst_clock_add_observation_unapplied() adds a new master/slave clock
observation and runs the regression without activating the new
calibration results.
gst_clock_adjust_with_calibration() uses directly passed calibration
parameters, instead of using the clock's current calibration,
allowing for calculations using pending or old calibration params
Otherwise the struct is going to be copied, which is not very efficient. And
also has the nice side effect that modifications of the struct might be
done in a copy, and we later use the original struct without the changes.
Caused LATENCY queries to always return the initialization values in one of my
tests, instead of the actual values reported by child elements.
API: GST_LEVEL_MAX
By compiling gstreamer (or plugins) with GST_LEVEL_MAX defined, only
the debugging statements at or below that level will be compiled in.
This allows compiling in some debugging (like errors and warnings) which
helps in debugging, but without the full cpu/memory overhead of all debugging
enabled.
Pools are allowed to change the size in order to adapt padding. So
don't check the size. Normally pool will change the size without
failing set_config(), but it they endup changing the size before
the validate method may fail on a false positive.
https://bugzilla.gnome.org/show_bug.cgi?id=741420
Add a function to check if the preset iface implementation is editable and
document this from the implementers perspective.
API: gst_preset_is_editable()
gstdebugutils.c: In function 'gst_debug_bin_to_dot_data':
gstdebugutils.c:683:530: error: 'return' with no value, in function returning non-void [-Werror]
g_return_if_fail (GST_IS_BIN (bin));
TRUE is 1, but every other non-zero value is also considered true. Comparing
for equality with TRUE would only consider 1 but not the others.
Also normalize booleans in a few places.
The documentation states that gst_element_send_event is to "send an event
to an element".
Therefore we *send* upstream events to a source pad and downstream events
to a sink pad
Previously, dropping a query from a pad probe would deem the
query succeeded, and the caller might then assume the query's
results are valid, and thus dereference an invalid object
such as a GstCaps.
We now assume dropped queries did not succeed. Dropped events
and buffers are still deemed a success.
Added back after previous revert, as it's been double checked.
https://bugzilla.gnome.org/show_bug.cgi?id=740003
Previously, dropping a query from a pad probe would deem the
query succeeded, and the caller might then assume the query's
results are valid, and thus dereference an invalid object
such as a GstCaps.
We now assume dropped queries did not succeed. Dropped events
and buffers are still deemed a success.
If a task thread is calling pause on it self and the
controlling/"main" thread stops the task, it could end in a race
where gst_task_func loops and then checks for paused after the
controlling thread just changed the task state to stopped.
Hence the task would actually call func again even though it was
both paused and stopped.
https://bugzilla.gnome.org/show_bug.cgi?id=740001
It's architecture dependent and should not be placed into the include
directory as the assumption is that all those headers are architecture
independent.
https://bugzilla.gnome.org/show_bug.cgi?id=739767
The GST_INFO ("initialized GStreamer succesfully") is currently at the end of
gst_init_check which isn't guaranteed to be run since GStreamer can be
initialized by using init_pre and init_post directly from GOptionContext like
gst-launch does. Ensure this message is displayed by moving it to init_post.
