Fixes test_opus_projection failure under ubsan, due to clz(0).

NaNs should be filtered at the Opus layer, so if there are any in the CELT
encoder, then it's likely something went horribly wrong (e.g. corrupted state).
In that case, better abort than have something bad happen.

Enables "safes" assertions even with ENABLE_ASSERTIONS isn't set

Reported by daddesio in #opus

This improves cases where a whole region is dominated by a handful of tones

Also adds the error terms for band 0 that were previously omitted

That corresponds to the fundamental for the shortest pitch period allowed

Roman Kalashnikov authored 7 years ago and Ralph Giles committed 7 years ago

Fixes a warning from PVS-Studio. This was a cut-and-paste error
from the stanza above and had no effect.

Signed-off-by: Ralph Giles <giles@thaumas.net>

Addresses issue https://github.com/xiph/opus/issues/54

Addresses issue https://github.com/xiph/opus/issues/58

Reported in https://github.com/xiph/opus/issues/55

The regression was introduced in 783ad767
by changes to celt_fir() that make it no longer in-place.

Based on two dense layers with a GRU layer in the middle

Make these consistent with the other optimization file
sets which use a suffix to indicate the extension they
use.

Signed-off-by: Jonathan Lennox <jonathan@vidyo.com>

Distinguish source files for the SSE 4.1 instruction
set extension consistently by their filename. This makes
it easier to check the correct flags are being set at
build time.

Signed-off-by: Jonathan Lennox <jonathan@vidyo.com>

Ray Essick authored 7 years ago and Felicia Lim committed 7 years ago

some SSE optimizations were using an instruction sequence that required
128-bit alignment, even though this is not always guaranteed. The error
was in handling a 64-bit entity; made the same macro changes that had
been done previously for 32-bit entities.

Signed-off-by: Felicia Lim <flim@google.com>

Linfeng Zhang authored 7 years ago and Jean-Marc Valin committed 7 years ago

This bug is introduced in commit 85fb8a1d.

Change-Id: I3822cdfc1308ca62ce03da008260de8f4b04596c

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Linfeng Zhang authored 8 years ago and Jean-Marc Valin committed 7 years ago

Call celt_inner_prod_neon() and remove redundant code.

Change-Id: I980e94330ae75c10297b9035fac221515aee144f

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Linfeng Zhang authored 8 years ago and Jean-Marc Valin committed 7 years ago

The floating-point optimizations are not bit exact with C functions,
because of the different orders of floating-point operations.
But they are bit exact with the simulation C functions which simulate
the floating operations in the optimizations.

Change-Id: I149fda5b602fd5712b16fc8983df3c6c0c9e76ad

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Linfeng Zhang authored 8 years ago and Jean-Marc Valin committed 7 years ago

This optimization is bit exact with C functions.

Change-Id: Ia9ce6dd3c20d2f56dbd43ddc02d1a6fd6554608d

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Linfeng Zhang authored 8 years ago and Jean-Marc Valin committed 7 years ago

Should call celt_inner_prod().
This requires the API change of celt_pitch_xcorr() by passing in
"arch".

We tested on x86 and arm, and got bit exact results as original.

Change-Id: I606915da6a196f327ce81f4a5ae32811f4c1fabb

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Linfeng Zhang authored 8 years ago and Jean-Marc Valin committed 7 years ago

Should call celt_inner_prod().

This change is bit exact as original, except for x86 floating-point.
In x86 floating-point, it calls celt_inner_prod_sse() which may have
different output with the change of floating-point operations' orders.

Change-Id: Ia2381e2e198a84296ac28305183f15be842b3454

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

We boost bands that either cause leakage or are filled with leakage

It seems like letting CBR use up to 2/3 of the bit is still a win

We now include the object files for those rather than attempt to
problems.

The code would have run fine on 32-bit archs, but would have overflowed
on a 16-bit arch

Some informal tests seem to confirm that reducing the trim at 32-64 kbps
improves quality (better HF). It's not clear whether it's also the case
at 96 kb/s and above, so we're leaving it as is for those rates.

This corresponds to buildC in this thread:
https://hydrogenaud.io/index.php/topic,113985.0.html

Also see:
https://hydrogenaud.io/index.php/topic,111798.0.html

- celt/modes.c:430:14: warning: cast from 'const unsigned char *' to
  'opus_int16 *' increases required alignment from 1 to 2 [-Wcast-align]
- 'C[0][1]' may be used uninitialized [-Wmaybe-uninitialized]
- Unused variable/parameter
- Value stored is never read
- MSVC warnings about "possible loss of data" due to type conversions
- MSVC warning C4146: unary minus operator applied to unsigned type
- silk/NLSF_del_dec_quant.c:137:20: warning: array subscript is above
  array bounds [-Warray-bounds] (gcc -O3 false positive)
- src/mlp_train.h:39:20: warning: function declaration isn't a prototype
  [-Wstrict-prototypes]
- Remove SMALL_FOOTPRINT code from SSE 4.1 FIR implementation, matching
  the C implementation.

The clang -Wcast-align warnings with SSE intrinsics are a known
clang issue: https://llvm.org/bugs/show_bug.cgi?id=20670