[FFmpeg-devel] av_resample_init() optimization

[Olivier Guilyardi]

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.

--
  Olivier