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

Martin Storsjö martin
Thu Sep 23 17:36:32 CEST 2010


On Sun, 19 Sep 2010, Martin Storsj? wrote:

> 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).

Any more optimizations to try? Or any objections to committing the 
straightforward (non-trellis) encoder?

// Martin



More information about the ffmpeg-devel mailing list