Check that system and stream are increasing and check that the coeff is
arround 1.0.
In case of invalid update, reset the clock (moving average reset to
1.0) and update starting the current point (that triggered the warning).
We assume that the previous points were bad and not the current.
In order to solve bad convergence of the initial jitter.
This will soften the aout->time_get imprecision at the beginning.
Thanks Denis Charmet for the idea.
Ref #27023
Use of the previouly created trace API to collect data from demuxer, decoder and video_output.
Fields "type", "id", and "stream" are then used by a script to identify data and name curves to
display.
Here is the link of the script project: https://gitlab.com/videolabs/public/vlc-pa
The function vlc_clock_Wait() was in charge of converting the stream
timestamp and handling a deadline provided by the caller.
Instead, just pass the deadline, expressed in system time. This will
allow the caller to compute arbitrary deadlines and to wake up the wait
on custom conditions.
Now that clock lock is exposed, a wrapper function to apply several
conversions at once becomes unnecessary: the caller could execute
each conversion successively with lock held.
This is a first step to allow the caller to compute an arbitrary
deadline based on vlc_clock_ConvertToSystemLocked() then wait using
vlc_clock_Wait() without race condition.
Don't wait more than CR_MAX_GAP. The CR_MAX_GAP might be too big
(60 seconds). This algorithm, like the one in input_clock.c could be
improved by comparing stream and system date.
This a work around buggy demuxers or corrupted samples/streams. That is
the reason that the new log should draw attention to developers.
The input master clock has a higher priority than the ES master clock.
There can be one input master and one es master at a given time. In that
case, the ES master will behave as a slave clock.
This will allow to be more flexible from the es_out.c when creating
input and ES clocks.
The "--clock-master=auto" option will select the input as the clock
source when the input can't pace (live content), and will fallback to
the "audio" source otherwise (most common case).
The "--clock-master=input" option (disabled by default) allow to setup
the input_clock_t as the master clock. This will restore the VLC 3.0
behavior and use PCR update points as the clock source. Therefore, audio
and video tracks will be altered to catch-up with the input.
If a second master was created, the first one was automatically
downgraded without notifying the owner.
This was never the case since es_out.c, the only clock client (for now)
is always ensuring that only one master is created.
Reminder of the design: Any calls to vlc_clock_ConvertToSystem() or
vlc_clock_Update() will create the reference point (wait_sync_ref) if it is the
first call of all sub clocks. This point will be used as a reference by all
clocks until the master does its first vlc_clock_Update().
Creating a reference point from vlc_clock_ConvertToSystem() can be discussed.
You don't expect to modify the main_clock from a function with such name
("convert"). The pro of this design is that vlc_clock_ConvertToSystem() can't
fail and will always return a valid point. Returning a valid point is
mandatory for the actual design, let's see how the audio output is using it:
The aout will first call vlc_clock_ConvertToSystem(ts) to get the first system
date of the ts, this first system date will take into account the output
dejitter, the input dejitter and the pcr_delay int and will be very likely in
the future. Enough in the future to wait for any other tracks. When this system
date is reached by the aout plugin, the aout will call the first update() and
will drive all other clocks.
Now the problem: any outputs can create the first reference point, but when it
is the SPU output, it can lead to very high imprecision. For example, with the
following .srt file:
"""
1
00:00:00,00 --> 00:00:42,00
SRT
"""
If you seek to 20seconds, the SPU output will convert its first point, that is
00:00:00,00, this could lead to the creation of the reference point. This
reference point will be delayed by 20seconds and will cause all other outputs to
wait for 20seconds (approximately) before doing their first rendering.
To fix this issue, this commit adds a priority system. The clock with higher
priority will always be able to override an old reference point. The SPU clock
will always have the lowest priority.
Alaric Senat