[Ffmpeg-devel] [PATCH][RFC] ac3 decoder

[Michael Niedermayer]

Hi

On Mon, Sep 25, 2006 at 05:55:46PM +0200, Benjamin Larsson wrote:
> Loren Merritt skrev:
> >On Sat, 23 Sep 2006, Michael Niedermayer wrote:
> >>
> >>could you (or someone else) provide
> >>1. a benchmark of it and liba52 (both with mmx/sse optims enabled and
> >>  disabled)
> >>2. lines of code / bytes of both decoder source
> >>3. compiled object sizes (and run strip over both)
> >>4. max and mse difference between liba52 and soc_ac3 output or if
> >>  available against some reference decoder with reference bitstreams
> >
> >versions tested:
> >a52: liba52 as present in ffmpeg svn
> >a52mp: liba52 as present in mplayer svn
> >soc: Kartikey's codec, including the attached patch to enable simd mdct
> >
> >test content: the audio track of The Matrix. AC3 stereo 192kbps 8179sec.
> >cpu: Athlon64 2.2GHz
> >
> >decoding time (mean and stddev of 10 runs):
> >27.448 \pm .012  sse_a52mp
> >28.076 \pm .008  c_a52
> >28.657 \pm .009  sse_soc
> >35.132 \pm .015  c_a52mp
> >36.748 \pm .006  c_soc
> >
> Those numbers look quite ok to me. Hopefully we can speed it up some 
> more with some optimizations from the aften ac3 encoder and maybe a 
> faster imdct routine.
> >
> >bytes
> >22432  ac3_decoder.o
> I think there are some tables that the decoder takes from the ac3 parser 
> in ffmpeg, it would add a few more bytes.
> >51064  a52dec.o liba52/*.o
> >94672  a52dec.o liba52mp/*.o
> >
> >pairwise differences:
> >psnr:101.06 mse:    0.34 max:   91  c_a52.wav   c_a52mp.wav
> >psnr: 78.63 mse:   58.85 max: 6647  c_a52.wav   sse_a52mp.wav
> >psnr: 78.66 mse:   58.52 max: 6647  c_a52mp.wav sse_a52mp.wav
> >psnr: 53.16 mse:20758.59 max:26788  c_soc.wav   c_a52.wav
> >psnr: 53.16 mse:20750.29 max:26788  c_soc.wav   c_a52mp.wav
> >psnr: 53.16 mse:20745.67 max:26788  c_soc.wav   sse_a52mp.wav
> >psnr:   inf mse:    0.00 max:    0  c_soc.wav   sse_soc.wav
> >
> >--Loren Merritt
> >
> My suggestion is to commit the new decoder and keeping liba52 as they 

can you post a patch to the mailinglist instead of instuctions to create one
(the instructions might not generate the same patch in the future thus
having it "archived" in the list is a good idea, i also dont like to
comment/accept/reject "external" patches as by the time someone applies
it it might no longer be what has been reviewed and accepted ...)

[...]
-- 
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