[vlc-devel] [PATCH] clock: fix false start with some SPU tracks

[Rémi Denis-Courmont]

Le perjantaina 11. lokakuuta 2019, 10.23.47 EET Thomas Guillem a écrit :
> 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.

Uh, that's a year and a half ago, so I don't remember the details, but AFAIR, 
vlc_clock_Update() only has effects in the master clock which should never be 
the SPU's. As for conversion, it should not even be able to create a reference 
point because it does not convey the data to do so; that it actually does 
create a reference point is a work-around for buffering.

> 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.

You could make the same argument with audio on codecs with large blocks, or 
with slow/VFR video codecs. AFAICT, the problem is that creating a reference 
point in the conversion is just bug compatibility with the buffering code. With 
that said, we probably cannot do away with this in the short term (4.0). So we 
need to distinguish the timestamp being converted, from the timestamp matching 
the system time.

The simplest way to do this is to subtract and then add back the gap:

offset = 20s
(ConvertToSystem(PTS + offset, now) - offset)

Or then you need to add a new paramter:

ConvertToSystem(PTS, offset, now)

-- 
レミ・デニ-クールモン
http://www.remlab.net/