[FFmpeg-devel] [PATCH] NellyMoser audio decoder

[Aurelien Jacobs]

On Tue, 11 Sep 2007 19:31:45 -0400
Gary Corcoran <gcorcoran at rcn.com> wrote:

> Aurelien Jacobs wrote:
> > On Tue, 11 Sep 2007 18:48:41 -0400
> > Rich Felker <dalias at aerifal.cx> wrote:
> > 
> >> 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.
> > 
> > IMO, a nice solution would be to use runtime generated tables under
> > #ifdef CONFIG_SMALL, and use static tables when not CONFIG_SMALL.
> > 
> >>> 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...
> > 
> > Disks are generally not practical in the embedded world. So better think
> > about flash. And also think about small devices which must be as cheep
> > as possible. There, saving a few KB of flash could be really important.
> > Also, in an embedded application, you most probably don't use more than
> > one encoding/decoding process, and don't use libdl. So you avoid the
> > potential troubles of generated tables.
> > 
> > As always, there is no single best solution. It all depends on the
> > constraints you set.
> 
> Yes, it depends...
> Some embedded systems use cheap, slow flash, and copy all of the executable
> code to RAM for fast (acceptable) execution.  There, if you generate the tables
> at run time, you end up with both the code and the table taking up valuable RAM
> space.  So static tables may be better for CONFIG_SMALL ...

And in this exact same situation, you can imagine ffmpeg was built with 2 codecs
builtin, but than only 1 codec is used at a time. Then only half of the tables
would be generated thus saving memory over static tables.

Once again, it depends :-)

IIRC, CONFIG_SMALL was supposed to be related to object file size, not to memory
usage, but I may be wrong ?

Aurel