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
In the unit test refactoring, the unlinked pad required to test
the different behaviour induced by "allow-not-linked" property
was removed.
Commit e364d7944e
Move all the code for this test in the proper function, and re-add
the missing unlinked pad. This makes the test useful again.
Split the large allocation_query test into seperate tests. Add a setup helper
to reduce code duplication. Fix the original test that used fail_unless instead
of ck_assert_int_eq and had it accidentially working.
There were a few errors:
* The plugin scanner now accepts executable path as an argument.
In case it is NULL, argc == 2
* We find the executable path in init_pre instead of gst_init,
allowing this to work when gst is initialized through the
option group (eg gst-inspect)
* There was a semi-colon missing in the __APPLE__ #ifdef
When a plugin declares a dependency using this flag, all the
relative paths are considered to be relative to the path of
the main executable.
We try to determine the path of the executable portably,
with implementations provided for Linux, Windows and Mac.
If retrieval of the path fails, we will not detect changes.
In order for the main executable path to be the same when
scanning a plugin in a child process, a new variable is
exposed in gst_private.h, _gst_executable_path
https://bugzilla.gnome.org/show_bug.cgi?id=788152
