[vlc-devel] [PATCH v1 07/33] filter: allow using filters with a sink callback to filter into a single picture

Steve Lhomme robux4 at ycbcr.xyz
Mon Sep 28 11:30:20 CEST 2020


On 2020-09-26 8:25, Rémi Denis-Courmont wrote:
> Le lauantaina 26. syyskuuta 2020, 9.06.28 EEST Steve Lhomme a écrit :
>> On 2020-09-25 17:27, Rémi Denis-Courmont wrote:
>>> Hi,
>>>
>>> That API is fundamentally incompatible with asynchronous use as the
>>> filter would have no sink to output to outside the callback.
>>
>> Filter users that use filter_FilterSingle() are indeed incompatible with
>> an asynchronous system.
> 
> Not really. You can trivially convert a synchronous filter into an asynchronous
> filter by just calling the output callback on return. It can even be done in
> the owner side so that filters don't need to be modified one by one.

OK, that would move what filter_FilterSingle() does into each filter. Or 
maybe it can even stay as-is.

> That's what we do for synchronous decoders.
> 
>>> That's why decoders get an owner callback for this purpose instead.
>>
>> This does not change anything.
> 
> It changes everything. The owner callback is available at all times from open
> to close. The sink is only available during the filter call.

I agree, but I don't see it as a problem. If the goal is to allow 
filters to output a picture anytime they want (rather than one picture 
in/many picture out) then yes it is a problem.

>>> While I don't expect that asynchronous filters will work quiet yet, I
>>> don't want to revector into an API that gets us further from the goal.
>>
>> Sinks are actually a big step towards asynchronous use.
> 
> It's more like a big backward. It adds a new parameter and a new object that
> need to be replaced anyway for asynchronous, into something that will be
> exactly or very much like an owner callback down the line.

I agree as of now there's no clear advantage for sinks. The asynchronous 
output would lean towards the owner (or something that can be set/changed).

>> The owner pattern is too centralized for that and would need to manage each
>> step of the pipeline, maybe with a state machine or something.
> 
> I disagree and in any case the owner callback system is what was agreed to
> implement at multiple workshops already.

That doesn't mean we can never find a case where it's a problem.


More information about the vlc-devel mailing list