If we pre-allocate only *exactly* as many nodes as we need for the
core types, we are practically guaranteed a re-alloc when external
code like GstVideoTimeCode or GstEncodingProfile register their
own GstValue things. So allocate a bit more than strictly needed.
An object that can be waited on and asked for asynchronous values.
In much the same way as promise/futures in js/java/etc
A callback can be installed for when the promise changes state.
Original idea by
Jan Schmidt <jan@centricular.com>
With contributions from
Nirbheek Chauhan <nirbheek@centricular.com>
Mathieu Duponchelle <mathieu@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=789843
The following could happen previously:
* T1: calls gst_pad_set_active()
* T2: currently (de)activating it
* T1: gst_pad_set_active() returns, caller assumes that the pad has
completed the requested (de)activation ... whereas it is not
the case since the actual (de)activation in T2 might still be
going on.
To ensure atomicity of pad (de)activation, we use a internal
variable (and cond) to ensure only one thread at a time goes through
the actual (de)activation block
https://bugzilla.gnome.org/show_bug.cgi?id=790431
checking whether we already were in the target GstPadMode was being
done too early and there was the risk that we *would* end up
(de)activating a pad more than once.
Instead, re-do the check for pad mode when entering the final pad
(de)activation block.
https://bugzilla.gnome.org/show_bug.cgi?id=790431
When EOS reaches concat, it will switch to the next candidate as its
activate pad.
The problem arises when there is only one sinkpad, the "active" pad
becomes NULL. This results in concat becoming unusable after it receives
a *single* EOS on its single sinkpad.
If we detect there is a single sinkpad and there is no current active pad:
* If we are waiting (from selected sink event/buffer), become the current
active pad.
* If there is a seek request, send it upstream. We don't switch the
active_sinkpad property at that point in time, since the seek could
fail. If the seek succeeds, the following SEGMENT (or STREAM_START)
will cause the pad_wait() to elect that pad as the new active one.
* Flush events get forwarded
https://bugzilla.gnome.org/show_bug.cgi?id=790167
Include the timestamp of the recorded log as in the 'stats' tracer.
This can be useful, for example, to plot a graph showing the latency
over time.
https://bugzilla.gnome.org/show_bug.cgi?id=781315
Add convenience API that iterates over all pads, sink pads or
source pads and makes sure that the foreach function is called
exactly once for each pad.
This is a KISS implementation. It doesn't use GstIterator and
doesn't try to do clever things like resync if pads are added
or removed while the function is executing. We can still do that
in future if we think it's needed, but in practice it will
likely make absolutely no difference whatsoever, since these
things will have to be handled properly elsewhere by the element
anyway if they're important.
After all, it's always possible that a pad is added or removed
just after the iterator finishes iterating, but before the
function returns.
This is also a replacement for gst_aggregator_iterate_sink_pads().
https://bugzilla.gnome.org/show_bug.cgi?id=785679
The goal of this tracer is to measure the processing latency between a
src and a sink. In push mode, the time was read after the chain function
have returned. As the amount of time we wait to get synched is reverse
to the amount of latency the source introduced, the result was quite
surprising.
This patch moves the latency calculation in the pre-push hook. When
there is no processing in a a pipeline (e.g. fakesrc ! fakesink), the
latency will now be 0 as it's supposed to. For pull mode, the code was
already correct. When GstBaseSink operate in pull mode, the processing
time is done durring the pull, so pull-post is the right hook. The
synchronization will happen after the pull has ended. Note that
GstBaseSink rarely operate in pull mode.
https://bugzilla.gnome.org/show_bug.cgi?id=788431
Asking to select no streams makes no sense and can create various
issues.
If one doesn't one any stream it should deactivate (or not use) the
element in question.
Boy scout rule. Make is a little less painful to debug the tests by using
fail_unless_equals_{uint64,int64,float} where appropriate. Ideally the large
tests would be splitted to avoid guessing data dependencies.
Rename print_element_features() to print_feature_info() and move the code that
handles the ElementFactory there. This simplifies the calling code and improves
readability.
Also don't leak the features for other factories.
Various plugins use the value of '0' as an invalid seqnum value
(qtdemux for matching duplicated seek events, for example). Make
that behaviour explicit, create a GST_SEQNUM_INVALID value,
and ensure gst_util_seqnum_next never returns it.
For linked elements, the resulting gst_bin_iterate_sorted() will
properly return elements from sink to sources.
If we have some elements that are not linked, we *still* want to
ensure that we return:
* In priority any sinks
* Last of all any sources
* And in between any element which is neither source nor sink
For this to work, when looking for the next candidate element,
not only check the degree order, but if there are two candidates
with the same degree order, prefer the non-source one.
Amongst other things, this fixes the case where we activating a
bin containing unlinked sources and other elements. Without this
we could end up activating sources (which might start adding pads
to be linked) before other (to which those new source element pads
might be linked) are not activated
https://bugzilla.gnome.org/show_bug.cgi?id=788434
The real use case is when downstream didn't set a pool or
allocation params, in which case we expect the tee to not
create a pool or param from thin air. Dowstream setting
an pool with size=0 was in fact testing a downstream element
bug. The fact we handle that is accidental.
If the aggregated size is 0 and we create a pool, the pool would provide
buffers with no memory assigned. Handle that case and skip the pool.
This was the behaviour before cf803ea9f4.
Add a test for this scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=730758
