Dec 9, 2020, 23:42 by jo...@kwiboo.se:
> On 2020-12-09 23:09, Lynne wrote:
>
>> Dec 9, 2020, 21:25 by jo...@kwiboo.se:
>>
>>> Signed-off-by: Jonas Karlman <jo...@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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
