[vlc-devel] [PATCH 1/5] vout: update the format after filters
rom1v at videolabs.io
Wed Oct 21 17:50:51 CEST 2020
On Wed, Oct 21, 2020 at 05:26:01PM +0300, Rémi Denis-Courmont wrote:
> Le keskiviikkona 21. lokakuuta 2020, 15.51.03 EEST Romain Vimont a écrit :
> > 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).
> And yet it still breaks in the ways that were already pointed out when this
> was proposed and rejected at the winter 2019 workshop.
I'm sorry, I don't understand how it breaks.
It just adds a possibility for the vout to accept a format change due to
filters, in order to avoid the insertion of a converter. If the vout
refuses, a converter is inserted as before.
> 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.
For a "pure ultimate push model", maybe, but here this is not the case:
- if the vout can handle the format change, it does,
- otherwise, it refuses and a converter is inserted as before.
In any case, this is never worse (and it's sometimes better) than the
current unconditional insertion of a converter (cases which are
currently broken work with these changes).
More information about the vlc-devel