On 3/26/2020 11:22 AM, Anton Khirnov wrote: > Quoting James Almer (2020-03-26 15:18:53) >> On 3/26/2020 11:06 AM, Anton Khirnov wrote: >>> Quoting James Almer (2020-03-25 18:56:44) >>>> Increase it in a linear way instead. >>>> Helps reduce memory usage, especially on long, non fragmented output. >>>> >>>> Signed-off-by: James Almer <jamr...@gmail.com> >>>> --- >>>> An alternative is using av_fast_realloc(), in a similar fashion as >>>> ff_add_index_entry(), which will keep the memory usage more closely tied >>>> to the >>>> amount of entries needed, but the amount of reallocations will be much >>>> higher, >>>> so i don't know if the tradeof is beneficial. >>> >>> Wait, wouldn't fast_realloc() do pretty much the same as your patch? Why >>> should the number of reallocations be higher? >> >> I meant mimicking the behavior of ff_add_index_entry(), doing something like >> >> cluster = av_fast_realloc(trk->cluster, >> &trk->cluster_capacity, >> (trk->entry + 1) * sizeof(*trk->cluster)); >> trk->cluster = cluster; >> >> Which will get rid of the fixed MOV_INDEX_CLUSTER_SIZE increase per >> realloc, and resulting in more, smaller size increment reallocs (but of >> course not after every single new entry, which is the entire point of >> av_fast_realloc()). > > Ah, got it. > > I'd say your patch is better, but it probably doesn't matter much.
Applied then, thanks. _______________________________________________ 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".
