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
When enabled, this property will make the allocation query fail. This is
the same as one could have done using a tee before the tee started
implementing the allocation query.
https://bugzilla.gnome.org/show_bug.cgi?id=730758
If multiple probes are set on a pad and one probe returns either
GST_PAD_PROBE_HANDLED or GST_PAD_PROBE_DROPPED we need to stop
calling the remaining probes.
https://bugzilla.gnome.org/show_bug.cgi?id=787243
We would constantly re-post the taglist because
posted_avg_rate only gets set to avg_bitrate if
parse->priv->post_avg_bitrate is true, so if it's
false the posted rate will always differ from the
current average rate and we'd queue an update,
which leads to us spamming downstream and the
application with taglist updates.
Fix this by only queuing an update if the average
rate will actually be posted.
These taglists updates could cause expensive
operations on the application side, e.g. in Totem.
https://bugzilla.gnome.org/show_bug.cgi?id=786561
Otherwise we might try unscheduling a clock id (that does not exist
yet), then the streaming thread waits for id and the state change never
continues because the streaming thread is blocked.
Also shutting down and flushing and similar should return FLUSHING, not
EOS. The stream is not over, we're just not accepting any buffers
anymore.
