[FFmpeg-devel] [PATCH] use MUL64 in ac3dec.c
Reimar Döffinger
Reimar.Doeffinger
Wed Jan 13 00:04:58 CET 2010
On Tue, Jan 12, 2010 at 06:36:12PM +0100, Reimar D?ffinger wrote:
> On Tue, Jan 12, 2010 at 08:12:42PM +0300, Yuriy Kaminskiy wrote:
> > Index: libavcodec/ac3dec.c
> > ===================================================================
> > --- libavcodec/ac3dec.c.orig 2010-01-12 19:05:46.000000000 +0300
> > +++ libavcodec/ac3dec.c 2010-01-12 19:18:44.000000000 +0300
> > @@ -420,10 +420,9 @@ static void calc_transform_coeffs_cpl(AC
> > int band_end = bin + s->cpl_band_sizes[band];
> > for (ch = 1; ch <= s->fbw_channels; ch++) {
> > if (s->channel_in_cpl[ch]) {
> > - int64_t cpl_coord = s->cpl_coords[ch][band];
> > + int cpl_coord = s->cpl_coords[ch][band] << 4;
> > for (bin = band_start; bin < band_end; bin++) {
> > - s->fixed_coeffs[ch][bin] = ((int64_t)s->fixed_coeffs[CPL_CH][bin] *
> > - cpl_coord) >> 23;
> > + s->fixed_coeffs[ch][bin] = MULH(s->fixed_coeffs[CPL_CH][bin]<< 5, cpl_coord);
>
> Going by what Justin said, shifting cpl_coord by 5 and fixed_coeffs by 4
> instead should be safe(r) and might be even faster on some architectures.
> This variant might be slightly slower on 64 bit architectures since there
> it means one shift more - I don't think it matters though.
I applied my suggestion, for what I can tell there should not be any overflow
issue, though it is of course possible I missed something.
More information about the ffmpeg-devel
mailing list