[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