[vlc-devel] [PATCH 1/8] decoder: let the decoder tell how many pictures it needs in the pool

Steve Lhomme robux4 at ycbcr.xyz
Fri Jul 31 06:18:13 CEST 2020


On 2020-07-30 17:43, Rémi Denis-Courmont wrote:
> Le keskiviikkona 29. heinäkuuta 2020, 8.06.31 EEST Steve Lhomme a écrit :
>> The contract is that the decoder tells the owner how many surfaces it's
>> going to use and it will query the owner for new wrappers via
>> decoder_NewPicture().
> 
> That's true for the legacy picture allocation path whereby the decoder asks
> the core to allocate the picture pool. But if the decoder allocates its own
> picture pool or has its own bespoke picture buffer management, the core has no
> reasons to know about the picture buffer count.

That's where the size of 0 comes in. It tells the owner not to bother 
with a picture pool because the decoder won't be using it (no 
decoder_NewPicture).

> So I don't think it should be embedded in the common generic decoder_t.
> 
>> For now it's only done for HW surfaces but it can also be done for all
>> other buffers if we want to (IMO we don't).
> 
> In the hardware case, the core can anyway not perform the allocation, so by
> definition it does not need to know the picture buffer count.

But it does. And it has to match (more or less) the count of surfaces as 
well. If the number of pictures in the owner is bigger than the number 
of surfaces, the decoder will end up waiting for an available picture, 
and then for an available surface. Hence the decoders still have to set 
i_extra_picture_buffers when needed.

> Repeating myself, but I don't think we should be using picture_pool_t for
> hardware decoders. The way we used picture_t and picture_pool_t in 2.2 and 3.x
> for opaque surfaces was just a path-of-least-resistance trick that has no
> reasons to live on now that vout_display_t.pool is gone.

I agree. But that means we have to tell the owner not to allocate a pool 
when it's never going to use it. It's harmless with decoders outputting 
opaque surfaces with no plane allocation. But that's still unnecessary.

> If you need a list of free pictures with a condition variable to wait on, you
> can instantiate a vlc_queue_t of picture_t, picture_context_t or whatever ad-
> hoc data type, in the hardware decoder... and forget about picture_pool_t.
> 
> -- 
> レミ・デニ-クールモン
> http://www.remlab.net/
> 
> 
> 
> _______________________________________________
> 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