Opus issueshttps://gitlab.xiph.org/xiph/opus/-/issues2018-11-26T18:44:40Zhttps://gitlab.xiph.org/xiph/opus/-/issues/1894exp_analysis doesn't work in fixed-point2018-11-26T18:44:40ZJean-Marc Valinexp_analysis doesn't work in fixed-pointThe exp_analysis branch added some float operations that need to be converted to fixed-point or #ifdef'ed out.The exp_analysis branch added some float operations that need to be converted to fixed-point or #ifdef'ed out.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1918OggIndex needs opus support2018-11-26T18:44:40ZGitlab BotOggIndex needs opus supportRight now one can not use Ogg with Theora and Opus with an index.
As a first step OggIndex needs support for Opus.
http://git.xiph.org/?p=OggIndex.git;a=tree
Right now one can not use Ogg with Theora and Opus with an index.
As a first step OggIndex needs support for Opus.
http://git.xiph.org/?p=OggIndex.git;a=tree
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1926Enhanced spatialization can lead to high-frequency swishiness after mixing do...2018-11-26T18:44:40ZkarlnordstromEnhanced spatialization can lead to high-frequency swishiness after mixing down to monoEnhanced spatialization during encoding can result in high-frequency swishiness after mixdown to mono. The problem becomes evident when the following conditions are true:
1. The encoder captures far-field (across-the room) audio in ster...Enhanced spatialization during encoding can result in high-frequency swishiness after mixdown to mono. The problem becomes evident when the following conditions are true:
1. The encoder captures far-field (across-the room) audio in stereo, and
2. the decoder side mixes the audio down to mono.
This can occur when the receiving side has a mono speaker. This is likely to occur in multi-chat with a mix of devices doing hands-free communication.
Reproducing the problem:
1. Capture far-field (across the room) speech with stereo mics.
2. Encode and decode with Opus.
3. Mix down to mono.
4. Listen.
Expected result:
Mono audio without audio artifacts.
Observed result:
High frequency "swishiness" due to high-frequency phase issues.
One (sub-optimal) solution is to just use the right or left channel for the mono signal instead of mixing the audio down to mono. However, this means that the mono signal will lose key information from the other channel.
The following patch eliminates the above-mentioned artifacts by not doing additional spatialization:
```
$ git diff
diff --git a/celt/bands.c b/celt/bands.c
index 62f0ee7..f493a81 100644
--- a/celt/bands.c
+++ b/celt/bands.c
@@ -794,7 +794,7 @@ static void compute_theta(struct band_ctx *ctx, struct split_ctx *sctx,
} else if (stereo) {
if (encode)
{
- inv = itheta > 8192;
+ inv = 0; // Don't reverse phase. leads to high-freq "swishiness" on mixdown to mono.
if (inv)
{
int j;
```
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1937opusenc : problem sample causes clipping2019-09-13T15:02:02ZJulian Hughesopusenc : problem sample causes clippingEncoding this 10 second pcm wav sample with opusenc 0.1.6 causes obvious clipping (repeated clicks in right channel) from about 7 seconds.
I tried default:
opusenc sample.wav sample.opus
That produced a file opusinfo shows as:
Average ...Encoding this 10 second pcm wav sample with opusenc 0.1.6 causes obvious clipping (repeated clicks in right channel) from about 7 seconds.
I tried default:
opusenc sample.wav sample.opus
That produced a file opusinfo shows as:
Average bitrate: 124.4 kb/s, w/o overhead: 123.3 kb/s
then I tried:
opusenc --bitrate 160 sample.wav sample_160.opus
That produced a file opusinfo shows as:
Average bitrate: 198 kb/s, w/o overhead: 196.8 kb/s
The 160 target file also clips.
Then I tried:
opusenc --bitrate 192 sample.wav sample_192.opus
That produced a file opusinfo shows as:
Average bitrate: 229.2 kb/s, w/o overhead: 227.7 kb/s
That plays without clipping. This is quite similar to Ogg Vorbis which on the same sample clips at -q 6 but is OK at -q 7. The sample is pcm from my retail CD and hasn't been touched by a lossy encoder. I've compressed it to flac for attachment.
Here are examples of what I did so you can see the version I'm using:
$ opusenc sample.wav sample.opus
Skipping chunk of type "LIST", length 26
Encoding using libopus 1.1-alpha (audio)
-----------------------------------------------------
Input: 44.1kHz 2 channels
Output: 2 channels (2 coupled)
20ms packets, 96kbit/sec VBR
Preskip: 356
Encoding complete
-----------------------------------------------------
Encoded: 10.02 seconds
Runtime: 1 seconds
(10.02x realtime)
Wrote: 155636 bytes, 501 packets, 13 pages
Bitrate: 123.112kbit/s (without overhead)
Rate range: 92.8kbit/s to 193.6kbit/s
(232 to 484 bytes per packet)
Overhead: 0.924% (container+metadata)
$ opusinfo sample.opus
Processing file "sample.opus"...
New logical stream (#1, serial: 1ce42e69): type opus
Encoded with libopus 1.1-alpha
User comments section follows...
ENCODER=opusenc from opus-tools 0.1.6
Opus stream 1:
Pre-skip: 356
Playback gain: 0 dB
Channels: 2
Original sample rate: 44100Hz
Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min)
Page duration: 1000.0ms (max), 910.9ms (avg), 20.0ms (min)
Total data length: 155636 bytes (overhead: 0.924%)
Playback length: 0m:10.007s
Average bitrate: 124.4 kb/s, w/o overhead: 123.3 kb/s
Logical stream 1 ended
This is on i386 Debian Wheezy/Testing on AMD Athlon64 CPU. I built opus-tools from the tarball supplied at http://www.opus-codec.org/downloads.
I also built ffmpeg and opus from current git (yesterday) and get identical results when using ffmpeg -c:a libopus.
I tried playback/decoding with and without software sample rate conversion and ruled out any possibility of sample rate conversion artefacts. I got the same clipping whether running opusdec alone or doing 'opusdec sample.opus --force-wav - |mplayer -'Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1949genversion.bat doesn't work if path contains a space2018-11-26T18:44:40ZDietrich Eppgenversion.bat doesn't work if path contains a spaceOn Windows, the `genversion.bat` script doesn't seem to work if the path contains a space, e.g., `C:\Users\John Doe\...`. It works fine if I move the project to a path containing no spaces. Maybe the script could start with `cd` and th...On Windows, the `genversion.bat` script doesn't seem to work if the path contains a space, e.g., `C:\Users\John Doe\...`. It works fine if I move the project to a path containing no spaces. Maybe the script could start with `cd` and then work with relative paths?Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1952opus 1.0.2 not working fine in windows (xp/7)2018-11-26T18:44:40Zsasugumaropus 1.0.2 not working fine in windows (xp/7)i unzipped the opus 1.0.2 and build in windows xp. i tried to decode "testvector01.bit" which i hav downloaded from www.opus_codec.org.
with command arguments "-d 48000 2 testvector01.bit testvector01.pcm".
"testvector01.pcm" not matc...i unzipped the opus 1.0.2 and build in windows xp. i tried to decode "testvector01.bit" which i hav downloaded from www.opus_codec.org.
with command arguments "-d 48000 2 testvector01.bit testvector01.pcm".
"testvector01.pcm" not matching with "testvector01.dec" ref testvector.
but it is matching if it decoded in linux ubuntu. it is working fine with same arguments.
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1954celt_decode_lost() - very poor precision/wrong result in application of frac_...2018-11-26T18:44:40ZJ.Dodscelt_decode_lost() - very poor precision/wrong result in application of frac_div32( arg1, arg2 )
## Looking in celt_decode_lost() under the comment:
```
/* Check if the waveform is decaying (and if so how fast)
We do this to avoid adding energy when concealing in a segment
with decaying energy */
decay = celt_sqrt(...
## Looking in celt_decode_lost() under the comment:
```
/* Check if the waveform is decaying (and if so how fast)
We do this to avoid adding energy when concealing in a segment
with decaying energy */
decay = celt_sqrt( frac_div32(SHR32(E1,1),E2) );
```
We see that if E1=1 then the 1-bit right shift of E1 makes E1=0. Therefore ANY E1, E2 combinations like 1/2, 1/3, ... 1/n will evaluate to zero.
Similarly, for small values of E1 the precision of the result is needlessly poor (see table below).
Suggested fix: If the intent of shifting was done to bound the output of frac_div32 to (0.5,0] then an alternate solution which avoids the E1=1 pitfall (and poor precision on small values of E1) is to shift the _result_ of frac_div32(), instead.
```
decay = celt_sqrt( frac_div32(E1,E2)>>1 );
```
Here is a small table of test values to illustrate:
decay = celt_sqrt ( frac_div32(SHR32(E1,1),E2) );
====================================================
7FEB = celt_sqrt( 3FF36D10 = frac_div32(1303/1303)) <-- so-so
687C = celt_sqrt( 2AAAAAA0 = frac_div32( 11/ 15)) <-- not great
5A86 = celt_sqrt( 1FFFFFF0 = frac_div32( 3/ 4)) <-- very bad
0000 = celt_sqrt( 00000000 = frac_div32( 1/ 1)) <-- wrong
With suggested code fix:
decay = celt_sqrt( frac_div32(E1,E2)>>1 );
====================================================
7FF6 = celt_sqrt( 3FFFFFF8 = frac_div32(1303/1303))
6D97 = celt_sqrt( 2EEEEEE8 = frac_div32( 11/ 15))
6ED5 = celt_sqrt( 2FFFFFF8 = frac_div32( 3/ 4))
7FF6 = celt_sqrt( 3FFFFFF8 = frac_div32( 1/ 1))
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1955what is the encoding parameters usef for opus testvectorx.bit2018-11-26T18:44:40Zsasugumarwhat is the encoding parameters usef for opus testvectorx.bithi! thanks for last reply. i am getting hard to find, what is the encoding parameters that is used for coding in the Bitconformance testvectorx.bit. pls send or ref some link regarding this.
i found decoding parameters
-d 48000 2 testv...hi! thanks for last reply. i am getting hard to find, what is the encoding parameters that is used for coding in the Bitconformance testvectorx.bit. pls send or ref some link regarding this.
i found decoding parameters
-d 48000 2 testvectorx.bit testx.out
any help greatly appreciated.
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1961libopus and libspeex can not be statically linked in same application2018-11-26T18:44:40ZGitlab Botlibopus and libspeex can not be statically linked in same applicationtrying to link libopus and libspeex in a static application on OS X (i.e. ffmpeg) fails due to duplicate symbols:
```
ld: duplicate symbol _pitch_xcorr in lib/libopus.a(pitch.o) and lib/libspeex.a(ltp.o)
```
to work around this, pitch_...trying to link libopus and libspeex in a static application on OS X (i.e. ffmpeg) fails due to duplicate symbols:
```
ld: duplicate symbol _pitch_xcorr in lib/libopus.a(pitch.o) and lib/libspeex.a(ltp.o)
```
to work around this, pitch_xcorr in opus could be renamed to opus_pitch_xcorrJean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1962Quality is poorer when the FrameSize is 10 ms2018-11-26T18:44:40ZCedrick FonkwaQuality is poorer when the FrameSize is 10 msRunning PESQ score with OPUS codec show that the quality is not as good with 10ms packet size as with others (20, 40, 60).
Example:
Mean PESQ with 8 kHz - 10000 kbps - 10 ms : 3.19
Mean PESQ with 8 kHz - 10000 kbps - 20 ms : 3.75
Is...Running PESQ score with OPUS codec show that the quality is not as good with 10ms packet size as with others (20, 40, 60).
Example:
Mean PESQ with 8 kHz - 10000 kbps - 10 ms : 3.19
Mean PESQ with 8 kHz - 10000 kbps - 20 ms : 3.75
Is there any reason that could explain this ? Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1968URL incorrect in celt/entdec.c2018-11-26T18:44:40ZTony WilsonURL incorrect in celt/entdec.cThe MMW98 pdf is in .../ee398a/... The MMW98 pdf is in .../ee398a/... Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1978opus_decode fails on >20ms zero-length frame following hybrid frame2018-11-26T18:44:40ZMark Harrisopus_decode fails on >20ms zero-length frame following hybrid frameopus_decode fails with OPUS_BAD_ARG on a packet containing a 40ms or 60ms LP zero-length frame when it follows a hybrid or MDCT frame.
The attached ogg opus file contains ten 40ms packets. The duration of the expected output is 400ms -...opus_decode fails with OPUS_BAD_ARG on a packet containing a 40ms or 60ms LP zero-length frame when it follows a hybrid or MDCT frame.
The attached ogg opus file contains ten 40ms packets. The duration of the expected output is 400ms - 6.5ms pre-skip = 393.5ms. However, opus_decode and the opusdec tool fail after the first packet. The 1.0 reference implementation decodes it successfully.
The first packet contains two 20ms Hybrid SWB frames, and the others each contain one 40ms LP WB frame. The first 40ms LP WB frame has a length of 0, invoking PLC.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1979opus_decode LP PLC fails to accommodate frame size change during packet loss2018-11-26T18:44:40ZMark Harrisopus_decode LP PLC fails to accommodate frame size change during packet lossSuppose opus packets are being received over an unreliable network with a frame size and packet size of 40ms. There is some packet loss, and during that time the sender switches to 10ms packets, as shown below:
Received packets:
|= tim...Suppose opus packets are being received over an unreliable network with a frame size and packet size of 40ms. There is some packet loss, and during that time the sender switches to 10ms packets, as shown below:
Received packets:
|= timestamp =|= content =|
|-------------|------------|
| //t// | 40ms frame |
| //t//+80ms | 10ms frame |
`opus_decode()` is called in the usual manner for the time //t// packet. When the next packet is received for time //t//+80ms, `opus_decode()` is called with that packet using `decode_fec`=1 and `frame_size`=1920 (40ms), to fill in the gap from //t//+40ms to //t//+80ms.
If libopus assertions are enabled, an assertion failure is produced:
```
Fatal (internal) error in silk/dec_API.c, line 142: assertion failed: 0
Abort trap
```
If libopus assertions are disabled it does not abort, but the pcm output contains 30ms of digital silence from //t//+40ms to //t//+70ms before the PLC (or FEC if available) activates. This is shown in the attached picture, in which //t//=0 and the audio is a continuous 880 Hz sine wave with constant amplitude.
It expected that the entire gap from //t//+40ms to //t//+80ms will be filled in with interpolated PLC data and any available FEC data, as it does with no frame size change, without producing an assertion failure.
Note that the same type of failure also occurs for other times and frame sizes, e.g. if the second packet contains a 2.5ms MDCT frame for time //t//+55ms.
The issue can be reproduced by decoding the attached opus_demo bitstream.
```
opus_demo -d 48000 1 -inbandfec opus-lp-plc-fail.opusdemo out.pcm
```Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1980opus_decode undefined behavior decoding FEC from invalid packet2018-11-26T18:44:40ZMark Harrisopus_decode undefined behavior decoding FEC from invalid packetAttempting to decode FEC from an invalid packet can cause the opus decoder to use uninitialized data from the stack, and potentially dereference out-of-bounds memory addresses or crash depending on the contents of the uninitialized data....Attempting to decode FEC from an invalid packet can cause the opus decoder to use uninitialized data from the stack, and potentially dereference out-of-bounds memory addresses or crash depending on the contents of the uninitialized data.
Decoding the attached opus_demo bitstream under valgrind demonstrates the issue.
```
opus_demo -d 48000 1 -inbandfec opus-fec-uninit.opusdemo out.pcm
```Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1981opus_multistream_decode read beyond end of payload2018-11-26T18:44:40ZMark Harrisopus_multistream_decode read beyond end of payloadUp to 2 bytes beyond the end of the payload may be read when decoding a specially-crafted self-delimited code 2 or code 3 vbr multistream packet.Up to 2 bytes beyond the end of the payload may be read when decoding a specially-crafted self-delimited code 2 or code 3 vbr multistream packet.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1984opus_multistream_encoder_ctl(st, OPUS_RESET_STATE) unimplemented2018-11-26T18:44:39ZMark Harrisopus_multistream_encoder_ctl(st, OPUS_RESET_STATE) unimplementedUnder `opus_multistream_encoder_init()`, the [Opus Multistream API](https://mf4.xiph.org/jenkins/view/opus/job/opus/ws/doc/html/group__opus__multistream.html#gae7586aa54c322fd9599de24b5c8b8c01) documentation states:
> To reset a previou...Under `opus_multistream_encoder_init()`, the [Opus Multistream API](https://mf4.xiph.org/jenkins/view/opus/job/opus/ws/doc/html/group__opus__multistream.html#gae7586aa54c322fd9599de24b5c8b8c01) documentation states:
> To reset a previously initialized state, use the `OPUS_RESET_STATE` CTL.
However, `opus_multistream_encoder_ctl(st, OPUS_RESET_STATE)` returns `OPUS_UNIMPLEMENTED`.
Workaround: Destroy encoder and create a new one.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1991llvm crashes when building pitch.c for iOS (opus 1.1rc2) with optimisation en...2017-10-21T19:37:06Zmcguinnllvm crashes when building pitch.c for iOS (opus 1.1rc2) with optimisation enabled and floating pointI am trying to build the latest opus 1.1rc2 within webrtc for iOS using the chromium gyp build framework.
The build flag OPUS_ARM_MAY_HAVE_NEON is defined to get access to any neon optimisations
Without minimal compiler optimisations ...I am trying to build the latest opus 1.1rc2 within webrtc for iOS using the chromium gyp build framework.
The build flag OPUS_ARM_MAY_HAVE_NEON is defined to get access to any neon optimisations
Without minimal compiler optimisations (-O0) I see a message stating that opus will be very slow, but things build just fine.
With any optimisation set for iOS in the file trunk/build/common.gypi (i.e.., 'mac_debug_optimization%': 's', instead of '0') and building for FIXED_POINT (toggled 'use_opus_fixed_point%': 1, in trunk/third_party/opus/opus.gyp) then the compiler crashes and reports a problem similar to what is described here: http://lists.cs.uiuc.edu/pipermail/llvmbugs/2013-August/029853.html
The file that building stops at is celt/pitch.c
However building with fixed point and optimisation is not a problem.
More information about the llvm crash dump:
ninja: Entering directory `trunk/out_ios/Debug-iphoneos'
[74/2136] CC obj/third_party/opus-1.1-rc2/src/celt/opus.pitch.o
FAILED: ../../third_party/llvm-build/Release+Asserts/bin/clang -MMD -MF obj/third_party/opus-1.1-rc2/src/celt/opus.pitch.o.d -DANGLE_DX11 -DDISABLE_NACL -DCHROMIUM_BUILD -DUSE_LIBJPEG_TURBO=1 -DENABLE_INPUT_SPEECH -DENABLE_EGLIMAGE=1 -DCLD_VERSION=1 -DENABLE_SPELLCHECK=1 -DDISABLE_FTP_SUPPORT=1 -DOPUS_BUILD -DOPUS_EXPORT= -DHAVE_LRINT -DHAVE_LRINTF -DVAR_ARRAYS -DOPUS_ARM_MAY_HAVE_NEON -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DWTF_USE_DYNAMIC_ANNOTATIONS=1 -I../../third_party/opus-1.1-rc2/src/celt -I../../third_party/opus-1.1-rc2/src/include -I../../third_party/opus-1.1-rc2/src/silk -I../../third_party/opus-1.1-rc2/src/silk/float -isysroot /Applications/Xcode5.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk -O1 -gdwarf-2 -fvisibility=hidden -Wnewline-eof -miphoneos-version-min=6.0 -arch armv7 -Wendif-labels -Wno-unused-parameter -Wno-missing-field-initializers -Wheader-hygiene -Wno-c++11-narrowing -Wno-char-subscripts -Wno-unused-function -Wno-covered-switch-default -Wstring-conversion -Wno-deprecated-register -Wno-deprecated-declarations -Wheader-hygiene -Wno-char-subscripts -Wno-unused-function -Wno-unnamed-type-template-args -Wno-c++11-narrowing -std=c99 -Xclang -load -Xclang /Users/tommcguinness/webrtc2/trunk/tools/clang/scripts/../../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.dylib -Xclang -add-plugin -Xclang find-bad-constructs -fcolor-diagnostics -c ../../third_party/opus-1.1-rc2/src/celt/pitch.c -o obj/third_party/opus-1.1-rc2/src/celt/opus.pitch.o
Assertion failed: (MLoc.isReg() && !Indirect && "This doesn't support offset/indirection - implement it if needed"), function EmitDwarfRegOp, file /work/chromium/src/third_party/llvm/lib/Target/ARM/ARMAsmPrinter.cpp, line 225.
0 clang 0x0000000101b5b138 llvm::sys::PrintStackTrace(__sFILE*) + 40
1 clang 0x0000000101b5b684 abort + 692
2 libsystem_platform.dylib 0x00007fff896ff5aa _sigtramp + 26
3 libsystem_platform.dylib 000000000000000000 _sigtramp + 1989151344
4 clang 0x0000000101b5b3e6 abort + 22
5 clang 0x0000000101b5b3c1 __assert_rtn + 81
6 clang 0x000000010103b135 std::_Rb_tree<llvm::MachineInstr*, std::pair<llvm::MachineInstr* const, unsigned int>, std::_Select1st<std::pair<llvm::MachineInstr* const, unsigned int> >, std::less<llvm::MachineInstr*>, std::allocator<std::pair<llvm::MachineInstr* const, unsigned int> > >::_M_erase(std::_Rb_tree_node<std::pair<llvm::MachineInstr* const, unsigned int> >*) + 805
7 clang 0x000000010152ee8e llvm::DwarfDebug::emitDebugLoc() + 878
8 clang 0x000000010152e748 llvm::DwarfDebug::endModule() + 648
9 clang 0x00000001015082c3 llvm::AsmPrinter::doFinalization(llvm::Module&) + 563
10 clang 0x0000000101af24de llvm::FPPassManager::doFinalization(llvm::Module&) + 94
11 clang 0x0000000101af2816 llvm::MPPassManager::runOnModule(llvm::Module&) + 710
12 clang 0x0000000101af314f llvm::PassManagerImpl::run(llvm::Module&) + 543
13 clang 0x00000001001c5b4e clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 5694
14 clang 0x00000001002cc813 clang::EmitObjAction::EmitObjAction(llvm::LLVMContext*) + 1555
15 clang 0x0000000100084b44 clang::MultiplexConsumer::HandleTranslationUnit(clang::ASTContext&) + 68
16 clang 0x000000010031fc54 clang::ParseAST(clang::Sema&, bool, bool) + 484
17 clang 0x00000001002cb801 clang::CodeGenAction::ExecuteAction() + 545
18 clang 0x0000000100069174 clang::FrontendAction::Execute() + 116
19 clang 0x00000001000422bd clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 973
20 clang 0x0000000100009064 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3348
21 clang 0x0000000100001179 cc1_main(char const**, char const**, char const*, void*) + 793
22 clang 0x00000001000072b5 main + 8901
23 clang 0x0000000100000e34 start + 52
24 clang 0x000000000000007b start + 4294963835
Stack dump:
0. Program arguments: /Users/tommcguinness/webrtc2/trunk/third_party/llvm-build/Release+Asserts/bin/clang -cc1 -triple thumbv7-apple-ios6.0.0 -emit-obj -disable-free -main-file-name pitch.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -target-cpu cortex-a8 -target-feature +soft-float-abi -target-abi apcs-gnu -mfloat-abi soft -target-linker-version 133.3 -gdwarf-2 -coverage-file /Users/tommcguinness/webrtc2/trunk/out_ios/Debug-iphoneos/obj/third_party/opus-1.1-rc2/src/celt/opus.pitch.o -resource-dir /Users/tommcguinness/webrtc2/trunk/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.4 -dependency-file obj/third_party/opus-1.1-rc2/src/celt/opus.pitch.o.d -MT obj/third_party/opus-1.1-rc2/src/celt/opus.pitch.o -isysroot /Applications/Xcode5.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk -D ANGLE_DX11 -D DISABLE_NACL -D CHROMIUM_BUILD -D USE_LIBJPEG_TURBO=1 -D ENABLE_INPUT_SPEECH -D ENABLE_EGLIMAGE=1 -D CLD_VERSION=1 -D ENABLE_SPELLCHECK=1 -D DISABLE_FTP_SUPPORT=1 -D OPUS_BUILD -D OPUS_EXPORT= -D HAVE_LRINT -D HAVE_LRINTF -D VAR_ARRAYS -D OPUS_ARM_MAY_HAVE_NEON -D DYNAMIC_ANNOTATIONS_ENABLED=1 -D WTF_USE_DYNAMIC_ANNOTATIONS=1 -I ../../third_party/opus-1.1-rc2/src/celt -I ../../third_party/opus-1.1-rc2/src/include -I ../../third_party/opus-1.1-rc2/src/silk -I ../../third_party/opus-1.1-rc2/src/silk/float -O1 -Wnewline-eof -Wendif-labels -Wno-unused-parameter -Wno-missing-field-initializers -Wheader-hygiene -Wno-c++11-narrowing -Wno-char-subscripts -Wno-unused-function -Wno-covered-switch-default -Wstring-conversion -Wno-deprecated-register -Wno-deprecated-declarations -Wheader-hygiene -Wno-char-subscripts -Wno-unused-function -Wno-unnamed-type-template-args -Wno-c++11-narrowing -std=c99 -fdebug-compilation-dir /Users/tommcguinness/webrtc2/trunk/out_ios/Debug-iphoneos -ferror-limit 19 -fmessage-length 0 -fvisibility hidden -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=ios-6.0.0 -fencode-extended-block-signature -fsjlj-exceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -load /Users/tommcguinness/webrtc2/trunk/tools/clang/scripts/../../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.dylib -add-plugin find-bad-constructs -o obj/third_party/opus-1.1-rc2/src/celt/opus.pitch.o -x c ../../third_party/opus-1.1-rc2/src/celt/pitch.c
1. <eof> parser at end of file
2. Code generation
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 3.4 (trunk 192635)
Target: arm-apple-darwin13.0.0
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /var/folders/h1/51w8ct3j2mq60f_y9djxbhxh04m7j1/T/pitch-c74fe5.c
clang: note: diagnostic msg: /var/folders/h1/51w8ct3j2mq60f_y9djxbhxh04m7j1/T/pitch-c74fe5.sh
clang: note: diagnostic msg:
********************
[74/2136] CC obj/third_party/opus-1.1-rc2/src/silk/opus.enc_API.o
ninja: build stopped: subcommand failed.
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1997Opus trunk/1.1 fails to build - 'export' is a GNU make-ism2020-04-22T04:16:23ZBrad SmithOpus trunk/1.1 fails to build - 'export' is a GNU make-ismOpus trunk/1.1 has had someregressions over 1.0.x and fails to build..
checking for C99 variable-size arrays... yes
checking for cos in -lm... (cached) yes
/home/ports/pobj/opus-1.1/opus-1.1/configure[12816]:
${inline_optimization:0:3}...Opus trunk/1.1 has had someregressions over 1.0.x and fails to build..
checking for C99 variable-size arrays... yes
checking for cos in -lm... (cached) yes
/home/ports/pobj/opus-1.1/opus-1.1/configure[12816]:
${inline_optimization:0:3}": bad substitution
AM_CONDITIONAL([OPUS_ARM_INLINE_ASM],
[test x"${inline_optimization:0:3}" = x"ARM"])
AM_CONDITIONAL([OPUS_ARM_EXTERNAL_ASM],
[test x"${asm_optimization:0:3}" = x"ARM"])
*** Parse error in /home/ports/pobj/opus-1.1/build-amd64: Need an
operator in 'yes' (Makefile:2756)
# Provide the full test output for failed tests when using the parallel
# test suite (which is enabled by default with automake 1.13+).
export VERBOSE = yes
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1998Opus 1.1: 64 bit windows compilation generates conversion warnings2017-10-21T19:37:06ZJ. MarkiewiczOpus 1.1: 64 bit windows compilation generates conversion warningsUsing the 2010 projects to compile opus 1.1 and generate the following warnings compiling x64 Release.
opus_compare.c
..\..\src\opus_compare.c(78): warning C4244: '=' : conversion from 'int' to 'float', possible loss of data
..\..\src...Using the 2010 projects to compile opus 1.1 and generate the following warnings compiling x64 Release.
opus_compare.c
..\..\src\opus_compare.c(78): warning C4244: '=' : conversion from 'int' to 'float', possible loss of data
..\..\src\opus_compare.c(233): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data
..\..\src\opus_compare.c(349): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data
..\..\src\opus_compare.c(367): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data
opus_decoder.c
opus_encoder.c
..\..\src\opus_encoder.c(588): warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
..\..\src\opus_encoder.c(589): warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
..\..\src\opus_encoder.c(608): warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
..\..\src\opus_encoder.c(615): warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
..\..\src\opus_encoder.c(620): warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
..\..\src\opus_encoder.c(623): warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
..\..\src\opus_encoder.c(625): warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
..\..\src\opus_encoder.c(714): warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
repacketizer.c
..\..\src\repacketizer.c(222): warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data
Maybe they are harmless, but they look scary especially when dealing we're talking about a codec. I didn't see a open issue filed on this so I thought I'd let you know.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/2000Opus decoder produces signed arithmetic overflow undefined behavior2017-10-21T19:37:05ZMark HarrisOpus decoder produces signed arithmetic overflow undefined behaviorThe libopus Opus decoder can produce signed multiplication overflows and signed addition overflows decoding Opus packets. This is undefined behavior according to ISO C.
When this happens, it is usually accompanied by loud, exceptionall...The libopus Opus decoder can produce signed multiplication overflows and signed addition overflows decoding Opus packets. This is undefined behavior according to ISO C.
When this happens, it is usually accompanied by loud, exceptionally poor quality clipped audio output.
The libopus README file claims that the implementation does not rely on any undefined behavior.
Attached is an example PCM input file that can be used with `opus_demo` to reproduce the issue. The packets produced by the Opus encoder produce overflows when decoded. The issue can be reproduced with either the floating point or fixed point implementation using the command below:
```
$ opus_demo audio 48000 1 9000 -cbr ticket2000.pcm out.pcm
libopus 1.1-42-ge1f8462
Encoding 48000 Hz input at 9.000 kb/s in auto mode with 960-sample frames.
```
Numerous occurrences of the following operations are encountered (with varying values for the operands):
```
CLANG ARITHMETIC UNDEFINED at <silk/NSQ_del_dec.c, (234:64)> : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int32): -284186 right (int32): 8512
CLANG ARITHMETIC UNDEFINED at <silk/decode_core.c, (224:36)> : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int32): 47718480 right (int32): 52
CLANG ARITHMETIC UNDEFINED at <silk/decode_core.c, (224:36)> : Op: +, Reason : Signed Addition Overflow, BINARY OPERATION: left (int32): 44894665 right (int32): 2140023376
```
The output audio also sounds nothing like the input.Jean-Marc ValinJean-Marc Valin