When holding a regular ref it will cause the GstBus to never
reach 0 references and it won't be destroyed unless the application
explicitly calls gst_bus_remove_signal_watch().
Switching to weakref will allow the GstBus to be destroyed.
The application is still responsible for destroying the
GSource.
https://bugzilla.gnome.org/show_bug.cgi?id=762552
Showcases the regression introduced by this commit:
Commit: ab55ad7eaa
Author: Stian Selnes <stian@pexip.com>
Date: Wed Jan 27 13:20:23 2016 +0100
ghostpad: Do nothing in _internal_activate_push_default
Fixes a race where an entry is set to BUSY in
gst_system_clock_id_wait_jitter() and is UNSCHEDULED before
gst_system_clock_id_wait_jitter_unlocked() starts processing it. The
wakeup added by gst_system_clock_id_unschedule() must be cleaned up.
Two stress tests are added. One test that triggers the specific issue
described above. The second stresses the code path where a wait is
rescheduled because the poll returned early.
https://bugzilla.gnome.org/show_bug.cgi?id=761586
Change the gst_tracer_record_new() api to take the parameters the make the
spec structure directly. This allows us to own the top-level structure and
also collect the args so that we can take ownership of the sub-structures.
https://bugzilla.gnome.org/show_bug.cgi?id=760821
Only hide GstTracer and GstTracerRecord API behind GST_USE_UNSTABLE_API,
but don't spew any warnings, otherwise everyone has to define this
to avoid compiler warnings.
This reverts parts of commit 89ee5d948d.
We use this class to register tracer log entry metadata and build a log
template. With the log template we can serialize log data very efficiently.
This also simplifies the logging code, since that is now a simple varargs
function that is not exposing the implementation details.
Add docs for the new class and basic tests.
Remove the previous log handler.
Fixes#760267
Changing states up and down while buffers are being pushed is not
a valid use case. If a pad is deactivated and reactivated during
a buffer push it is racy with the check of pushed sticky events
and the actual chainfunction call. As it might call the chain
without noticing the peer pad lost its previous sticky events.
https://bugzilla.gnome.org/show_bug.cgi?id=758340
Adds 3 new tests for testing accept-caps behavior with
proxy-caps pads.
1) A scenario where there is no proxy. The caps should be compared to the
template caps of the pad
2) A scenario where there is a compatible pad. The caps should be compared
to the proxied pad caps (and also with the template)
3) A scenario where there is an incompatible proxy pad. No caps should be
possible at all.
https://bugzilla.gnome.org/show_bug.cgi?id=754112
Updated gst_segment_position_from_stream_time and gst_segment_to_stream_time to reflect correct calculations for the case when the applied rate is negative.
Pasting from design docs:
===============================
Stream time is calculated using the buffer times and the preceding SEGMENT
event as follows:
stream_time = (B.timestamp - S.start) * ABS (S.applied_rate) + S.time
For negative rates, B.timestamp will go backwards from S.stop to S.start,
making the stream time go backwards.
===============================
Therefore, the calculation for applied_rate < 0 should be:
stream_time = (S.stop - B.timestamp) * ABS (S.applied_rate) + S.time
and the reverse:
B.timestamp = S.stop - (stream_time - S.time) / ABS (S.applied_rate)
https://bugzilla.gnome.org/show_bug.cgi?id=756810
The previous change (see bgo #756069) was causing us to free the same pointer
multiple times. If we actually get a sample back, the test fails, no need to
free anything in that case.
When g_option_context_parse fails, context and error variables are not getting free'd
which results in memory leaks. Free'ing the same.
And replacing g_error_free with g_clear_error, which checks if the error being passed
is not NULL and sets the variable to NULL on free'ing.
https://bugzilla.gnome.org/show_bug.cgi?id=753851
The default padding I introduced in d4f81fb4e6 is
actually only 4 pointers and on 32bit platforms already smaller than the union.
Replace it with a fixed 64byte padding. Don't add the normal padding for now.
Fixes#755822
While this technically is an abi break, we decided to do this:
1) the struct is documented to be internal
2) the struct is alloced and freed inside the library
3) there are no public methods that receive or return instances
4) the only code known to use this struct are classes containd here
When adding an element to a bin we need to propagate the GstContext's
to/from the element.
This moves the GstContext list from GstBin to GstElement and adds
convenience functions to get the currently set list of GstContext's.
This does not deal with the collection of GstContext's propagated
using GST_CONTEXT_QUERY. Element subclasses are advised to call
gst_element_set_context if they need to propagate GstContext's
received from the context query.
https://bugzilla.gnome.org/show_bug.cgi?id=705579
gst_segment_to_position might cause confusion, especially with the addition of
gst_segment_position_from_stream_time . Deprecated gst_segment_to_position
now, and replaced it with gst_segment_position_from_running_time.
Also added unit tests.
Iterator may need to be resynced, for instance if pads are released
during state change.
got_eos should be protected by the object lock of the element, not of
the pad, as is the case throughout the rest of the funnel code.
https://bugzilla.gnome.org/show_bug.cgi?id=755343
In order for gst_harness_new_full to be MT-safe the increase and
decrease of HARNESS_REF must be MT-safe. This allows for creating
multiple harnesses from different threads wrapping the same element.
https://bugzilla.gnome.org/show_bug.cgi?id=754661
As this test is using a short sleep (GST_USECOND, which is 10ms
in microsecond), sometimes that EOS event is received before the
loop in basesrc have run _do_seek() and pushed the update segment.
To solve this issue, we wait for the initial segment (and flush it)
then we wait for the second segment before sending EOS.
https://bugzilla.gnome.org/show_bug.cgi?id=753365
In some cases, probes might want to handle the buffer/event/query
themselves and stop the data from travelling further downstream.
While this was somewhat possible with buffer/events and using
GST_PROBE_DROP, it was not applicable to queries, and would result
in the query failing.
With this new GST_PROBE_HANDLED value, the buffer/event/query will
be considered as successfully handled, will not be pushed further
and the appropriate return value (TRUE or GST_FLOW_OK) will be returned
This also allows probes to return a non-default GstFlowReturn when dealing
with buffer push. This can be done by setting the
GST_PAD_PROBE_INFO_FLOW_RETURN() field accordingly
https://bugzilla.gnome.org/show_bug.cgi?id=748643
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
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
Update test_seeking testcase to verify the render and render_list
virtual method handle buffers and buffer list containing multiple
memory blocks correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=747223
GstFileSink implements the render_list virtual method to render
a list of buffers. Update the test_seeking test case to also
check the render_list method implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=747100
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
Otherwise baseparse will consider empty streams to be an error while
an empty stream is a valid scenario. With this patch, errors would
only be emitted if the parser received data but wasn't able to
produce any output from it.
This change is only for push-mode operation as in pull mode an
empty file can be considered an error for the one driving the
pipeline
Includes a unit test for it
https://bugzilla.gnome.org/show_bug.cgi?id=733171
This property avoids not linked error when all the pads are unlinked
or when there are no source pads. This is useful in dynamic pipelines
where it can happen that for a short time there are no pads at all or
all downstream pads are not linked yet.
https://bugzilla.gnome.org/show_bug.cgi?id=746436
3 new tests:
1) Tests that a stream that is empty (just an EOS event)
on inactive pad doesn't get through and tamper
with the active pad that still has data
2) Tests that a stream that is shorter than the active one
(pushes EOS earlier) doesn't has its EOS pushed
3) Tests that switching to an inactive stream that has received
EOS will make input-selector push EOS
https://bugzilla.gnome.org/show_bug.cgi?id=746518
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.
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
Demultiplex a stream to multiple source pads based on the stream ids from the
stream-start events. This basically reverses the behaviour of funnel.
https://bugzilla.gnome.org/show_bug.cgi?id=707605
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.
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.
