Opus issueshttps://gitlab.xiph.org/xiph/opus/-/issues2018-10-12T10:17:30Zhttps://gitlab.xiph.org/xiph/opus/-/issues/2316Assert in celt_decoder when custom modes are disabled2018-10-12T10:17:30ZPhilippe NormandAssert in celt_decoder when custom modes are disabledI can't reproduce this issue outside of WebKit unfortunately. With a libopus built with `--enable-custom-modes=no`, open a youtube video (make sure MediaSource webkit websetting is turned on).
```
Fatal (internal) error in /home/phil/We...I can't reproduce this issue outside of WebKit unfortunately. With a libopus built with `--enable-custom-modes=no`, open a youtube video (make sure MediaSource webkit websetting is turned on).
```
Fatal (internal) error in /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/celt/celt_decoder.c, line 118: assertion failed: st->mode == opus_custom_mode_create(48000, 960, NULL)
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f54bd4e82f1 in __GI_abort () at abort.c:79
#2 0x00007f545143e81f in celt_fatal () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/celt/arch.h:76
#3 0x00007f5451446a65 in validate_celt_decoder () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/celt/celt_decoder.c:118
#4 0x00007f5451446b84 in celt_decode_with_ec () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/celt/celt_decoder.c:867
#5 0x00007f545146d7bf in opus_decode_frame () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/src/opus_decoder.c:518
#6 0x00007f545146eb16 in opus_decode_native () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/src/opus_decoder.c:721
#7 0x00007f545147810a in opus_multistream_decode_native () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/src/opus_multistream_decoder.c:253
#8 0x00007f54514784b9 in opus_multistream_decode () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/libopus-1.3-rc2/src/opus_multistream_decoder.c:398
#9 0x00007f545275c134 in opus_dec_chain_parse_data () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.14.4/ext/opus/gstopusdec.c:630
#10 0x00007f545275d5b3 in gst_opus_dec_handle_frame () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.14.4/ext/opus/gstopusdec.c:908
#11 0x00007f54bf915dc9 in gst_audio_decoder_push_buffers () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.14.4/gst-libs/gst/audio/gstaudiodecoder.c:1540
#12 0x00007f54bf91615b in gst_audio_decoder_chain_forward () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.14.4/gst-libs/gst/audio/gstaudiodecoder.c:1654
#13 0x00007f54bf917377 in gst_audio_decoder_chain () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gst-plugins-base-1.14.4/gst-libs/gst/audio/gstaudiodecoder.c:1914
#14 0x00007f54bfa0daba in gst_pad_chain_data_unchecked () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4322
#15 gst_pad_push_data () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4578
#16 0x00007f54bfa15c32 in gst_pad_push () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4697
#17 0x00007f54bfa0daba in gst_pad_chain_data_unchecked () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4322
#18 gst_pad_push_data () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4578
#19 0x00007f54bfa15c32 in gst_pad_push () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4697
#20 0x00007f54bf9fbcbb in gst_proxy_pad_chain_default () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstghostpad.c:127
#21 0x00007f54bfa0daba in gst_pad_chain_data_unchecked () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4322
#22 gst_pad_push_data () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4578
#23 0x00007f54bfa15c32 in gst_pad_push () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4697
#24 0x00007f54bf9fbcbb in gst_proxy_pad_chain_default () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstghostpad.c:127
#25 0x00007f54c69d892b in webkitMediaSrcChain(_GstPad*, _GstObject*, _GstBuffer*) () from /home/phil/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37
#26 0x00007f54bfa0daba in gst_pad_chain_data_unchecked () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4322
#27 gst_pad_push_data () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4578
#28 0x00007f54bfa15c32 in gst_pad_push () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gstpad.c:4697
#29 0x00007f54bfb13485 in gst_base_src_loop () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/libs/gst/base/gstbasesrc.c:2957
#30 0x00007f54bfa41cb1 in gst_task_func () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer-1.14.4/gst/gsttask.c:332
#31 0x00007f54beb78933 in g_thread_pool_thread_proxy () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/glib-2.54.2/glib/gthreadpool.c:307
#32 0x00007f54beb77fd5 in g_thread_proxy () at /home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/glib-2.54.2/glib/gthread.c:784
#33 0x00007f54c06edf2a in start_thread (arg=0x7f54537fe700) at pthread_create.c:463
#34 0x00007f54bd5a8edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
I don't understand this assert, pointer comparison doesn't make much sense to me in this context.https://gitlab.xiph.org/xiph/opus/-/issues/2317Make usage tracking switchable!2018-11-20T16:57:36ZSven JörnsMake usage tracking switchable!I'm not quite sure if it's true, but in the README from Asterisk
(http://downloads.digium.com/pub/telephony/codec_opus/asterisk-13.0/x86-64/README) states that the Opus codec always sends anonymous usage data to an Asterisk community se...I'm not quite sure if it's true, but in the README from Asterisk
(http://downloads.digium.com/pub/telephony/codec_opus/asterisk-13.0/x86-64/README) states that the Opus codec always sends anonymous usage data to an Asterisk community server.
In the times of the European data protection regulation this is an avoidable problem.
Therefore, the usage tracking should at least be switchable off.https://gitlab.xiph.org/xiph/opus/-/issues/2318Problem with `SATURATE` and `SROUND16 ` macros?2020-06-16T04:19:34ZVikram DattuProblem with `SATURATE` and `SROUND16 ` macros?Please have a look at below macros from celt/fixed_generic.h:
```c
#define SATURATE(x,a) (((x)>(a) ? (a) : (x)<-(a) ? -(a) : (x)))
#define SATURATE16(x) (EXTRACT16((x)>32767 ? 32767 : (x)<-32768 ? -32768 : (x)))
/** Shift by a and rou...Please have a look at below macros from celt/fixed_generic.h:
```c
#define SATURATE(x,a) (((x)>(a) ? (a) : (x)<-(a) ? -(a) : (x)))
#define SATURATE16(x) (EXTRACT16((x)>32767 ? 32767 : (x)<-32768 ? -32768 : (x)))
/** Shift by a and round-to-neareast 32-bit value. Result is a saturated 16-bit value */
#define SROUND16(x,a) EXTRACT16(SATURATE(PSHR32(x,a), 32767));
```
1.
As one can see clearly that macros `SATURATE` and `SATURATE16` are not similar when `SATURATE` is used for value 32767 or 32768.
Shouldn't the macro SATURATE be like:
`#define SATURATE(x,a) (((x)>(a) ? (a) : (x)<-(a + 1) ? -(a + 1) : (x)))`
or is it good as it is?
2.
The macro `SROUND16` uses `SATURATE` with value 32767.
Shouldn't it use SATURATE16 instead as it considers lower bound for 16 bits; -32768 as well?
Please note that this will in turn also enable some platform optimised instructions which saturate the value in certain bits.https://gitlab.xiph.org/xiph/opus/-/issues/2319Opusenc produces broken samples (wrong quantization) with 24-bit source2020-08-09T16:44:10ZstevenleleOpusenc produces broken samples (wrong quantization) with 24-bit source# Original Issue
I was encoding a specific sample of music (24 bits, 48 kHz) with `opusenc` in `opus-tools 0.2 (Opus 1.3)` and noticed a significant artifact in the beginning.
**More description:** You can hear the artifact within 00:01...# Original Issue
I was encoding a specific sample of music (24 bits, 48 kHz) with `opusenc` in `opus-tools 0.2 (Opus 1.3)` and noticed a significant artifact in the beginning.
**More description:** You can hear the artifact within 00:01. It's a broken "boom"-like sound.
Check the image below. The waveform graph has significant changes.
![comparison](/uploads/0d3ce65baebb985497f03086d09e4708/comparison.png)
This is how I encoded:
```
>opusenc sample.flac --bitrate 256 sample.opus
Encoding using libopus 1.3 (audio)
-----------------------------------------------------
Input: 48 kHz, 2 channels
Output: 2 channels (2 coupled)
20ms packets, 256 kbit/s VBR
Preskip: 312
Encoding complete
-----------------------------------------------------
Encoded: 1 minute and 31.1 seconds
Runtime: 1 second
(91.1x realtime)
Wrote: 2993392 bytes, 4555 packets, 94 pages
Bitrate: 261.351 kbit/s (without overhead)
Instant rates: 1.2 to 510.4 kbit/s
(3 to 1276 bytes per packet)
Overhead: 0.576% (container+metadata)
```
# Update
I tried using `FFmpeg` to convert the original file into 16 bits (original is 24 bits).
```
>ffmpeg -i sample.wav -f wav -c pcm_s16le sample_16bit.wav
```
Then I encoded again with the same settings.
```
>opusenc sample_16bit.wav --bitrate 256 sample_16bit.opus
Skipping chunk of type "LIST", length 26
Encoding using libopus 1.3 (audio)
-----------------------------------------------------
Input: 48 kHz, 2 channels
Output: 2 channels (2 coupled)
20ms packets, 256 kbit/s VBR
Preskip: 312
Encoding complete
-----------------------------------------------------
Encoded: 1 minute and 31.1 seconds
Runtime: 1 second
(91.1x realtime)
Wrote: 2990541 bytes, 4555 packets, 94 pages
Bitrate: 261.103 kbit/s (without overhead)
Instant rates: 1.2 to 510.4 kbit/s
(3 to 1276 bytes per packet)
Overhead: 0.576% (container+metadata)
```
The result turned out to be good.
Check the image below. The waveform graph has **no** significant changes now.
![comparison_2](/uploads/119ac4dce2ed78c692075e8d90315457/comparison_2.png)
So there may be issue in quantization of 24-bit (or high bit depth?) samples.
# Sample Download
The updated sample files are [here](https://www.mediafire.com/file/jiat0cn2cjccu2y/sample_new.7z/file).
All source samples are converted to FLAC files for better compression.
The 16-bit sample is converted from the 24-bit one; the 24-bit one is the original, not padded.https://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/2321.exe opens CMD and closes it.2020-06-13T22:50:59ZJose.exe opens CMD and closes it.How can I even open the .exe when it closes right after?How can I even open the .exe when it closes right after?https://gitlab.xiph.org/xiph/opus/-/issues/2322Autogen failed on Cygwin2020-05-25T17:30:32ZredmanmaleAutogen failed on Cygwin`./autogen.sh` failed on Cygwin when trying to build from cloned repo:
```bash
Updating build configuration files, please wait....
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
autoreconf-2.69: libtoo...`./autogen.sh` failed on Cygwin when trying to build from cloned repo:
```bash
Updating build configuration files, please wait....
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
autoreconf-2.69: libtoolize failed with exit status: 1
```
Maybe it's because `ltmain.sh` is a symlink.
Building from tarball (without autogen) works fine.
**Env**
windows 10 x64
autoreconf 2.69
libtoolize 2.4.6
opus 1.3.1https://gitlab.xiph.org/xiph/opus/-/issues/2323Equivalent bitrate calculation is broken for <20ms frame sizes2020-05-26T04:56:56ZHector MartinEquivalent bitrate calculation is broken for <20ms frame sizesThis leads to negative bitrates at smaller frame sizes, which does bad things like making all bands available for intensity stereo coding.
So, for example, encoding with these parameters:
`opusenc --hard-cbr --bitrate 192 --framesize 2...This leads to negative bitrates at smaller frame sizes, which does bad things like making all bands available for intensity stereo coding.
So, for example, encoding with these parameters:
`opusenc --hard-cbr --bitrate 192 --framesize 2.5`
Yields output that, when mono downmixed, sounds completely terrible, which definitely shouldn't happen at those bitrates (phase inversion intensity stereo should not be used).
Fix: [0001-celt_encoder-fix-equivalent-bitrate-calculation-for-.patch](/uploads/0cc8ff9d0576f97bfad81e649c8e67ec/0001-celt_encoder-fix-equivalent-bitrate-calculation-for-.patch)https://gitlab.xiph.org/xiph/opus/-/issues/2324SILK complexity levels 1 and 2 are inconsistent2020-06-01T19:22:07ZFrancis QuiersSILK complexity levels 1 and 2 are inconsistentIn `silk_setup_complexity()`, it seems that the parameters chosen for complexity levels 2 and 3 are mostly swapped (except `nStatesDelayedDecision`)In `silk_setup_complexity()`, it seems that the parameters chosen for complexity levels 2 and 3 are mostly swapped (except `nStatesDelayedDecision`)https://gitlab.xiph.org/xiph/opus/-/issues/2325float to short improvements2020-06-16T14:23:47ZMarcus Asteborgfloat to short improvements[22:58.40] <+jmspeex> xnorpx: About rounding, I actually think the right solution is to write functions that convert whole vectors at a time and then we can just use the normal run-time intrinsics method
[22:59.09] <+jmspeex> BTW, does S...[22:58.40] <+jmspeex> xnorpx: About rounding, I actually think the right solution is to write functions that convert whole vectors at a time and then we can just use the normal run-time intrinsics method
[22:59.09] <+jmspeex> BTW, does SSE2 even have a proper way to round without messing with rounding modeshttps://gitlab.xiph.org/xiph/opus/-/issues/2326undefined behavior in silk_NSQ_del_dec_neon2020-06-14T07:36:42ZRalph Gilesundefined behavior in silk_NSQ_del_dec_neonCompiling for aarch64 with gcc 9.3.0, I get an undefined behaviour warning:
```
silk/arm/NSQ_del_dec_neon_intr.c: In function ‘silk_NSQ_del_dec_neon’:
silk/arm/NSQ_del_dec_neon_intr.c:422:55: warning: iteration 80 invokes undefined behav...Compiling for aarch64 with gcc 9.3.0, I get an undefined behaviour warning:
```
silk/arm/NSQ_del_dec_neon_intr.c: In function ‘silk_NSQ_del_dec_neon’:
silk/arm/NSQ_del_dec_neon_intr.c:422:55: warning: iteration 80 invokes undefined behavior [-Waggressive-loop-optimizations]
422 | NSQ->sLPC_Q14[ i ] = psDelDec->sLPC_Q14[ i ][ Winner_ind ];
| ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
silk/arm/NSQ_del_dec_neon_intr.c:421:9: note: within this loop
421 | for( ; i < NSQ_LPC_BUF_LENGTH; i++ ) {
| ^~~
```https://gitlab.xiph.org/xiph/opus/-/issues/2327CMake - Consistent warning levels between autotools and cmake2020-08-08T17:36:52ZMarcus AsteborgCMake - Consistent warning levels between autotools and cmakeIf things blow up on automake it should blow up on cmakeIf things blow up on automake it should blow up on cmakehttps://gitlab.xiph.org/xiph/opus/-/issues/2328cmake - intrinsics is not enabled for x86 for non windows due to missing defines2022-07-12T14:05:59ZMarcus Asteborgcmake - intrinsics is not enabled for x86 for non windows due to missing defineshttps://gitlab.xiph.org/xiph/opus/-/issues/2329Any plans to make new release?2023-04-20T23:34:55ZTomasz KłoczkoAny plans to make new release?Looks like it is alread +600 commits since last release +year ago.
I think that it would be good to flush currently committed changes and make new release :)Looks like it is alread +600 commits since last release +year ago.
I think that it would be good to flush currently committed changes and make new release :)https://gitlab.xiph.org/xiph/opus/-/issues/2330Make decoder state completely relocatable by avoiding inline pointer to mode2020-08-06T12:42:35ZDan RavivMake decoder state completely relocatable by avoiding inline pointer to modeCurrently, Opus Decoder state can be freely moved in memory in the same process, but it can't e.g. be copied as bytes to be sent across the network and set as a state for another decoder. But it *almost* can! The only thing preventing th...Currently, Opus Decoder state can be freely moved in memory in the same process, but it can't e.g. be copied as bytes to be sent across the network and set as a state for another decoder. But it *almost* can! The only thing preventing this use case is the `mode` pointer at the start of `CELTDecoder`. A clean decoder state on one machine has identical bytes to those of a clean state on another machine with the same architecture, except for possibly the bytes of the `mode` pointer - even when the mode itself is the same.
I'm not sure how to fix this in a way compatible with any custom mode, but it would be nice to be able to do this for the default mode, at least.https://gitlab.xiph.org/xiph/opus/-/issues/2331Enable NEON optimizations for Windows ARM642020-08-09T04:09:13ZMarcus AsteborgEnable NEON optimizations for Windows ARM64Windows on ARM64 uses another header then the general neon one.
AC:
- Enable Neon for Windows ARM in CMake
- Fix includes
- Verify on ARM64 deviceWindows on ARM64 uses another header then the general neon one.
AC:
- Enable Neon for Windows ARM in CMake
- Fix includes
- Verify on ARM64 devicehttps://gitlab.xiph.org/xiph/opus/-/issues/2332cmake - Add OPUS_TARGET_ARCH for crosscompiling from commandline for CMake build2020-11-21T06:59:41ZMarcus Asteborgcmake - Add OPUS_TARGET_ARCH for crosscompiling from commandline for CMake buildCurrently one need to use toolchain file for cross compiling, for easier crosscompiling in CI we can add a option to CMake so all cross compile options can be specified through commandline without the need for toolchain files.Currently one need to use toolchain file for cross compiling, for easier crosscompiling in CI we can add a option to CMake so all cross compile options can be specified through commandline without the need for toolchain files.https://gitlab.xiph.org/xiph/opus/-/issues/2333cmake - Add Doxygen doc generation to CMakebuild2020-08-09T04:24:52ZMarcus Asteborgcmake - Add Doxygen doc generation to CMakebuildhttps://vicrucann.github.io/tutorials/quick-cmake-doxygen/https://vicrucann.github.io/tutorials/quick-cmake-doxygen/https://gitlab.xiph.org/xiph/opus/-/issues/2334cmake - Build all tests and programs for Opus in CMake build2020-08-09T04:24:33ZMarcus Asteborgcmake - Build all tests and programs for Opus in CMake buildAC:
- Add minor unittest for dll and static build
- Add missing programs for dll and static buildAC:
- Add minor unittest for dll and static build
- Add missing programs for dll and static buildhttps://gitlab.xiph.org/xiph/opus/-/issues/2335Remove WINCE define from source2020-11-21T06:59:12ZMarcus AsteborgRemove WINCE define from sourceWINCE is no longer relevant platform and defines can be removed from Opus sourceWINCE is no longer relevant platform and defines can be removed from Opus source