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

[Michael Niedermayer]

On Sun, Mar 02, 2008 at 02:11:43PM -0500, Justin Ruggles wrote:
> Michael Niedermayer wrote:
> > 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
> 
> http://tinyurl.com/34ud6f

This also doesnt describe how to convert between the 2 efficiently, it just
shows how it can be done, not how it can be done fast. That is doing a
512 IMDCT + windowing + 256 MDCT would be faster than the generic matrix
multiply described.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- 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/33a94253/attachment.pgp>