Since glib 2.64, gthreadpool will start waiting on a GCond immediately upon
creation. This can cause issues if we fork *before* actually using the
threadpool since we will then be signalling that GCond ... from another process
and that will never work.
Instead, delay creationg of thread pools until the very first time we need
them. This introduces a minor (un-noticeable) delay when needing a new thread
but fixes the issues for all users of GSTreamer that will call gst_init, then
fork and actually start pipelines.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2131 for more context.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/531>
The signal handlers were performing mutex operations in the signal handlers
which is bad idea that may lead to deadlocks.
1. Implement a separate signal thread to handle the signals.
2. Use the glib provided signal GSource to avoid performing operations in
the signal handler.
Fix#186
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/487>
When compiling for 32bit ios arm, the static assert that the
GstClockEntryImpl smaller or equal to the struct _GstClockEntryImpl
triggered. (they were 12bytes off).
To fix this, the padding is increased by 12 bytes (on 32bit).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/525>
These can be passed to gst_type_mark_as_plugin_api, to inform
plugin cache generation.
For now a single flag is specified, "IGNORE_ENUM_MEMBERS", it
can be used for dynamically generated enums to avoid documenting
environment-specific enumeration members. An example is
GstX265EncTune.
Since those are using the clock for sync, they need to also
provide a clock for good measure. The reason is that even if
downstream elements provide a clock, we don't want to have
that clock selected because it might not be running yet.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/509>
When we want to perform a downstream bitrate query, just
set the reconfigure flag on the srcpad and get the streaming
thread to do it. That avoids emitting a downstream query
when receiving the upstream RECONFIGURE event - which can
lead to deadlocks if downstream is sending the event from
within a lock - e.g. input-selector.
If querying the downstream bitrate changes the cached
value, then make sure to update our buffering state
and potentially post a BUFFERING message to the application.
Fixes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/566
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/501>
The deadlock was the following:
* One thread requests a new pad, the internal lock is kept while adding the pad
* Another thread (or the same one) requests the internal links of a pad (could
be that pad)... which also requires that lock.
That internal lock is not required when adding the pad to the element (which is
the last action when requesting a new pad). The fact it will be actually used
will be *after* the request pad function is released.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/512>
This can be used to mark additional types exposed by plugins (i.e.
enums, flags and GObjects) via properties, signals or pad templates as
plugin API. They can then be picked up by the documentation for the
plugin.
Not all types exposed by plugins are documented automatically because
they might come from an external library and should be documented from
there instead.
When posting a buffering message succesfully:
* Remember the *actual* percentage value that was posted
* Make sure we only reset the percent_changed variable if the value we just
posted is indeed different from the current value
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/511>
This test takes 39 seconds on my machine even though it just runs
a couple of fakesrc num-buffers=2 ! fakesink pipelines. Most of
the cpu seems to be spent in libz, related to stack trace management.
Use stack-traces-flags=none instead of stack-traces-flags=full
until a better solution can be found. Might warrant more
investigation in any case..
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/503>
This is a follow up to review comments in !297
+ The posting of the buffering message in READY_TO_PAUSED isn't
needed, removing it made the test fail, but the correct fix
was simply to link elements together
+ Move code to relock the queue and set last_posted_buffering_percent
and percent_changed inside the buffering_post_lock in create_write().
This makes locking consistent with post_buffering()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/297>
This fixes a bug that occurs when an attempt is made to post a buffering
message before the queue2 was assigned a bus. One common situation where
this happens is when the use-buffering property is set to TRUE before the
queue2 was added to a bin.
If the result of gst_element_post_message() is not checked, and the
aforementioned situation occurs, then last_posted_buffering_percent and
percent_changed will still be updated, as if posting the message succeeded.
Later attempts to post again will not do anything because the code then
assumes that a message with the same percentage was previously posted
successfully and posting again is redundant.
Updating these variables only if posting succeed and explicitely
posting a buffering message in the READY->PAUSED state change ensure that
a buffering message is posted as early as possible.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/297>
Nowadays we are only waking up the head entry waiting if either the head
entry is unscheduled (which is handled some lines above already), or
when the head entry specifically is woken up because a new entry became
the new head entry.
We're not waking up *all* entries anymore whenever any entry in the last
was unscheduled.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/500>
We already have a mutex in each clock entry anyway and need to make use
of that mutex in most cases when the status changes. Removal of the
atomic operations and usage of the mutex instead simplifies the code
considerably.
The only downside is that unscheduling a clock entry might block for the
time it needs for the waiting thread to go from checking the status of
the entry to actually waiting, which is not a lot of code.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/500>
