* Don't mention explicitly that API is MT safe, this implies that
other API is not. GStreamer API is assumed to be MT safe, thread
safety should only be explicitly mentioned when API is *not* MT safe
* Don't repeat what annotations are stating with respect to ownership
transfer, nullability
* Document virtual methods in standalone comments, so that parameters
can be documented. This is not critical here, as parameters do not
need annotations / specific documentation, but serves as an up to
date example
* Document enumeration members in standalone comments, so that their
Since tag is accounted for by gobject-introspection
* Misc cleanup / typo fixes / addition of links
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/747>
This was effectively disabled in 1.0 with the intent of maybe re-enabling it.
The problem is that caching duration at a bin level doesn't make much sense
since there might be queueing/buffering taking place internally and therefore
the duration reported might have no correlation to what is actually being
outputted.
Remove commented code and fixmes, and update documentation
Fixes#4
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/489>
To allow the refcounting tracer to work better. In childproxy/iterator
these might be plain GObjects but gst_object_unref() also works on them.
In other places where it is never GstObject, g_object_unref() is kept.
This would cause us to set GST_GROUP_ID_INVALID as group-id in the
aggregated STREAM_START message if there are no sinks at all or none of
them have a STREAM_START message, which is simply wrong.
If we have not a single STREAM_START message then the bin should not be
considered STREAM_START.
A common use case of a dynamically built pipeline is that you want to
(conditionally) find a certain element, e.g. the `rtpbin`s in a
`uridecodebin`. If that element has a fixed name inside its parent bin
(and only has a single instance) this can be easily done by
`gst_bin_get_by_name()`.
If there are multiple instances of the element however, you can only use
`gst_bin_iterate_all_by_interface()`, but this doesn't work if you don't
have the specific `GType` (which is often the case, due to plugins being
dynamically loaded). As such, another fallback could be to use the
well-known name of the element's factory (in case of our example, this
is of course `"rtpbin"`).
By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
This patch simply add a null check around a case where a child may have
been unparented concurrently to the deep_add_remove operation. This was
found by accident in the form of an "IS_GST_OBJECT" assertion, but had
no other known side effect in that test.
We need to take the state lock here to ensure that we're
not currently just before setting the state of this child
element. Otherwise it can happen that we removed the element
here and e.g. set it to NULL state, and shortly afterwards
have another thread set it to a higher state again as part of
a state change for the whole bin.
When adding an element to the bin this is not needed as we
require callers to always ensure after adding to the bin that
the new element is set to the correct state.
gst_element_post_message() takes ownership of the message so we need to increase
its refcount until we no longer require access to its data (context_type).
https://bugzilla.gnome.org/show_bug.cgi?id=797099
There is a possibility that the accumlation functions don't set
a seqnum. Make sure we only set/override the seqnum of the new
messages if we *have* a valid upstream seqnum to use
For linked elements, the resulting gst_bin_iterate_sorted() will
properly return elements from sink to sources.
If we have some elements that are not linked, we *still* want to
ensure that we return:
* In priority any sinks
* Last of all any sources
* And in between any element which is neither source nor sink
For this to work, when looking for the next candidate element,
not only check the degree order, but if there are two candidates
with the same degree order, prefer the non-source one.
Amongst other things, this fixes the case where we activating a
bin containing unlinked sources and other elements. Without this
we could end up activating sources (which might start adding pads
to be linked) before other (to which those new source element pads
might be linked) are not activated
https://bugzilla.gnome.org/show_bug.cgi?id=788434
If a function takes a floating reference parameter, it should also be
sinked in error cases. Otherwise the function behaves differently
between error and normal cases, which is impossible for bindings to
handle.
https://bugzilla.gnome.org/show_bug.cgi?id=747990
If a function takes a floating reference and sinks it, it should also do
that in error cases. I.e. call ref_sink() followed by unref().
Otherwise the reference counting behaviour of the function will be
different between the good and the error case, and simply inconsistent.
https://bugzilla.gnome.org/show_bug.cgi?id=747990
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.
