[Ffmpeg-devel] mpegaudiodec.c and armv5te optimizations

[Michael Niedermayer]

Hi

On Thu, Oct 05, 2006 at 08:01:10AM +0300, Siarhei Siamashka wrote:
> On Wednesday 04 October 2006 11:05, Michael Niedermayer wrote:
> 
> [...]
> 
> > > > > I would like to ask those who are familiar with mp3 decoding
> > > > > algorithm in mpegaudiodec.c better if there could be any really nasty
> > > > > things happening after changing current
> > > > >
> > > > > #define MULH(a,b) (((int64_t)(a) * (int64_t)(b))>>32)
> > > > > #define FIXHR(a) ((int)((a) * (1LL<<32) + 0.5))
> > > > >
> > > > > to something like
> > > > >
> > > > > #define MULH(a,b) (((int64_t)(a) * (int16_t)(b))>>16)
> > > > > #define FIXHR(a) ((int16_t)((a) * (1LL<<16) + 0.5))
> > > > >
> > > > > in low quality decoding mode.
> 
> [test results of a simple inline asm patch skipped]
> 
> > > Effect is minimal and quite disappointing. We gain very little,
> >
> > 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 ...


> 2. what audio file samples to use (for example testing on a file with a
> complete silence encoded would be stupid)? probably sound volume can
> probably also have some effect on decoding precision.

google with aac and vorbis first link and some mouse clicks lead me to
http://www.rarewares.org/test_samples/


> 3. what to use as a reference mp3 decoder which is supposed to have ideal
> quality? or maybe just grab some audio CD, encode it (with something?) to
> different bitrates, decode it with different mp3 decoders and compare results
> against original CD file and not against a reference decoder?

yes


[...]

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