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

Rémi Denis-Courmont remi at remlab.net
Thu Oct 22 17:17:37 CEST 2020


Le torstaina 22. lokakuuta 2020, 9.12.54 EEST Thomas Guillem a écrit :
> > 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's not what the code does currently (predating any intervention by me), 
and I doubt very much that it would fly, especially on lower-end / mobile 
systems.

> That is why GPU filters should be preferred.

GPU filters are helpful if the input (decoder) and/or the output (display) are 
compatible. But that's pretty much irrelevant to this discussion. You can 
already filter in GPU without this patch in all three cases. HW->SW and HW->HW 
are obvious. SW->HW is feasible but it will remain clumsy/tricky until/unless 
we initialise filters before display, regardless of this patch.

> 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.

I remember discussing if we should have nothing, a control or a callback, yes. 
I also remember concluding that we should have nothing because the input 
format is the only remaining property of the display (now that window and pool 
management are elswhere), and it's also the one property that cannot change 
without breaking the existing probing scheme.

-- 
Rémi Denis-Courmont
http://www.remlab.net/





More information about the vlc-devel mailing list