[Ffmpeg-devel] mpegaudiodec.c and armv5te optimizations

[Michael Niedermayer]

Hi

On Sun, Oct 08, 2006 at 08:03:24PM +0300, Siarhei Siamashka wrote:
> On Thursday 05 October 2006 11:22, Michael Niedermayer wrote:
> 
> > > > 17% of the difference between libmad and ffmp3 isnt that small
> > > > if you do another 5 such optimizations we would beat libmad
> > > >
> > > > > but lose some
> > > > > precision.
> > > >
> > > > yes, but its not much, worst case +-4 difference
> > > > btw, could you test by how much the high-low quality difference changes
> > > > with this optimization (mean squared error and max difference), if it
> > > > doesnt double the error then iam in favor of applying this patch
> > >
> > > That +-4 difference was just a quick and completely nonscientific
> > > observation of cmp output. To get valid test results of this quality
> > > reduction, surely proper tests are requred. Just got an idea, I did
> > > benchmark a fast low quality build of libmad, it is interesting to check
> > > not only performance but also quality for libmad as well. It may be that
> > > ffmpeg decoder  is somewhat slower, but has higher quality and that
> > > could explain the results, so that could be considered a win already :-)
> > >
> > > But I have a few questions:
> > > 1. are there any tools that can be used for such tests? could they
> > > be 'audiogen.c' and 'tiny_psnr.c' from tests subdirectory in ffmpeg? if
> > > ffmpeg has some tools for audio quality regression testing, it would be
> > > stupid not to use them and invent something new :)
> >
> > tiny_psnr fileA fileB 2 [<shift>]
> > should do a silly raw 16bit compare (tiny_psnr doesnt know about headers so
> > either use raw audio or there will be a tiny error from the few bytes of
> > the wav header
> > also different decoders might have a slightly different delay, thats what
> > the shift value is for ...
> 
> Well, here are the results of decoding precision tests for the collection of
> samples you adviced: http://www.rarewares.org/test_samples/
> 
> Each file was compressed with lame 3.96.1 to mp3 
> ('lame -b bitrate infile.wav outfile.mp3') and then decompressed also with
> lame. This lame decoded sample was used as a reference in all these
> tests.
> 
> Decoders were tested using mplayer :
> # mplayer -ao pcm:file=somefile.wav -ac decodername filename.mp3
> 
> wav header was skipped (otherwise max difference does not make any sense)
> 
> stddev - standard deviation as reported by tiny_psnr, maxdiff - maximum 
> absolute difference between sample values from reference and decoded files.
> 
> Decoder names 'mp3' and 'mad' don't need any explanations.
> 
> 'ffmp3 hq' - ffmp3 compiled in high quality mode
> 
> 'ffmp3 lq' - ffmp3 compiled in low quality mode
> 
> 'ffmp3 hq+mulh16' - ffmp3 compiled in high quality mode but also with MULH 
> shift changed to 16
> 
> 'ffmp3 lq+mulh16' - ffmp3 compiled in low quality mode and MULH shift changed
> to 16
> 
> Overall, looks like using 16-bit shift in MULH/FIXHR has a lower impact on
> precision than the current low precision mode. In addition precision loss is

ok, so iam fine with the 16bit MULH change for the LQ mode


> quite consistent while current low precision mode seems to degrade quality 
> a lot sometimes (see 'DaFunk' sample), maybe it could be some overflow bug 
> in the decoder?

possible, maybe the following is causing it?

#if FRAC_BITS <= 15
        /* NOTE: can cause a loss in precision if very high amplitude
           sound */
        if (v > 32767)
            v = 32767;
        else if (v < -32768)
            v = -32768;
#endif

one way to test this is to scale the data down by 2 before and upscale by 2
after it or just change the variables to something large enough to avoid the
problem ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is