On 10/17/2012 04:38 AM, Luca Barbato wrote: > On 10/16/2012 09:18 PM, Justin Ruggles wrote: >> On 10/16/2012 03:00 PM, Luca Barbato wrote: >>> On 10/16/2012 08:19 PM, Justin Ruggles wrote: >>>> The LAME API documentation for the required buffer size refers to the size >>>> for >>>> a single encode call. However, we store multiple frames in the same output >>>> buffer but only read 1 frame at a time out of it. As a result, the buffer >>>> size >>>> given in lame_encode_buffer() is actually smaller than what it should be. >>>> Since we do not know how many frames it will end up buffering, it is best >>>> to >>>> just reallocate if needed. >>>> --- >>>> libavcodec/libmp3lame.c | 34 +++++++++++++++++++++++++++++++--- >>>> 1 files changed, 31 insertions(+), 3 deletions(-) >>>> >>> >>> Don't we have a function similar somewhere around the pattern seems common. >> >> Similar, but not exactly. The trigger for reallocation is only based on >> the minimum size needed, but when doing the reallocation it adds double >> what it needs to avoid small incremental reallocations. > > we might have a tunable fast malloc > > so instead of > > min_size = FFMAX(17 * min_size / 16 + 32, min_size); > > we have a coefficient.
Also, in this case, it's not the size of the buffer that matters, it's the remaining size of the buffer from the current index. I don't see how making this into a generic function will be that useful in other places. -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
