[vlc-devel] [PATCH 1/5] vout: update the format after filters

Romain Vimont rom1v at videolabs.io
Wed Oct 21 14:51:03 CEST 2020


On Tue, Oct 20, 2020 at 07:32:33PM +0300, Rémi Denis-Courmont wrote:
> Le tiistaina 20. lokakuuta 2020, 18.06.53 EEST Romain Vimont a écrit :
> > On Tue, Oct 20, 2020 at 05:02:58PM +0300, Rémi Denis-Courmont wrote:
> > > Hi,
> > > 
> > > We have already covered this in (audio and) video-related IRL discussions
> > > and concluded every time that the current system is the least bad.
> > Hmmm, I'm not sure (especially in discussions about push).
> 
> In the pure ultimate push model, filters are created from upstream to 
> downstream, and the output is created last, supplied with the output format of 
> the filter chain. When the filter chain is changed, all downstream elements 
> (filters if any, and output) are destroyed and recreated. Visual glitches are 
> no longer a concern because the video window is preserved. A potential 
> optimisation is to reuse the output if only ratii and/or size change.
> 
> But as was pointed out at the workshop, and as Steve already pointed out 
> again, if you need to change the pixel format, you need to go through the 
> display capability modules to re-apply priorities and fallback chroma search.
> 
> Of course, this only makes sense whence filters are created before output.

Initially, the commit message of patch 1 ended with:

    In the future, to avoid a two-steps vout initialization, we could
    consider creating the filters before the vout.

I removed it because this was just a remark, but I agree that filters
should be created before the output. But this is a big change.

Meanwhile, this patchset is far less ambitious (and quite independent),
it's just a local optimization/fix: instead of inserting a converter
unconditionally on filters/vout format mismatch, the core just requests
the vout to accept the new format directly. If it can't, it just inserts
a converter like before, but if it can, this avoids an additional
converter (and a failure for opaque formats).

> > OpenGL filters accept "any" input format (the OpenGL interop takes care
> > of the import) and always produce RGBA pictures.
> 
> As you know, there are other display modules than OpenGL at stake.

This patchset avoids a converter if the vout accepts the format
directly. In itself, this feature is independent of OpenGL. But since
OpenGL filters always output RGBA regardless of the input, it just makes
the problem apparent.

Regards


More information about the vlc-devel mailing list