[FFmpeg-devel] [PATCH 1/5] avutil/buffer: add av_buffer_pool_flush()

Lynne dev at lynne.ee
Thu Dec 10 01:06:34 EET 2020


Dec 9, 2020, 23:42 by jonas at kwiboo.se:

> On 2020-12-09 23:09, Lynne wrote:
>
>> Dec 9, 2020, 21:25 by jonas at kwiboo.se:
>>
>>> Signed-off-by: Jonas Karlman <jonas at kwiboo.se>
>>> ---
>>>  doc/APIchanges      |  3 +++
>>>  libavutil/buffer.c  | 13 +++++++++++++
>>>  libavutil/buffer.h  |  5 +++++
>>>  libavutil/version.h |  2 +-
>>>  4 files changed, 22 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/doc/APIchanges b/doc/APIchanges
>>> index 3fb9e12525..4a739ce453 100644
>>> --- a/doc/APIchanges
>>> +++ b/doc/APIchanges
>>> @@ -15,6 +15,9 @@ libavutil:     2017-10-21
>>>  
>>>  API changes, most recent first:
>>>  
>>> +2020-xx-xx - xxxxxxxxxx - lavu 56.63.100 - buffer.h
>>> +  Add av_buffer_pool_flush().
>>> +
>>>  2020-12-03 - xxxxxxxxxx - lavu 56.62.100 - timecode.h
>>>  Add av_timecode_init_from_components.
>>>  
>>> diff --git a/libavutil/buffer.c b/libavutil/buffer.c
>>> index d67b4bbdaf..a0683664cf 100644
>>> --- a/libavutil/buffer.c
>>> +++ b/libavutil/buffer.c
>>> @@ -300,6 +300,19 @@ static void buffer_pool_free(AVBufferPool *pool)
>>>  av_freep(&pool);
>>>  }
>>>  
>>> +void av_buffer_pool_flush(AVBufferPool *pool)
>>> +{
>>> +    ff_mutex_lock(&pool->mutex);
>>> +    while (pool->pool) {
>>> +        BufferPoolEntry *buf = pool->pool;
>>> +        pool->pool = buf->next;
>>> +
>>> +        buf->free(buf->opaque, buf->data);
>>> +        av_freep(&buf);
>>> +    }
>>> +    ff_mutex_unlock(&pool->mutex);
>>> +}
>>>
>>
>> This frees all buffers from the pool, which an API user probably has references to,
>> leading to very nasty crashes. I can't see how this is even useful nor needed.
>>
>
> This function should only free buffers that has been returned to the pool and
> is once again part of the pool->pool linked list.
>
> Main use-case is to flush and free all returned buffers in a pool used by a
> hwaccel ctx while a new hwaccel ctx is being initialized, i.e. during seek
> of H.264 video and a SPS change triggers initialization of a new hwaccel ctx.
>
> For devices with memory constraints keeping all previously allocated buffers
> for the old hwaccel ctx around while trying to allocate new buffers for a new
> hwaccel ctx tend to cause to much memory usage, especially for 2160p video.
>
> This function works around this limitation by freeing all buffers that has
> already been returned to the pool during hwaccel uninit, before the last
> buffer is returned, the last buffer is most of the time being displayed and
> is not returned to the pool until next frame has been decoded and displayed
> from next hwaccel ctx.
> Without this the pool buffers is only freed once the last buffer is returned.
>
> Please note that I may have mixed up hwaccel and hw frames ctx above :-)
>
> This function is being called from ff_v4l2_request_uninit and
> v4l2_request_hwframe_ctx_free in next patch.
>

Why can't av_buffer_pool_uninit() free all the buffers currently returned in the pool?
You only seem to be calling it the function during uninitialization.


More information about the ffmpeg-devel mailing list