[vlc-devel] [PATCH 08/17] es_out: use the input_clock as a master source of vlc_clock

[Thomas Guillem]

Hello Rémi,

Thanks for your comments.

What about just propagating the input clock drift AvgGet(&cl->drift) to the output clock then?
It won't have any effects if the AUDIO ES is the master (since it can't be resampled) but it can have an effect when using the monotonic clock.

Then, we can add something in es_out.c, forcing the clock-master to monotonic if the demux is paced.


On Wed, Mar 3, 2021, at 18:35, Rémi Denis-Courmont wrote:
> Le keskiviikkona 3. maaliskuuta 2021, 14.24.25 EET Thomas Guillem a écrit :
> > > I don't see how that makes any sense, for the simpel reason already
> > > outlined that, in most cases, there is NO input clock.
> > 
> > What do you mean by NO input clock here?
> 
> I mean that the input block timestamps and PCR controls are not derived from a 
> clock.
> 
> > If I understand correctly, using the input_clock as master is not advised in
> > most cases but can be useful with PACED content (reminder: the input_clock
> > is directly feed by the demux module via the SET_PCR control).
> 
> In theory, it can make sense if (and only if) the input is paced. However in 
> most cases, the input is not, or not effectively, paced. And even then when the 
> input is effectively paced, the input clock reconstruction algorithm is pretty 
> flaky, especially at startup where there is typically a burst of data and thus 
> quickly increasing timestamps.
> 
> More importantly, in most cases the outputs *are* paced. If there is audio, 
> and there is almost always is, we have to adjust to the audio clock one way or 
> another.
> 
> So with that, the proposal makes absolutely no sense to me.
> 
> > Do we agree on that? If so, I can modify my patch set to:
> >  - Let the input_clock as master if the user asked it or if the demux is
> > paced.
> 
> No. It can only make if the user asked *and* (NOT OR) the input is paced.
> 
> And even then, it seems useless (and contrary to the agreed upon plan).
> 
> > - Otherwise, fallback to Audio master or monotonic clock (like
> > before).
> > 
> > By the way, the main reason of this patchset is to fix drift when using the
> > monotonic clock of the audio one when playing PACED content.
> 
> You're not going to be able to fix drift with that. If the input is paced, the 
> input and audio clocks will drift because Physics, and you'll have to resample 
> because you can't ignore either of the clocks.
> 
> And if there are no output clocks, then we are supposed to ignore any clock 
> and stick to flow control rather than time synchronisation. That's basically 
> how "offline" conversion works.
> 
> -- 
> 雷米‧德尼-库尔蒙
> http://www.remlab.net/
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel