[vlc-devel] [PATCH v3 2/6] clock: add vlc_clock_main_SetInputDrift

[Alexandre Janniaux]

Hi,

On Tue, Mar 16, 2021 at 09:05:14PM +0200, Rémi Denis-Courmont wrote:
> Le tiistaina 16. maaliskuuta 2021, 20.52.31 EET Alexandre Janniaux a écrit :
> > I'm not sure to understand, those issues arise with paced inputs
> > but Thomas has been explicitely saying for three mails and in the
> > patch itself that it copies the behaviour from 3.0 for non-paced
> > stream.
>
> And I ahve been explicitly saying in the previous threads that the previous
> proposals make zero sense for non-paced inputs. This one does not make more
> better sense in those scenarii for the same reasons.

Sorry, I've been re-reading the previous thread and I've just
realized I might not have been using the correct terminology.

By non-paced inputs, I meant inputs where it has been signalled
CAN_CONTROL_PACE = false, which probably actually means paced
inputs, hence the confusion here right?

So you've mentioned two issues:

- Sometimes playback never "catches up".

What do you mean by «never catches up»?

- Especially as start/resume, doppler sound effect (resampling) due to
abnormally quick succession of SetPCR calls.

If the audio clock is master, it means that the time reported
by the audio output (either from the underlying output service
or computed from the rate of the consumption of the buffer,
which sort of equivalent) will drive the consumption speed of
the buffer. If the consumption is faster than the actual live
then there will be buffer glitches (like you said, because of
physics) which could lead to the same doppler sound effect
without starting to resample from the start.

Having the audio clock as master only prevents glitches when
the input is available at least as fast as it is consumed. You
cannot guarantee that on a live stream AFAIK, which is also
probably why the design doc on clock in the repo is also
talking about the input PCR clock.

The «doppler sound effect» on 3.0 and the artifacts were
happening because of the way this clock was implemented, ie
it's only about how you resample and filter the result. It
doesn't mean that using the input PCR is incorrect.

Then after saying that, I am also aware that we might not be
talking about the same thing here. Partly because of Denis's
comment and because of your differents thread, it seems to me
that you're against the very core of this patch, which is why
I don't understand the incoherence with the design document.

Maybe I'm mistaken and you actually criticize the way it is
implemented, (ie. an input_drift stored by the main thread)
in which case making it clearer might help draw a better
implementation of the design.

Regards,
--
Alexandre Janniaux
Videolabs