Validate that the proxy pad indeed accepts the caps by also
comparing with the pad template caps, otherwise when the pad
had no internally linked pads it would always return true.
https://bugzilla.gnome.org/show_bug.cgi?id=754112
Instead of re-sending sticky events over and over to a not-linked
pad, mark them as sent the first time. If the not-linked came from
downstream, it already received the events. If the pad is actually
not-linked, the sticky events will be rescheduled when the
pad is linked anyway.
Keep tracer base class in tracer and move core support into the utils module.
Add a unstable-api guard to the tracer.h so that external modules would need to
acknowledge the status by setting GST_USE_UNSTABLE_API.
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
