[FFmpeg-devel] [PATCH] RDFT for Bink and QDM2

[Alex Converse]

On Tue, Jan 20, 2009 at 1:50 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Tue, Jan 20, 2009 at 12:24:06PM -0500, Alex Converse wrote:
>> On Tue, Jan 20, 2009 at 11:52 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > On Mon, Jan 19, 2009 at 07:44:38PM -0500, Alex Converse wrote:
> [...]
>> >
>> > [...]
>> >
>> >> +/**
>> >> + * Sets up a real FFT.
>> >> + * @param nbits           Log2 of the length of the input array
>> >
>> >> + * @param inverse         If TRUE, perform the inverse of the transform
>> >
>> > i suggest if 0 perform the forward transform, if 1 perform the inverse
>>
>> I believe these are equivalent.
>
> I searched for TRUE in the iso C standard and found no match.
> But lets assume it where defined as 1, this doesnt document any
> other value, is inverse=2 or 0 invalid? the forward transform?
> 99% of the people will guess correct but why write something ambigous if
> it can be written unambigous ...
>
>
>>
>> >
>> >
>> >> + * @param sign_convention The sign of j of the forward FFT.
>> >
>> > i do not understand this, j is a variable that has no clear relation to a FFT
>> >
>>
>> j is the unit vector in the vertical direction on the complex plane. j
>> = sqrt(-1).
>
> wasnt that i, i for imaginary?
>
>
>>
>> The forward DFT can be defined as:
>> X_k = \sum_{n=0}^{N-1} x_n e^{-{2\pi j \over N} nk }
>>
>> It also can be defined as
>> X_k = \sum_{n=0}^{N-1} x_n e^{{2\pi j \over N} nk }
>
> you can, but why would we need it?
>

Bink uses it. As per the comments, the inverse of this transform is
not simply the transform with the opposite sign convention.

--Alex