[FFmpeg-devel] [PATCH] NellyMoser audio decoder

[Michael Niedermayer]

Hi

On Tue, Sep 11, 2007 at 07:31:45PM -0400, Gary Corcoran 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 ...

anyone wanna add CONFIG_HARDCODED_TABLES

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070912/cf1cf0de/attachment.pgp>