The problem was that the macro was always used with 'ret' as the defaultval
argument.
This would result in the macro eventually expanding to
if (G_UNLIKELY (ret != ret && ret != GST_FLOW_OK))
... ret != ret will always fail, and therefore we'd never call the
following line.
Instead of that, store the previous value locally for comparision
Previously, dropping a query from a pad probe would deem the
query succeeded, and the caller might then assume the query's
results are valid, and thus dereference an invalid object
such as a GstCaps.
We now assume dropped queries did not succeed. Dropped events
and buffers are still deemed a success.
Added back after previous revert, as it's been double checked.
https://bugzilla.gnome.org/show_bug.cgi?id=740003
Previously, dropping a query from a pad probe would deem the
query succeeded, and the caller might then assume the query's
results are valid, and thus dereference an invalid object
such as a GstCaps.
We now assume dropped queries did not succeed. Dropped events
and buffers are still deemed a success.
Inactive pads should at all times have the flushing flag set. This means
that when we get a flush-stop on an inactive pad we must ignore it.
On sinkpads, make this more explicit. We used to not clear the flush
flag but remove the events and then return an error because the flushing
flag was set. Now just simply refuse the event without doing anything.
On srcpads, check that we are trying to push a flush-stop event and
refuse it. We would allow this and mark the srcpad as non-flushing
anymore.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=735357
Support for (nullable) was added to G-I at the same time as nullable
return values. Previous versions of G-I will not mark return values as
nullable, even when an (allow-none) annotation is present, so it is
not necessary to add (allow-none) annotations for compatibility with
older versions of G-I.
https://bugzilla.gnome.org/show_bug.cgi?id=730957
Stores the last result of a gst_pad_push or a pull on the GstPad and provides
a getter and a macro to access this field.
Whenever the pad is inactive it is set to FLUSHING
API: gst_pad_get_last_flow_return
https://bugzilla.gnome.org/show_bug.cgi?id=709224
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
events_foreach adds an extra ref when giving the event to the
user function. In case it was unrefed by the user, this extra ref
disappeared, but events_foreach still should unref again to
lose its own ref before removing the event from the array.
https://bugzilla.gnome.org/show_bug.cgi?id=722467
This allows blocking a pad, add a new blocking probe, removing
the first probe and then having the second probe called. Which
could then decide that data-flow should actually continue
instead of blocking now.
https://bugzilla.gnome.org/show_bug.cgi?id=721289
Also only check the data types for non-IDLE probes. When we
are idle, we have no data type obviously.
Previously we were calling IDLE probes during data flow whenever
a non-blocking probe would be called. The pad was usually not idle
at that time.
Make a new flag on the pad that tweaks the default behaviour of the
accept-caps function. By default it will check for a subset of the
query-caps result but this is not always desirable. The query-caps
result contains all the constraints to make a good caps decision
upstream but sometimes, like for parsers, not all the constrained caps
fields are known upstream and then a subset check would fail. Switching
to an intersection makes this work again.
See https://bugzilla.gnome.org/show_bug.cgi?id=705024https://bugzilla.gnome.org/show_bug.cgi?id=677401
* fix typo GstBufferFlag -> GstBufferFlags
* fix typo GstFeatures -> GstCapsFeatures
* fix typo GstAllocatorParams -> GstAllocationParams
* fix typo GstContrlSources -> GstControlSource
* do not refer to gstcheck as an object
* make references gtk_init() and tcase_set_timeout() not be references
* gst_element_get_pad() renamed gst_element_get_static_pad()
* gst_clock_id_wait_async_full() renamed gst_clock_id_wait_async()
* _drop_element() is really gst_queue_array_drop_element()
* gst_pad_accept_caps() was removed, do not refer to it
* separate GST_META_TAG_MEMORY_STR declaration from description
* do not describe removed gst_collect_pads_collect()
* correctly link to GstElementClass' virtual set_context()
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=719614
Renegotiation and reconfiguration will fail because all queries
and events won't be accepted by the pad if it's flushing. In the
best case this just causes unneeded work and spurious warnings in
the debug logs, in the worst case it causes elements to fail completely.
But do this only for events that are not dropped by flushing,
i.e. do it only for everything except SEGMENT and EOS.
Without this we might drop a CAPS event if flushing happens
at an unfortunate time and nobody is resending the CAPS event.
https://bugzilla.gnome.org/show_bug.cgi?id=700806
If a pad block was triggered from sending a sticky event downstream, it
could happen that the pad block is relinking pads, which then requires
to resend previous sticky events.
Previous patch was inforcing a complete ordering of the sticky events, while
in fact, only STREAM_START, CAPS and SEGMENT events need proper ordering.
See: https://bugzilla.gnome.org/show_bug.cgi?id=688188
We can prevent buggy element from causing other elements to fail or crash
by sorting sticky event at insertion. In this case, we also warn as this
is not supposed to happen.
See: https://bugzilla.gnome.org/show_bug.cgi?id=688188
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.
