[vlc-devel] [PATCH 2/2] RFC: input: notify when a control is processed
thomas at gllm.fr
Wed Sep 5 09:06:52 CEST 2018
On Wed, Sep 5, 2018, at 06:34, Rémi Denis-Courmont wrote:
> It is probably not a good idea for UI to wait on seek anyhow, because
> it could take arbitrarily long (stuck network).
I know. I don't want the UI to block waiting for anything, but be
notified when some events are processed.
What I'm an trying to fix is the seekbar value that is inconsistent
when you seek.
I explain with the worst case scenario (that happens very often):
- The player time is 60s
- The UI ask the player to seek to 120s, and set the seekbar
progress to 120s - In the meantime, the input_thread finish a demux() call and update
the time values: 61ms. The UI update the progress value to 61. - The seek command is processed, the input_thread signal the new time:
around 120s, the UI update the progress value to 120s.
This result to a glitch on the seekbar: 60 -> 120 -> 61 -> 120
> We should rather expose an event when the correlation between
> monotonic clock and play time changes - regardless of why: seek,
> pause, rate change, buffer refill...
Maybe. This current solution is not correct as I explained in my
My other solution was to notify when a seek started (with the time/pos
value requested) and notify when this seek ended (and failed). But this
looks like your solution, that is more generic.
One problem with your solution: I would like to notify the next probable
time/pos value (when you start a seek). That's way the UI can either
change the value of the seekbar (of display an indefinite progress).
> Then the UI can update the slider and (re)program its update timer if
> it wants.> --
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
> excuser ma brièveté.> _________________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel