[MPlayer-dev-eng] [PATCH] fix for -srate bug

[D Richard Felker III]

On Tue, Oct 19, 2004 at 05:39:04PM +0100, Ed Wildgoose wrote:
> 
> >WTF are you thinking? you need at least 20x realtime to even CONSIDER
> >using a resampler in a movie player, because the vast majority of cpu
> >time is needed for the VIDEO!!!
> > 
> >
> 
> Please be gentle... 
> 
> I am not quite sure I follow your logic here?  If the darn things plays 
> video and can keep up then personally I'm not fussed whether it has 1% 
> safety margin or 95% safety margin?  I dont see that I need that much 
> CPU for video to be honest though?  Switching on the software scaler 
> with bilinear resizing and normal audio output is about 15% CPU on my 
> P2.8.  With the resampler on and 6 channel audio it's about 60%.  Both 
> of these are acceptable (to me).
> 
> I could switch off the software scaler and be using a lot less cpu than 
> 15% for example if it was a problem. (XV resizing or similar).

you insist on quality, yet you're not using overlay?!?
i hope you know that all of the non-overlay vo drivers do not sync to
vblank, so you'll get horrible tearing. that's a much worse offense
than slight distortion in resampling, in fact it makes things
unwatchable...

> At the moment I have added the "-av-adv=1" flag which based on the 
> previous discussion is the same as the "-af resample" flag (and CPU 
> requirements seem to be similar, ie high).

hmm? -af-adv force=1 ?

> The CPU requirements seem unusually low in your case, but perhaps this 
> is because of the integer optimisation?  For comparison, Brutefir 

well i also said my case is 2-channel only.

> implementing some low order crossovers on my P2.8 machine needs about 
> 10% CPU (and these are very short filters, 1500 samples or 
> thereabouts.)  Not directly comparable I know.

if you use really long filters then it will be slow, _and_ i expect
you'll generate (pre- and post-) echo artifacts. this is just based on
very naive mathematical intuition, so it's possible that more advanced
filters have some workaround.

> OK, well steady on there.  I didn't write libsamplerate, and it's only 
> popular with me because I have tested it's audio performance and found 
> it indistinguishable from the original.  It's CPU requirements seemed 
> similar to those of the mplayer resampler that I was trying.

well the resampler in mplayer is totally unoptimized... but i never
recall having any high cpu usage when using it. i just force linint
instead because of some extreme borderline cases where i need every
cycle i can get.

rich