[vlc-devel] [PATCH 0/5] Introducing dynamic pools

[Rémi Denis-Courmont]

Le keskiviikkona 5. joulukuuta 2018, 10.59.01 EET Steve Lhomme a écrit :
> As discussed during the vout workshop each decoder/filter/converter will
> need to have its own output pool (sharing them may be a future
> optimization).

No. They will need to allocate pictures. They may use a picture_pool_t, or a 
custom pool implementation, or anything else that fits.

> The problem is that for everything to work fine, each pool
> would need to have a large default amount of pictures (maybe the decoder
> pdb ?)

That's neither new nor a problem. For hardware decoding, we need to allocate 
enough pictures up-front to ensure that we won't run out of video memory and 
fail during decoding.

For software decoding, allocating too many pictures is a non-issue since 
demand paging will leave the higher numbered pictures phyiscally unallocated 
(that is why we always take the first free picture, instead of rotating the 
pool like in the old days). Instead, the pool is there to constrain memory 
use, and prevent picture reference leaks from starving the whole system.

> or at least 2 or 3 so that the next module that uses these pictures,
> hold them while one is being written to.
> 
> The static pools we have right now impose that.

That is a feature, not a bug. If it does not fit your use case, then don't use 
the VLC picture pool. The only interface contract that mandates the use of 
picture_pool_t lies between the core and the vout display, and it only applies 
to the buffer-pull model.

However, using dynamic pools for hardware decoding sounds like it will end in 
epic failure, because of hardware resource limits.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/