[vlc-devel] [PATCH 0/5] Introducing dynamic pools
remi at remlab.net
Wed Dec 5 17:15:45 CET 2018
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
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.
More information about the vlc-devel