[FFmpeg-devel] [PATCH] NellyMoser audio decoder

[Rich Felker]

On Tue, Sep 11, 2007 at 08:34:56PM +0200, Reimar D?ffinger wrote:
> Hello,
> On Tue, Sep 11, 2007 at 01:32:24PM -0400, Rich Felker wrote:
> > On Tue, Sep 11, 2007 at 02:13:36PM +0200, Reimar D?ffinger wrote:
> [...]
> > > yes, forget that part. Happens when you don't take your time...
> > > Btw. would others prefer int16_t instead of short as well? I like it
> > > better and I think it is more consistent with other ffmpeg code.
> > > In addition it might be worth to check if those tables are better created
> > > at runtime...
> > 
> > Runtime creation of tables is bad. If we could get rid of all the
> > runtime tables it would be a big step forward for anti-bloat,
> > simplicity, and preventing memleak issues in corner cases. (The other
> > approaches aside from including tables directly in the source cause
> > additional memory usage per-process and possibly memory leaks with
> > libdl loading.)
> 
> While I am aware of the problems with it, to me ffmpeg is not just a
> decoding library but also a project that should help people to learn not
> understand things.
> And in that respect, a runtime generated table is orders of magnitude
> better than a table dumped into a source without documentation and even
> confusing names (of course, the better solution is to just properly document
> them and also give the formula/algorithm to regenerate them).
> It is also worse for verifying correctness (would not be the first time
> there if there is a typo in one of them).

Then include the code to generate the table in a comment or
supplemental file, and generate the table from that. You could even
run the tablegen code from the Makefile if it makes you happy, but IMO
that's bad because it requires a targetcc/hostcc distinction for cross
compiling.

> Static tables also bloat the binary - while not such an important thing,
> it is not irrelevant.

Bloating memory is orders of magnitude worse. 250 GB of disk costs the
same as 2-4 GB of ram...

Rich