An ASYNC READY->PAUSED might have failed without the bin code noticing during
the state change, in which case we will never get PAUSED->READY and would leak
messages.
https://bugzilla.gnome.org/show_bug.cgi?id=756611
When adding an element to a bin we need to propagate the GstContext's
to/from the element.
This moves the GstContext list from GstBin to GstElement and adds
convenience functions to get the currently set list of GstContext's.
This does not deal with the collection of GstContext's propagated
using GST_CONTEXT_QUERY. Element subclasses are advised to call
gst_element_set_context if they need to propagate GstContext's
received from the context query.
https://bugzilla.gnome.org/show_bug.cgi?id=705579
This fixes a race where a state change may return failure if it has
request pads that are deactivated and removed (and thus have no
parent) at the same time as the element changes state and (de)activates
its pads.
https://bugzilla.gnome.org/show_bug.cgi?id=755342
When a bin changes states upwards, and a child fails to change,
any child that was already switched will not be reset to its
original state, leaving its state inconsistent with the bin,
which does not change state due to the failure.
If the state change was from NULL to READY, it means that deleting
this bin will cause those children to be deleted while not in
NULL state, which is a Bad Thing. For other upward changes, it
is less of a problem, as a subsequent switch back to NULL will
cause an actual downwards change on those inconsistent elements,
albeit from the "wrong" state.
We now reset state to the original one when a child fails.
Includes unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=747610
Otherwise the struct is going to be copied, which is not very efficient. And
also has the nice side effect that modifications of the struct might be
done in a copy, and we later use the original struct without the changes.
Caused LATENCY queries to always return the initialization values in one of my
tests, instead of the actual values reported by child elements.
TRUE is 1, but every other non-zero value is also considered true. Comparing
for equality with TRUE would only consider 1 but not the others.
Also normalize booleans in a few places.
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
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.
We might not have reached PAUSED yet because of an async error,
but nonetheless we want to make sure that the pads are always
deactivated in READY state.
Every instance of calling bin_do_message_forward() first took the
object lock, so that bin_do_message_forward() could drop it and
then reclaim. Instead, only take the object lock afterward where
needed.
If all stream-start messages had a group id (for backwards compatibility),
we only consider a stream started if all had the same group id.
In 2.0 we should make the group id mandatory.
This makes sure that no bin misses the clock-lost messages, independent
of the state, and could return an old, non-working clock from
gst_bin_provide_clock_func().
https://bugzilla.gnome.org/show_bug.cgi?id=701997
Elements should override GstElement::set_context() and also call
gst_element_set_context() to keep this context up-to-date with
the very latest context they internally use.
gst_bin_query() now forwards the query to the source pads as well if
none of the sinks of the bin satisfied the query. This helps in the
case of DURATION queries done a bin containing a source element.
Fixes bug 638749
Add a GST_BIN_FLAG_NO_RESYNC that disables a resync when an element is added,
removed or linked in the bin. This is interesting for complex bins that
dynamically add elements to themselves and want to manage the state of those
elements without interference from resyncs.
See https://bugzilla.gnome.org/show_bug.cgi?id=690420
The duration should be re-queried via a query using the
normal path, we don't want applications to use the value
from the message itself, since it might no match what a
duration query done from the sink upstream might yield.
Also disables duration caching in GstBin. It should be
added back again at some point.
Stop querying the duration once an element return unknown and return unknown
as a final result. This avoid eventually cutting off a stream too early.
Add a tests to docuement the behavior.
These changes are to clean up syntax issues such as missing colons,
missing spaces, etc., and minor issues such as argument names in
headers not matching the implementation and/or documentation.
Add the running-time of the buffer that caused the async operation to complete
to the async-done message.
Update bin to handle the new async-done message.
Make the gst_bin_remove_func more like the add_func. Check if the element we try
to remove from the bin has the bin as the parent and set the parent flag to NULL
immediately, this allows us to avoid concurrent remove operations without using
the UNPARENTING element flag. After we unparented the element from the bin, we
update the bin state and remove the element from the list. Finally we unlink
all the pads.
This avoids a race condition where the element could still claim to have the
bin as the parent while the bin didn't have a pointer to the element anymore.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=647759
When the bin does an upward state change, try to avoid doing a downward state
change on the child and vice versa.
Add some more unit tests for this fix.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=621833
