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

[Thomas Guillem]

On Thu, Oct 22, 2020, at 07:31, Rémi Denis-Courmont wrote:
> Le keskiviikkona 21. lokakuuta 2020, 19.30.31 EEST Romain Vimont a écrit :
> > On Wed, Oct 21, 2020 at 07:12:48PM +0300, Rémi Denis-Courmont wrote:
> > > Le keskiviikkona 21. lokakuuta 2020, 18.50.51 EEST Romain Vimont a écrit :
> > > > 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.
> > > 
> > > That's pretty convoluted just for one single display module and naughty
> > > filters. Normally, we take the output of the previous filter and give that
> > > as input to the next, which is both simple and locally optimal.
> > > 
> > > I don't see why we should create a display with the wrong format, and then
> > > change the format.
> > 
> > Because currently, we create a display with the wrong format, and then
> > insert a converter. That's not better.
> 
> There's no such thing as creating a display with the wrong format, unless 
> either a display or a filter messes it up. The display is free to request a 
> better format than what the decoder gives, and indeed, many display plugins do 
> so, notably GPU-accelerated one.
> 
> > > For obvious performance reasons, filters should not change the format.
> > 
> > That's not true for GPU filters.
> 
> That's of course true for all types of filters. Gratuitious conversions may be 
> passable in audio output, but they're a massive wastage of computing resource 
> in video.
> 
> This looks like trying to accomodate some broken design that does not exist in 
> the tree, and contradicts the workshop decisions, as I seem to remember them, 
> so -1.

I don't follow you. Indeed adding a video or audio filter will decrease performances. But if it's the user choice (or deinterlacer), then we need to do the maximum to load it without wasting too many performances.
That is why GPU filters should be preferred.

As far as CPU fitlers are concerned, I remember talking about it in the push workshop, saying that we should remove the last conversion filter that adapt to the vout, and instead reconfigure the vout. I remember it was explicitly approved by Steve and Alexandre.

ANd for me, it's not obvious at all. I do think that a vout is best suited for handling non native format than a CPU filter. I think it summarizes to non native -> native conversion, done in GPU vs in CPU.

> 
> -- 
> Rémi Denis-Courmont
> http://www.remlab.net/
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel