When flushing, it is expected that upstream will send a SEGMENT
event afterwards.
This also avoids stray SEGMENT events from coming through after a
flush.
the code ifed a debug statement, that can't be right. anyway, the way it is,
we don't really need that branch, as we set the flag to unset only if set
(and that can't fail) hence the end result is always to unset the flag.
Signed-off-by: Niv Sardi <xaiki@evilgiggle.com>
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=691985
It's usually not a problem if a query fails if there's no peer,
especially as it will happen during pad linking (caps query)
quite often and spams the logs.
If we try to push sticky events but a probe dropped them, we don't mark
the event as received and mark the pad as PENDING_EVENTS. This ensures
that we resend the event the next time. For this we need to let the
custom flow return from the probe trickle up to
gst_pad_push_event_unchecked() so that we can differentiate between
OK and DROPPED probe returns.
Also add test to make sure that if a pad probe is removed while it's
callback is running, the cleanup_hook isn't called again if it
returns GST_PAD_PROBE_REMOVE
Recheck for sticky events after doing a pad block because the pad block could
have caused a relink and then we need to resend the events to the newly linked
pad.
Fixes things like switching of visualisations.
Add an alternative version of gst_pad_check_reconfigure that doesn't
clear the reconfigure flag.
Useful for increasing error resilience without duplicating the
reconfigure code in pad task functions.
API: gst_pad_needs_reconfigure
https://bugzilla.gnome.org/show_bug.cgi?id=681198
In the proxy_query_caps function, also filter against the filter in the query.
We don't need to filter against the filter in the query anymore in the default
caps query function because we already did this in the proxy_query_caps.
The ghostpad code directly activates/deactivates the child code by
calling gst_pad_activate_mode, rather than gst_pad_set_active, so
make sure to clear the flags in gst_pad_activate_mode(), which should
catch all cases.
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.
This has to be handled explicitely by elements to
make sure that they support all the metas passed
in the allocation query.
Metas have to supported explicitely, otherwise the
query will fail. All elements in a chain need to
support a specific meta to allow its usage.
Use GstFlowReturn to internally pass events between pads.
When we sticky events cause an error, translate this error into a GstFlowReturn.
Caps events will, for example, generate a NOT_NEGOTIATED return when the event
function returns an error.
This allows us then to refuse sending buffers if one of the sticky events is
refused and generate a correct error return value.
If we are dealing with a blocking probe, only then check if one the
blocking flags of the hook matches.
Add some more debug.
Make the pad unit test less racy.
This check is correct but unfortunately it's impossible to implement
in a threadsafe way because the caps could have changed in the meantime.
Fixes bug #659606.
Add a new event flag for sticky events so that multiple events of that type can
be stored on a pad at the same time. Change the _get_sticky_event() function to
loop over the multiple events of a type.
Change the foreach function to make it possible to removed and modify the sticky
events on a pad.
Use an variable size array now to store the events. This could later be
optimized some more.
Rewrite sticky events, trying to make it a bit more simple.
When sticky events are pushed on a srcpad, store them in the sticky event
array and mark the event with received = FALSE.
When the sticky event is successfully sent to the peer pad, make
received = TRUE.
Keep a PENDING_EVENTS pad flag that is set when one of the events is in
the received = FALSE state for some reason.
when activating a sinkpad, mark all events received = FALSE on the peer
srcpad.
When pushing a buffer, check the PENDING_EVENTS flag and if it is set, push all
events to the peer pad first.
Add _full variants of the pad function setters that take a destroy notify.
Make some macros that make the old method name pass NULL to this new
function.
Add the pad mode to the activate function so that we can reuse the same function
for all activation modes. This makes the core logic smaller and allows for some
elements to make their activation code easier. It would allow us to add more
scheduling modes later without having to add more activate functions.
