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

[Steve Lhomme]

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
>> 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.

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.

Agreed

> 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.

>
> -- 
> 雷米‧德尼-库尔蒙
> http://www.remlab.net/
>
>
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel