[FFmpeg-devel] [PATCH] avcodec/alsdec: properly allocate raw_buffer
Paul B Mahol
onemda at gmail.com
Sun Jul 2 17:13:04 EEST 2017
On 7/2/17, Thilo Borgmann <thilo.borgmann at mail.de> wrote:
> Am 01.07.17 um 03:38 schrieb Paul B Mahol:
>> This also reverts 18f94df8.
>> Fixes #5297.
>> Signed-off-by: Paul B Mahol <onemda at gmail.com>
>> libavcodec/alsdec.c | 7 +------
>> 1 file changed, 1 insertion(+), 6 deletions(-)
>> @@ -2062,7 +2057,7 @@ static av_cold int decode_init(AVCodecContext
>> channel_size = sconf->frame_length + sconf->max_order;
>> ctx->prev_raw_samples = av_malloc_array(sconf->max_order,
>> - ctx->raw_buffer = av_mallocz_array(avctx->channels *
>> channel_size, sizeof(*ctx->raw_buffer));
>> + ctx->raw_buffer = av_mallocz_array(avctx->channels *
>> channel_size + sconf->max_order, sizeof(*ctx->raw_buffer));
>> ctx->raw_samples = av_malloc_array(avctx->channels,
> This looks like guessing only about a needed overhead to the raw buffer.
> What is
> needed and actually done, is an overhead of max_order and that is already
> to the buffer length three lines above the proposed change. So this is
> more than guessing an overhead of 2*max_order should be enough but it does
> resolve knowingly any cause of the bug.
> Therefore no, this still does not get applied until the actual reason of the
> is found and properly fixed. I've got less time than I thought today and I
> not dive in as deep as I want. I cannot predict if there will be more time
> me to do it soon. So Paul, I'd appreciate if you could solve this bug but I
> only accept a proper patch and no guesswork.
This is not guesswork, The raw buffers needs this enough bytes.
See this line:
ctx->raw_samples = ctx->raw_buffer + sconf->max_order;
> p.s. I have the original pred.wav used by the ticket author and for me both
> rm22rev2 and rm23 of the reference codec fail to decode pred.mp4 properly.
> anyone else have the same problem with the reference codecs?
Reference code crashes all the time.
More information about the ffmpeg-devel