[FFmpeg-devel] av_resample_init() optimization

[Michael Niedermayer]

On Fri, Jan 08, 2010 at 12:05:01PM +0100, Olivier Guilyardi wrote:
> On 01/08/2010 02:56 AM, Michael Niedermayer wrote:
> > On Thu, Jan 07, 2010 at 11:46:31PM +0100, Olivier Guilyardi wrote:
> >> On 01/06/2010 11:43 PM, Michael Niedermayer wrote:
> >>> On Wed, Jan 06, 2010 at 07:34:42PM +0100, Olivier Guilyardi wrote:
> >>>> I'm using libavcodec resampling on an Android ARM (Qualcomm MSM7200A 528 MHz)
> >>>> device, without FPU support. The fact that it's integer-based is really great
> >>>> for performances (this is for a closed source application, but I plan full LGPL
> >>>> compliance with dynamic linking).
> >>>>
> >>>> Nevertheless, there is an overhead upon initialization, when calling:
> >>>> av_resample_init(44100, 48000, 16, 10, 0, 0.8).
> >>>>
> >>>> This comes from av_build_filter() which takes about 6.9 *seconds* to build the
> >>>> polyphase filterbank.
> >>> uhm 7 seconds
> >>>
> >>>> About 300ms (4%) can be saved by applying resample-xfactor.1.patch to r21036. It
> >>>> caches some constant factor, and prevent bessel() and sqrt() from being called
> >>>> when unnecessary. I'm not sure whether the cached factor affects accuracy.
> >>> dont use kaiser windows if you have no FPU or optimize the code properly
> >>> its surely possibly to do this faster with table and cubic interpolation
> >>> also i think your float/double emulation might be trash because even without
> >>> FPU 7sec appears quite extreem, it just calculates ~16k samples of a function
> >>> on a ~500mhz cpu in 7sec thats 200k cpu cycles for a single value
> >> Well, I tried the cubic type by settings WINDOW_TYPE to 0, and calling
> >> av_resample_init() as above. Initialization was indeed much faster, but it
> >> sounded terrible. Any advice on the parameters?
> > 
> > try WINDOW_TYPE 1
> 
> Okay, with this window type, it now takes 2350ms as-is, and 1650ms by applying
> my resample-float.1.patch and using floats instead of doubles. The sound quality
> is good. Further testing is needed to tell whether it is as good as the kaiser
> window. But thanks, that helps.
> 
> Anyway, these initialization times are still too long for me, so I'm using a
> phase_count of 8 instead of 10, which is 4x faster. Any reason why I shouldn't?
> 

> Also, what about my resample-xfactor.1.patch? It prevents bessel() and sqrt()
> from being called for no reason, since the following:
> 
> y *= bessel(type*sqrt(FFMAX(1-w*w, 0)));
> 
> is a no-op when 1-w*w is less than or equal to zero.

as said if you want speed use a lut and cubic interpolation
this would make the code >10x faster. There are probably other ways to
make it faster but you are optimizing the wrong code (that is float code
on a fpu less system with a very poor fpu emulator)
You could also look at libavutil/softfloat* which should be faster for
doing float calculations
also the 0 check should make less of a difference after my recent changes

[..]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Thouse who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100108/db18c62f/attachment.pgp>