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

[Ed Wildgoose]

Michael Niedermayer wrote:

>to answer the question, how does libavcodecs resampler perform, i added 
>support for it in that test proggy, see attached diff & output
>i also had to change the rolloff calculation, as it searched for the 3db 
>attenuation during upsampling and libavcodec doesnt have such a large 
>attenuation during upsampling, so it does the test with downsampling now
>
>summary:
>lavc is at least twice as fast as the fastest converter from libsamplerate 
>(the benchmark routine should be replaced with rdtsc to find out by how much 
>exactly, it could be much more)
>the -3db rolloff point of lavc is at 92.70 %, the one from the best converter 
>of libsamplerate is at 96.94 % and the second best is at 90.66 %
>the SN ratio of lavc is 68.05 dB while libsamplerates 3 best converters are 
>around 100 db and the 2 remaining at 10-20, the reason for the lower SN ratio 
>is almost certainly caused by the 16bit in/output used in lavc while 
>libsamplerate uses floats
>
>[...]
>  
>


Hmm, thanks Michael!  This is a very interesting test!  It would have 
been beyond me to whip up such a comparison in such a short time.

Can I just confirm that what you have done is the equivalent of using 
"mplayer -af resample=blah"?  I just want to be sure that I am comparing 
like with like?

If the speed is only off by a factor of two, then this is pretty good 
news for libsamplerate I think, since as you say, it's doing 32bit 
arithmetic to lavcs 16 bit.  As a rough rule of thumb that would seem to 
be quite close (twice the data, half the speed...)

The -3db rolloff point of lavc seems pretty good as well.  However, the 
SN ratio seems pretty poor..  All I can say having only done some quick 
listening tests is that the mplayer high quality resampling doesn't have 
the annoying buzzing sounds, but it does sound a little different, and 
things like human voices are a little bit harder to make out and a 
little muffled.  It's not enough to instantly say that it sounds 
horrible, but there is something just not quite right there?

What are the issues involved with making lavc also offer 32 bit integer 
maths..?  I haven't looked at the code yet, so I don't understand 
whether this is a rewrite, or straightforward...

Off the top of my head I suspect the big issue with films is that they 
generally have pretty large dynamic range.  It's not uncommon to have a 
film sitting at -15db or -20db usually, and thus have some headroom for 
the big effects.  And quiet sequences are frequently down to -40db.  So 
losing dynamic range is probably going to really show up when 
resampling?  (Haven't thought this through completely yet).

So what are my options in order to get some really high quality 
resampling working?  Is the only option to work on lavc?  Are there 
other libraries already in mplayer which could be leveraged?  Is it an 
option to include other stuff in mplayer if it's a compile time option 
(like the way the jack output libraries are)?  For my purposes I have a 
machine which is mostly idle while using mplayer, so doubling the CPU 
requirements are far from being an issue (and be clear that I am no way 
thinking that this should be the normal state for everyone else though!  
I understand that this is strictly an option).

Thanks for any thoughts

Ed W