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

[Martin Storsjö]

On Fri, 17 Sep 2010, Michael Niedermayer wrote:

> On Fri, Sep 17, 2010 at 09:31:15AM +0300, Martin Storsj? wrote:
> > On Fri, 17 Sep 2010, Michael Niedermayer wrote:
> > 
> > > have you tried to put a
> > > 
> > > if(limit > low_quant[X] * state->scale_factor)
> > >     i=X+1;
> > > 
> > > before the loop ?
> > > value of X would be somewhat left of the middle
> > > 
> > > and i prefer the simpler code if speed matches
> > > though i smell compiler messup
> > 
> > Yes, this actually improved the performance quite a bit, down from 917 
> > dezicycles to 855. Since the performance of the version with multiple 
> > sentinels and a boundary check at the end didn't differ much, I removed 
> > that change.
> > 
> > I also checked this on another compiler version and got similar results.
> > 
> > Updated version attached, the current version of the code discussed looks 
> > like this:
> > 
> >     limit = limit + 1 << 10;
> >     if (limit > low_quant[8] * state->scale_factor)
> >         i = 9;
> 
> and after that:
> if (limit > low_quant[i+X] * state->scale_factor)
>     i+= X+1;
> 
> might be faster (or maybe not ...)

I tried this, and after testing a lot of combinations back and forth, I 
found one combination that was as fast as the original single-step 
version, the rest of them were marginally slower.

> you can also try a complete binary search with these

Tried to implement that, too, like this:

    int min = 0, max = 29;
    while (min < max) {
        int mid = min + max >> 1;
        if (limit > low_quant[mid] * state->scale_factor) {
            min = mid + 1;
        } else {
            max = mid;
        }
    }
    i = min;

But that was a bit slower, 1080 dezicycles vs 882 for the best one (the 
patch in the previous mail).

// Martin