[vlc-devel] [PATCH 2/7] picture_pool: add the video format requested when waiting for a picture
Steve Lhomme
robux4 at ycbcr.xyz
Mon Nov 9 10:36:57 CET 2020
On 2020-11-09 10:22, Alexandre Janniaux wrote:
> Hi,
>
> On Mon, Nov 09, 2020 at 09:04:49AM +0100, Steve Lhomme wrote:
>> On 2020-11-06 18:00, Rémi Denis-Courmont wrote:
>>> Le perjantaina 6. marraskuuta 2020, 16.42.09 EET Steve Lhomme a écrit :
>> The generic/clean way is to create a new pool. But it is creating a lot of
>> stress on the memory. Imagine decoding 4K HEVC on 32 cores. You have a huge
>> pool. And you would allocate such a pool every time the video format
>> changes. That may happen often with HDR metadata (in HDR10+ I suppose that
>> would be the case). Same thing with interlacing in push. Then at some point
>> you could have 4/10/whatever the same huge pool allocated in memory.
>
> In addition to what I mentioned in the other thread on
> memory stressing, I don't think we should realloc new
> pool each time metadata change, which would likely be a
> waste of resources when you can just set them. But I would
> typically make the decoder attach them after picking from
> the pool.
>
>> IMO the picture pool should only deal with the buffer pooling and not the
>> video_format_t attached to it. This patch is one step in that direction. I
>> can do the rest if needed.
>
> I agree that it should only deal with the buffer pooling,
> hence why it should actually not deal with format change.
I agree, it should be attached outside of the pool. And "surface" (as in
decoding width/height and chroma planes) changes will also be handled
outside. So all we need is a bare pool.
I can work on that if we agree on that direction. That will also
simplify the nvdec_pool_t and maybe the va_surface.
More information about the vlc-devel
mailing list