Opus issueshttps://gitlab.xiph.org/xiph/opus/-/issues2020-06-14T03:57:12Zhttps://gitlab.xiph.org/xiph/opus/-/issues/2320silk_LPC_inverse_pred_gain_neon methods reads memory outside of the intended ...2020-06-14T03:57:12ZRomansilk_LPC_inverse_pred_gain_neon methods reads memory outside of the intended bufferThe problem connected with attempt to read data outside of the intended buffer in method silk_LPC_inverse_pred_gain_neon.
Buffer of length MAX_LPC_ORDER (=16) is placed in silk_find_LPC_FIX stack:
```C
opus_int16 a_tmp_Q12[ MAX_LPC_OR...The problem connected with attempt to read data outside of the intended buffer in method silk_LPC_inverse_pred_gain_neon.
Buffer of length MAX_LPC_ORDER (=16) is placed in silk_find_LPC_FIX stack:
```C
opus_int16 a_tmp_Q12[ MAX_LPC_ORDER ];
```
Attempt to read the buffer outside boundaries in silk_LPC_inverse_pred_gain_neon
```C
t0_s16x8 = vld1q_s16( A_Q12 + 0 );
t1_s16x8 = vld1q_s16( A_Q12 + 8 );
t2_s16x8 = vld1q_s16( A_Q12 + 16 );
```
Backtrace of methods
silk_LPC_inverse_pred_gain_neon
silk_NLSF2A
silk_find_LPC_FIXhttps://gitlab.xiph.org/xiph/opus/-/issues/2368Default branch has changed from "master" to "main"2024-02-02T05:48:37ZJean-Marc ValinDefault branch has changed from "master" to "main"The default branch for the Opus repository has changed from "master" to "main". It is more than merely a name change, as main points to what used to be the opus-ng branch and thus has many improvements over what was in master. For more d...The default branch for the Opus repository has changed from "master" to "main". It is more than merely a name change, as main points to what used to be the opus-ng branch and thus has many improvements over what was in master. For more details, see https://lists.xiph.org/pipermail/opus/2024-January/004585.html
Please report any issue you may encounter due to that change.https://gitlab.xiph.org/xiph/opus/-/issues/2367Noise in LFE channel at the start of a stream2023-12-13T07:53:43ZJason PetersonNoise in LFE channel at the start of a streamWhen encoding a 6 channel WAV file containing an inaudible level of noise with opusenc.exe on win64 platform, the LFE channel in the resulting opus file contains a short impulse of noise with a bandwidth of 4 kHz. This does not happen wh...When encoding a 6 channel WAV file containing an inaudible level of noise with opusenc.exe on win64 platform, the LFE channel in the resulting opus file contains a short impulse of noise with a bandwidth of 4 kHz. This does not happen when a file starts with absolute silence. Problem happens with any recent version including libopusenc 0.2.1-16-ge4285b5. It is audible in a downmix when the LFE is played on full range speakers.
To reproduce, create a short silent audio file and add shaped dither.
Sample: http://j7n.sytes.net/temp/opussample/https://gitlab.xiph.org/xiph/opus/-/issues/2366Compilation error with clang-cl 16 and vcpkg on Windows2023-12-03T20:18:26ZAlexandre BiqueCompilation error with clang-cl 16 and vcpkg on WindowsOpus fails to build on windows when using clang-cl (clang-16)
See https://github.com/microsoft/vcpkg/issues/35441Opus fails to build on windows when using clang-cl (clang-16)
See https://github.com/microsoft/vcpkg/issues/35441https://gitlab.xiph.org/xiph/opus/-/issues/2365reserved identifier violation2023-08-15T15:04:00ZMarkus Elfringreserved identifier violation:eyes: I would like to point out that identifiers like “[`_MLP_H_`](https://gitlab.xiph.org/xiph/opus/-/blob/9fc8fc4cf432640f284113ba502ee027268b0d9f/src/mlp.h#L27 "Update candidate")” and “[`__SILK_MACROS_MIPSR1_H__`](https://gitlab.xip...:eyes: I would like to point out that identifiers like “[`_MLP_H_`](https://gitlab.xiph.org/xiph/opus/-/blob/9fc8fc4cf432640f284113ba502ee027268b0d9f/src/mlp.h#L27 "Update candidate")” and “[`__SILK_MACROS_MIPSR1_H__`](https://gitlab.xiph.org/xiph/opus/-/blob/9fc8fc4cf432640f284113ba502ee027268b0d9f/silk/mips/macros_mipsr1.h#L29 "Another update candidate")” [do not fit](https://wiki.sei.cmu.edu/confluence/display/cplusplus/DCL51-CPP.+Do+not+declare+or+define+a+reserved+identifier#DCL51CPP.Donotdeclareordefineareservedidentifier-NoncompliantCodeExample%28HeaderGuard%29 "Do not declare an identifier which is reserved for the compiler implementation.") to the expected naming convention of the C++ language standard.
:thought_balloon: Would you like to adjust your selection for unique names?https://gitlab.xiph.org/xiph/opus/-/issues/2364Added the OPUS_SET_INBAND_FEC(2) option2023-07-27T04:04:32Zhua yanAdded the OPUS_SET_INBAND_FEC(2) optionWhat are the benefits of adding the OPUS_SET_INBAND_FEC(2) option? How does it affect audio quality? How does it affect audio quality compared to OPUS_SET_INBAND_FEC(1)?What are the benefits of adding the OPUS_SET_INBAND_FEC(2) option? How does it affect audio quality? How does it affect audio quality compared to OPUS_SET_INBAND_FEC(1)?https://gitlab.xiph.org/xiph/opus/-/issues/2363Just a question, about LBRR2023-07-07T06:42:52ZJian GaoJust a question, about LBRRI've seen the remarkable improvent in PLC with DRED, but just out of curiosity, is it realistic to contain more than one LBRR frame in one Opus frame?I've seen the remarkable improvent in PLC with DRED, but just out of curiosity, is it realistic to contain more than one LBRR frame in one Opus frame?https://gitlab.xiph.org/xiph/opus/-/issues/2361Building libopus for mac os x universal binary2022-09-17T17:20:30Zcbarrett69Building libopus for mac os x universal binaryCurrently, the active mac hardware includes both x86_64 and arm64 architecture. Apple supports universal binaries that include support for both of these architectures, such that the appropriate code is used at runtime. In order for an ...Currently, the active mac hardware includes both x86_64 and arm64 architecture. Apple supports universal binaries that include support for both of these architectures, such that the appropriate code is used at runtime. In order for an application to successfully support both, all dependent libraries must also be universal binaries. Libopus is a dependent library for my application.
My build machine is x86_64, but Apple includes the compilers for both architectures in recent versions of Xcode.
For most libs (libogg, libflac, ...) the following seems to work, but it does not work for libopus:
```
./configure CXXFLAGS="-arch x86_64 -arch arm64" CFLAGS="-arch x86_64 -arch arm64"
make -j8
sudo make install
```
result:
checking How to get X86 CPU Info... configure: error: no supported Get CPU Info method, please disable run-time CPU capabilities detection or intrinsics
Then I tried:
```
./configure --disable-rtcd CXXFLAGS="-arch x86_64 -arch arm64" CFLAGS="-arch x86_64 -arch arm64"
make -j8
```
result:
Undefined symbols for architecture arm64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)https://gitlab.xiph.org/xiph/opus/-/issues/2358Excessive noise generated by CELT PLC2021-06-24T16:30:44ZFrancis QuiersExcessive noise generated by CELT PLCWe recently came across a situation where bursty loss resulted in relatively loud noise in output of the Opus decoder.
The previous frames (before the gap) were all encoded as CELT, and since the gap was more than 5 frames, the noise-ba...We recently came across a situation where bursty loss resulted in relatively loud noise in output of the Opus decoder.
The previous frames (before the gap) were all encoded as CELT, and since the gap was more than 5 frames, the noise-based CELT PLC eventually got triggered (because of [this piece of logic](https://gitlab.xiph.org/xiph/opus/-/blob/v1.3.1/celt/celt_decoder.c#L531)), and this is when the noise starts.
The problem can be reproduced using the following branch, which is based on tag v1.3.1, plus an extra option in `opus_demo` in order to be able to feed a stream that does not include the "final range" check, but only each packet's length (or 0 for a lost packet) followed by the opus data:
https://gitlab.xiph.org/cisquiers/opus/-/tree/opus_demo_support_for_decoding_external_streams
The commands to run are the following:
```
./autogen.sh
./configure --enable-fixed-point
make
./opus_demo -d 48000 1 -external_stream stream.opus output.pcm
```
Input stream:
[stream.opus](/uploads/92e308f2c6374561db59e63ee5e967e8/stream.opus)
Output raw audio (mono, 16-bit, little-endian, 48kHz):
[output.pcm](/uploads/28f3afc3cf62f57df76f0c951f2feb82/output.pcm)
Note that I tried to reproduce the problem by starting from raw audio (either using silence, or a small negative DC as what the stream decodes to prior to the gap) and encoding it using `opus_demo`, but I wasn't unable to do so.
Unfortunately I don't have access to the original raw audio, or the source code for the client that generated this stream.
I cannot actually guarantee that the encoder that was used was a vanilla Opus release, without any custom modification that could perhaps have generated this (perhaps slightly unusual?) bitstream (particularly the DC offset). However, since the bitstream appears to be valid, perhaps the CELT decoder should still not generate such a noise in output in this case.https://gitlab.xiph.org/xiph/opus/-/issues/2357iOS SIGSEGV crash in silk_encode_indices on version 1.3.12021-06-01T17:20:55ZRyan MaloneyiOS SIGSEGV crash in silk_encode_indices on version 1.3.1We recently received the following crash report from a user of our iOS app. The app is using Opus 1.3.1. Unfortunately, we don't have repro steps.
Here is the exception info, and the crashing thread's stack trace (The full crash report ...We recently received the following crash report from a user of our iOS app. The app is using Opus 1.3.1. Unfortunately, we don't have repro steps.
Here is the exception info, and the crashing thread's stack trace (The full crash report is attached):
```
Exception Type: SIGSEGV
Exception Codes: SEGV_MAPERR at 0x18
Crashed Thread: 26
Thread 26 Crashed:
0 AppXAudio 0x00000001054a3840 silk_encode_indices (encode_indices.c:91)
1 AppXAudio 0x00000001054b8484 silk_encode_frame_FLP (encode_frame_FLP.c:205)
2 AppXAudio 0x00000001054a2e3c silk_Encode (enc_API.c:499)
3 AppXAudio 0x00000001054c7484 opus_encode_native (opus_encoder.c:1845)
4 AppXAudio 0x00000001054c7e50 opus_encode_float (opus_encoder.c:2263)
5 AppXAudio 0x00000001054585e0 -[AppXOpusEncoder encodeAudioBuffer:withCompletion:] (AppXOpusEncoder.m:59)
6 AppXAudio 0x000000010547b358 closure #1 () -> () in closure #1 (__C.AVAudioPCMBuffer, __C.AVAudioTime) -> () in AppXAudio.AppXAudioRecorder.(installTap in _D59F0003FB45C5CBF6B0090245925C5B)() -> () (AppXAudioRecorder.swift:173)
7 AppXAudio 0x000000010545acdc reabstraction thunk helper from @escaping @callee_guaranteed () -> () to @escaping @callee_unowned @convention(block) () -> () (<compiler-generated>:0)
8 libdispatch.dylib 0x000000018322da54 _dispatch_call_block_and_release + 28
9 libdispatch.dylib 0x000000018322f7ec _dispatch_client_callout + 16
10 libdispatch.dylib 0x0000000183236fd4 _dispatch_lane_serial_drain + 616
11 libdispatch.dylib 0x0000000183237bd0 _dispatch_lane_invoke + 400
12 libdispatch.dylib 0x000000018324248c _dispatch_workloop_worker_thread + 760
13 libsystem_pthread.dylib 0x00000001cf05e7a4 _pthread_wqthread + 272
14 libsystem_pthread.dylib 0x00000001cf06574c start_wqthread + 4
```
At this time, we have no more info, but we will update here if there is anything new to add.
[report-2517809400350009999-ea0d674f-525b-46ec-b113-d09d14ad2c93.txt](/uploads/62681068ac46b7d240b8efdc240f581a/report-2517809400350009999-ea0d674f-525b-46ec-b113-d09d14ad2c93.txt)https://gitlab.xiph.org/xiph/opus/-/issues/2355cmake build generates an (almost) empty config.h2022-07-12T14:03:00ZLiviu Androncmake build generates an (almost) empty config.h$ cmake ~/dev/Opus
$ cat opus/config.h
#define PACKAGE_VERSION "1.3.1-91-g7b05f44f"
while the ./configure generated one has over 200 lines.
Maybe only some of the defines are missing, like CPU_INFO_BY_C / ASM:
$ grep -R CPU_INFO_...$ cmake ~/dev/Opus
$ cat opus/config.h
#define PACKAGE_VERSION "1.3.1-91-g7b05f44f"
while the ./configure generated one has over 200 lines.
Maybe only some of the defines are missing, like CPU_INFO_BY_C / ASM:
$ grep -R CPU_INFO_BY_C .
$ grep -R CPU_INFO_BY_ASM .
$ grep -r OPUS_X86_MAY_HAVE_AVX .
./CMakeCache.txt:OPUS_X86_MAY_HAVE_AVX:BOOL=ON
./opus/CMakeFiles/opus.dir/flags.make:C_DEFINES = -DENABLE_ASSERTIONS -DENABLE_HARDENING -DHAVE_ALLOCA_H -DHAVE_CONFIG_H -DOPUS_BUILD -DOPUS_HAVE_RTCD -DOPUS_X86_MAY_HAVE_AVX -DOPUS_X86_MAY_HAVE_SSE -DOPUS_X86_MAY_HAVE_SSE2 -DOPUS_X86_MAY_HAVE_SSE4_1 -DOPUS_X86_PRESUME_SSE -DOPUS_X86_PRESUME_SSE2 -DVAR_ARRAYS -D_FORTIFY_SOURCE=2
./opus/CMakeFiles/opus.dir/DependInfo.cmake: "OPUS_X86_MAY_HAVE_AVX"
Neither of CPU_INFO_BY_C and CPU_INFO_BY_ASM is defined:
[ 84%] Building C object opus/CMakeFiles/opus.dir/celt/x86/x86cpu.c.o
~/dev/Opus/opus/celt/x86/x86cpu.c: In function ‘cpuid’:
~/dev/Opus/opus/celt/x86/x86cpu.c:58:32: warning: unused parameter ‘CPUInfo’ [-Wunused-parameter]
58 | static void cpuid(unsigned int CPUInfo[4], unsigned int InfoType)
| ~~~~~~~~~~~~~^~~~~~~~~~
~dev/Opus/opus/celt/x86/x86cpu.c:58:57: warning: unused parameter ‘InfoType’ [-Wunused-parameter]
58 | static void cpuid(unsigned int CPUInfo[4], unsigned int InfoType)
| ~~~~~~~~~~~~~^~~~~~~~https://gitlab.xiph.org/xiph/opus/-/issues/2353Encoding silence as VOIP results in low-level noise in output of decoder2022-03-08T12:28:21ZFrancis QuiersEncoding silence as VOIP results in low-level noise in output of decoderIn a scenario where speech is followed by pure silence (for example in a VoIP application where the user might mute their microphone), and DTX is disabled, it seems that the Opus (SILK) decoder generates very low-level noise (around -56d...In a scenario where speech is followed by pure silence (for example in a VoIP application where the user might mute their microphone), and DTX is disabled, it seems that the Opus (SILK) decoder generates very low-level noise (around -56dB). I am not sure whether this is a known, and potentially expected/desired behaviour, but I thought I would report it anyway. It feels that it would be nice if the transcoded output in this case could still be pure silence. This is the case if changing the application type from "voip" to "audio". Could you please comment? Many thanks.
Steps to reproduce (environment: Linux Ubuntu 18.04 64-bit, Opus 1.3.1):
```
./autogen.sh
./configure --enable-fixed-point --disable-doc --with-pic
./opus_demo voip 16000 1 64000 speech_and_silence.raw speech_and_silence_output.raw
```
[speech_and_silence.raw](/uploads/14ca8c17d68b6b0322300f53e5d3bdf9/speech_and_silence.raw)
[speech_and_silence_output.raw](/uploads/3caa5cfed4ce43ef1b94e29f6b729d22/speech_and_silence_output.raw)https://gitlab.xiph.org/xiph/opus/-/issues/2352[Question]How to edit metadata without re-encoding ?2021-01-30T21:24:09Zsebma[Question]How to edit metadata without re-encoding ?Hi,
How can I edit metadata without re-encoding ?Hi,
How can I edit metadata without re-encoding ?https://gitlab.xiph.org/xiph/opus/-/issues/2351fixed point compile on armv5te architecture2021-01-16T12:19:50ZDavid Summersfixed point compile on armv5te architectureTrying to compile fixed point on armv5te architecture, using opus 1.3.1. I configure with:
`CPPFLAGS="-D_FORTIFY_SOURCE=2" CFLAGS="-march=armv5te -O2 -pipe -fstack-protector-strong -fno-plt" CXXFLAGS="-march=armv5te -O2 -pipe -fstack-p...Trying to compile fixed point on armv5te architecture, using opus 1.3.1. I configure with:
`CPPFLAGS="-D_FORTIFY_SOURCE=2" CFLAGS="-march=armv5te -O2 -pipe -fstack-protector-strong -fno-plt" CXXFLAGS="-march=armv5te -O2 -pipe -fstack-protector-strong -fno-plt" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro" ./configure --prefix=/usr --disable-static --enable-custom-modes --enable-fixed-point --disable-silent-rules`
The make fails with:
```
gcc -DHAVE_CONFIG_H -I. -I./include -I./celt -I./silk -I./silk/float -I./silk/fixed -D_FORTIFY_SOURCE=2 -march=armv5te -O2 -pipe -fstack-protector-strong -fno-plt -fvisibility=hidden -W -Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes -MT celt/kiss_fft.lo -MD -MP -MF celt/.deps/kiss_fft.Tpo -c celt/kiss_fft.c -fPIC -DPIC -o celt/.libs/kiss_fft.o
{standard input}: Assembler messages:
{standard input}:971: Error: first transfer register must be even -- `ldrd r9,r10,[r3,#-8]'
{standard input}:1148: Error: first transfer register must be even -- `ldrd r5,r6,[r1,fp]'
```
So looks like some faulty machine code for the armv5te architecture. Haven't yet worked out where this machine code is generated ...https://gitlab.xiph.org/xiph/opus/-/issues/2350cmake - add API test for shared library2021-01-08T17:25:15ZMarcus Asteborgcmake - add API test for shared libraryhttps://gitlab.xiph.org/xiph/opus/-/issues/2349When packet loss (less than 30%) exists in the code stream, the decoded resul...2021-01-06T12:40:33ZJie YangWhen packet loss (less than 30%) exists in the code stream, the decoded results will be distorted?When opus is used for codec, if packet loss exists in the code stream, the opus decoding to compensate will occur sound breakage. Especially when the packet loss rate is high, this phenomenon is easy to happen. After many tests, we found...When opus is used for codec, if packet loss exists in the code stream, the opus decoding to compensate will occur sound breakage. Especially when the packet loss rate is high, this phenomenon is easy to happen. After many tests, we found that this abnormal situation would occur at either 16K or 48K sampling rate. We also tried the latest 1.3 version, and unfortunately, this phenomenon hasn't gone away. Now we send you the results of raw data, encoded stream, packet loss and decoding, hoping to get a reply.[data_opus_1.rar](/uploads/bf8412434c03c1982d5112acab866208/data_opus_1.rar)https://gitlab.xiph.org/xiph/opus/-/issues/2346Kiss FFT replacement2023-08-11T06:54:17ZVitaly IvanovKiss FFT replacementI wonder if there are any plans to replace Kiss FFT with much faster pffft? Here's this older issue: https://monorail-staging.appspot.com/p/webrtc/issues/detail?id=3350
I ran some tests myself (although I was using RNNoise), and on my M...I wonder if there are any plans to replace Kiss FFT with much faster pffft? Here's this older issue: https://monorail-staging.appspot.com/p/webrtc/issues/detail?id=3350
I ran some tests myself (although I was using RNNoise), and on my MacBook Pro (i7) opus_fft (complex, N=960, forward) is about 3.5x slower than pffft_transform_orderedhttps://gitlab.xiph.org/xiph/opus/-/issues/2345shared description of public API headers2020-10-27T16:09:01ZRalph Gilesshared description of public API headersWe have a shared list of source files in `*_sources.mk` which are used by all the build systems to reduce the maintenance burden. However, there is no such list of headers, so each build system maintains its own list of files defining th...We have a shared list of source files in `*_sources.mk` which are used by all the build systems to reduce the maintenance burden. However, there is no such list of headers, so each build system maintains its own list of files defining the public API.
In the discussion of !13 it was suggested that we create such a shared definition. @tmp volunteered to propose an implementation.https://gitlab.xiph.org/xiph/opus/-/issues/2344unexpected result using inbandfec in cbr mode.2020-10-12T16:47:40Zwumasterunexpected result using inbandfec in cbr mode.when I use this command:
`voip 16000 1 32000 -framesize 40 -loss 20 -inbandfec -cbr es01_l_16k.pcm out.pcm`
[es01_l_16k.pcm](/uploads/57c337058263bb3f0dafd897c55f82ee/es01_l_16k.pcm)
[out.pcm](/uploads/9ee13b2557c37a0a33470d7360025817/ou...when I use this command:
`voip 16000 1 32000 -framesize 40 -loss 20 -inbandfec -cbr es01_l_16k.pcm out.pcm`
[es01_l_16k.pcm](/uploads/57c337058263bb3f0dafd897c55f82ee/es01_l_16k.pcm)
[out.pcm](/uploads/9ee13b2557c37a0a33470d7360025817/out.pcm)
![image](/uploads/bb3fe48e9d57c6b62ae7daca6b7a9765/image.png)
![image](/uploads/020f2bb24020756f6dba82ec3896be56/image.png)
The output data seems to have a very bad quality. Is this normal?https://gitlab.xiph.org/xiph/opus/-/issues/2343cmake - neon optimizations doesn't compile on rp2020-10-05T21:26:53ZMarcus Asteborgcmake - neon optimizations doesn't compile on rpReference: https://github.com/xiph/opus/issues/203Reference: https://github.com/xiph/opus/issues/203