[vlc-devel] [PATCH 12/14] filter_chain: add a default implementation for the video_allocator

Steve Lhomme robux4 at ycbcr.xyz
Wed Jul 31 09:17:15 CEST 2019


On 2019-07-31 8:49, Rémi Denis-Courmont wrote:
> Hi,
> 
> NULL means that there is no video context and the filter knows if it needs one or not. There are no distinctions to be made between none and missing.

It might be doable but I don't think it's desirable. And there's still 
the problem of the decoder device that is needed to adapt the 
decoder+filter dynamic output to the display.

Just as we're adding a "vout_get_device" for decoders, we could add it 
to filter chains so when it tries to adapt the filter it can recover it. 
It should also be added to each filter at creation so they can also 
match the same device if they need to/can.

> And I stopped reading 

Am I supposed to take in considerations your comments if you don't even 
bother reading replies to yours ?

> at vout allocating pictures. Vout displays do not allocate pictures anymore, except internally as an implementation detail.
 >
> Le 31 juillet 2019 09:37:07 GMT+03:00, Steve Lhomme <robux4 at ycbcr.xyz> a écrit :
>> On 2019-07-30 18:52, Rémi Denis-Courmont wrote:
>>> Le tiistaina 30. heinäkuuta 2019, 9.57.24 EEST Steve Lhomme a écrit :
>>>>> If all GPU filters are using the video context, it means that you
>> can't
>>>>> have
>>>> All filters have a video context, even if it's a "CPU" video
>> context. A
>>>> NULL video context will not be allowed. It wouldn't make sense, just
>>>> like an empty video format doesn't make sense. It's also the best
>>>> candidate to carry the decoder device along the whole filter chain
>> (see
>>>> previous answer).
>>>
>>> Sure it makes sense. Regular RAM has no reason to have a video
>> context, except
>>> maybe for convenience.
>>
>> Except you can't tell if NULL means it's a CPU video context or it's
>> simply missing because the code couldn't create it in the first place.
>>
>>>> Yes, at the very least the last filter in a chain must get pictures
>> from
>>>> the outside, not create its own.
>>>
>>> I completely disagree, and that's not how push model was designed.
>>>
>>> Push model means filters and converters allocate their *output*
>> picture, just
>>> like decoders do. Nothing else makes sense - the downstream has to
>> handle the
>>> case that there are no filters and the decoders pushes its pictures,
>> so it
>>> might as well do the same with filters.
>>
>> And by what magic do you think it can accept any video format+context
>> it's given ? By using filters which will have to adapt for both the
>> input and the output format+context. And there are plenty of vout that
>> won't accept pictures they did not allocate. So the last filter will
>> have to handle the pictures from the outside/downstream (which is what
>> they do now).
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel
> 
> -- 
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
> 


More information about the vlc-devel mailing list