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

[Alexandre Janniaux]

On Mon, Feb 22, 2021 at 11:39:40AM +0100, Steve Lhomme wrote:
> On 2021-02-22 11:16, Rémi Denis-Courmont wrote:
> > 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.
>
> 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.
>
> From what I understood of what you said about audio, the latency of filters
> must be bad on the audio side as well.
>
> Given these 2 paragraphs, I don't think audio is the golden standard we
> should look into to fix video issues.


> > > > 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.
>
> "I don't think we agreed to support multiple prepared picture.
> We did discuss the display prepare/display lifecycle and even
> mentionned a prepare/display/unprepare construction but I'm
> not sure what else we discussed."
>
> One of us is not reading this correctly.

Let's not be aggressive against each other and attack one's
ability please. From what I remember we didn't agree on something
specific and end up saying «this is hard to solve», but afair this
subject has been raised by j-b and Thomas so it's not like Rémi is
mentioning this out of nowhere.

Honestly, we don't care about whether it has been decided or not if
the situation is not clear anymore. We need plan, global picture of
how this should work like how we (partially) did for push, and we
need the list of problems it solves and the list of problems it brings
in a much clearer than just some random sentence on the mailing list.

I think we all agree that waiting half the available time is a crappy
workaround but still much better than using all the available time
waiting for a deadline and blocking the controls. Saying that it's
better or that it's worse on one example won't bring us forward since
it will basically favour one situation (eg. video rendering) instead
of one another (eg. 360 rendering for my case) in a completely
arbitrary way, which can make the discussion take forever. So let's
focus on the more general design and what we want to achieve in general
with this design instead.

Regards,
--
Alexandre Janniaux
Videolabs