[MPlayer-dev-eng] [PATCH] intresample first attempt

[Anders Johansson]

Hi,

> Hi!
> 
> I attached two new patches. One is af_intresample.c, 
> the other adds -af linint to the options. If you don't like it,
> feel free to do whatever you want with it, or I can change it too.

The af options will change in next week see the pre9 thread.
also the selection between yours and mine resample will be made inside
the resample filter using the AF_CONTROL_POST_CREATE call.

> > intresample() function to work with 1 to 6 channels and resend it -
> This I did, but could not test.

No worries I'll test it.

> > filter creates a frequency offset that changes over time, that could be
> > fixed by using a counter to add samples when the counter passes "step"
> > (I think).
> I don't really understand this. The change I made, is that pt is now saved in
> the context, so it is not initialized to 0 always.
> Also of course this filter sounds much worse than your resample filter - 
> interpolation I might add later if you want, but that will make it a bit 
> slower (and much nicer too).

What I mean is that 

uint32_t     end16   = (c->len*s->drate/s->srate)>>1;

truncates the length of the output when gcd(len*drate,srate) != srate
This will lead to jitter between the blocks and will cause incorrect
playback speed for the video. It can however be avoided by inserting
an extra sample every now and then. Exactly how to solve this Is an
other problem however...

> > I knew there would be a sample frequency somewhere that would contain a
> > big enough prime number :). Could you check the "up" and "down" numbers
> > (mplayer -v) and post them here.
> mplayer -v says:
> 
> Building audio filter chain for 11127Hz/1ch/8bit -> 44100Hz/2ch/16bit...
> [dummy] Was reinitialized, rate=11127Hz, nch = 1, format = 0x00000008 and bps 
> = 1
> [resample] Changing sample rate to 44100Hz
> [resample] New filter designed up: 14700 down: 3709
> 
> 
> > I really hope you don't mind if we don't make it a separate filter,
> > the reason is that I want it to work with the automatic conversion.
> Not at all.
> 
> 
> Now I have made some tests. There is this 11127->44100 hz video.
> With the original resample audio time is 2.4 s, with the new
> 0.6s  - that's like 1% improvement in cpu utilization.
> Then I tried matrix trailer pocketdivx, 44100->11025 hz .
> With the original resample audio time is ~7.8 s, with the
> new one ~6.8 s - that's like less than 1 % improvement in
> cpu utilization. So it turns out that af_resample is not slow at 
> all actually, that waiting at the beginning is than probably a bug (and in 
> deed, it didn't happen with the matrix pocketdivx).

It is not a bug - it is the side effects of a very accurate feature :)

The problem is that a 14700*16 long FIR filter is designed before
playback starts, this takes time. I will add a -truncate switch to fix
this sometime in the future.

> I hope it is still useable something, but I won't be surprised if it is not ;)
> 
> 
> best regards
> Denes

//Anders