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

[Thomas Guillem]

Hello,

OK with this plan?

On Fri, Mar 5, 2021, at 16:00, Thomas Guillem wrote:
> 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
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel