tis 2022-07-05 klockan 22:26 +0200 skrev Andreas Rheinhardt: > Using a linked list had very much overhead (the pointer to the next > entry increased the size of the index entry struct from 16 to 24 > bytes, > not to mention the overhead of having separate allocations), so it is > better to (re)allocate a continuous array for the index. > av_fast_realloc_array() is used for this purpose, in order not to > reallocate the array for each entry. It's feature of allowing to > restrict the number of elements of the array is put to good use here: > Each entry will lead to 18 bytes being written and the array is > contained in an element whose size field has a length of three bytes, > so that more than (2^24 - 1) / 18 entries make no sense. >
> + /* The filepositions array is part of a metadata element whose > size field > + * is three bytes long; so bound the number of filepositions in > order not > + * to allocate more than could ever be written. */ > + int ret = av_fast_realloc_array(&flv->filepositions, > + &flv->filepositions_allocated, > + flv->filepositions_count + 1, > + (((1 << 24) - 1) - 10) / Why -10? I see it bumps max_nb down from 932067 to 932066, but it make no difference keeping below 1<<24 Looks like the rest of the patch makes the code faster and easier to read. Very nice. /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".