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

[Justin Ruggles]

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