Displaying 3 results from an estimated 3 matches for "vbr_rate".
2010 Dec 03
1
memory violation in mode_create() !
...r the folling loop, which is
populating the allocated memory.?
?The other allocations seem ok.
thanks a lot,
Marko.
?
?
our config:
?- version = 0.9.1
?- ARM9, FIXED_POINT, DOUBLE_PRECISION, VAR_ARRAYS
?- f<s> = 48kHz
?- frame_size = 240 (p.ch.) (--> 5ms)?
?- rate = 128 kbit/s (stereo)
?- vbr_rate = 0
?- prediction = 2
?- complexity = 10 ?
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/opus/attachments/20101203/7085b16a/attachment-0002.htm
2011 Mar 01
1
Possible bug in CELT's VBR code
Hi guys,
It looks to me like line 955 in celt.c should be:
effectiveBytes = vbr_rate>>(3+BITRES);
otherwise it seems like "effectiveBytes" is 8 times larger than it
should be (at least if it's really meant to be bytes).
Cheers,
John Ridges
2010 Dec 01
1
stack + heap sizes
...nc_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 kbit/s (stereo)
?- vbr_rate = 0
?- prediction = 2
?- complexity = 10
?
Why do we need additionally a GLOBAL_STACK_SIZE ?
Could these allocations also be redirected to a common method, like celt_alloc()
?
It is not really clear to me what is the idea behind the switches VAR_ARRAYS,
USE_ALLOCA, GLOBAL_STACK_SIZE and how much R...