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.
