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

Rich Felker dalias
Sun Mar 9 19:06:47 CET 2008


On Sun, Mar 09, 2008 at 01:28:54PM -0400, Justin Ruggles wrote:
> Rich Felker wrote:
> > On Sun, Mar 09, 2008 at 05:18:18PM +0000, M?ns Rullg?rd wrote:
> >> Justin Ruggles <justinruggles at bellsouth.net> writes:
> >>
> >>> jbr wrote:
> >>>> Author: jbr
> >>>> Date: Sun Mar  9 18:05:19 2008
> >>>> New Revision: 12397
> >>>>
> >>>> Log:
> >>>> downmix before imdct unless different size transforms are used. about 20%
> >>>> faster 5.1-to-stereo downmixing.
> >>> But still about 13% slower than liba52.  I don't think it will ever be
> >>> able to match liba52's speed in downmixing, but at least it's much
> >>> closer now.
> >> Why can't it be as fast as liba52?
> > 
> > I don't understand what's meant by "delay samples", but upmixing them
> > then downmixing them again sounds incredibly misguided. I suspect
> > linearity makes it totally useless to do these two steps.
> 
> It is necessary because 256 samples from the previous block are combined
> with 256 samples from the current block.  The channel information has to
> be the same.  So if the previous block was downmixed before IMDCT, but
> the current block will be downmixed after IMDCT, you have to upmix the
> previous 256 samples in order to combine with all channels for the
> current block.  Then you have the same thing in reverse when you go back
> to downmixing before IMDCT.  liba52 does the same thing.

Unless AC3 does something really odd and contrary to what the usual
math would be, which I have not seen any evidence of, this should be a
simple matter.

My understanding of what you're doing now when the current frame
cannot be downmixed prior to IMDCT:

coefficients -> IMDCT -> mix with upsampled previous frame -> downmix

It works just as well do to:

coefficients -> IMDCT -> downmix -> mix with previous frame

Or do you have a good argument why this is not possible?

Rich




More information about the ffmpeg-cvslog mailing list