[Ffmpeg-devel] [PATCH] faad decoding error return
Benjamin Larsson
banan
Wed Mar 8 10:14:13 CET 2006
Hi,
Mike Melanson wrote:
> [...]
> That's a good start. That would obviate the need for iq_table.h
> (~250 KB). Other obvious tables:
>
> * sine_win.h (~150 KB) which is a bunch of sin() values
> * cfft_tab.h (~117 KB) has a bunch of complex constants for FFT (cos()
> and sin() values)
> * ic_predict.h (~15 KB) has a table of inverse exponent (right term?)
> values (1/2, 1/4, 1/8, etc.), as well as another table I am not sure
> of (named mnt_table, 128 values descending from .953 -> .479)
> * kbd_win.h (~85 KB) has tables named kbd wich run from 0.0 -> 1.0;
> what does kbd mean?
Keiser Bessel Derived. A mdct window.
> * sbr_noise.h (~37 KB) comes from the official spec but must be based
> off of some known random function with a known seed
> * sbr_qmf_c.h (~22 KB) contains a qmf array-- does anyone know what
> that means?
qmf - Quadrature Mirror Filter.
> * ssr_win.h (~14 KB) more sine and kbd (?) tables
>
> Wondering why the author(s) chose to transport these tables, I can
> only assume they were targeting platforms that had no floating point
> units and did not even have the support libraries to emulate the
> functions in software. Or perhaps on platforms with flawed FP
> functionality. I think FFmpeg at least assumes that sin() and cos()
> will be available. And we traditionally have been apathetic toward
> platforms deemed "broken". So it shouldn't be a problem if we want to
> generate the tables at runtime.
Tables are always faster then sin or cos. But there they could have
generated them at runtime.
>
> Then there are the Huffman tables. There is no getting around
> having to transport those. However, the FAAD source uses some
> roundabout process for decoding them (or perhaps just codifies a
> double cascaded Huffman table; I am still working through the
> details). I wonder if we can unify the tables and let FFmpeg's
> internal Huffman facilities worry about the heavy lifting?
>
> These are just some things I have been investigating. I wanted to
> let people know that the AAC task might actually be manageable. :)
>
MvH
Benjamin Larsson
--
"incorrect information" is an oxymoron. Information is, by definition, factual, correct.
More information about the ffmpeg-devel
mailing list