Keep a copy of the release tarball sha-256 checksums in the
repository for reference. Having a copy with the code in
distributed version control adds a verification path.

This should match http://downloads.xiph.org/releases/opus/SHA256SUMS.txt

1. Removed an inappropriate normative MAY.
2. Gave an explicit range of sample rates deemed to be "non-crazy".
3. Give explicit guidance on packet sizes that SHOULD and MAY be rejected.

We already needed these macros for gcc with optimizations disabled,
 but it appears clang needs them all the time.

Thanks to Jonathan Lennox for the report.

This way we won't break this by accident.

During review of c95c9a04, I replaced a call to
 _mm_cvtepi8_epi32() with the OP_CVTEPI16_EPI32_M64() macro (note
 the 16 instead of 8).
Make a separate OP_CVTEPI8_EPI32_M32() macro and use that instead.

Thaks to Wei Zhou for the report.

This should suppress our current issues with unused parameters,
 unused variables, and set-but-not-used variables.

Viswanath Puttagunta authored 10 years ago and Timothy B. Terriberry committed 10 years ago

Optimize celt_pitch_xcorr function (for floating point)
using ARM NEON intrinsics for SoCs that have NEON VFP unit.

To enable this optimization, use --enable-intrinsics
configure option.

Compile time and runtime checks are also supported to make sure
this optimization is only enabled when the compiler supports
NEON intrinsics.

Signed-off-by: Timothy B. Terriberry <tterribe@xiph.org>

See the mailing list discussion at
http://lists.xiph.org/pipermail/opus/2014-December/002802.html

It was under-quoted in c95c9a04, which
leads to a flood of warnings when it gets incorrectly expanded, like:

configure.ac:354: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body

This should not take an arch parameter, so it can properly be used
 as a fallback for accelerated versions which do not.
This patch instead provides a separate version which can call
 accelerated helpers for platforms that have taken that approach.

Mark Harris authored 10 years ago and Jean-Marc Valin committed 10 years ago

Avoid undefined behavior (signed arithmetic overflow) or
implementation-defined behavior (malloc(0)) on out-of-range arguments,
e.g. opus_multistream_encoder_create(48000, 2, 2147483647, 1, ...)
or opus_multistream_surround_encoder_create(48000, 3, 0, ...).

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

Cameron Gutman authored 10 years ago and Tristan Matthews committed 10 years ago

Signed-off-by: Tristan Matthews <tmatth@videolan.org>

This is just a should, so we want to leave the RFC 6716 reference
to the second occurance, but using the same language ties them
together and to the later occurances.

The Opus RFC doesn't really say what to do beyond rejecting
a particular packet, but having the reference reinforces that
we're trying to leverage the same constraints in the specific
context of ogg encapsulation, and this isn't a new rule.

Suggestion from mark4o.

This avoids confusion with the number of frames being defined
by more than the first byte with code 3 packets.

Patch from mark4o.

The macros take arguments, they aren't just constants. Thanks to
mark4o for the report.

Add a limit of no more than 6 characters for these tags' values.

Based on http://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html

There is also no trailing whitespace.