A proxy-pad should always proxy the caps related queries
and events to its down or upstream peers on the other side
of the element. Falling back to a caps query seems wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=754112
In some cases, probes might want to handle the buffer/event/query
themselves and stop the data from travelling further downstream.
While this was somewhat possible with buffer/events and using
GST_PROBE_DROP, it was not applicable to queries, and would result
in the query failing.
With this new GST_PROBE_HANDLED value, the buffer/event/query will
be considered as successfully handled, will not be pushed further
and the appropriate return value (TRUE or GST_FLOW_OK) will be returned
This also allows probes to return a non-default GstFlowReturn when dealing
with buffer push. This can be done by setting the
GST_PAD_PROBE_INFO_FLOW_RETURN() field accordingly
https://bugzilla.gnome.org/show_bug.cgi?id=748643
It will make the default accept-caps handler use the pad template
caps instead of the query-caps result to check if the caps is
acceptable. This is aligned with what the design docs says the
accept-caps should do (be non-recursive) and should be faster. It
is *not* enabled by default, though.
API: GST_PAD_FLAG_ACCEPT_TEMPLATE
API: GST_PAD_IS_ACCEPT_TEMPLATE
API: GST_PAD_SET_ACCEPT_TEMPLATE
API: GST_PAD_UNSET_ACCEPT_TEMPLATE
https://bugzilla.gnome.org/show_bug.cgi?id=753623
The previous implementation was doing a direct call to the peer pad,
which resulted in query probes never being called on the original pad.
Instead of that, get the peer pad caps by using gst_pad_peer_query()
which will call probes in the expected fashion.
In case there is an IDLE probe fired from gst_pad_push_data and it
doesn't return GST_FLOW_OK, the code jumps to the probe_stopped
label which tries to unref the data object. However, at this point
the data object belongs downstream and must not be touched.
By setting data = NULL, the code skips this unref.
https://bugzilla.gnome.org//show_bug.cgi?id=753151
The check for the presence of the parent in the presence of
the NEED_PARENT flag was missing for the chain function. Also keep
a ref on the parent in case the pad is removed mid-chain.
When idle probe runs directly from the gst_pad_add_probe() function
we need to make sure that no data flow happens as idle probe
is a blocking probe. The idle probe will prevent that any
buffer, bufferlist or serialized events and queries are not
flowing while it is running.
https://bugzilla.gnome.org/show_bug.cgi?id=747852
Use case: we want to block the source pad of a leaky queue and
drop the buffer that causes the block. If we return PROBE_DROP
then the buffer gets dropped, but we get called again. If we
return PROBE_OK we can't easily drop the buffer. If we just
replace the item into the GstPadProbeInfo structure with NULL,
GStreamer will push a NULL buffer to the next element when we
unblock the pad probe. This patch ensures it doesn't do that.
https://bugzilla.gnome.org/show_bug.cgi?id=734342
A single unlinked pad can make the latency query fail across the
pipeline, which is probably not desirable. Instead, we return a default
anything goes value.
Perhaps we should also be emitting a gst_message_new_latency() when a
PLAYING element has one of its pads linked.
https://bugzilla.gnome.org/show_bug.cgi?id=745197
Before we just took the values from the first pad that succeded the query,
now we accumulate the results of every sinkpad properly and return that
result.
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.
