[vlc-devel] [PATCH v1 06/33] filters: allow filters to output multiple pictures without chaining them

[Rémi Denis-Courmont]

Le maanantaina 28. syyskuuta 2020, 12.19.11 EEST Steve Lhomme a écrit :
> On 2020-09-26 8:21, Rémi Denis-Courmont wrote:
> > Le lauantaina 26. syyskuuta 2020, 8.58.15 EEST Steve Lhomme a écrit :
> >> The owner is one special kind of sink which is attached (to the decoder)
> >> for good.
> > 
> > The owner is just a name for the structure that carries callbacks for the
> > module to use.
> 
> But it doesn't carry the same concept. You probably don't want to change
> the owner once your filter is created. Whereas you can redirect the
> output with every call.

You can't change the owner once the filter is created. That's what makes it 
safe to use asynchronously.

> This can be done via a fixed owner too. But that's the kind of
> "centralization" I mentioned earlier which IMO adds too much complexity
> in the end. For example doing it in filter_chain would be a PITA.

I don't see how else we'd add asynchronous filtering, and AFAIR, we did decide 
that we eventually wanted to support it, for hardware and threaded filtering.

Leaving aside the "owner" name, the output callback would have to be constant 
and available from open to close anyway.

> > But on the filter side, this drastically limits flexibility on the filter.
> > It makes asynchronous filtering outright impossible, and threaded
> > filtering very inefficient and potentially flaky (as was threaded
> > decoding before asynchronous decoding became supported).
> 
> The sink doesn't prevent asynchronous use of filters.

With your proposed patch, there are *no* sinks to output to when the filter 
callback is not being called. Thus asynchronous use is impossible.

> In fact it makes it more asynchronous.

Compared to the current HEAD, it does add a callback. And thus, it allows to 
output pictures "throughout" the pf_video_filter call, so it is arguably very 
slightly more asynchronous.

I agree that we need a callback, but not in this form. I don't think we should 
be changing the filter callback prototype - and that's not even considering 
Alexandre's ongoing work. We should be consistent and add an owner callback.

If the owner wants to change the sink, it can do that in its callback, where 
the filter needs not know about it.

> If you look at filter_FilterSingle() it's exactly like turning an
> aysnchronous call (sink) into a synchronous one (returning synchronously a
> picture).

I don't really call this asynchronous. It's just passing results by 
synchronous callback instead of function return.

To me, asynchronous filtering is when the output callback is called outside of 
the execution time of pf_video_filter.

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