[vlc-devel] [PATCH 08/13] player: add the timer API
thomas at gllm.fr
Thu Aug 22 12:15:38 CEST 2019
On Thu, Aug 22, 2019, at 11:06, Thomas Guillem wrote:
> On Wed, Aug 21, 2019, at 19:28, Rémi Denis-Courmont wrote:
> > Le keskiviikkona 21. elokuuta 2019, 17.13.59 EEST Thomas Guillem a écrit :
> > > Any interface or control modules could request a timer from the player. This
> > > player timer is like the player event listener except that:
> > >
> > > - It is only used to receive time update
> > >
> > > - The timer is not locked by the player lock. Indeed the player lock can be
> > > too "slow" (it can be recursive, it is used by the playlist, and is it held
> > > when sending all events). So it's not a good idea to hold this lock for
> > > every frame/sample updates.
> > >
> > > - The minimum delay between each updates can be configured: it avoids to
> > > flood the UI when playing a media file with very high fps or very low audio
> > > sample size.
> > I don't think that works.
> cf. Qt implementation.
> > A UI would typically want to know when the clock crosses a certain threshold,
> > e.g. everytime the value of lround(play_time / CLOCK_FREQ) changes. In other
> > words, it wants to know when to replace 00:00 with 00:01.
> It can't work, some inputs have audio samples size that are bigger than
> one seconds, same with <1fps video.
> And you don't want to update the UI every 1seconds: the UI slider won't
> be smooth enough.
> > And then the flood argument does not add up to high playback rates.
> > > The time updated is the output time, unlike the on_position_changed event
> > > that use the input time. It can fixes a very big delay between the UI time
> > > widgets and the outputted content (depending on the audio output module,
> > > this delay could be close to 2seconds).
> > >
> > > The vlc_player_timer_value struct is used by timer update callbacks. This
> > > public struct hold all the informations to interpolate a time at a given
> > > date. It could be done with the vlc_player_timer_value_Interpolate()
> > > helper. In this way, it is now possible to get the last player time without
> > > holding any locks.
> > >
> > > There are two timer types:
> > >
> > > - Source: update are sent only when a frame or a sample is outputted. Users
> > > of this timer should take into account that the delay between each updates
> > > is not regular and can be up to 1seconds (depending of the input). In that
> > > case, they should use their own timer (from their mainloop) and use
> > > vlc_player_timer_value_Interpolate() to get the last time.
> > > - Regular: The player will spawn a vlc timer (likely an other thread) that
> > > will send regular time updates. It can be used by control/interfaces that
> > > don't have any mainloop.
> > That's sure to cause long term drift, and will obviously fail at non-nominal
> > playback rates. Does not make much sense to me.
> Are you talking about the regular timer ? How can it cause long term
> drift ? The timer is corrected every time the clock is updated by the
> output. If the rate changes, an update is sent to every timers,
> regardless of their configured period/type.
Ah indeed, the regular timer should send updates at exact times, not like it is doing right now.
I mean be sure to be triggered at 1~Ɛ, 2~Ɛ, 3~Ɛ and not at 1~Ɛ, 2~(2xƐ), 3~(3xƐ).
> > --
> > 雷米‧德尼-库尔蒙
> > 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:
More information about the vlc-devel