On 18/04/15 13:50, Andreas Cadhalpun wrote: > 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. >
I know, once you get a 0 you get completely out of the previous loop and you do not even enter in the other. To sum up the problem, a way to tackle it is to calculate the limit of that expression and replace with that result whenever you get there. Another neat way is to figure out how many other values are 0 (thus my questions about how you get thr set to 0) and skip computation even before. That code needs to be reshaped a bit before even thinking about fixing it IMHO. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
