On 20 July 2011 15:14, Diego Biurrun <[email protected]> wrote:
> 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.

Right, that can be removed but leave the rest of the function please.

Regards,
Rob
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to