xiph / opus Goto Github PK
View Code? Open in Web Editor NEWModern audio compression for the internet.
Home Page: https://opus-codec.org/
License: Other
Modern audio compression for the internet.
Home Page: https://opus-codec.org/
License: Other
== Opus audio codec == Opus is a codec for interactive speech and audio transmission over the Internet. Opus can handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even remote live music performances. It can scale from low bit-rate narrowband speech to very high quality stereo music. Opus, when coupled with an appropriate container format, is also suitable for non-realtime stored-file applications such as music distribution, game soundtracks, portable music players, jukeboxes, and other applications that have historically used high latency formats such as MP3, AAC, or Vorbis. Opus is specified by IETF RFC 6716: https://tools.ietf.org/html/rfc6716 The Opus format and this implementation of it are subject to the royalty- free patent and copyright licenses specified in the file COPYING. This package implements a shared library for encoding and decoding raw Opus bitstreams. Raw Opus bitstreams should be used over RTP according to https://tools.ietf.org/html/rfc7587 The package also includes a number of test tools used for testing the correct operation of the library. The bitstreams read/written by these tools should not be used for Opus file distribution: They include additional debugging data and cannot support seeking. Opus stored in files should use the Ogg encapsulation for Opus which is described at: https://tools.ietf.org/html/rfc7845 An opus-tools package is available which provides encoding and decoding of Ogg encapsulated Opus files and includes a number of useful features. Opus-tools can be found at: https://gitlab.xiph.org/xiph/opus-tools.git or on the main Opus website: https://opus-codec.org/ == Deep Learning and Opus == Lossy networks continue to be a challenge for real-time communications. While the original implementation of Opus provides an excellent packet loss concealment mechanism, the team has continued to advance the methodology used to improve audio quality in challenge network environments. In Opus 1.5, we added a deep learning based redundancy encoder that enhances audio in lossy networks by embedding one second of recovery data in the padding data of each packet. The underlying algorithm behind encoding and decoding the recovery data is called the deep redundancy (DRED) algorithm. By leveraging the padding data within the packet, Opus 1.5 is fully backward compatible with prior revisions of Opus. Please see the README under the "dnn" subdirectory to understand DRED. DRED was developed by a team that Amazon Web Services initially sponsored, who open-sourced the implementation as well as began the standardization process at the IETF: https://datatracker.ietf.org/doc/draft-ietf-mlcodec-opus-extension/ The license behind Opus or the intellectual property position of Opus does not change with Opus 1.5. == Compiling libopus == To build from a distribution tarball, you only need to do the following: % ./configure % make To build from the git repository, the following steps are necessary: 0) Set up a development environment: On an Ubuntu or Debian family Linux distribution: % sudo apt-get install git autoconf automake libtool gcc make On a Fedora/Redhat based Linux: % sudo dnf install git autoconf automake libtool gcc make Or for older Redhat/Centos Linux releases: % sudo yum install git autoconf automake libtool gcc make On Apple macOS, install Xcode and brew.sh, then in the Terminal enter: % brew install autoconf automake libtool 1) Clone the repository: % git clone https://gitlab.xiph.org/xiph/opus.git % cd opus 2) Compiling the source % ./autogen.sh % ./configure % make On x86, it's a good idea to use a -march= option that allows the use of AVX2. 3) Install the codec libraries (optional) % sudo make install Once you have compiled the codec, there will be a opus_demo executable in the top directory. Usage: opus_demo [-e] <application> <sampling rate (Hz)> <channels (1/2)> <bits per second> [options] <input> <output> opus_demo -d <sampling rate (Hz)> <channels (1/2)> [options] <input> <output> mode: voip | audio | restricted-lowdelay options: -e : only runs the encoder (output the bit-stream) -d : only runs the decoder (reads the bit-stream as input) -cbr : enable constant bitrate; default: variable bitrate -cvbr : enable constrained variable bitrate; default: unconstrained -bandwidth <NB|MB|WB|SWB|FB> : audio bandwidth (from narrowband to fullband); default: sampling rate -framesize <2.5|5|10|20|40|60> : frame size in ms; default: 20 -max_payload <bytes> : maximum payload size in bytes, default: 1024 -complexity <comp> : complexity, 0 (lowest) ... 10 (highest); default: 10 -inbandfec : enable SILK inband FEC -forcemono : force mono encoding, even for stereo input -dtx : enable SILK DTX -loss <perc> : simulate packet loss, in percent (0-100); default: 0 input and output are little-endian signed 16-bit PCM files or opus bitstreams with simple opus_demo proprietary framing. == Testing == This package includes a collection of automated unit and system tests which SHOULD be run after compiling the package especially the first time it is run on a new platform. To run the integrated tests: % make check There is also collection of standard test vectors which are not included in this package for size reasons but can be obtained from: https://opus-codec.org/docs/opus_testvectors-rfc8251.tar.gz To run compare the code to these test vectors: % curl -OL https://opus-codec.org/docs/opus_testvectors-rfc8251.tar.gz % tar -zxf opus_testvectors-rfc8251.tar.gz % ./tests/run_vectors.sh ./ opus_newvectors 48000 == Compiling libopus for Windows and alternative build systems == See cmake/README.md or meson/README.md. == Portability notes == This implementation uses floating-point by default but can be compiled to use only fixed-point arithmetic by setting --enable-fixed-point (if using autoconf) or by defining the FIXED_POINT macro (if building manually). The fixed point implementation has somewhat lower audio quality and is slower on platforms with fast FPUs, it is normally only used in embedded environments. The implementation can be compiled with either a C89 or a C99 compiler. While it does not rely on any _undefined behavior_ as defined by C89 or C99, it relies on common _implementation-defined behavior_ for two's complement architectures: o Right shifts of negative values are consistent with two's complement arithmetic, so that a>>b is equivalent to floor(a/(2^b)), o For conversion to a signed integer of N bits, the value is reduced modulo 2^N to be within range of the type, o The result of integer division of a negative value is truncated towards zero, and o The compiler provides a 64-bit integer type (a C99 requirement which is supported by most C89 compilers).
NDK compile,opusfile 0.9 opus 1.2.1. android 7.1.1 test.
My own music is converted to opus, always play after 1 second stop.(use opusenc)
use offical website sample But everything is OK!
https://people.xiph.org/~giles/2012/opus/ehren-paper_lights-96.opus
I debug found op_pcm_total func in opusfile.c always return 47880 / 48000 = 0.98sec
Who can tell me if this is a bug?
I've tried various parameters for opusenc and various music. So it shouldn't be a format problem.
By the way, everything is ok at windows
opus-1.2.1
# rpm -qa | grep gcc
libgcc-4.8.5-11.el7.centos.aarch64
gcc-c++-4.8.5-11.el7.centos.aarch64
gcc-gfortran-4.8.5-11.el7.centos.aarch64
gcc-4.8.5-11.el7.centos.aarch64
libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I./include -I./celt -I./silk -I./silk/float -I./silk/fixed -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -fvisibility=hidden -W -Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes -c silk/CNG.c -fPIC -DPIC -o silk/.libs/CNG.o
In file included from celt/arm/celt_neon_intr.c:37:0:
celt/arm/celt_neon_intr.c: In function 'xcorr_kernel_neon_float':
celt/arm/celt_neon_intr.c:137:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
SUMM = vmlaq_lane_f32(SUMM, YY[0], vget_low_f32(XX[0]), 0);
^
celt/arm/celt_neon_intr.c:139:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
SUMM = vmlaq_lane_f32(SUMM, YEXT[0], vget_low_f32(XX[0]), 1);
^
celt/arm/celt_neon_intr.c:141:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
SUMM = vmlaq_lane_f32(SUMM, YEXT[1], vget_high_f32(XX[0]), 0);
^
celt/arm/celt_neon_intr.c:143:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
SUMM = vmlaq_lane_f32(SUMM, YEXT[2], vget_high_f32(XX[0]), 1);
^
celt/arm/celt_neon_intr.c:145:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
SUMM = vmlaq_lane_f32(SUMM, YY[1], vget_low_f32(XX[1]), 0);
^
celt/arm/celt_neon_intr.c:147:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
SUMM = vmlaq_lane_f32(SUMM, YEXT[0], vget_low_f32(XX[1]), 1);
^
celt/arm/celt_neon_intr.c:149:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
SUMM = vmlaq_lane_f32(SUMM, YEXT[1], vget_high_f32(XX[1]), 0);
^
celt/arm/celt_neon_intr.c:151:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
SUMM = vmlaq_lane_f32(SUMM, YEXT[2], vget_high_f32(XX[1]), 1);
^
celt/arm/celt_neon_intr.c:170:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
SUMM = vmlaq_lane_f32(SUMM, YY[0], vget_low_f32(XX[0]), 0);
^
celt/arm/celt_neon_intr.c:172:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
SUMM = vmlaq_lane_f32(SUMM, YEXT[0], vget_low_f32(XX[0]), 1);
^
celt/arm/celt_neon_intr.c:174:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
SUMM = vmlaq_lane_f32(SUMM, YEXT[1], vget_high_f32(XX[0]), 0);
^
celt/arm/celt_neon_intr.c:176:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
SUMM = vmlaq_lane_f32(SUMM, YEXT[2], vget_high_f32(XX[0]), 1);
^
celt/arm/celt_neon_intr.c:184:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
SUMM = vmlaq_lane_f32(SUMM, YY[0], XX_2, 0);
^
celt/arm/celt_neon_intr.c:189:11: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
SUMM = vmlaq_lane_f32(SUMM, YY[0], XX_2, 0);
It seems like that there is no defination of float32x4_t in the current gcc.
I'm trying to use the opus codec with ogg encapsulation in an iOS app. I came so far that I have data encoded into opus but I'm stuck at packaging it with Ogg.
I noticed that when building the 64 bit versions that casts from int32
to 64 bit generates a warning.
Same is true for 32 bit builds saying cast from int64 to int
warning. Might need to review the code or suppress the warnings (they can be annoying.)
I'm trying to experiment with extremely low bitrates and would like to set my frame size to 1000 ms or higher, even if that sounds crazy to you.
I am layman user of the codec. I chanced upon the NE10 switch while trawling the source code to find ways through which I could help improve the audio output performance of ExoPlayer since I was getting audible glitches. This was quite some time back. Meanwhile, it seems that the good folks at Google have added some NEON related things to opus (pardonne moi for my complete ignorance).
I have no idea whether NE10 has any utility any more, and whether removing it would have any impact. Furthermore, is there a need/mechanism to activate the NEON related things added to the codec or are they automatically activated?
Apologies for the dumb queries.
Minor nit.
In the documentation of the ec_dec_uint
function, there is a note that the param "must be at least one, and no more than 2**32-1", so >= 1
. In the implementation of the function we have the following:
opus_uint32 ec_dec_uint(ec_dec *_this,opus_uint32 _ft){
/* [...] */
/*In order to optimize EC_ILOG(), it is undefined for the value 0.*/
celt_assert(_ft>1);
... so requiring >1
for the param.
In calls with DTX enabled there is sometimes an issue with periodic "noise bursts" during the DTX period. The issue appears when the background noise is slighty unstationary. In my experience the problem is common and can be triggered by noise from ventilation etc.
To illustrate the problem I have encoded a 10 seconds long file containing speech and slowly increasing noise.
I encoded the file with opus_demo from master as of May 8th 2018 (commit 1b58446). I used DTX and the highest complexity mode.
./opus_demo voip 48000 1 32000 -complexity 10 -dtx original.raw encoded.raw
libopus 1.3-beta-33-g1b584467
Encoding 48000 Hz input at 32.000 kb/s in auto bandwidth with 960-sample frames.
average bitrate: 15.400 kb/s
maximum bitrate: 64.400 kb/s
active bitrate: 25.930 kb/s
bitrate standard deviation: 17.448 kb/s
The issue can easily be seen in the following spectrograms. The first spectrogram shows the original file with the encoded file below.
The reason for these clicks is a mismatch between two voice activity detectors: the Opus VAD and the Silk VAD.
The Opus VAD decides when to go into DTX. During DTX a packet is transmitted every 420 ms containing an update of the background noise. If the VAD in the Silk layer of the codec considers the signal to be active (type TYPE_UNVOICED
or TYPE_VOICED
instead of TYPE_NO_VOICE_ACTIVITY
) the decoder will conceal the DTX region by using packet loss concealment (PLC) instead of pure comfort noise (CNG). This will case a noise burst every time a packet is decoded.
I have created two competing pull requests: #84 and #87 . The two PRs solve the issue slightly differently.
PR #84 avoids DTX when the Opus and Silk VADs do not agree.
Pros of #84:
Behaves similarly to lower complexity modes (where only the Silk VAD is used).
Cons of #84:
Results in higher bit-rates (in this example DTX is alomost not used at all).
Encoding with opus_demo from pull request 84:
./opus_demo_pr84 voip 48000 1 32000 -complexity 10 -dtx original.raw encoded_pr84.raw
libopus 1.3-beta-34-g2e635837
Encoding 48000 Hz input at 32.000 kb/s in auto bandwidth with 960-sample frames.
average bitrate: 31.296 kb/s
maximum bitrate: 64.400 kb/s
active bitrate: 33.355 kb/s
bitrate standard deviation: 6.355 kb/s
Spectrogram showing the file encoded with PR84
PR #87 passes the result of the Opus VAD to Silk. If the Opus VAD says no activity the maximum value of the Silk VAD is clamped to just below the activity threshold. The Silk encoder then produces a frame with type TYPE_NO_VOICE_ACTIVITY
.
Pros of #87:
Does not alter the decision of when to enter DTX (same bit-rate as master)
Cons of #87:
Slightly more code than #84.
Encoding with opus_demo from pull request 87:
./opus_demo_pr87 voip 48000 1 32000 -complexity 10 -dtx original.raw encoded_pr87.raw
libopus 1.3-beta-34-gdbc27362
Encoding 48000 Hz input at 32.000 kb/s in auto bandwidth with 960-sample frames.
average bitrate: 15.386 kb/s
maximum bitrate: 64.400 kb/s
active bitrate: 25.941 kb/s
bitrate standard deviation: 17.431 kb/s
Spectrogram showing the file encoded with PR87
I made all audio files available here (raw and wav formats):
https://drive.google.com/drive/folders/1wY-_yz5I44QTccmV0lFohTWHVIGH2Vqx
Conclusion:
Both pull requests solves the issue, but the DTX behavior of #87 is more similar to the current DTX behavior. I suggest that #87 is merged to master and #84 is withdrawn.
Hi ,
When I use opus in WICED-Studio-6.0.0.43(http://www.cypress.com/products/wiced-software), it will report compile errors like undefined reference to __aeabi_i2f' , undefined reference to
__aeabi_fdiv' and so on . Do you have any suggestions ? thanks very much.
Hello and congrat for that wonderful project.
I have done a translation of the C header into pascal:
https://github.com/fredvs/uos/blob/master/src/uos_opusfile.pas
op_open_file() is working like charm with op_read().
But with op_open_memory() I have problem: op_read() gives always 0 as result.
Why ?
Thanks.
Fre;D
Using op_open_file()
HandleOP := op_open_memory(BufferURL[0],PipeBufferSize, Err);
op_test_open(StreamIn[x].Data.HandleOP);
I can retrieve the tags infos, all seems ok.
But for reading, using this gives 0 outframes:
outframes :=
op_read_float(Data.HandleOP, at Buffer[0], Wantframesm, nil);
Compiling opus for the armv7 architecture for Android outputs
[armeabi-v7a] Compile arm : opus <= opus_multistream.c
In file included from ./libopus/celt/kiss_fft.h:100:0,
from ./libopus/celt/mdct.h:46,
from ./libopus/celt/modes.h:36,
from ./libopus/src/opus_decoder.c:44:
./libopus/celt/arm/fft_arm.h:37:20: fatal error: config.h: No such file or directory
#include "config.h"
^
compilation terminated.
There is no config.h in the opus sources, except one in the win32 directory which is not applicable for the current build. The offending line is this
#include "config.h"
(https://github.com/xiph/opus/blob/master/celt/arm/fft_arm.h#L36-L37)
Both fft_arm.h and mdct_arm.h have the same config block, and subsequently the same error.
Should we be checking HAVE_CONFIG_H before including the config.h, similar to the check in other files?
The static function celt_fir5 is used only once, at line 214 inside the pitch_downsample
function. There are some minor issues that could warrant a cleanup:
mem
is sort of superflous. It is created on the stack of pitch_downsample and initialized with 0, and passed to celt_fir5 but there only the 0 values are read from mem, and while there is writing to mem afterwards, pitch_downsample never reads that. One could just simply initialize mem0-mem4 with 0 and drop the mem variable entirely, no?I might be missing something and this is all done to nudge the compiler to vectorize which it otherwise wouldn't do, but IMO if that's the case then it would be nice to have a comment in the code.
If DTX is enabled, the Opus codec goes into DTX after 10 frames of inactivity, and then stays in DTX for 20 frames before coding the noise and sending a new frame.
In Silk only mode, DTX is entered after 9 frames of inactivity, and DTX is maintained for 21 frames before coding a new frame.
The behaviour of DTX should not differ depending on modes, and the latter behaviour does not match the macros in define.h:
/* DTX settings */
#define NB_SPEECH_FRAMES_BEFORE_DTX 10 /* eq 200 ms */
#define MAX_CONSECUTIVE_DTX 20 /* eq 400 ms */
Minor nit.
See this place in mathops.h and the cE definition above. We define cE but undef cD.
Hi all,
I used Freac converter which convert a mp3 track to opus then from the opus back to mp3. However, the lengths of the original and converted is now different. Could you give explanation?
Kind regards
Will
Minor nit of the README. It says:
There is also collection of standard test vectors which are not
included in this package for size reasons but can be obtained from:
https://opus-codec.org/testvectors/opus_testvectors.tar.gz
To run compare the code to these test vectors:
% curl -O https://opus-codec.org/testvectors/opus_testvectors.tar.gz
% tar -zxf opus_testvectors.tar.gz
% ./tests/run_vectors.sh ./ opus_testvectors 48000
but curl -O
only gives us an HTML file that tells us that the file has moved permanently to https://opus-codec.org/static/testvectors/opus_testvectors.tar.gz , and tar fails to decompress this.
To fix this, either the URL should be updated, or curl -LO
should be suggested which follows redirects.
Hello,
It would be extremely helpful if the project could be built via CMake. As it is the project can be built under Cygwin or MSYS2, but these environments are not always available. The VS2015 project is thoughtful but MSVC produced libraries sometimes do not work with other compilers (mainly MinGW[-w64]).
I understand this may be some work.
Cheers,
R0b0t1
Regarding that post here:
https://www.reddit.com/r/audiophile/comments/40g900/flac_vs_lossy_compression_opusaacmp3_etc/
Is said that Opus 512 takes more underlying song elements away as compared to lower bitrates.
This link leads here - where a comparison was done about the elements which Opus and other audio codecs remove (Listen to the 256 and 512 Opus samples)
https://soundcloud.com/kingo64-1/sets/lossy-audio-compression-comparisons
So, is it normal that 512 strips away more minor parts than 256?
root@dou-pc:~/opus# make
./celt/arm/arm2gnu.pl < celt/arm/armopts.s > celt/arm/armopts-gnu.S
./celt/arm/arm2gnu.pl < celt/arm/celt_pitch_xcorr_arm.s > celt/arm/celt_pitch_xcorr_arm-gnu.S
make all-recursive
make[1]: Entering directory /root/opus' make[2]: Entering directory
/root/opus'
CC celt/bands.lo
CC celt/celt.lo
CC celt/celt_encoder.lo
CC celt/celt_decoder.lo
CC celt/cwrs.lo
CC celt/entcode.lo
CC celt/entdec.lo
CC celt/entenc.lo
CC celt/kiss_fft.lo
/tmp/ccOBaCHb.s: Assembler messages:
/tmp/ccOBaCHb.s:281: Error: first destination register must be even -- ldrd r5,r6,[lr,fp]' /tmp/ccOBaCHb.s:292: Error: first destination register must be even --
ldrd r5,r6,[r9,fp]'
make[2]: *** [celt/kiss_fft.lo] Error 1
make[2]: Leaving directory /root/opus' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory
/root/opus'
make: *** [all] Error 2
Autotools is pretty severely out-dated, and especially a pain to use on Windows. Some modern alternatives are CMake and Meson. CMake is probably the most popular C/C++ build system today, but it is quite insane (e.g. it is 'stringly typed' and even lists are just semi-colon delimited strings).
Meson is very new, but aims to be a much saner version of CMake. It is gaining popularity and I have implemented a rough version of a meson-based build system for Opus here.
It doesn't do everything your current one does, because honestly whenever I come near a configure.ac
I get angry that anyone could allow such a monstrosity to exist, so I haven't worked out what all the options in the Opus build system are meant to do. But if someone were to explain it they could easily be added.
What do you think?
hello, boys. We have decide to use opus in our product. but the size of lib complied to more than 200KB is also too larger to use. is that any options to cut off the size? we only need speech , music is not necessary, can these part be cut?
I happened to come across this bug with spearmint, available at spearmint.pw. The description of this bug is, when you go to compile opus, the compiler gives out 4 warnings. Here's an excerpt of the warning as it happens:
CC code/opus-1.1/silk/NLSF2A.c
code/opus-1.1/silk/NLSF2A.c: In function ‘silk_NLSF2A’:
code/opus-1.1/silk/NLSF2A.c:121:17: warning: array subscript is above array bounds [-Warray-bounds]
Ptmp = P[ k+1 ] + P[ k ];
^
code/opus-1.1/silk/NLSF2A.c:122:17: warning: array subscript is above array bounds [-Warray-bounds]
Qtmp = Q[ k+1 ] - Q[ k ];
^
code/opus-1.1/silk/NLSF2A.c:121:17: warning: array subscript is above array bounds [-Warray-bounds]
Ptmp = P[ k+1 ] + P[ k ];
^
code/opus-1.1/silk/NLSF2A.c:122:17: warning: array subscript is above array bounds [-Warray-bounds]
Qtmp = Q[ k+1 ] - Q[ k ];
^
This also happens when compiling any project which uses opus, meaning it's probably also a bug with opus.
I'm a passionate music listener, and a game developer, so I deal with a lot of music and sound files.
99.9% of the content that I encountered in my life is in 44.1 kHz sampling rate, but Opus does not support that. I'm really concerned about the resampling.
From the documentation https://wiki.xiph.org/OpusFAQ#But_won.27t_the_resampler_hurt_the_quality.3F_Isn.27t_it_better_to_use_44.1_kHz_directly.3F
The Opus encoder is heavily tuned for 48 kHz now and using it at 44.1 kHz will cause it to make sub-optimal decisions.
Isn't the better solution, is to add a special mode for the 44.1, and tune that mode the same way as 48 is tuned?
Because right now when trying to use Opus with 44.1, we have resampling + lossy compression on top of that. So 2 lossy operations.
If you would provide a tuned version of the encoder for 44.1 mode, then we would have only one lossy operation, which is the encoding, without having to do resampling. I think that would be the best solution.
I strongly believe that if you would add native support for 44.1 sampling rate, then Opus would become much more popular. Because, like I said at the start, at least in my experience, 44.1 is the 99.9% of the audio content flying on the internet, and because of the resampling needed, Opus doesn't seem like a perfect solution, for which I'm still sticking with Vorbis.
The clang static analyzer detects memory leaks due to early returns in opus_compare.c and opus_demo.c.
More info in this bug and patch from the WebKit project:
https://bugs.webkit.org/show_bug.cgi?id=186009
https://trac.webkit.org/changeset/232236
This causes incompatible-pointer compilation warnings with neon intrinsics on 64-bit systems.
Hi. I am on a sse-only machine. I noticed that in test_unit_rotation.c and test_unit_mathops.c some files that could use celt_inner_prod_sse by macro expansion of celt_inner_prod like pitch.c and vq.c are included before pitch_sse.c resulting in errors.
I only changed the order of the includes and it compiles fine. I'm not sure but also could be needed the inclusion of vq.c after pitch.c.
Maybe unrelated, but i don't know much about c/c++ but i like to learn and i wonder why the compiler could mark a macro function as an implicit declaration of that function. ¿do you know?. It happened to me on pitch_sse.h:115.
I think it's not needed but i will atach a build log and a little patch.
Thanks.
original: https://people.xiph.org/~tdaede/Xte.flac
64kbps: https://people.xiph.org/~tdaede/Xt_.opus
192kbps: https://people.xiph.org/~tdaede/Xt2.opus
I am personally unable to ABX this.
I tried compiling this but I got an error at the first place:
$./autogen.sh
Updating build configuration files, please wait....
aclocal: error: aclocal: file 'm4/lt~obsolete.m4' does not exist
autoreconf: aclocal failed with exit status: 1
It complains that there is no m4/lt~obsolete.m4
. Does anyone have an idea?
When compiling Opus using the included VS2015 projects, the opus_strerror
and opus_get_version_string
functions are not exported into the resulting DLL.
This is caused because those functions are implemented in the CELT VS project, which, unlike the Opus project, does not define the DLL_EXPORT
preprocessor symbol (as implemented in 6e96173).
Changing the CELT project properties to also define DLL_EXPORT
causes the functions to be exported as expected.
(EDIT: As pointed out below, this is only a problem with 1.1.3 and has been fixed on master.)
I could be wrong, but in the encoder-specific-ctls I see OPUS_GET_LAST_PACKET_DURATION documented with reference to the number of packets decoded instead of encoded:
_Gets the duration (in samples) of the last packet successfully _decoded* or concealed*
afaik the encoder isn't aware of a decoder so this seems like a typo to me.
Line 699 in 699b643
hi,
i always see a
Inline Assembly Optimizations: . No inline ASM for your platform, please send patches
am i doing something wrong, is there something missing in my building environment?
i'm compiling using msys2, no errors, but no optimization.
at the end it also tells me again:
you appear to be compiling without optimization, if so opus will be very slow
I'm using recent clone of git repository (HEAD of master branch at commit 99aaff5), and I'm noticing some spurious behavior with versions and tags. When I go through typical autoconf procedure (ie, running ./autogen.sh
to create configure
), I note that configure.ac
calls the update_version
script. Looking at that script, I see the following lines:
# We run `git status` before describe here to ensure that we don't get a false
# -dirty from files that have been touched but are not actually altered in the
# working dir.
GIT_VERSION=$(cd "$SRCDIR" && git status > /dev/null 2>&1 \
&& git describe --tags --match 'v*' --dirty 2> /dev/null)
GIT_VERSION=${GIT_VERSION#v}
On my system (Debian Jessie [amd64], with git version 2.1.4), the output of this git call is:
v1.1.1-rc-91-g99aaff59
But that seems a bit ridiculous, as the output of git tag | tail -1
is:
v1.1.2
I suspect there's some issue with the tagging of v1.1.2, also recognizable in that the v1.1.2 tag does NOT show up if I execute git log --decorate=full
, but does show up if I execute git log --decorate=full --tags
. The v1.1.1-rc tag shows up in both cases. I've read about some weird corner cases with tagging on StackOverflow, maybe this is related.
Regardless, it results in the wrong version information being embedded in the autoconf
configured output, which I don't think is a good thing.
I actually discovered this while hunting for another, related bug in versioning, but I'll report that separately.
Trying to compile on Mac after updating to latest version I get this error:
silk/x86/x86_silk_map.c:63:3: Excess elements in array initializer
opus_int (*const SILK_VAD_GETSA_Q8_IMPL[ OPUS_ARCHMASK + 1 ] )(
silk_encoder_state *psEncC,
const opus_int16 pIn[]
) = {
silk_VAD_GetSA_Q8_c, /* non-sse */
silk_VAD_GetSA_Q8_c,
silk_VAD_GetSA_Q8_c,
MAY_HAVE_SSE4_1( silk_VAD_GetSA_Q8 ), /* sse4.1 */
MAY_HAVE_SSE4_1( silk_VAD_GetSA_Q8 ) /* avx */
};
Because OPUS_ARCHMASK appears to be 0.
I took a look at cpu_support.h and indeed it's possible it's set to 0.
So it looks like your initializer list is unsafe, because it ignores checks for OPUS_ARCHMASK
In the file silk/MacroCount.h line 694, shouldn't the return type of the silk_LIMIT_32 function be "opus_int32" instead of "opus_int"? All parameters and the variable used to compute the return value are declared as "opus_int32". Moreover, in the case of other functions from the same file, there is a consistency between these types and the return type of the corresponding functions. I detected this automatically using a CodeSonar plugin.
https://wiki.xiph.org/Opus_Recommended_Settings#Framesize_Tweaking
Increasing the frame duration also slightly improves coding efficiency, but the gain becomes small for frame sizes above 20 ms.
From this I understand that I get better quality from greater frame sizes than 20 ms, but only by a little.
https://wiki.xiph.org/OpusFAQ#What_frame_size_should_I_use.3F
For file encoding, using a frame size larger than 20 ms will usually result in worse quality for the same bitrate because it constrains the encoder in the decisions it can make.
And this says, that I will get worse quality.
So which one is the true?
I'm using on average 96kbps, stereo.
I recommend:
Because without stumbling upon this problem I've always assumed that the best quality is achieved with highest frame size (60ms), but now it seems that 20ms gives better quality?
Perhaps you can make some constant in the header file:
#define OPUS_FRAME_SIZE_BEST_QUALITY 20
I'm asking for a define, in case in a future release of the library would offer some improvements, and for example 60ms would become the better solution than 20ms, in which you would just change
#define OPUS_FRAME_SIZE_BEST_QUALITY 60
and I could use the define in my own codes without worrying which one is the best.
I'm using Manjaro Linux (Arch Linux). After following all the steps the compilation completes successfully but on checking in Terminal
opus reports previous version (1.2.1) which is present in repository.
So...
Opus doesn't seem to like a lot of electronic music... on this sample in particular it's having issues...
Here's the lossless
https://drive.google.com/file/d/1ERvzuTO86OcSTBcI7uOLlrY5dGaTE8Px/view?usp=sharing
Especially near the beginning and middle... near the end the music changes and I don't think it's as audible (but then again, I didn't test the end of the sample much... as I was hearing a lot of artifacting in the beginning and middle)
At 48kbps it has pretty much the same artifacting but MUCH more audible... it's mainly in the 0-1khz range... same with 320kbps
This is the sample encoded with Opus at 48kbps
https://drive.google.com/file/d/1DQrGaXP82Wx1H20nlPKtGY7Fts91i6nh/view?usp=sharing
It's whirling/thumping sounds that I'm hearing... mostly artifacts in the 0-1khz range... at 48kbps it's understandable... but at 320.... not so much
Oh, and here's the ABX test of 320kbps Opus versus lossless
https://i.imgur.com/FIsTWC4.png
It seems to be issues with mostly electronic music... at least, I think...
I used 1.2.1 Opus and VBR
As a comparison to AAC at 48kbps... you can tell it is a lot better because it doesn't have those whirling effects... or at least, drastically reduced
https://drive.google.com/file/d/1R36tsP0NrSxFvekfyeWXSzFMTK_YzkbV/view?usp=sharing
Now, AAC did use about 7% more bitrate overall... but even then... it's a LOT better
Is there a pre analysed R-value for OPUS codec in Full band 48kHZ? I'm trying to calculate MOS and R-factor but I can't seem to get it. There is one calculation shown for G711
I am getting errors in windows build "expression must have a constant value" on ALLOC macro. How to fix that?
I am building Opus 1.2.1
The update_version
script is inexplicably missing from the downloadable tarball (or zip-file) of the last released version (v1.1.2), even when it is present in the repository --- I'm confused / surprised that this is happening, but find it easily reproducible. Per my other recent issue report (#12), I'm running Debian Jessie (amd64) with git version 2.1.4. I download the gzip'd tarball from GitHub as follows:
wget https://github.com/xiph/opus/archive/v1.1.2.tar.gz
tar xzvf v1.1.2.tar.gz
I clone the repo at the same tag as follows:
git clone http://github.com/xiph/opus.git
git checkout tags/v1.1.2
I then compare the list of files between the two (via successive find -type f | sort -k9
), and find that v1.1.2 from the tarball is missing update_version
(as well as the .git
directory, which is obviously to be expected), even though it is present in v1.1.2 tag via git-clone... Weird (at least to me). Please see the output from diff FileList.FromTarBall FileList.FromGitClone
:
120a121,144
> ./.gitattributes
> ./.git/config
> ./.git/description
> ./.git/HEAD
> ./.git/hooks/applypatch-msg.sample
> ./.git/hooks/commit-msg.sample
> ./.git/hooks/post-update.sample
> ./.git/hooks/pre-applypatch.sample
> ./.git/hooks/pre-commit.sample
> ./.git/hooks/prepare-commit-msg.sample
> ./.git/hooks/pre-push.sample
> ./.git/hooks/pre-rebase.sample
> ./.git/hooks/update.sample
> ./.gitignore
> ./.git/index
> ./.git/info/exclude
> ./.git/logs/HEAD
> ./.git/logs/refs/heads/master
> ./.git/logs/refs/remotes/origin/HEAD
> ./.git/objects/pack/pack-80603375c3f957ac617456b999e2240d6ff6d204.idx
> ./.git/objects/pack/pack-80603375c3f957ac617456b999e2240d6ff6d204.pack
> ./.git/packed-refs
> ./.git/refs/heads/master
> ./.git/refs/remotes/origin/HEAD
344a369
> ./update_version
I'm sure you can imagine that there are all kinds of follow-on effects of this missing update_version
script. The configure.ac
script ends up selecting unknown
for the version information, which then gets embedded in the pkg-config
files, and (at least via my method of configuring opus-tools
via PKG_CONFIG_PATH
environmental variables), causing the opus-tools
configure script to fail (as libopus
no longer passes the version check, even though it definitely is the most recent version).
Thoughts on how to correct this, please? I'd presume it's either an issue with the v1.1.2 tag (perhaps related to issue #12 I just submitted), or maybe there's some script that makes the tarballs that is not properly including this update_version
file (though I grep'd throughout the source-tree and couldn't find anything obvious).
Thanks for all your help, as well as a great bunch of libraries (in opus/ogg)!
Is there a way to figure out all the configurable switches/flags/parameters while compiling the codec?
I ask this because NE10 does not find a mention on the website or the README, but seems to be a useful flag while compiling for mobile platforms that support NEON.
In case there is an automated way of figuring out these switches/flags/parameters, please help me point to it (something like a "opus --help" or "man opus").
There are a few files that are applications, and I would recommend moving them to a separate folder, outside of the library folder:
src/opus_compare.c
src/repacketizer_demo.c
It will be more clean if library and demo apps are in separate folders.
https://stackoverflow.com/questions/47555361/are-there-tools-to-repair-opus-file-stream
Summary: there seem to be no [official and supported] way to repair otherwise salvageable opus streams. opusdec seems to be rather anal about the proper format and will not let it repaired. There should be either a switch to allow lax parsing in opusdec or a separate tool which is able to actually pick all the frames from a possibly semi-broken bitmess. Real-life users would really appreciate that.
(Sidenote: xiph webpage and xiph wiki isn't quite consistent where we're suposed to report bugs. I've been sent to trac, or here, or to the mailing list.)
Hello.
I battle with op_callback_open() to use it with Pascal to access url-steaming.
OK, I can use it, assigning a named pipe as "source" and a pre-filled buffer as "initial data".
The callback-set used is op_callbacks:
op_test_callbacks(InPipe, op_callbacks, BufferURL[0], PipeBufferSize, err);
But using in a loop op_read_float, it read to the end of song only if "initial data" was filled completely.
Huh.., this is not streaming, it is downloading then playing...
Is it possible to use a PipeBufferSize < than the whole song (like for web-radio) ?
Thanks.
PS: Of course c code is welcome.
Fre;D
Hi,first of all,thanks for your nice work,this is not a issue,rather a question for a new learner.
the opus's pitch_search module,is it relate to the sample rate?If I just want to use the module for pitch search,is this module need the input sequence to have the same sample rate?
Thanks,expecting your reply!
Hi Opus team,
Recently i want to porting opus in to Android. But there is not any document, resource out there to do so.
Could you please provide a sample Android application which use opus and provide a guide to build opus for Android ?
On Ubuntu 16.04 with fresh clone, I see this error and not being a C developer I don't know how to address it.
opus$ ./autogen.sh
Updating build configuration files, please wait....
configure.ac:38: warning: macro 'AM_PROG_LIBTOOL' not found in library
configure.ac:38: error: possibly undefined macro: AM_PROG_LIBTOOL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
Hi,
I discovered Opus has a PLC mechanism and wanted to use it.
I tried opus_demo in version 1.2.1 and it doesn't really seem to work.
Here is what I do: opus_demo audio 48000 2 70600 -loss 1 input.wav out.wav
Using "voip" instead of "audio" doesn't help.
In any case, I can clearly hear the missing audio (and see silence using audacity).
I tried to debug the demo application and I can clearly see it is passing a NULL pointer but a size > 0 (around opus_demo.c:778), which is what you need to do, according to the documentation.
And that afterwards some processing is taking place which seems related to PLC (e.g. in celt_decode_lost) but I'm not sure what it is actually doing.
Does someone know more about how PLC is working in Opus?
I spend some time looking around but couldn't find useful resources about this.
I suspect it might work or not depending on the audio input, how repetitive it is etc. but would be curious to know the limitations it might have.
In advance, thanks a lot!
Arnaud
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.