On 10/17/2012 02:55 PM, Justin Ruggles wrote: > 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. >
Push the patch as is =) _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
