[vlc-devel] [PATCH 0/5] Introducing dynamic pools
robux4 at ycbcr.xyz
Wed Dec 5 18:05:57 CET 2018
On 05/12/2018 17:15, Rémi Denis-Courmont wrote:
> 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.
And where is that pool coming from if not from the
decoder/filter/converter ? It may not have the same output format as the
next in line so it cannot share the pool easily.
>> 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
It may be a feature but it makes things trickier to debug. I've been
beaten many times.
> use, and prevent picture reference leaks from starving the whole system.
Are you sure it works like that on all OSes ? Because it seems to me
allocated memory is readily available.
>> 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.
You mentioned on your first comment "They may use a picture_pool_t" so I
don't understand which one is which.
The pool is a tool. Rather than allocating/freeing pictures all the time
it seems better to use a pool of pictures to avoid pressure on the
allocator. It's easy enough to use.
> However, using dynamic pools for hardware decoding sounds like it will end in
> epic failure, because of hardware resource limits.
The dynamic feature is opt-in in the code I provided. Static pools many
not have a use anymore in the end.
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel