[FFmpeg-devel] [PATCH] NellyMoser audio decoder

[Gary Corcoran]

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 ...

Gary