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

[Rémi Denis-Courmont]

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.

> Filters on the other hand can tell for sure where they have to
> send their output.

Neither decoders nor filters know what happens to their output. That's the 
owner's job to manage. There's no differences there.

> It can be dynamically changed in a filter chain if
> you append another filter after this filter.

That's the filter chain's problem to handle, in other words the owner.

> I think the sink concept gives more flexibility and less complexity on
> both sides.

The sink concept hardly gives more flexibility on the owner. The owner could 
just as well use a sink behind the owner callback to the exact same effect 
(just with a little extra boiler plate), if it needed to.

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

> > Queueing multiple pictures at a time seems like a useless intricacy for
> > every implementation of the interface.
> 
> But that already exists in the code. deinterlacers and fps filter do
> output multiple pictures in one call.

Yes but:

1) On output side, this is currently necessary due to passing by return value. 
It is no longer needed if passing by callback.

2) On input side, this was never allowed, and it should not be because it just 
adds complexity to every filter.

> And the receiver has to be ready to handle that.

AFAIR, the filter chain already has a queue on pending pictures. Though that's 
only really needed because it doesn't support asynchronous filtering yet.

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