[FFmpeg-devel] [PATCH] Rewrite COMMON_CORE resampling loop.

Ronald S. Bultje rsbultje at gmail.com
Tue May 27 13:08:35 CEST 2014


Hi,

On Mon, May 26, 2014 at 11:24 PM, Michael Niedermayer <michaelni at gmx.at>wrote:

> On Mon, May 26, 2014 at 06:09:56PM -0400, Ronald S. Bultje wrote:
> > This moves a condition in the loop outside. In one particular fate
> > test (fate-swr-resample-s32p-8000-2626), this makes the code about
> > 10% faster. It also simplifies the loop, allowing us to rewrite it
> > in yasm at some later point.
> > ---
> >  libswresample/resample_template.c | 30 ++++++++++++++++--------------
> >  1 file changed, 16 insertions(+), 14 deletions(-)
> >
> > diff --git a/libswresample/resample_template.c
> b/libswresample/resample_template.c
> > index becff12..44fb667 100644
> > --- a/libswresample/resample_template.c
> > +++ b/libswresample/resample_template.c
> > @@ -135,34 +135,36 @@ int RENAME(swri_resample)(ResampleContext *c,
> DELEM *dst, const DELEM *src, int
> >          *consumed= index;
> >          index = 0;
> >      }else if(compensation_distance == 0 && !c->linear && index >= 0){
> > +        int64_t end_index = (1 + src_size - c->filter_length) <<
> c->phase_shift;
>
> the shift is 32bit, probably would be safer as 64bit


The 64 bit was mainly to not have to cast in the next line:


> > +        int64_t delta_frac = (end_index - index) * c->src_incr -
> c->frac;
>
> cant this overflow ?


That's a good question, theoretically speaking I'm not sure. It obviously
doesn't in any of the tests, but I'm not sure what the limits o these
numbers are. I see phase_shift being 10 and then src_incr will be in that
area also (say 15 bit upper bound on massive resampling change), which is
only 25 bits so then it easily fits. But I don't know if that holds for all
input/configs.

Ronald


More information about the ffmpeg-devel mailing list