[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