[CELT-dev] CELT grabbing 100KB of memory right off the top

[Timothy B. Terriberry]

> I suspect this is going to provoke a religious war, but please put
> braces around single statement "if", "for", etc.  I had two particularly
> hard to find bugs because I rearranged stuff in celtenc.c and the indent
> looked okay.

Complain to Jean-Marc. I never do this when following my own coding style.

> Is there a good reason why I'm not getting a factor of 2 improvement
> from using 24KHz instead of 48KHz?  How about the drop from 128kbps to
> 64kbps?  Framesize?

Bitrate has an effect, but I don't think it's a linear one. There's less 
splitting, which saves some overhead and means fewer range coder symbols 
have to be decoded, and means less work for PVQ (though for small N we 
have O(Nlog K) special cases, instead of the low-memory O(NK) algorithm 
needed for large N, so how much less is not clear). But there's also 
more work to do for folding to make up for the bits of spectrum that 
weren't coded. The latter doesn't hurt as much as it might, though, 
since libcelt currently does a lot of work for folding whether it 
ultimately needs to or not.

Frame size also has an effect, but it's not even clear to me which 
direction it would go in. The frames are larger but there's less of 
them. The MDCT and PVQ (at least as implemented) are superlinear, so 
they'll get slower by some amount, but there's a lot of per-frame 
overhead (e.g., energy coding, bit allocation, looping overheads, etc.) 
that is cut in half every time you double the frame size, simply because 
it runs half as often.

Jean-Marc already said everything else I was going to say, so I'll skip 
the rest.