[vlc-devel] [PATCH] video_output: wait half the extra time we have without getting the display_lock

[Rémi Denis-Courmont]

Le maanantaina 22. helmikuuta 2021, 12.39.40 EET Steve Lhomme a écrit :
> > You're the one bringing pause which has nothing to do with putting
> > multiple
> > samples in the rendering pipeline, and the problem of the filter setting
> > latency. Those last two issues do affect both audio and video.
> 
> Yes, I'm giving a very concrete example of why audio and video cannot be
> compared when it comes to rendering. Pause is totally different there.

No. First pause has hardly anything to do with it. You're just bringing a red 
herring. The fact that we should maybe repaint during pause is *totally* 
*irrelevant* to the problem here: we already have a solution for that problem 
and nobody suggests that we should change that.

And then in fact, pause otherwise affects audio too and in much the same ways. 
In particular, on both sides, data/buffers must be preserved during pause.

Both audio and video outputs started by only supporting low latency mode. Both 
modern audio and video outputs support high latency mode for better power 
management, resource utilisation, robustness, etc.

Though VLC is still stuck with low latency on the video side, unable to call 
prepare far ahead, and unable to queue more than one picture.


>  From what I understood of what you said about audio, the latency of
> filters must be bad on the audio side as well.

It is in fact much better on audio side where the slightest system scheduling 
jitter won't cause a glitch and where we don't wake up the CPU way more often 
than actually necessary.

We have already solved the latency problem for volume and mute changes, and we 
could solve it by rewinding for EQ and other filter changes, if we *cared*. We 
eviedntly don't care that much about that corner case of a corner case.

-- 
Rémi Denis-Courmont
http://www.remlab.net/