[vlc-devel] [PATCH 2/2] RFC: input: notify when a control is processed
remi at remlab.net
Wed Sep 5 15:16:19 CEST 2018
Le mercredi 5 septembre 2018, 10:06:52 EEST Thomas Guillem a écrit :
> 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
There is only one way to fix that: it consists of not updating the slider on
user interaction, but only actual play time. And while it is more correct from
engineering point of view, I can see the argument that from user experience
point of view, it is probably worse than glitching.
So you cannot avoid glitching: The demuxer itself does not tell you if/when it
has processed your seek - and the time that the demuxer returns after seek
might not match what you requested. And then the input thread cannot "invent"
infos that the demuxer does not give.
How would you deal with the case that the demuxer decides the best
approximation of your seek in the example above is 90 seconds? How do you know
that 90 seconds is the result of the seek, the result of time moving forward
after your seek was somehow ignored, or the result of another interface
seeking at the same time?
More information about the vlc-devel