[FFmpeg-devel] [PATCH] Common ACELP code & G.729 [1/7] - filters
Michael Niedermayer
michaelni
Wed May 7 02:47:10 CEST 2008
On Wed, May 07, 2008 at 07:05:07AM +0700, Vladimir Voroshilov wrote:
> On Wed, May 7, 2008 at 3:42 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >
> > On Tue, May 06, 2008 at 11:24:38PM +0700, Vladimir Voroshilov wrote:
> > > On Mon, May 5, 2008 at 3:42 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > > > On Sun, May 04, 2008 at 01:19:10PM +0700, Vladimir Voroshilov wrote:
> > > > > On Sat, May 3, 2008 at 7:23 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > > > > > On Sat, May 03, 2008 at 03:24:54PM +0700, Vladimir Voroshilov wrote:
> > > > > > > Michael Niedermayer wrote:
> > > > > > [...]
> > > > > > > +void ff_acelp_convolve_circ(
> > > > > > > + int16_t* fc_out,
> > > > > > > + const int16_t* fc_in,
> > > > > > > + const int16_t* filter,
> > > > > > > + int subframe_size)
> > > > > > > +{
> > > > > > > + int i, k;
> > > > > > > +
> > > > > > > + memset(fc_out, 0, subframe_size * sizeof(int16_t));
> > > > > >
> > > > > > > +
> > > > > > > + /* Since there are few pulses over all subframe (i.e. almost all
> > > > > >
> > > > > > > + fc_in[i] are zero, in case of G.729D it is only two non-zero
> > > > > > > + samples of total 40), it is faster to swap two loops and process
> > > > > > > + non-zero samples only. This will reduce number of multiplications
> > > > > >
> > > > > > > + from 40*40 to 2*40 for G.729D */
> > > > > >
> > > > > > doesnt ff_acelp_fc_enchance_harmonics() increase the number of non 0
> > > > > > elements above 2 ?
> > > > >
> > > > > Perhaps i misspelled sentence.
> > > > > I meant that using swapped loops with checking for non-zero will
> > > > > require 2*40 multiplications,
> > > >
> > > > The sentance is fine.
> > > > What i meant is that ff_acelp_fc_enchance_harmonics() can increase the number
> > > > of non zero samples above 2. Or do i miss somehing that prevents this?
> > >
> > > This is exactly what this filter intended to do.
> > > It get buffer with few pulses and smooth them over all subframe.
> > > In reference code it is caller "pitch_shrp" ("pitch sharpening" i guess).
> >
> > What iam trying to say is, if ff_acelp_fc_enchance_harmonics() increases the
> > number of non zero samples above 2 then the comment is no longer correct.
> > As its no longer exactly 2 for g729d
>
> I'm afraid you still don't understand what I wanted to say.
> 1. At each call "in" buffer for g729d contains exactly two no-zero values.
Then please explain me the following:
memset(fc, 0, sizeof(int16_t) * ctx->subframe_size);
formats[ctx->format].decode_fixed(fc, parm->fc_indexes[i], parm->pulses_signs[i]);
** here fc will have exactly 2 non zero elements **
ff_acelp_fc_enchance_harmonics(fc, pitch_delay_int, ctx->pitch_sharp, ctx->subframe_size);
** here fc can have more non zero elements i think **
...
if(ctx->format == FORMAT_G729D_6K4)
{
int16_t exc_new[MAX_SUBFRAME_SIZE];
ctx->onset = g729d_onset_decision(ctx->onset, ctx->past_gain_code);
ctx->voice_decision = g729d_voice_decision(ctx->onset, ctx->voice_decision, ctx->past_gain_pitch);
** here fc still should have more non zero elements **
g729d_get_new_exc(exc_new, ctx->exc + i * ctx->subframe_size, fc, ctx->voice_decision, ctx->past_gain_code[0], ctx->subframe_size);
----
void g729d_get_new_exc(
int16_t* out,
const int16_t* in,
const int16_t* fc_cur,
int dstate,
int gain_code,
int subframe_size)
{
int i;
int16_t fc_new[MAX_SUBFRAME_SIZE];
** so should fc_cur here **
ff_acelp_convolve_circ(fc_new, fc_cur, ff_g729_phase_filter[dstate], subframe_size);
------
The reason why id like this clarified is because if there really are just
2 non zero elements in there then a simple array of 2 int could be used to
store them and this should be much simpler. But it does not look like there
are just 2 (or maybe the code is buggy or iam stupid ...)
> 2. During process these two pulses are smoothed over all subframe and
> written to "output" (!) buffer. "in" buffer remains the same.
> 3. When used formula from doxygen comments, filter will make 40*40
> multiplications (regardless of values in "in" buffer).
> 4. When two loops are swapped (comparing to formula in doxygen
> comment) and check for non-zero is added, filter will make only 2*40
> multiplications (since input buffer is never touched).
>
> This is why i asked for phrase correctness (i meant not english, but
> phrase meaning).
>
> > > +void ff_acelp_high_pass_filter(
> > > + int16_t* out,
> > > + int16_t* hpf_z,
> > > + int* hpf_f,
> > > + const int16_t* in,
> > > + int length)
> > > +{
> > > + int i;
> > > +
> > > + for(i=0; i<length; i++)
> > > + {
> > > + memmove(hpf_z + 1, hpf_z, 2 * sizeof(hpf_z[0]));
> > > + hpf_z[0] = in[i];
> > > + hpf_f[0] = MULL(hpf_f[1], 15836); /* (14.13) = (13.13) * (1.13) */
> > > + hpf_f[0] += MULL(hpf_f[2], -7667); /* (13.13) = (13.13) * (0.13) */
> > > + hpf_f[0] += 7699 * (hpf_z[0] - 2*hpf_z[1] + hpf_z[2]); /* (14.13) = (0.13) * (14.0) */
> >
> > > +
> > > + /* Multiplication by 2 with rounding can cause short type
> > > + overflow, thus clipping is required. */
> > > +
> > > + out[i] = av_clip_int16((hpf_f[0] + 0x800) >> 12); /* (15.0) = 2 * (13.13) = (14.13) */
> > > +
> > > + memmove(hpf_f + 1, hpf_f, 2 * sizeof(hpf_f[0]));
> > > + }
> >
> >
> > t = MULL(hpf_f[0], 15836); /* (14.13) = (13.13) * (1.13) */
> > + MULL(hpf_f[1], -7667); /* (13.13) = (13.13) * (0.13) */
> > + 7699 * (in[i] - 2*in[i-1] + in[i-2]); /* (14.13) = (0.13) * (14.0) */
> >
> > out[i] = av_clip_int16((t + 0x800) >> 12); /* (15.0) = 2 * (13.13) = (14.13) */
> >
> > hpf_f[1]= hpf_f[0];
> > hpf_f[0]= t;
>
> This will require either two samples before start in "in" buffer, copied from
> the previous subframe or
yes, i thought that would be just something like
memcpy(in-2, in+len-2, 2*sizeof(*in))
?
If so that should be simpler than it is currently
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080507/cc4b92bd/attachment.pgp>
More information about the ffmpeg-devel
mailing list