[vlc-devel] [PATCH 2/2] RFC: input: notify when a control is processed

[Rémi Denis-Courmont]

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?

-- 
Rémi Denis-Courmont