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
Be notified in the application thread via bus messages about
notify::* and deep-notify::* property changes, instead of
having to deal with it in a non-application thread.
API: gst_element_add_property_notify_watch()
API: gst_element_add_property_deep_notify_watch()
API: gst_element_remove_property_notify_watch()
API: gst_message_new_property_notify()
API: gst_message_parse_property_notify()
API: GST_MESSAGE_PROPERTY_NOTIFY
https://bugzilla.gnome.org/show_bug.cgi?id=763142
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
Pretty much every single element does
gst_element_class_add_pad_template (element_class,
gst_static_pad_template_get (&some_templ));
which is both confusing and unnecessary. We might just
as well add a function to do that in one step.
https://bugzilla.gnome.org/show_bug.cgi?id=762778
This reverts commit b427997119.
It breaks things that used to work before, even if the change by itself is
correct and the previous code is just working around deeper bugs in the async
state change code. Let's go back to what previously worked and then fix async
state changes in general.
https://bugzilla.gnome.org/show_bug.cgi?id=760532
'gst_element_post_message' takes the ownership of the message, so it
shall unref it when there is no post_message implementation. Otherwise
message is leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=759300
This lock seems to exist only to prevent elements from changing states while
events are being processed. However events are going to be processed
nonetheless in those elements if sent directly via pads, so protection must
already be implemented inside the elements for event handling if it is needed.
As such having the lock here is not very useful and is actually causing
various deadlocks in different situations as described in
https://bugzilla.gnome.org/show_bug.cgi?id=744040
The pad could be activated but flushing because of a FLUSH_START event. That's
not what we're looking for here, we want to check for activated pads.
https://bugzilla.gnome.org/show_bug.cgi?id=758928
Helps catching when a state change is starting and ending.
It is also possible to track the end of state changes by checking the
async-done or state-change messages.
This is particularly important for elements that do async state changes.
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.
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
This reverts commit 1911554cff.
This breaks the functionality of GST_PAD_FLAG_NEED_PARENT, the reason for this
flag is that if a pad is removed from a running element, you don't want
functions (such as chain or event) to be called on the pad without a parent set.
This can happen if you remove a request or sometimes pad from a running element.
I don't see the code that caused this in tsdemux, but if it needs to unset
the flag on remove, it should do it itself and then make sure that the parent
exists in any pad function.
The documentation states that gst_element_send_event is to "send an event
to an element".
Therefore we *send* upstream events to a source pad and downstream events
to a sink pad
This function is not really pad or slow for the common case of requesting a
pad with the name of the template. It is only slower if you to name your pads
directly instead of letting the element handle it.
Also there's no reason to deprecate it in favor of a more complicated function
for the common case.
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
When a pad is added the need-parent flag is set to true, so when
they are removed the flag should be set back to false
This was preventing GstPads to be reused in elements (removed and
later re-added). A unit tests was added to verify that this is
working now.
The use case is tsdemux that has a program-number property and
allows the user to switch programs. In order to do that tsdemux
will remove the pads of the current program and add from the new
ones. The removed pads are kept in the demuxer for later if the
user selects the old program again.
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.
and remove all the printf extension/specifier stuff for
the system printf. Next we need to add back the custom
specifiers to our own printf implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=613081
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.
The order of returned pads wasn't specified before, so let's specify
it and use an order which might prove the most useful : the order in
which pads were added to the element.
If someone changes the order, make sure users of those iterators from
now on don't rely on that order !
