[FFmpeg-devel] [PATCH] Add a G.722 encoder
Martin Storsjö
martin
Sun Sep 19 21:10:07 CEST 2010
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
More information about the ffmpeg-devel
mailing list