On 18.04.2015 03:54, Luca Barbato wrote: > if thr is really tiny norm_fac would be huge, not tiny. (or tiny and not > huge depending if you look it before or after norm_fac = 1/norm_fac)
That depends. If band->thr is 0 this more or less means band->energy is 0 (band->thr is set to 'band->energy * 0.001258925f') and then band->active_lines is set to 0 in calc_pe_3gpp. Thus the problematic case is 0/0, which is undefined. > Once you have a threshold 0 you could basically short circuit the whole > loop I'm not sure what a short circuit helps, when you get NaN? > and the one below gets sort of funny since you have a 0 * Inf. The one below isn't that funny, because norm_fac is already NaN. > And while at it maybe it could be simplified like this (still not fully > awake). This simplification shouldn't change the behavior. > @@ -685,8 +684,7 @@ static void psy_3gpp_analyze_channel(FFPsyContext > *ctx, int channel, > if (active_lines > 0.0f) > band->thr = calc_reduced_thr_3gpp(band, > coeffs[g].min_snr, reduction); > pe += calc_pe_3gpp(band); > - band->norm_fac = band->active_lines / band->thr; > - norm_fac += band->norm_fac; > + norm_fac += band->active_lines / band->thr; Here you can still have 0/0. Best regards, Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
