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

[Justin Ruggles]

Rich Felker wrote:
> 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?

Hmm.  That does seem possible.  The IMDCT function would have to be
reworked a bit since right now transformed output is saved to a temp
buffer which holds only one channel of output, which is then windowed
and combined with samples from the previous block.  Changing it as per
your suggestion would definitely make things faster when switching.  My
guess is that the handful of times this happens for typical audio won't
make a huge difference, but it's worth a try, if only for simplicity.

Thanks,
Justin