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.
lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
