[vlc-devel] Display update/restart

Alexandre Janniaux ajanni at videolabs.io
Tue Nov 17 09:21:40 CET 2020


Hi,

On Tue, Nov 17, 2020 at 07:56:50AM +0100, Steve Lhomme wrote:
> On 2020-11-16 17:11, Alexandre Janniaux wrote:
> > Hi,
> >
> > On Mon, Nov 16, 2020 at 05:01:29PM +0100, Steve Lhomme wrote:
> > > On 2020-11-16 16:08, Thomas Guillem wrote:
> > > > Indeed, the more important, glitch-wise, is to keep the window enabled.
> > > >
> > > > Can we stop and start the 3 main vouts (gl, d3d9, d3d11) without any glitches? Even when changing the video size for example ?
> > >
> > >  From what I understood at least on iOS the background becomes white if you
> > > remove the display module. But that's probably not hard to fix.
> >
> > This might be tuned to keep the previous surface as long as we
> > don't disable the window or have a new surface to render. I'm
> > not sure it can be turned into glitch free though but we could
> > try.
>
> If the surface belongs to the display module it will be gone when the
> display is released.

I'd like you to recall that closing the vout display is not the
same as releasing the underlying surface, which is particularily
visible in iOS modules since they live in different threads and
you cannot block one over the other. In particular, when closing
the application, the underlying UIView (be it for display or
window) might even be destroyed __after__ libvlc is destroyed.

Doing thing like this is expensive, it needs a reference counting
architecture for the display private data. But on Apple platform
this comes for free because we already have that (because of ARC)
so this is something that can be done (without saying that this
must be done).

> > > The issue is not the glitch. It's how long it's going to take to unload a
> > > display module and reload it, for a tiny change that would take almost no
> > > time to handle directly.
> >
> > We should measure it. Shader recompilation is an issue but we
> > might workaround it with shader caching. Some platforms already
> > have transparent caching for this.
>
> There's a persistent cache even after the display module is released ?

Yes, even after the application is closed.
See MESA_GLSL_CACHE_DISABLE.

> > > The other issue, already mentioned in another email, is that the detection
> > > of format change is done on picture.next, not picture.current. So we would
> > > not display picture.current if we close the display when picture.next is
> > > just loaded.
> > >
> > > And there's also the question of getting picture.next from the deinterlacer.
> > > There's no way to put it back in the filter for the next display to get it.
> > >
> > > In short, it's a giant mess to handle with the current code.
> >
> > I think it's more about defining the policy to make sense
> > of the mess, than handle this mess before. ;)
>
> Yes.
>
> Another important topic is filter draining. For example if you switch from
> interlacing to non interlacing you don't just unload the filters, you have
> to tell them to keep outputting pictures with no input pictures until it's
> all dry. Only then you can switch to the non interlaced filter chain(s).

IMHO filter draining is orthogonal, and can be implemented
either before or after the switch is made, as it was really
dependant upon having multiple pools instead of one to be
efficient.

> > Regards,
> > --
> > Alexandre Janniaux
> > Videolabs
> >
> > > > On Mon, Nov 16, 2020, at 16:04, Rémi Denis-Courmont wrote:
> > > > > Le lundi 16 novembre 2020, 13:24:33 EET Steve Lhomme a écrit :
> > > > > > One of the last missing part in push is the possibility to
> > > > > > update/restart the display module when the source changes. A corollary
> > > > > > of this is when we decide to use a converter filter or not.
> > > > >
> > > > > We covered that in the last related workshop. In the push model, there's no
> > > > > point reusing the display anymore, since it won't cause problems with the
> > > > > picture pool, and it won't glitch the window.
> > > > >
> > > > > You can just make a new one. In other words, this is a non-issue.
> > > > >
> > > > > --
> > > > > Rémi Denis-Courmont
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > vlc-devel mailing list
> > > > > To unsubscribe or modify your subscription options:
> > > > > https://mailman.videolan.org/listinfo/vlc-devel
> > > > _______________________________________________
> > > > vlc-devel mailing list
> > > > To unsubscribe or modify your subscription options:
> > > > https://mailman.videolan.org/listinfo/vlc-devel
> > > >
> > > _______________________________________________
> > > vlc-devel mailing list
> > > To unsubscribe or modify your subscription options:
> > > https://mailman.videolan.org/listinfo/vlc-devel
> > _______________________________________________
> > vlc-devel mailing list
> > To unsubscribe or modify your subscription options:
> > https://mailman.videolan.org/listinfo/vlc-devel
> >
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel


More information about the vlc-devel mailing list