When we get GST_ITERATOR_RESYNC, we need to call gst_iterator_resync()
otherwise we will always get GST_ITERATOR_RESYNC (and that loop would
run forever).
This means applications and bin sub-classes can easily track when
a new child element is added to the pipeline sub-hierarchy or
removed.
Currently doesn't signal deep added/removed for elements inside
a bin if a bin is added/removed.
https://bugzilla.gnome.org/show_bug.cgi?id=578933
When doing a transition from PLAYING to PLAYING, we will fail
to forward an EOS message on the bus, and noone else will ever
send it because there'll be no actual state changed message.
Allow EOS through directly in that case.
This calls a function from another thread, asynchronously. This is to be
used for cases when a state change has to be performed from a streaming
thread, directly via gst_element_set_state() or indirectly e.g. via SEEK
events.
Calling those functions directly from the streaming thread will cause
deadlocks in many situations, as they might involve waiting for the
streaming thread to shut down from this very streaming thread.
This is mostly a convenience function around a GThreadPool and is for example
used by GstBin to continue asynchronous state changes.
https://bugzilla.gnome.org/show_bug.cgi?id=760532
Updated the GST_REFCOUNTING logging so that it includes the pointer
address of the object that is being disposed or finalized.
With this change is is then possible to match up GST_REFCOUNTING log messages
for object allocation/disposal/finalization. This can help with diagnosing
"memory leaks" in applications that have not correctly disposed of all the
GStreamer objects it creates.
https://bugzilla.gnome.org/show_bug.cgi?id=749427
Otherwise each bin might have a different latency in the end, causing
synchronization problems.
The bin will still first handle latency internally as before, but gives the
overall pipeline the opportunity to update the latency of the whole pipeline
afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=759125
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
