es_out: trace wake up delay for input pacing monitoring
- Mar 26, 2025
-
-
Alexandre Janniaux authored
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.5f6060a4
-
