[vlc-devel] [PATCH 00/17] Restart the display module on format changes

[Romain Vimont]

On Sun, Nov 22, 2020 at 11:45:54AM +0200, Rémi Denis-Courmont wrote:
> Le sunnuntaina 22. marraskuuta 2020, 11.34.17 EET Romain Vimont a écrit :
> > On Sun, Nov 22, 2020 at 11:08:33AM +0200, Rémi Denis-Courmont wrote:
> > > Le perjantaina 20. marraskuuta 2020, 16.44.50 EET Steve Lhomme a écrit :
> > > > The display may be able to cope with the
> > > > change but in case it doesn't we need to restart the display.
> > > 
> > > That's not how we usually solve that problem. As was already mentioned at
> > > the last workshop, we already have a simple and robust solution for that,
> > > that has been used for years. The display requests up-front whatever
> > > format is most convenient, and lets the the filter chains figure insert
> > > any necessary conversion.
> > 
> > That's stupid to add a converter if a filter outputs a format that can
> > be handled directly by the vout display.
> 
> No. It's smart. It avoids bloating the display with conversions that would 
> needed in filters anyway and duplicating code.

Hmm, no, this does not add an additional conversion in the display (just
a "reconfigure"). In practice, creating the vout after the filters will
solve the case where filters output != decoder output.

> It also avoids breaking the fine 
> and simple format negotiation and chain build that we have.

It's not fine because it causes issues (when a filter produces pictures
with chroma or size different from its input picture). It would be more
straightforward to just create the vout display with the format the last
filter (if any) produces.

> > The display sometimes do not have a "most convenient format". For
> > example, the OpenGL display doesn't care if it receives I420, NV12 or
> > RGBA for example. Adding a converter to match the decoder format (which
> > is meaningless) is a pure waste.
> 
> Lol. Native I420 in OpenGL? And you call me stupid?

I never said "native in OpenGL", I talked about the vout display.
The vout display does not care about the input format, because it always
uses an interop to import the picture.

Btw, currently, if the decoder produces I420 pictures and the vout
display receives RGBA pictures, then a converter from RGBA to I420 must
be added so that OpenGL receives I420 (while its "native" format is
RGBA).

> And you call me stupid?

I didn't call _you_ stupid, I called _this strategy_ stupid. Or
meaningless if you prefer: the vout display does not receive the
pictures from the decoder, but from the last filter, so why should it be
created from the decoder format?

Regards