[FFmpeg-cvslog] r12284 - trunk/libavcodec/ac3dec.c

[Michael Niedermayer]

On Sun, Mar 02, 2008 at 12:40:01PM -0500, Justin Ruggles wrote:
> Rich Felker wrote:
> > On Sat, Mar 01, 2008 at 07:30:13PM -0500, Justin Ruggles wrote:
> >> Rich Felker wrote:
> >>> On Sat, Mar 01, 2008 at 09:30:11AM -0500, Justin Ruggles wrote:
> >>>> So obviously the biggest area for improvement is in the downmixing.
> >>>> Today, I am planning on trying to move the conversion to int16 to before
> >>>> downmixing and doing the downmix in fixed-point.  I'm not sure if it
> >>>> will be faster though until I test it out.
> >>> Does the downmix take place before or after IMDCT? It should take
> >>> place before so that the unnecessary DCT steps are skipped.
> >> The downmix is currently after the IMDCT.  The problem with downmixing
> >> before the IMDCT is that it only works if all channels within the block
> >> use the same transform length.  There are ways to convert between the
> >> 512-point and 256-point coefficients, but I have not delved into the
> >> math on this.
> > 
> > Well it's definitely worthwhile. Performance without pre-IMDCT downmix
> > will always be significantly worse than with pre-IMDCT downmix,
> > regardless of what other optimizations you do.
> > 
> >> Another solution could be to check if all the block switch flags are the
> >> same for all channels, and order the downmix and IMDCT accordingly.
> >> I'll try it.
> > 
> > This is a cheap solution for the time being, but really, aside from
> > scaling issues, the transformation between 256- and 512-point should
> > just involve appending a lot of zero coefficients. AFAIK MPlayer's
> > liba52 does the pre-IMDCT downmix and I don't see any reason why it
> > should be difficult.
> 
> The 2 transforms are actually not the same, so you can't just append
> zeros.  I have a couple papers that show how to convert from one to the
> other, but the math is above me knowing exactly what is going on without
> putting some serious time into it.  I do want to eventually though.
> 
> I had a look at MPlayer's liba52 code and it seems to be doing the other
> solution of checking the block switch flags and then ordering the
> downmix and MDCT accordingly.  So I'll try that as a temporary solution
> until I can figure out the math (or if someone with a bit stronger
> mathematics background wants to try, these are the 2 papers...)
> 
> Szu-Wei Lee and Chi-Min Liu: "Transformation from 512-point transform
> coefficients to 256-point transform coefficients for Dolby AC-3
> decoder". Electronics Letters, 1999, Vol. 35, pp. 1614-1615

i havnt found this one yet


> 
> Chi-Min Liu , Szu-Wel Lee, and Wen-Chieh Lee: "Efficient Downmixing
> Methods for Dolby AC-3 Decoders". 1997

>From a brief look this doesnt look like it contains anything usefull
the author just says its fastest to do before the imdct in the sense
of doing both long and short imdcts when needed for channels. That is
he says downmix only channels with matching imdct before the imdct and
do the remaining downmixing afterwards. And
the second thing is that he describes a fast _approximation_ aka
something we cannot use.
Though that is based on reading the text, not the equations.


> 
> Both papers are on CiteSeer <http://citeseer.ist.psu.edu/>
> I would give direct links, but the site is currently down for maintenance.

citeseer rules, its one of the few paper sources which isnt run by
captitalistic criminals :)

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20080302/8ac8cc4f/attachment.pgp>