On Wed, Jul 20, 2011 at 02:21:37PM +0200, Rob wrote: > On 19 July 2011 15:39, Diego Biurrun <[email protected]> wrote: > > On Tue, Jul 19, 2011 at 08:48:07AM +0200, Rob wrote: > >> On 15 July 2011 23:48, Diego Biurrun <[email protected]> wrote: > >> > --- a/libavcodec/acelp_pitch_delay.c > >> > +++ b/libavcodec/acelp_pitch_delay.c > >> > @@ -88,39 +88,6 @@ void ff_acelp_update_past_gain( > >> > quant_energy[0] = (6165 * ((ff_log2(gain_corr_factor) >> 2) - > >> > (13 << 13))) >> 13; > >> > } > >> > > >> > -int16_t ff_acelp_decode_gain_code( > >> > - DSPContext *dsp, > >> > - int gain_corr_factor, > >> > - const int16_t* fc_v, > >> > - int mr_energy, > >> > - const int16_t* quant_energy, > >> > - const int16_t* ma_prediction_coeff, > >> > - int subframe_size, > >> > - int ma_pred_order) > >> > -{ > >> > - int i; > >> > - > >> > - mr_energy <<= 10; > >> > - > >> > - for(i=0; i<ma_pred_order; i++) > >> > - mr_energy += quant_energy[i] * ma_prediction_coeff[i]; > >> > - > >> > -#ifdef G729_BITEXACT > >> > - mr_energy += (((-6165LL * ff_log2(dsp->scalarproduct_int16(fc_v, > >> > fc_v, subframe_size, 0))) >> 3) & ~0x3ff); > >> > - > >> > - mr_energy = (5439 * (mr_energy >> 15)) >> 8; // (0.15) = > >> > (0.15) * (7.23) > >> > - > >> > - return bidir_sal( > >> > - ((ff_exp2(mr_energy & 0x7fff) + 16) >> 5) * > >> > (gain_corr_factor >> 1), > >> > - (mr_energy >> 15) - 25 > >> > - ); > >> > -#else > >> > - mr_energy = gain_corr_factor * exp(M_LN10 / (20 << 23) * mr_energy) > >> > / > >> > - sqrt(dsp->scalarproduct_int16(fc_v, fc_v, > >> > subframe_size, 0)); > >> > - return mr_energy >> 12; > >> > -#endif > >> > -} > >> > >> Hmm, this function looks very familiar to me for AMR though my > >> implementation was float, sipro appears to use a floating point > >> version of this function and I know it is a core function of ACELP > >> codecs so perhaps it is good to keep around. > >> > >> We were aiming to build up a collection of the common ACELP functions > >> to reuse to quickly write other ACELP decoders. If removed it would be > >> in the history but it would be difficult to know about or find for > >> someone who didn't know it had been there. > > > > I'll take that as a vote to keep it then. > > Yes.
I'll send an updated patch soon. What about this G729_BITEXACT chunk? That is not defined anywhere, so it's all completely dead code. Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
