If no date and only a time is given in gst_date_time_new_from_iso8601_string(),
assume that it is "today" and try to parse the time-only string. "Today" is
assumed to be in the timezone provided by the user (if any), otherwise Z -
just like the behavior of the existing code.
https://bugzilla.gnome.org/show_bug.cgi?id=753455
To be able to disable the slightly "magic" forwarding of the
necessary events between the harnesses.
Also introduce a new test-suite for GstHarness, that documents the
feature, and should hopefully expand into documenting most of the
features the harness possesses.
https://bugzilla.gnome.org/show_bug.cgi?id=752746
Writing a test for unscheduling the gst_clock_id_wait inside the
identity element, found an invalid read, caused by removing the clock-id
when calling _unschedule instead of letting the code calling _wait remove
the clock-id after being unscheduled.
https://bugzilla.gnome.org/show_bug.cgi?id=752055
The check for the presence of the parent in the presence of
the NEED_PARENT flag was missing for the chain function. Also keep
a ref on the parent in case the pad is removed mid-chain.
test_intersect_flagset fails because when caps is being
created, flags and mask are being cast to uint64 while
they should be uint. This results in invalid memory access
or a segfault.
https://bugzilla.gnome.org/show_bug.cgi?id=751628
Adds tests for gst_element_get_compatible_pad for when it has to
request pads.
Note that these tests don't cover the case when it has to request
a pad that already exists.
https://bugzilla.gnome.org/show_bug.cgi?id=751235
Make gst_collect_pads_clip_running_time() function also store the
signed DTS in the CollectData. This signed DTS value can be used by
muxers to properly handle streams where DTS can be negative initially.
https://bugzilla.gnome.org/show_bug.cgi?id=740575
Allow for sub-classes which want to collate incoming buffers or
split them into multiple output buffers by separating the input
buffer submission from output buffer generation and allowing
for looping of one of the phases depending on pull or push mode
operation.
https://bugzilla.gnome.org/show_bug.cgi?id=750033
gst/gstmemory.c:570:38: error: implicit conversion from enumeration type 'GstMapFlags' to different enumeration
type 'GstLockFlags' [-Werror,-Wenum-conversion]
fail_unless (gst_memory_lock (mem, GST_MAP_WRITE));
~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
GstPtpClock implements a PTP (IEEE1588:2008) ordinary clock in
slave-only mode, that allows a GStreamer pipeline to synchronize
to a PTP network clock in some specific domain.
The PTP subsystem can be initialized with gst_ptp_init(), which then
starts a helper process to do the actual communication via the PTP
ports. This is required as PTP listens on ports < 1024 and thus
requires special privileges. Once this helper process is started, the
main process will synchronize to all PTP domains that are detected on
the selected interfaces.
gst_ptp_clock_new() then allows to create a GstClock that provides the
PTP time from a master clock inside a specific PTP domain. This clock
will only return valid timestamps once the timestamps in the PTP domain
are known. To check this, the GstPtpClock::internal-clock property and
the related notify::clock signal can be used. Once the internal clock
is not NULL, the PTP domain's time is known. Alternatively you can wait
for this with gst_ptp_clock_wait_ready().
To gather statistics about the PTP clock synchronization,
gst_ptp_statistics_callback_add() can be used. This gives the
application the possibility to collect all kinds of statistics
from the clock synchronization.
https://bugzilla.gnome.org/show_bug.cgi?id=749391
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
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()
gst_debug_unset_threshold_for_name() used to go into an
infinite loop when there was more than one category in
the list. This test captures the problem by failing
via timeout.
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
Only save the messages we're interested in and expecting.
When run with *:9 we might get additional TRACE level
messages from other categories and then we don't end up
with the number of messages we expect.
This tests add an idle probe on an idle pad from a separate thread
so that the callback is called immediatelly. This callback will sit
still and then we try to push a buffer on this same pad. It verifies
that the idle probe blocks data passing
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
