[FFmpeg-devel] PATCH: COOK audio decode infastructure to support fixpoint optimization

[Marc Hoffman]

On 7/15/07, Benjamin Larsson <banan at ludd.ltu.se> wrote:
>
> Marc Hoffman wrote:
> > This patch changes the way the data flows by introducing a vec_t data
> > type which is just unsigned char. This way we can abstract the low
> > level data type itself keeping the logic the same.  I'm using a char
> > type so we can walk through the data this is not possible with voids
> > to my knowledge. I have chosen to use vec_t so that we can easily
> > locate the vectors which represent the input and output signals of the
> > system.
>
> Ok, I don't know if this is the best way to do it, but I'll assume it is
> for now.
>
> >
> > I will then add a set of overloaded primitives to the existing
> > structure that handle the lowlevel stuff like quantization, decouple,
> > satruate, interpolate, and imlt etc that needs to know if your working
> > with float or shorts.  I want to keep all the logic the same so I will
> > also introduce a fixpoint fft which I'm in the process of developing
> > under the ffmpeg license as GPL code.
>
> No chance for a LGPL license ? And if you need a reference fp fft to
> look at use this:



LGPL thats what I meant .


http://svn.rockbox.org/viewvc.cgi/trunk/apps/codecs/libwma/wmadeci.c?revision=13859&view=markup
>
> >
> > Please review:
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > Index: libavcodec/cook.c
> > ===================================================================
> > --- libavcodec/cook.c (revision 9441)
> > +++ libavcodec/cook.c (working copy)
> > @@ -61,6 +61,8 @@
> >  #define JOINT_STEREO    0x1000003
> >  #define MC_COOK         0x2000000   //multichannel Cook, not supported
> >
> > +#define vec_t uint8_t
> > +
> >  #define SUBBAND_SIZE    20
> >  //#define COOKDEBUG
> >
> > @@ -69,7 +71,43 @@
> >      int *previous;
> >  } cook_gains;
> >
> > -typedef struct {
> > +
> > +
> > +typedef struct cook {
> > +
> > +    /*
> > +      joint_decode: creates mlt_buffer1, mlt_buffer2
> > +
> > +     mono_decode: creates decode_buffer
> > +          ... category handling all integer and bitstream related...
> > +
> > +          decode_vectors: creates mlt_buffer from categories.
> > +              scalar_dequant: for each block of 20 elements ie
> SUBBAND_SIZE. 32bit-floats
> > +                 (quant_centroid_tab[index][subband_coef_index[i]],
> > +                  dither_tab[index],
> > +                  rootpow2tab[quant_index+63])
> > +
> > +          mlt_compensate_output:
> > +              imlt_gain: inverse modified dct + windowing all dones as
> 32bit-floats
>
> dones
>
> > +                 (mlt_window)
> > +              saturate to 16bit integers
> > +
> > +     then decode_buffer is separated into mlt_buffer1, mlt_buffer2 via
> cplscale multipliers.
> > +    */
> > +    void (* scalar_dequant)(struct cook *q, int index, int quant_index,
> > +                         int* subband_coef_index, int*
> subband_coef_sign,
> > +                         vec_t* mlt_p);
> > +
> > +    void (* decouple) (struct cook *q, int *decouple_tab,
> > +                    vec_t *decode_buffer, vec_t *mlt_buffer1, vec_t
> *mlt_buffer2);
> > +
> > +    void (* interpolate) (struct cook *q, vec_t* buffer, int
> gain_index, int gain_index_next);
> > +
> > +    void (* saturate_output) (struct cook *q, int chan, int16_t *out);
> > +
> > +
> > +    int f_sample_size;
> >
> > [...]
> >
> > +
> > +static void joint_decode(COOKContext *q, vec_t* mlt_buffer1,
> > +                         vec_t* mlt_buffer2) {
> > +    int decouple_tab[SUBBAND_SIZE];
> > +    vec_t *decode_buffer;
> > +
> > +    decode_buffer = av_malloc (1060*q->f_sample_size);
>
> Don't allocate memory with malloc during decode. Use a fixed max size.
>
> > +    memset(decouple_tab, 0, sizeof(decouple_tab));
> > +    memset(decode_buffer, 0, 1060*q->f_sample_size);
> > +
> > +    /* Make sure the buffers are zeroed out. */
> > +    memset(mlt_buffer1,0, 1024*q->f_sample_size);
> > +    memset(mlt_buffer2,0, 1024*q->f_sample_size);
> > +    decouple_info(q, decouple_tab);
> > +    mono_decode(q, decode_buffer);
> > +    q->decouple (q, decouple_tab, decode_buffer, mlt_buffer1,
> mlt_buffer2);
> > +    av_free (decode_buffer);
> > +}
> > +
>
> To me it looks ok but are you sure the f_sample_size thing is needed ?
> It should be 4 for both float and fp and if it is set to that lots of
> logic is simplified.


I guess you might be correct. Initially I was thinking we might be able to
use 16-bit ints to represent the signal and not 32-bits.  I'm still not sure
if the implementation requires the higher precision to be maintained does
anyone know if the algorithm requires the 24bits?

MvH
> Benjamin Larsson
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>