sync=TRUE implementation changes the latency query of a non-live
upstream into live, though it wrongly set the upstream max latency to 0.
As non-live sources won't loose data if we wait longer, this should have
been reported as have no max latency limite (-1).
I copied `error-after` to make the `eos-after` property, but it turned
out there were some problems with that one, so this patch: adds
separate counters (so setting to NULL and reusing the element will
still work); clarifies the properties' min values; and reports an
error when both are set.
Using `num-buffers` can be unpredictable as buffer sizes are often
arbitrary (filesrc, multifilesrc, etc.). The `error-after` property on
`identity` is better but obviously reports an error afterwards. This
adds `eos-after` which does exactly the same thing but reports EOS
instead.
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
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.
They can fail for various reasons.
For non-fatal cases (such as the dump feature of identiy and fakesink),
we just silently skip it.
For other cases post an error message.
https://bugzilla.gnome.org/show_bug.cgi?id=728326
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
TRUE is 1, but every other non-zero value is also considered true. Comparing
for equality with TRUE would only consider 1 but not the others.
Also normalize booleans in a few places.
We always work in passthrough mode so there's no point in doing
something more clever in basetransform. Also the basetransform
code leads to problems with incomplete caps and downstream
elements that use GST_PAD_FLAG_ACCEPT_INTERSECT.
https://bugzilla.gnome.org/show_bug.cgi?id=732559
Default to not creating lots of overhead by doing a couple of
g_strdup_printf()/g_free() per buffer or event just to generate
a last-message update that rarely anyone listens to. This means
that you need to enable silent=true explicitly in order to get
last-message dumps in gst-launch -v now. On the upside, people
won't inadvertently end up benchmarking g_strdup_printf()
performance instead of gstreamer data handling performance any
more.
Maybe the silent property should be renamed to enable-last-message
or something like that?
Correctly mark passthrough on the baseclass so that it can correctly do the
allocation of the output buffers.
Remove our custom prepare_output_buffer function now that the baseclass is
smarter.
Conflicts:
gst/gstindexfactory.c
libs/gst/base/gstbasetransform.c
plugins/elements/gstfakesink.c
plugins/elements/gstfakesrc.c
plugins/elements/gstidentity.c
plugins/elements/gstinputselector.c
plugins/elements/gstoutputselector.c
Note: did not merge any of the basetransform changes from 0.10.
