[CELT-dev] CELT grabbing 100KB of memory right off the top
Timothy B. Terriberry
tterribe at xiph.org
Mon Apr 18 18:07:29 PDT 2011
> 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
More information about the celt-dev