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

[Justin Ruggles]

Michael Niedermayer wrote:
> 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.

Thanks for deciphering it. :)  It would have taken me much longer to
figure out that it would be a waste of time trying to code a solution
using this method.

-Justin