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

Reply via email to