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

[Ed Wildgoose]

>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).


>>Do you have any benchmarks of the performance of the highest quality 
>>encoder in mplayer on your 500Mhz machine?  It would be interesting to 
>>    
>>
>
>yes i do on mine. iirc, it's around 1-2% cpu (i.e. 50-100x realtime).
>  
>

OK, well that's a lot faster than I would have expected...  Can you 
describe to the stupid end user here how I can setup my mplayer to 
decode mpeg2 with 6 channel audio using this resampler so that I can try 
it please?

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).

The CPU requirements seem unusually low in your case, but perhaps this 
is because of the integer optimisation?  For comparison, Brutefir 
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.


>libsamplerate is bloated, poor code. the resampler in lavc is much
>faster and can do the same stuff and probably more than your precious
>libsamplerate. can we please let this rest? dependencies on new poorly
>written libs are not welcome in mplayer.
>  
>

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.

This may well be user error, so please just work with me to try your 
suggested alternatives.  I don't think I am being quite so stupid as you 
are implying since this whole thread started out over a misunderstanding 
on how to engage the high quality resampler code?  I would be extremely 
happy to find that I don't have to do any coding, and I'm sure the 
original poster would be happy to discover a much faster AND better 
resampler was available.

Basically, grateful for your guidance on how to set this up.  I'm afraid 
that your clues so far are not enough for me to know exactly what needs 
doing here in order to get a test setup going.

Thanks

Ed W