Tomas Härdin:
> fre 2022-07-01 klockan 00:29 +0200 skrev Andreas Rheinhardt:
>> Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@outlook.com>
>> ---
>> libavcodec/pthread_slice.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/pthread_slice.c b/libavcodec/pthread_slice.c
>> index 756cc59dbf..a4d31c6f4d 100644
>> --- a/libavcodec/pthread_slice.c
>> +++ b/libavcodec/pthread_slice.c
>> @@ -242,9 +242,11 @@ int
>> ff_slice_thread_allocz_entries(AVCodecContext *avctx, int count)
>> if (avctx->active_thread_type & FF_THREAD_SLICE) {
>> SliceThreadContext *p = avctx->internal->thread_ctx;
>>
>> - if (p->entries) {
>> - av_freep(&p->entries);
>> + if (p->entries_count == count) {
>> + memset(p->entries, 0, p->entries_count * sizeof(*p-
>>> entries));
>> + return 0;
>
> Couldn't this trivially handle p->entries_count < count also?
>
Yes, but then this would basically be yet another never-shrinking
buffer. And with every such never-shrinking buffer I fear that we might
allocate too much forever (e.g. because of a single invalid packet).
>> }
>> + av_freep(&p->entries);
>>
>> p->entries = av_calloc(count, sizeof(*p->entries));
>> if (!p->entries) {
>
> Looks like we could use an av_fast_calloc()
>
> /Tomas
>
_______________________________________________
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".
