[FFmpeg-devel] [libav-devel] [PATCH] aacpsy: avoid norm_fac becoming NaN
andreas.cadhalpun at googlemail.com
Sat Apr 18 00:55:08 CEST 2015
On 17.04.2015 23:39, Luca Barbato wrote:
> On 17/04/15 16:08, Andreas Cadhalpun wrote:
>> On 17.04.2015 02:01, Luca Barbato wrote:
>>> is band->thr = 0.0f a valid value?
>> Come to think of it, that's probably invalid.
I retract that, it seems band->thr = 0.0f is valid.
>> It can happen if coeffs[g].ath is not positive.
> ath() returns easily Inf and negative values...
It returns Inf for 0 and Inf, though that's not the
problem here. Neither is that it can return negative
values, because the minimum of the ath() function is
(or rather should be) subtracted:
coeffs[g].ath = minscale - minath;
The problem is that minath is not the minimum, only close:
minath = ath(3410, ATH_ADD) = -5.24237967
ath(3407, ATH_ADD) = -5.24241638
Attached patch is fixing this. With it the minimal value
of coeffs[g].ath is 0.0f.
>> Attached patch errors out in this case.
Scratch that patch. It shouldn't be negative (fixed with
attached patch), but 0.0f is possible.
>>> band->energy can be 0?
>> Yes, it's set to 0.0f in calc_thr_3gpp if enough coefs are 0.
> and in that case the threshold? (that is calculated as a fraction of the
> energy at least in one place).
In that case band->thr is set to coeffs[g].ath:
band->thr_quiet = band->thr = FFMAX(band->thr, coeffs[g].ath);
So band->thr still can be 0.0f, i.e. the patch checking for (band->thr > 0.0f)
is still necessary.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1050 bytes
Desc: not available
More information about the ffmpeg-devel