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

[Rémi Denis-Courmont]

Le torstaina 15. lokakuuta 2020, 22.16.42 EEST Alexandre Janniaux a écrit :
> Hi,
> > 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).
> 
> I don't think so, I'm not the one bringing this tbh, and I'm
> actually using the filter_t pipeline like explained in the RFC
> so I really don't follow what you're talking about.

AFAIU, you brought two complaints against the current video filter interface, 
buffer requirements and processing time. Both of those problems boil down to 
processing breadth first, when you presumably want depth first instead.

There are three approeaches to do depth first:
a) This patch adds a new function for further pictures. This is probably the 
most convoluted way.
b) Separate the input and output function are less convoluted conceptually and 
for the caller. But they needlessly impacts all filters, even those outputting 
1:1 to their input.
c) A(n owner) callback takes output pictures, just like with decoders already. 
This is actually naturally suited for depth first processing, since the 
callback can directly invoke the next filter chain element.

(...)
> It also seems completely unrelated to why it cannot work with those
> two differences handled with one or two mechanisms, without switching
> to a dedicated thread or dedicated fifo for each filters.

Nobody said to introduce threads or FIFOs for each filters. It would be 
ridiculous for some of the most trivial filters (e.g. VDPAU's). If a filter 
wants to run in a thread, because it is slow, asynchronous and/or prone to 
parallel computing, it's an implementation detail of that filter.

Again, same as with threaded and asynchronous decoders. The picture queuing 
callback gives the option. It does not require any change. Existing filters can 
still return their output picture(s), and let the filter chain invoke the 
queuing callback on their behalf.

-- 
レミ・デニ-クールモン
http://www.remlab.net/