[FFmpeg-devel] [PATCH] G.729 Fixed-codebook vector decoding

[Michael Niedermayer]

On Mon, Jun 29, 2009 at 02:09:12AM +0700, Vladimir Voroshilov wrote:
> 2009/6/28 Vladimir Voroshilov <voroshil at gmail.com>:
> > 2009/6/28 Vladimir Voroshilov <voroshil at gmail.com>:
> >> 2009/6/28 Vladimir Voroshilov <voroshil at gmail.com>:
[...]
> > Please disregard this mail, since calculations are wrong (subframe
> > size os 40, not 80).
> >
> > Any ideas about sparse vector are still welcome.
> >
> 
> Further investigation about sparse fixed-codebook vector.
> 
> Where this vector is used:
> 1. is constructed (creating several non-pulses in zero array)
> 
> 2. harminoc filter:
> for(i=pitch_delay; i<subframe_size;i++)
> fc[i] += fc[i-pitch_delay] * gp;
> 
> 3. gain_code decoding:
> sum = scalarproduct(fc);
> 
> 4. attenuating excitation signal
> for(i=0;i<subframe_size;i++)
> exc[i] = exc[i] * gp + fc[i] *gc;
> 
> (1),(3) can be easyli implemented with sparse vector.
> (2) implementation is harder, but  looks possible even for me.
> 
> But compare code:
> 
>     for (i=0; i<fc.count; i++) {
>         int new_index = fc.index[i] + pitch_delay;
>         if (new_index < SUBFRAME_SIZE) {
>             for(j=1; j<fc.count; j++)
>                 if (new_index == fc.index[j])
>                     break;
>             if (j == fc.count) {
>                 fc.index[out->count] = new_index;
>                 fc.value[out->count] = 0;
>                 fc.count++;
>             }
>             fc.value[j] = av_clip_int16(((fc.value[j] << shift) +
> fc.value[i] * gain_pitch + rounder)>>shift);
>         }
>     }
> 
> fc.count is less or equal 8 in above code.

have you tested this code?


> 
> and:
> 
> for(i=pitch_delay; i<40;i++)
>     fc[i] += fc[i-pitch_delay] * gp;
> 
> 
> (4) i can't see effective implementation with sparse vector.
> because elements corresponding sparse vector elemens are calculated as
> the only way i see is:
> 
> for(i=0; i<40; i++)
> exc[i] *=gp;
> for(i=0;i<fc.count; i++)
> exc[fc.index[i]] += fc.value[i] * gc
> 
> vs.
> 
> for(i=0;i<40;i++)
> exc[i] = exc[i] * gp + fc[i] *gc;
> 
> 
> I prefer second (non-sparse) form. If you think that first is better,
> even if harder to understand (at least for me),
> i'll change code.

what is the speed difference of the 2 ?
also, are you sure the *gp can not be merged into a prior step?


> I'm not also sure if this sparse-vector code can be reused by other
> celp-based codecs.
> The non-sparse form uses more usual primitives like "scalarproduct of
> vectors", "weighted sum of vectors" and so on.
> 
> I hope i've given you enough arguments to protect  my point of view.

no, your argument of 2 extra lines of code being bad is a little weak,
the rest i could not really follow and wont bother with before you confirm
that the code has been tested and thus doesnt follow under your prior
comment of "Please disregard this mail, since calculations are wrong"

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- 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/20090628/0ef5f9f5/attachment.pgp>