[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, 9.46.46 EET Steve Lhomme a écrit :
> >> There's a very simple scenario to support this behaviour. Pause the
> >> video and change the user filters from the UI. The render changes. It's
> >> done on the same "pre-rendered" (deinterlace+convert) picture.
> > 
> > That's still an exception within an exception. It's very seldom that
> > somebody changes filter settings while paused. In the first place, most
> > people don't use filters, and most filters mostly don't work anymore due
> > to hardware acceleration.
> > 
> > And besides, then what? How is this any different from audio, where we do
> 
> You can pause video and still see the rendered result.
(...)
> None of
> that is possible in audio. So let's not compare apples and pears.

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.

> > process samples ahead of time (subject to low latency setting) rather than
> > at the last minute? You're just confusing latency and frame period here.
> > 
> > In most cases, latency can be larger than a period. In fact, some filters
> > do require it (if they need to look ahead) already now. The general idea
> > that we need to support multiple prepared pictures was already agreed at
> > the workshop anyway, AFAIR.
> 
> I don't remember that at all.

If Alexandre remembers it, it's not just me.

-- 
Реми Дёни-Курмон
http://www.remlab.net/