# [FFmpeg-devel] (i)(m)dct help for g.722.1

Ramiro Ribeiro Polla ramiro
Wed May 16 22:10:19 CEST 2007

Ramiro Ribeiro Polla wrote:
> Hello,
>
> Justin Ruggles wrote:
>
>> Ramiro Ribeiro Polla wrote:
>>
>>
>>> Hello,
>>>
>>> When I got to the dct part of g.722.1 (which is currently in
>>> cook.c:687), I realized it doesn't use the same transform as cook (at
>>> least I think so). After the window, overlap, and add, the output is
>>> faster than it should be, making the last half of the 320 samples look
>>>
>>> I wanted to know if FFmpeg already has the same transform used in
>>> g.722.1, or if I'm just using it the wrong way.
>>>
>>> The standard says it's a "type IV DCT":
>>> u(n) = \sum_{m=0}^{319} \sqrt{\frac{2}{320}} cos( \frac{\pi}{320}
>>> (m+0.5)(n+0.5) ) mlt(m)
>>> for 0 \leq n \leq 319
>>>
>>> Or else, how would I go about implementing it?
>>>
>>>
>> I suspect Benjamin's advice is correct, but in case not, here is an
>> example of how a type iv dct is related to a standard mdct.  See the
>> mdct_512() function (and ignore mdct_256() which is an AC-3 oddity).
>> Also, this example is for the forward transform, but the same concept
>> applies to the inverse.
>>
>> http://aften.svn.sourceforge.net/viewvc/*checkout*/aften/libaften/mdct.c?revision=98
>>
>>
>>
>
> Thanks for the tips. I tried what Benjamin suggested, and it seems the
> problem is because g.722.1 uses 320 samples, and the mdcts in FFmpeg
> work only with powers of 2. Cook uses powers of 2. Vorbis also supports
> only powers of 2.
>
> Any thoughts on a solution besides implementing my own dct? Can the mdct
> and fft functions be modified to accept any number of samples?
>
>
Ok, after reading more on the subject, it seems I'd have to implement
another fft algorithm.

Questions to the math gurus:
What's the best alternative FFT algorithm in terms of speed and accuracy
that supports arbitraty sizes?
Is there a way to use the current code with some additional math
(convolution, re-sampling) and produce accurate results?

Ramiro Polla