As reported by Mark Warner opus_multistream_*_create were depending on
 the behavior of malloc(0) in order to correctly report some kinds of
 argument errors. Bad arguments could be incorrectly reported as
 allocation failures. This changes multistream to explicitly check the
 arguments like the single stream _create functions. The unit tests were
 enough to catch this on systems where malloc(0) returns NULL but didn't
 catch it on other systems because the later _init call would catch the
 bad arguments and trigger the correct error if and only if the malloc
 didn't return a null pointer.

In multistream_encoder_init failures of the internal non-multistream
 init calls were not being caught and propagated. Decode didn't have
 this problem. This propagates the errors and adds additional tests
 (the multistream encoder api is sill under tested) that would have
 detected this error.

Plus add some stronger tests for things like error==NULL for the _create
 functions that take a pointer for error output.

Specify the correct debug runtime libraries for the test
and demo executables to prevent mismatch warnings with
the default runtime.

Signed-off-by: Ralph Giles <giles@mozilla.com>

Previously the test programmes happened to link because _getpid
returns an int, which is the default prototype. Instead, include
the appropriate header to supply a real declaration, fixing the
associated warning.

I moved the getpid->_getpid define to the site of the header
inclusion to make clear what's going on, rather than have it
floating in win32/config.h.

Philip Jägenstedt authored 12 years ago and Gregory Maxwell committed 12 years ago

I stumbled upon the typo in README.draft, so took the opportunity to
grep for common misspellings using List_of_common_misspellings.txt for
hunspell.

Match up the exit behavior when the no-fuzz enviroment variable
is set.

gcp authored 12 years ago and Gregory Maxwell committed 12 years ago

The (non-default) temporary & output dirs configured in the projects could
cause issues when doing compilation on a multiprocessor machine. Cleaned
this up a little to use the defaults, which makes that work again and
doesn't make the output structure any worse. Also removed debug output for
release binaries & a tiny whitespace fix.

gcp authored 12 years ago and Jean-Marc Valin committed 12 years ago

Add project files for Opus tests, fixup test source for Win32.

The last commit changed some of the multistream tests to use a
dual-mono setup instead of a single-stereo setup. Some of the
accompanying explicit valgrind checks were still setup to
look for stereo streams.

This CTL was requested by Nicolas George for FFmpeg.

Gregory Maxwell authored 12 years ago and Jean-Marc Valin committed 12 years ago

In places where an ignored return or a null-arg is a sure indication
of a bug add the GCC warning attributes. The null arg annotation
is not enable for Opus itself because it will cause the compiler
to optimize out some null checks. I don't trust our callers
quite that much.

This reverts commit 9f407afa.

Also added 3rd clause to "master" COPYING file

See http://www.ietf.org/mail-archive/web/codec/current/msg02833.html
Still more changes to come

Ralph Giles authored 13 years ago and Jean-Marc Valin committed 13 years ago

Also fixes a minor typo.

CLANG IOC no longer likes the 'deterministic random' bitstreams, so move the test_opus_decode bailout up.

- Draft updates
- Updated code to produce and check test vectors
- Making sure that the test vectors pass at all rates as well as for mono and stereo

Gregory Maxwell authored 13 years ago and Jean-Marc Valin committed 13 years ago

No changes to the codec itself.

Multistream encode was failing to add the length of the extra length for
self-delimited packets causing corrupted output. Multistream decode was
not properly handling lost frames (and potentially reading out of bounds
as a result).

GET_FINAL_RANGE has been implemented as the xor of the final range of all
the streams in the packet.

test_opus_encode now does the mono narrowband tests using dual-mono
multistream.

Files are already compiled with -I./include, the relative
path in the #include line isn't necessary.

Our arch.h makes sure it's always defined. Thanks to derf
for the suggestion.

We use the __GNUC_PREREQ macro from celt/arch.h to check
the required minimum gcc version. The previous check would
have failed for gcc 5.n with n from 0 to 5.

Thanks to pcgod for pointing out the problem and derf for
pointing out we had a macro for this.

This array is only used by the malloc failure test, and
defining it unconditionally creates an unused variable
warning on platforms where MALLOC_FAIL isn't set.