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

Steve Lhomme robux4 at ycbcr.xyz
Wed Jul 31 08:37:07 CEST 2019


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


More information about the vlc-devel mailing list