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

Rémi Denis-Courmont remi at remlab.net
Thu Jul 30 17:43:53 CEST 2020

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.

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.

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.

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.


More information about the vlc-devel mailing list