The various wait implementation have a latency ranging from 50 to 500+
microseconds. While this is not a major issue when dealing with a low number of
waits per second (for ex: video), it does introduce a non-negligeable jitter for
synchronization of higher packet rate systems.
The `clock_nanosleep` syscall does offer a lower-latency waiting system but is
unfortunately blocking, so we don't want to use it in all scenarios nor for too
long.
This patch makes GstSystemClock use clock_nanosleep (if available) as such:
* Any wait below 500us uses it
* Any wait below 2ms will first use the regular waiting system and then
clock_nanosleep
# modified: gst/gstsystemclock.c
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/688>
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>
Otherwise it can happen that unscheduling a clock id never takes place
and instead it is waiting until the normal timeout. This can happen if
the wait thread checks the status and sets it to busy, then the
unschedule thread sets it to unscheduled and signals the condition
variable, and then the waiting thread starts waiting. As condition
variables don't have a state (unlike Windows event objects), we have to
remember ourselves in a new boolean flag protected by the entry mutex
whether it is currently signalled, and reset this after waiting.
Previously this was not a problem because a file descriptor was written
to for waking up, and the token was left on the file descriptor until
the read from it for waiting.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/500>
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.
There is not point waiting if the time to wait is less than this
platform specific value. The worst case here is GCond usage on windows
where the granularity is 1ms.
Problem:
multiple aggregator elements (audiomixer, compositor) in a live
pipeline use a lot of CPU waiting each other up. This is because
of the previously unused clock entry unscheduling during regular
operation.
Clock entry unscheduling has the potential to wake up every clock entry
waiting using the system clock which may be a large number.
Solution:
Implement waiting per entry and only wakeup the unscheduled entry.
While this may be possible using GCond, theoretically GCond only gives
us microsecond accuracy and uses relative waits in a number of places.
We can unfortunately do better poking at the platform specifics
ourselves by using futexes on linux and pthread on other unix. Windows
may have a possible implementation using Waitable timers but that is
not implemented here and instead falls back to the GCond implementation.
GCond waits on Windows is still as accurate as the previous GstPoll-based
implementation.
We kept the start time around and subtracted it everywhere for "easy of
debugging", but we don't do anything like this anywhere else and it
only complicates the code unnecessarily.
GST_CLOCK_TYPE_TAI is GStreamer abstraction for CLOCK_TAI. Main
motivation for this patch is support for transmission offloading features
- when network packets are timestamped with the time they are deemed to
be actually transmitted. Linux API for that requires that time to be
in CLOCK_TAI coordinate.
With GST_CLOCK_TYPE_TAI, applications can use CLOCK_TAI directly on
their pipelines, avoiding the need to cross timestamp packet times. By
leveraging system's CLOCK_TAI, applications also don't need to keep track
of leap seconds - less burden for them. Just keep system's CLOCK_TAI
accurate and use it.
This is something bindings can't handle and it causes leaks. Instead
move the ref_sink() to the explicit, new() constructors.
This means that abstract classes, and anything that can have subclasses,
will have to do ref_sink() in their new() function now. Specifically
this affects GstClock and GstControlSource.
https://bugzilla.gnome.org/show_bug.cgi?id=743062
Fixes a race where an entry is set to BUSY in
gst_system_clock_id_wait_jitter() and is UNSCHEDULED before
gst_system_clock_id_wait_jitter_unlocked() starts processing it. The
wakeup added by gst_system_clock_id_unschedule() must be cleaned up.
Two stress tests are added. One test that triggers the specific issue
described above. The second stresses the code path where a wait is
rescheduled because the poll returned early.
https://bugzilla.gnome.org/show_bug.cgi?id=761586
If the clockentry is too late and is unscheduled before it gets
a change to detect its lateness the wakeup count and the poll are
used but never properly cleaned up. This leaves it in a dirty state
that is going to mess with the next clock entry waiting requests.
https://bugzilla.gnome.org/show_bug.cgi?id=761586
When choosing the first entry from the list, gst_system_clock_async_thread
must set the entry state to busy before releasing the clock lock. Otherwise
a new entry could be added to the beginning of the list and
gst_system_clock_async_thread will be unaware and keep waiting on the entry
it has already chosen.
Also improved messages about expected state and bumped them to ERROR level
to detect unexpected state changes.
https://bugzilla.gnome.org/show_bug.cgi?id=760757
On iOS/OSX g_get_current_time was used by default. However, mach_time is
the preferred high-resolution monotonic clock to be used on Apple
platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=758012
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.
Running two threads, one executing the timer and one unscheduling it, the
unscheduled status set by the second thread is sometimes overwritten by the
first one.
https://bugzilla.gnome.org/show_bug.cgi?id=737999
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.
Clear the initial floating ref in the init function for
busses and clocks. These objects can be set on multiple
elements, so there's no clear parent-child relationship
here. Ideally we'd just not make them derive from
GInitiallyUnowned at all, but since we want to keep
using GstObject features for debugging, we'll just do
it like this.
This should also fix some problems with bindings, which
seem to get confused when they get floating refs from
non-constructor functions (or functions annotated to
have a 'transfer full' return type). This works now:
from gi.repository import GObject, Gst
GObject.threads_init()
Gst.init(None)
pipeline=Gst.Pipeline()
bus = pipeline.get_bus()
pipeline.set_state(Gst.State.NULL)
del pipeline;
https://bugzilla.gnome.org/show_bug.cgi?id=679286https://bugzilla.gnome.org/show_bug.cgi?id=657202
See #651514 for details. It's apparently impossible to write code
that avoids both type punning warnings with old g_atomic headers and
assertions in the new. Thus, macros and a version check.
