Displaying 3 results from an estimated 3 matches for "mode_cr".
Did you mean:
mode_c
2010 Dec 03
1
memory violation in mode_create() !
?
There seems to be a memory violation when calling celt_mode_create(48000, 240).
?
The function compute_pulse_cache() calls celt_alloc (the second one,
bits=celt_alloc()) in order to allocate 343 byte, but it is using about 872
bytes at that location, which will be deleted by the following allocations.
?
In this case the following encoder call crashes at first...
2010 Dec 03
0
memory violation in mode_create() -- SOLVED.
hi Jean-Marc,
the memory after the allocated space is definitely destroyed. It took me some
time to find out why. I expected local arrays to be allocated on stack, not on
the heap. The function get_required_bits allocates a local array uint32[] which
will be located on heap right after the array fromcompute_pulse_cache(), what
made me think it was written behind its end.
I am sorry for the
2010 Dec 01
1
stack + heap sizes
...c/dec per channel.
But are those sizes really independent of any settings, like frame_size,
bitrate, complexity, etc. ?
?
at least in our configuration I find these requirements:?
?- native stack: < 2.1kB (enc or dec) measured by RealView Profiler
?- heap: (summing up the celt_alloc calls):
???? mode_create: 2430
???? enc_create: 10284
???? dec_create: 17568
?- GLOBAL_STACK_SIZE:
???? not sure! (default = 100k ???)
???? 2k is not enough, 5k is ok.
?
our config:
?- version = 0.9.1
?- ARM9, FIXED_POINT, DOUBLE_PRECISION
?- f<s> = 48kHz
?- frame_size = 240 (p.ch.) (--> 5ms)?
?- rate = 128 kb...