[vlc-devel] [PATCH 1/8] decoder: let the decoder tell how many pictures it needs in the pool
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
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