[vlc-devel] [PATCH v2 09/20] deinterlace: implement draining of extra pictures

Rémi Denis-Courmont remi at remlab.net
Thu Oct 15 17:53:55 CEST 2020

Le torstaina 15. lokakuuta 2020, 18.36.23 EEST Alexandre Janniaux a écrit :
> I'm not sure I understand your point. I never claimed that
> this patchset implements GPU filtering, I've only mentioned
> that moving the backpressure back in the pipeline was good
> for GPU buffers and my work is not about GPU filtering, but
> more precisely GPGPU filtering with OpenGL.

You're splitting hairs. GPU filtering is already feasible in some cases. This 
patchset makes it feasible in a few more cases. But it comes at the cost of an 
increased complexity and asymmetry within the filters - unlike an owner 
callback for output pictures (as we already have for decoders).

> Since I actually did use the filter pipeline like I described,
> I'm quite curious why you are saying that it cannot work in
> the following sentence.
> > That's not draining and it cannot be treated the same way.

I have already explained that multiple times, and I have no alternative 
explanations to give here. I think it is obvious that processing the last 
input and output picture(s) in a stream is not the same as processing further 
output picture(s) with no new input pictures mid-stream.

> > For that, you need asynchronous filtering, in other words with owner
> > callbacks.
> I also don't understand what kind of backpressure you want to
> have and which execution model you want with asynchronous
> filtering.

The same model and the same motivation as with decoders.

Rémi Denis-Courmont

More information about the vlc-devel mailing list