[vlc-devel] Display update/restart

[Romain Vimont]

On Mon, Nov 16, 2020 at 12:24:33PM +0100, Steve Lhomme wrote:
> 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.
> 
> The current way of handling source changes is to redo the filter chain(s)
> and add an extra filter if the last filter doesn't output what it was
> supposed to. So the source change is effectively canceled by this last
> filter.
> 
> It's even worse because instead of updating osys->converter we add an extra
> filter to the interactive chain. And then there will still be the old
> osys->convereter. I have patches to fix this and update the osys->converter
> instead (the extra added filter never needed to be "interactive").
> 
> No matter what, we will still need the osys->converter because not all
> display modules can handle all chroma/colorimetry/360 formats we send them.
> 
> So when a new format should we
> - create a new display no matter what ?
> - reuse the display if possible ? And if not create a new display ?
> 
> From previous mail it doesn't seem clear what we should do. It seems Remi is
> leaning towards #1 while Alexandre, Romain and myself towards #2.

IMO, there are two situations to distinguish:
 1. the format changes because the format of the source really changes
    (which should be rare);
 2. the format "changes" just because we initialized the vout/display
    first, without knowing the actual format of the pictures it will
    receive.

For (1), I think we could request the display to accept the new format,
and if it does not accept, we recreate the whole chain with the new
format. (Or just recreate the whole chain on every change, it's just a
detail.)

For (2), I think the filters must be created before the vout/display.
That way, the vout/display will always be created with the correct
format (the one of the pictures it will receive) and there is no change
to handle.

As a temporary solution for (2), I proposed to update the vout format:
https://mailman.videolan.org/pipermail/vlc-devel/2020-October/139458.html

This allows to support filters changing the chroma (like OpenGL filters
producing RGBA or opaque pictures). But this is quite hacky and limited
(for example supporting resizing via this method is tricky).

> This is becoming critical because we have to handle interlaced HEVC which
> decoders output field by field, rather than 2 fields at a time for all other
> interlaced codecs. So when deinterlacing kicks in (patches coming soon), the
> dimension coming out of filter is double the height. To display it properly
> we need to update the display or create a new one. We should not use a
> filter to reduce by half the height and display it in the old display. And
> given the picture surface is actually double the size, it's quite a big
> change for the display module.
> 
> Even if we try to reuse the display with the new format, there will always
> be cases where the display refuses. So we have to handle the
> restart/recreate no matter what.
> 
> There is another issue arising from this. We only know about this format
> change after the picture is deinterlaced. With the current code, that
> happens when preparing (pre-rendering) a picture. Except this is when
> deinterlacing the picture.next which is not the one that will be sent to the
> display right away (picture.current). So this is not the right moment to
> restart the display. We may need to change how we handle this.
> 
> I think it is better to reuse the display module if possible. In the end
> people are only going to use opengl/direct3d11 99% of the time and they are
> capable of handling such texture size changes, even without recompiling
> shaders. It's a lot less time sensitive as well. We don't have to worry if
> we'll have time to restart a display to display the frame that has the new
> format.