This patch adds a new metric to track and understand the behaviour of
the input pacing done from the input buffering values. The behaviour is
showing correct properties currently, but as will be shown later in this
commit message, this metric helps debugging pacing issues leading to
screen freeze.
In the work for making clock-start distributed across every clock
tracker, and because of a change removing the call to the function
input_clock_ChangeSystemOrigin, the input clock wake-up delay was not
computed correctly. Specifically, a huge delay of multiple hundred of
millisecond was appearing at the startup of the playback for file://
media, leading to a huge gap in playback.
The problem can be revealed when tracing the input_clock_GetWakeup
values. Those values are used to pace the input, and they are dates
matching with up until when the input is allowed to sleep, or 0 to
disable sleeping altogether. The value returned is valid up until
vlc_tick_now() is bigger or a new input_clock_Update() is made.
By substracting vlc_tick_now() to this date when the value is not 0, we
can get the time the input is supposed to wait before doing anything
else. The graph would typically look like this when the freeze was
happening at the beginning of the playback
Input clock wake up ^330ms -| +----+ | | | | | | 0 -| ------------+ +--------.. +----------------------------->t
In the current state or after proper fixes for the input pacing were
done, it would display the following graph:
Input clock wake up ^ | +----------------------------->t 0 -| ------------++-------------- | || | || -550ms -| ++
As such, a very high value looks suspiciously wrong, and improvement
could be made later to start the wake-up delay at -pts_delay immediately
instead of returning 0 as long as the reference point is not registered
yet in the input clock buffering subsystem.
This metric also catches additional artifacts that are generated by the
input decoder waits right at the end of buffering, which might be
interesting to investigate later.
In grafana, here is how the graph currently looks like:
Here is how the graph looks like with the freeze right at the beginning (after a few hundred millisecond playback).
Here is how the graph looks like without the freeze, and without the decoder wait:
For this last case, I've been running with the following patch. The usage of this is currently quite specific to my use cases, but the consequences is still interesting to gather. Using this kind of patch has a lot of consequences on what to do for clock bootstrapping in audio master, so it cannot be part of the tree right now of course.
