[FFmpeg-devel] [PATCH] Add a G.722 encoder

Martin Storsjö martin
Wed Sep 15 11:41:34 CEST 2010


On Tue, 14 Sep 2010, Michael Niedermayer wrote:

> On Sat, Sep 11, 2010 at 10:18:38PM +0300, Martin Storsj? wrote:
> > On Fri, 10 Sep 2010, Martin Storsj? wrote:
> > 
> > > This actually turned out to work quite well, thanks! New version attached 
> > > that does trellis for both of them at the same time.
> > 
> > Updated patches attached - I tuned the testing range for the lower subband 
> > a bit to achieve even better results.
> > 
> > // Martin

> > +static inline int encode_high(G722Context *c, int xhigh)
> > +{
> > +    int diff = av_clip_int16(xhigh - c->band[1].s_predictor);
> > +    int pred = 564 * c->band[1].scale_factor >> 10;
> 
> *141 >> 8

Fixed

> > +    int index = diff >= 0 ? (diff < pred) + 2 : diff >= -pred;
> > +
> > +    update_high_predictor(&c->band[1], c->band[1].scale_factor *
> > +                          high_inv_quant[index] >> 10, index);
> > +    return index;
> > +}
> > +
> > +static inline int encode_low(const struct G722Band* state, int xlow)
> > +{
> > +    int diff  = av_clip_int16(xlow - state->s_predictor);
> > +    int limit = diff >= 0 ? diff : -(diff + 1);
> 
> > +    int i = 0;
> > +    while (i < 29 && limit >= (low_quant[i] * state->scale_factor) >> 10)
> > +        i++;
> 
> that doesnt look efficient
> limit >= (low_quant[i] * state->scale_factor) >> 10)
> can be changed to
> C > low_quant[i]

Hmm, do you mean something like this?

    limit = (limit << 10) / state->scale_factor;
    while (i < 29 && limit >= low_quant[i])
        i++;

This makes the results differ slightly from the reference test vectors 
(which perhaps in itself is acceptable, but a bitexact mode to test 
against the reference may still be useful). This actually made it slower,

1015 dezicycles in encode_low, 1048518 runs, 58 skips

vs

963 dezicycles in encode_low, 1048494 runs, 82 skips

initially.

> also a LUT could be tried if this matters speed wise

Hmm, what would this LUT contain? The output depends both on the current 
16-bit diff and the current scale factor, so one single 64k LUT isn't 
enough.

// Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-a-G.722-encoder.patch
Type: text/x-diff
Size: 6136 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100915/cbc8ebc9/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Add-initial-trellis-support-in-the-G.722-encoder.patch
Type: text/x-diff
Size: 8251 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100915/cbc8ebc9/attachment-0001.patch>



More information about the ffmpeg-devel mailing list