Tomas Härdin: > 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 >
This was designed to make the result of the following computation (performed in shift_data) to always fit into three bytes: metadata_size = flv->filepositions_count * 9 * 2 + 10 But now upon rereading I see that there is some change added to this unconditionally after that. I will also account for that. (Notice that it is not intended to account for flv->metadata_totalsize which is added later.) - Andreas _______________________________________________ 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".
