similar to: CELT_ALLOC_FAIL

Hi Jean-Marc, I was just wondering if maybe you would consider a "blog-like" text file in the codebase where you just jot down your thoughts about why you are making a change, and where you think you are headed. For example, I noticed today that you completely removed the pitch prediction code. It would be nice to know if you did that because you're moving away from using it as

Congrats to the team for 0.10.0. It sounds really good in the tests I've done so far. I'm really looking forward to the 1.0 release. One question though: could you explain briefly the difference between VBR and unconstrained VBR? And, in my case, the $64K question: is there any situation where CELT could produce more data than specified by nbCompressedBytes when encoding? Thanks

Hi Jean-Marc, I could be way off base here, but it seems to me that line 115 in pitch.c in the function "pitch_downsample": x_lp[i] = SHR32(HALF32(HALF32(x[1][(2*i-1)]+x[1][(2*i+1)])+x[1][2*i]), SIG_SHIFT+2); should actually be: x_lp[i] += SHR32(HALF32(HALF32(x[1][(2*i-1)]+x[1][(2*i+1)])+x[1][2*i]), SIG_SHIFT+2); Sorry if I'm totally misreading things and just

Hi Jean-Marc, I'd just like to put in a vote that I wish you'd left in the high-complexity mode in CELT (with the assumption that it could be conditionally compiled out for the IETF standard codec). It seems like it makes it a more useful standalone codec in Xiph's arsenal, and from my own viewpoint I'm uncertain I'll be able to use the SILK codec because of the patent

Thanks, I look forward to seeing what you find out. BTW, I was wondering if you tried replacing the SIG2WORD16 macro using the vqmovns_s32 intrinsic? I'm sure it would be faster than the C code, but in the grand scheme of things it might not make much difference. On 11/13/2015 12:15 PM, Jonathan Lennox wrote: >> On Nov 13, 2015, at 1:51 PM, John Ridges <jridges at masque.com>

Hi JM, When porting my project to the Mac, I found that the definition for "celt_int16" and "celt_uint16" are wrong for the MacOS X Framework in celt_types.h, and need to be changed to "int16_t" and "u_int16_t" respectively. Just thought you ought to know. John Ridges

Hi Jean-Marc, I've been compiling CELT for 64-bit Windows and it all seems to work fine (with the occasional benign warning message) except for one place, and that is in "float_cast.h" where there is some inline assembly language that gets complied for Windows. Since the Microsoft 64-bit compiler won't allow inline assembly language (and *still* doesn't have

I?ve tried adding support for OPUS_FAST_INT64 to celt/arch.h, and I?ve found that this is indeed comparable in speed, if not a touch faster, than my inline assembly. I?ll submit patches for this. The inline assembly parts of my aarch64 patch set can thus be considered withdrawn. I haven?t yet tried replacing SIG2WORD16 (or silk_ADD_SAT32/silk_SUB_SAT32) with Neon intrinsics. That?s an obvious

I too would like to know the status of the opus IP holders. From what I've seen on the CELT and opus lists, it seems that the CELT part of opus is covered by patents from Xiph and Broadcom, and the SILK part of opus is covered by the rest. All of the IP holders except Qualcomm and Huawei have released their patents to the public as far as opus is concerned, and the general consensus from

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

Since you're already set up for benchmarks, I would ask if you could benchmark the difference between using and not using the ARM64 inline assembly. I believe the original justification on ARMv7 for the assembly was the processor's panoply of multiply instructions and their long cycle times. It seems to me that the ARM64 processor is much more like an x86 one, where using a

We were trying to normalize bands that didn't actually exist (e.g., the last band with 320-sample frames at 32kHz). Thanks to John Ridges for the report. --- libcelt/celt.c | 24 +++++++++++++++++------- 1 files changed, 17 insertions(+), 7 deletions(-) diff --git a/libcelt/celt.c b/libcelt/celt.c index 31d35f8..287c720 100644 --- a/libcelt/celt.c +++ b/libcelt/celt.c @@ -1137,6 +1137,7

Hi Jonathan, I'm sorry to bring this up again, and I don't want to beat a dead horse, but I was very surprised by your benchmarks so I took a little closer look. I think what's happening is that it's a little unfair to compare the ARM64 inline assembly to the C code, because looking at the C macros in "fixed_generic.h" for MULT16_32_Q16 and MULT16_32_Q15 you find

I got the approximation from a Google book: http://books.google.com/books?id=2CAqsF-RebgC&pg=PA385 Page 392, formula (10.33) Using this formula, you're right, hypergeom_gain() would *not* converge to 1 for large x, but would instead be gamma(1.25)/sqrt(sqrt(x)) which would approach zero. Now if the formula for the hypergeometric gain were instead gamma(1.5) * M(-.5;1;-x) / sqrt(x)

Speex tells me that the decoder is always 5 ms, but it says that the encoder is 5 ms for NB, 8.9375 ms for WB, and 10.90625 ms for UWB. Is there an extra frame of delay in the encoder that isn't otherwise accounted for? John Ridges Jean-Marc Valin wrote: > Quoting John Ridges <jridges at masque.com>: > >> I also need to know the precise delays from Speex but I used

By my reckoning the confluent hypergoemetric functions should have the following values: M(-.25;1;-.5) = 1.11433 M(-.25;1;-1) = 1.21088 M(-.25;1;-1.5) = 1.29385 M(-.25;1;-2) = 1.36627 M(-.25;1;-2.5) = 1.43038 M(-.25;1;-3) = 1.48784 M(-.25;1;-3.5) = 1.53988 M(-.25;1;-4) = 1.58747 M(-.25;1;-4.5) = 1.63134 M(-.25;1;-5) = 1.67206 M(-.25;1;-5.5) = 1.71009 M(-.25;1;-6) = 1.74579 M(-.25;1;-6.5) =

Hi Jean-Marc, I hate to nitpick, but perhaps "logN" should be freed somewhere in celt_mode_destroy. Cheers, John Ridges

> On Nov 19, 2015, at 5:47 PM, John Ridges <jridges at masque.com> wrote: > > Any speedup from the intrinsics may just be swamped by the rest of the encode/decode process. But I think you really want SIG2WORD16 to be (vqmovns_s32(PSHR32((x), SIG_SHIFT))) Yes, you?re right. I forgot to run the vectors under qemu with my previous version (oh, the embarrassment!) Fixed forthcoming

Hi Jean-Marc, As the self-appointed keeper of CELT_RESET_STATE (since I may be the only one actually using it) I've been kind of lax lately and have only now tried to reconcile it with the state structures in the 0.7.1 drop. I think (and feel free to contradict me here) that the following lines should be added to CELT_RESET_STATE in celt_encoder_ctl: st->fold_decision = 1;

Fixed definition of SIG2WORD16, thanks to John Ridges. --- celt/arch.h | 4 +++- celt/arm/fixed_arm64.h | 35 +++++++++++++++++++++++++++++++++++ celt_headers.mk | 1 + 3 files changed, 39 insertions(+), 1 deletion(-) create mode 100644 celt/arm/fixed_arm64.h diff --git a/celt/arch.h b/celt/arch.h index 670527b..9a06359 100644 --- a/celt/arch.h +++ b/celt/arch.h @@ -123,7