[FFmpeg-devel] [PATCH 2/3] avcodec/aacenc_is: Assert that minthr is not 0.0, this would lead to division by 0 later
Claudio Freire
klaussfreire at gmail.com
Mon May 16 18:33:37 CEST 2016
On Mon, May 16, 2016 at 12:26 PM, Kieran Kunhya <kierank at obe.tv> wrote:
>> Testcase is fate-aac-pred-encode
>>
>> Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
>> ---
>> libavcodec/aacenc_is.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/libavcodec/aacenc_is.c b/libavcodec/aacenc_is.c
>> index 473897b..e5cfa14 100644
>> --- a/libavcodec/aacenc_is.c
>> +++ b/libavcodec/aacenc_is.c
>> @@ -64,6 +64,9 @@ struct AACISError ff_aac_is_encoding_err(AACEncContext
>> *s, ChannelElement *cpe,
>> abs_pow34_v(I34, IS, sce0->ics.swb_sizes[g]);
>> maxval = find_max_val(1, sce0->ics.swb_sizes[g], I34);
>> is_band_type = find_min_book(maxval, is_sf_idx);
>> +
>> + av_assert0(minthr != 0.0);
>> +
>> dist1 += quantize_band_cost(s, &L[start + (w+w2)*128], L34,
>> sce0->ics.swb_sizes[g],
>> sce0->sf_idx[w*16+g],
>> --
>> 1.7.9.5
>>
>>
>>
> Does this assert on actual input data?
A threshold of 0 would in theory cause a zeroed band (zeroes[i] == 1),
and those should be skipped.
I think the proper fix would be figuring out why those aren't being
skipped, if that is the case.
More information about the ffmpeg-devel
mailing list