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

Rémi Denis-Courmont remi at remlab.net
Sat Feb 20 18:06:06 UTC 2021

Le lauantaina 20. helmikuuta 2021, 16.54.42 EET Steve Lhomme a écrit :
> On 2/20/2021 10:22 AM, Rémi Denis-Courmont wrote:
> > Le lauantaina 20. helmikuuta 2021, 11.03.18 EET Steve Lhomme a écrit :
> >> On 2/19/2021 4:06 PM, Rémi Denis-Courmont wrote:
> >>> Le perjantaina 19. helmikuuta 2021, 15.12.49 EET Steve Lhomme a écrit :
> >>>> In an ideal world we would never wait between prepare and display, they
> >>>> would have predictable time and we could estimate exactly when we must
> >>>> do the prepare to be on-time for the display.
> >>> 
> >>> That's not ideal either. prepare() should rather be called at the
> >>> earliest
> >>> option, which is to say whence the picture has been filtered and
> >>> converted.
> >>> Estimations should only be used for display() if at all.
> >> 
> >> I disagree. First the picture is not "filtered" at this stage, only
> >> deinterlaced and converted.
> > 
> > That's plain nonsense. At the stage "whence the picture has been filtered
> > and converted", the picture has, by definition, been filtered.
> > 
> >> The user filters are applied just before rendering.
> > 
> > That's a bug. It prevents evening out the resources usage (both internally
> > and externally with other concurrent processes), and generally being more
> > robust against scheduling glitches. It's also incompatible with modern
> > video filters and outputs that support queueing.
> > 
> > There is no basis to assume that only deinterlacing requires ahead-of-time
> > processing for optimal results. Motion blur is an obvious counter example
> > here. Besides, in practice deinterlacing is the only filter (if any) in
> > most cases.
> 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 

And besides, then what? How is this any different from audio, where we do 
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.

The current simplistic prepare-display API is just a historical artefact from 
the penultimate vout rework by Laurent and myself, for the sole sake of 
limiting the scope of changes back then.


More information about the vlc-devel mailing list