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
