[vlc-devel] Display update/restart

[Alexandre Janniaux]

Hi,

I actually lean towards a mix of #1 and #2, ie. creating the display
after the filters (meaning that the only hint filters have is the
decoder device that should be video device) and then potentially
allowing the format to change for some metadatas.

#2 is much easier to do (it's done and has been submitted by Romain)
and fits the current model, but #1 is much cleaner. However, we must
take care of the different factors that might restart a display:

 - a chroma change is likely to restart filters/display anyway
 - a colorimetry metadata change shouldn't restart the display if the
   display supports metadata
 - an aspect ratio change shouldn't restart the display too if the
   display is able to scale the picture

That's more or less splitting the video format information from the
video metadata information, but there's multiple way to define this.

About the interlacing part, wouldn't it be easier to have the correct
size for interlaced content anyway, but considering interlaced content
like a different format (meaning it needs a filter or a display able
to deinterlace in one way or another)? It would mean that we need a
way to enforce interlacing format check which might be harder than
what it seems by just saying that, but size doesn't really mean
something when you typically have half the lines that might not be used
contiguously when displaying. Did you investigate such design?

Regards,
--
Alexandre Janniaux
Videolabs

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.
>
> 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.
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel