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

[Michael Niedermayer]

Hi

On Wed, May 16, 2007 at 05:10:19PM -0300, Ramiro Ribeiro Polla wrote:
> 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 
> >>> like a fade-out.
> >>>
> >>> 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?

IIRC the only thing needed to do a 320 point FFT is that you write a
5 point FFT (the naive O(n^2) algo will do) and combine that with the
existing 64 point FFT with the correct twiddle factors

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070516/8c79ca00/attachment.pgp>