On 12/29/2017 8:42 PM, Carl Eugen Hoyos wrote: > Sorry, I don't understand this sentence - could you try with > other words?
Because the buffer is now grown exponentially (by a factor of 2 every time it is resizes), it's possible that it ends up with almost double the size of 'entries' after resizes. For example, consider a valid MP4 file with (1024 * 1024 + 1) entries. With the new code, the final buffer sizes will be (1024 * 1024 * 2) after iterating over everything. I don't know if it's something we care about. Completely Unrelated: Multiple types of atoms are similar to the stts atom, in that they contain a coded number of entries we allocate - maybe we should consistently apply this sort of allocation strategy to them, too (out of scope of this patch, though)? - Derek _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
