Context: Latency configuration should not be
messed up because of not-linked pads. In general,
one return FALSE on latency distribution causes
the "overall" pipeline latency configuration to
fail. This shows up as noise in logs (warning).
Conflicts:
gst/gstpad.c
Otherwise a pipeline where one sticky event fails to be sent will
never forward EOS events downstream. This can cause pipelines to
wait forever for EOS on errors.
Improve the docs of the get/pull_range functions, define the lifetime of the
buffer in case of errors and short reads.
Make sure the code does what the docs say.
Make it so that one can specify a buffer for get/pull_range where the downstream
element should write into. When passing NULL, upstream should allocate a buffer,
like in 0.10.
We also need to change the probes a little because before the pull probe, there
could already be a buffer passed. This then allows us to use the same PROBE
macro for before and after pulling.
While we're at the probes, make the query probe more powerful by handling the
GST_PAD_PROBE_DROP return value. Returning _DROP from a query probe will now
return TRUE upstream and will not forward the probe to the peer or handler.
Also handle _DROP for get/pull_range properly by not dispatching to the
peer/handler or by generating EOS when the probe returns DROP and no buffer.
Make filesrc handle the non-NULL buffer passed in the get_range function and
skip the allocation in that case, writing directly into the downstream provided
buffer.
Update tests because now we need to make sure to not pass a random value in the
buffer pointer to get/pull_range
Make a helper function check_sticky to check and push pending sticky events.
Move the handling of the result of pushing the sticky event inside the
push_event function, we need to mark the event as received when it was pushed
correctly.
Move the sticky events code outside of gst_pad_push_event_unchecked and
make it purely handle sending the event to the peer.
when pushing a sticky event, first store it on the pad. Then check and push any
pending sticky events when we get a serialized or sticky event on a srcpad. This
fixes the issue where sticky events are not pushed when an event is pushed.
Because gst_pad_get_pad_template_caps() returns ANY when there is no template,
the query caps function should also return ANY when there is no template (and no
pad current caps) instead of EMPTY.
When we have no chain function or when we are operating the pad in the wrong
mode, emit a critical instead of posting an error message. This is certainly a
programming error and we cannot always post a message (like when the pad has no
parent)
We don't use the sticky event index anymore, ordering of the events are how they
were sent initially.
Add some more padding between the event numbers so that we can insert new events
later.
