https://wiki.xiph.org/api.php?action=feedcontributions&user=Jmspeex&feedformat=atomXiphWiki - User contributions [en]2024-03-28T09:11:00ZUser contributionsMediaWiki 1.40.1https://wiki.xiph.org/index.php?title=OpusFAQ&diff=16577OpusFAQ2017-06-08T01:07:19Z<p>Jmspeex: /* But won't the resampler hurt the quality? Isn't it better to use 44.1 kHz directly? */</p>
<hr />
<div>[[Image:Opus logo trans.png]]<br />
<br />
If you are looking for info not covered in this FAQ, try the '''[https://opus-codec.org main Opus website]''' or the pages included in the '''[[:Category:Opus|Opus category]]''' of this wiki.<br />
<br />
== General Questions ==<br />
<br />
=== What is Opus? Who created it? ===<br />
<br />
Opus is a totally open, royalty-free, highly versatile audio codec.<br />
<br />
It is primarily designed for interactive speech and music transmission over the Internet, but is also applicable to storage and streaming applications. It incorporates technology from Skype's '''[https://en.wikipedia.org/wiki/SILK SILK]''' codec and Xiph.Org's '''[http://celt-codec.org/ CELT]''' codec. It has been standardized by the '''[https://www.ietf.org/ Internet Engineering Task Force]''' (IETF) as '''[https://tools.ietf.org/html/rfc6716 RFC 6716]'''. <br />
<br />
Opus has been in development since early 2007. Programmers associated with '''[https://xiph.org/ Xiph.Org]''', '''[https://www.skype.com/ Skype]''' and several other organizations have contributed to its development and to the standardization process as part of the '''[https://datatracker.ietf.org/wg/codec/charter/ IETF's Codec Working Group]'''.<br />
<br />
=== How does Opus compare to other codecs? ===<br />
<br />
Opus is distinguished from most high quality formats (eg: [[Vorbis]], AAC, MP3) by having '''[https://tools.ietf.org/html/rfc6716#section-2 low delay]''' (5 ~ 66.5 ms) and distinguished from most low delay formats (eg: [[Speex]], G.711, GSM) by supporting '''[https://tools.ietf.org/html/rfc6716#section-2.1.1 high audio quality]''' (supports narrow-band all the way to full-band audio).<br />
<br />
It '''[https://opus-codec.org/comparison meets or exceeds existing codecs' quality]''' across a wide range of bitrates, and it operates at lower delay than virtually any existing compressed format.<br />
<br />
Most importantly, the Opus format and its reference implementation are both available under '''[https://opus-codec.org/license/ liberal, royalty-free licenses]'''.<br /><br />
This makes it:<br />
* easy to adopt<br />
* compatible with free software<br />
* suitable for use as part of the basic infrastructure of the Internet<br />
<br />
=== Does Opus make all those other lossy codecs obsolete? ===<br />
<br />
Yes.<br />
<br />
From a technical point of view (loss, delay, bitrates, ...) Opus renders '''[[Speex]]''' obsolete and should also replace '''[[Vorbis]]''' and the common proprietary codecs too (e.g. AAC, MP3, ...).<br />
<br />
=== Will Opus replace Vorbis in video files? ===<br />
<br />
For '''[[Ogg]]''' video files (which use the '''[[Theora]]''' video codec), you ''can'' use Opus instead of Vorbis, but the overall size reduction will be minimal and it will break compatibility with existing players.<br />
<br />
For WebM video files, the convention is to use the '''[http://www.webmproject.org/vp9/ VP9 video codec]''' when using Opus as an audio codec.<br />
<br />
=== How do I use Opus? ===<br />
<br />
For now, the best way to '''encode''' audio into Opus files is to use the '''opusenc''' command-line tool from the '''[https://opus-codec.org/downloads/ opus-tools package]'''.<br />
<br />
If you want to encode many files at once (e.g. your music library), try the applications listed in the '''[[OpusSupport|Opus Support]]''' page.<br />
<br />
For rough guidelines on encoding settings, see the '''[[Opus Recommended Settings]]''' page.<br />
<br />
=== What programs support Opus? ===<br />
<br />
Opus decoding support is now included in '''[http://caniuse.com/opus some Internet browsers]''' and '''[[OpusSupport|many applications]]''', including '''[https://www.mozilla.org/firefox Firefox]''', '''[https://www.foobar2000.org/ foobar2000]''' and '''[https://www.videolan.org/vlc/ VLC]''', as well as in frameworks such as '''[https://gstreamer.freedesktop.org/ GStreamer]''' and '''[https://ffmpeg.org/ FFmpeg]'''.<br />
<br />
For real-time applications, Opus support is available in '''[https://www.webrtc.org/ Google's WebRTC codebase]'''.<br />
<br />
Opus is a relatively new codec: '''[[OpusSupport|many more applications]]''' will support it in the near future.<br />
<br />
=== Does Opus support higher sampling rates, such as 96 kHz or 192 kHz? ===<br />
<br />
Yes and no.<br />
<br />
Opus encoding tools like opusenc will happily encode input files that are sampled at 96 or 192 kHz.<br />
<br />
However, files at these rates are internally '''converted to 48 kHz''' and then only frequencies '''up to 20 kHz''' are encoded.<br />
<br />
The reason is simple: lossy codecs are designed to preserve audible details while discarding irrelevant information. Since the human ear can only hear up to 20 kHz at best (usually lower than that), frequency content above 20 kHz is the first thing to go.<br />
<br />
See Monty's '''[https://people.xiph.org/~xiphmont/demo/neil-young.html article]''' for more details.<br />
<br />
If you want a codec to handle higher sampling rates losslessly, use '''[[FLAC]]'''!<br />
<br />
=== What are the licensing requirements? ===<br />
<br />
The reference Opus source code is released under a three-clause BSD license, which is a very permissive Open Source license. Commercial use and distribution (including in proprietary software) is permitted, provided that some basic conditions specified in the license are met. <br />
<br />
Opus is also covered by some patents, for which royalty-free usage rights are granted, under conditions that the authors believe are compatible with (hopefully) all open source licenses, including the GPL (v2 and v3).<br />
<br />
See the '''[https://www.opus-codec.org/license/ Opus Licensing]''' page for details.<br />
<br />
=== Why make Opus free? ===<br />
<br />
On the Internet, protocol and codec standards are part of the common infrastructure everyone builds upon.<br />
<br />
Most of the value of a high-quality standard is the innovation and inter-operation provided by the systems built on top of it. When a few parties have monopoly rights to monetize a standard, that infrastructure stops being so common and everyone else has more reason to use their own solution instead, increasing cost and reducing efficiency.<br />
<br />
Imagine a road system where each type of car could only drive on its own manufacturer's pavement. We all benefit from living in a world where all the roads are connected.<br />
<br />
This is why Opus, unlike many codecs, is free.<br />
<br />
=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===<br />
<br />
No.<br />
<br />
The SILK codec, as submitted by Skype to the IETF, was heavily modified as part of its integration within Opus. The modifications are significant enough that it is not possible to just write a "translator". Even sharing code between Opus and the "old SILK" would be highly complex.<br />
<br />
=== Why not keep the SILK and CELT codecs separate? ===<br />
Opus is more than just two independent codecs with a switch.<br />
<br />
In addition to a [https://en.wikipedia.org/wiki/Linear_predictive_coding Linear Prediction] '''SILK mode''' and an [https://en.wikipedia.org/wiki/Modified_discrete_cosine_transform MDCT] '''CELT mode''' it has a '''hybrid mode''', where speech frequencies up to 8 kHz are encoded with LP while those between 8 and 20 kHz are encoded with MDCT. This is what allows Opus to have such high speech quality around 32 kbps.<br />
<br />
Another advantage of the integration is the ability to switch between these 3 modes seamlessly, without any audible "glitches" and without any out-of-band signalling.<br />
<br />
=== Now that Opus is standardized, will its development stop or can it be further improved? ===<br />
Yes, Opus '''can''' and '''should''' be improved, because unlike most '''[https://en.wikipedia.org/wiki/ITU-T#Key_standards_published_by_ITU ITU-T codecs]''', Opus is only defined in terms of its decoder.<br />
<br />
The encoder can keep evolving as long as the bitstream it produces can be decoded by the reference decoder. This is what made it possible for modern MP3 encoders (e.g. '''[https://en.wikipedia.org/wiki/LAME LAME]''') to improve far beyond the original '''[https://en.wikipedia.org/wiki/L3enc L3enc]''' and '''dist10''' reference implementations.<br />
<br />
Although it is unlikely that Opus encoders will see such a spectacular evolution, we certainly hope that future encoders will become much better than the reference encoder.<br />
<br />
In fact, the 1.1 libopus release significantly improves on the reference encoder's quality. See '''[https://people.xiph.org/~xiphmont/demo/opus/demo3.shtml Monty's demo]''' for more details.<br />
<br />
=== Will all future Opus releases comply with the [https://tools.ietf.org/html/rfc6716 Opus specification]? ===<br />
<br />
Yes.<br />
<br />
=== In what ways is Opus optimized for the Internet? ===<br />
<br />
Opus has good packet loss robustness and concealment, but its optimisations go further.<br />
<br />
One of the first things we've been asked when designing Opus was to make the rate '''really''' adaptable because we never know what kind of rates will be available. This not only meant having a wide range of bitrates, but also being able to vary in small increments.<br />
<br />
This is why Opus scales from about '''6 ''' to '''512 kb/s''', in increments of '''0.4 kb/s''' (one byte with 20 ms frames). Opus can have '''more than 1200 possible bitrates''' while spending only '''11 bits''' signalling the bitrate because UDP already encodes the packet size.<br />
<br />
One last aspect is that Opus is simple to transport over RTP, as can be seen from the [https://tools.ietf.org/html/rfc7587 Opus RTP payload format]. For example, it's possible to decode RTP packets without having even seen the SDP or any out-of-band signalling.<br />
<br />
=== What applications for Android can play Opus? ===<br />
<br />
Right now, there are just a few but that list is fast growing. Please reference [https://android.stackexchange.com/q/37970/7425 this question on android.stackexchange.com]. Feel free to suggest other applications.<br />
<br />
=== When will the next version be released? ===<br />
<br />
When it's done. Seriously, we do not know.<br />
<br />
Opus is not a large project with a fixed release schedule.<br />
<br />
That being said, our '''[https://www.opus-codec.org/downloads/ pre-releases]''' and even the git repositories ('''[https://git.xiph.org/?p=opus.git Xiph]''', '''[https://github.com/xiph/opus GitHub]''') are pretty stable and given proper testing (which you should always do anyway), are safe to distribute.<br />
<br />
Just be aware that the API of new features (that have never been included in a stable release) could potentially still change.<br />
<br />
== Software Developers' Questions ==<br />
<br />
=== On what platforms does Opus run? ===<br />
<br />
The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs.<br />
<br />
Some of the platforms '''[https://mf4.xiph.org/jenkins/view/opus/ on which Opus has been tested]''' include x86, x86-64, ARM, Itanium, Blackfin, and SPARC.<br />
<br />
=== Is there a fixed-point implementation? ===<br />
<br />
Yes.<br />
<br />
The fixed-point and floating-point decoder and encoder implementations are part of the same code base.<br />
<br />
The code defaults to float, so you need to configure with '''--enable-fixed-point''' (or define '''FIXED_POINT''' if not using the configure script) to build the code for fixed-point.<br />
<br />
=== Which implementation should I use? ===<br />
<br />
While the implementation in RFC 6716 is what ''defines'' the standard, it is likely not the best and most up-to-date implementation.<br />
<br />
The [https://opus-codec.org/ Opus] website was set up for the purpose of continually improving the implementation — in terms of speed, encoding quality, device compatibility, etc — while still conforming to the standard.<br />
<br />
All Opus implementations are compatible by definition.<br />
<br />
=== How is supporting Opus different from supporting Speex/G.711/MP3? ===<br />
<br />
Opus has variable frame durations which can change on the fly, so an Opus decoder needs to be ready to accept packets with durations that are '''any multiple of 2.5ms''' up to a '''maximum of 120ms'''. <br />
<br />
The opus encoder and decoder do not need to have matched sampling rates or channel counts. It is recommended to always just decode at the highest rate the hardware supports (e.g. 48kHz stereo) so the user gets the full quality of whatever the far end is sending.<br />
<br />
=== My application doesn't work. Can anyone help me? ===<br />
<br />
It's possible to get help, but before doing so, there are a few basic things to try:<br />
<br />
* Implement your application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus.<br />
* Read the [https://www.opus-codec.org/docs/ Opus documentation].<br />
* Read the [https://git.xiph.org/?p=opus.git;a=blob;f=src/opus_demo.c opus_demo.c] source code to see how to use the encoder and decoder.<br />
<br />
If you still can't solve the problem, the best option is to ask for help on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on the '''#opus''' IRC channel on '''irc.freenode.net'''.<br />
<br />
=== How do I report a bug? ===<br />
<br />
If you think you have found a bug in Opus (and not in your application), please [https://trac.xiph.org/newticket?component=Opus file a bug report].<br />
<br />
Please include a way for us to reproduce the problem. The best way to do this is to provide an input file, along with the opusenc/opusdec/opus_demo command line that causes the bug to occur.<br />
<br />
If the bug cannot be triggered by the command line tools, please provide a simple patch or C file that can help reproduce it. Please also provide any other relevant information, such as OS, CPU, build options, etc.<br />
<br />
Don't hesitate to also contact us on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on [irc://irc.freenode.net/opus IRC].<br />
<br />
=== What is Opus Custom? ===<br />
<br />
Opus Custom is an '''optional''' part of the Opus standard that allows for sampling rates other than 8, 12, 16, 24, or 48 kHz and frame sizes other than multiples of 2.5 ms.<br />
<br />
Opus Custom requires additional out-of-band signalling that Opus does not normally require and disables many of Opus' coding modes. Also, because it is an optional part of the specification, using Opus Custom may lead to compatibility problems.<br />
<br />
For these reasons, '''its use is discouraged''' outside of very specific applications. <br />
<br />
You may want to use Opus Custom for:<br />
<br />
* ultra-low-delay applications, where synchronization with the soundcard buffer is important. <br />
* low-power embedded applications, where compatibility with others is not important.<br />
<br />
For almost all other types of applications, Opus Custom should not be used.<br />
<br />
=== How do I use 44.1 kHz or some other sampling rate not directly supported by Opus? ===<br />
<br />
Tools which read or write Opus should inter-operate with other sampling rates by transparently performing sample rate conversion behind the scenes whenever necessary. In particular, software developers should not use Opus Custom for 44.1 kHz support, except in the very specific circumstances outlined above.<br />
<br />
Note that it's generally preferable for a decoder to output at 48kHz, even when you know the original input was 44.1kHz. This is not only because you can skip resampling, but also because many cheaper audio interfaces have poor quality output for 44.1kHz.<br />
<br />
The '''[https://opus-codec.org/downloads/ opus-tools]''' package source code contains a small, high quality, high performance, BSD licensed '''[https://github.com/xiph/opus-tools/blob/master/src/resample.c resampler]''' which can be used where resampling is required.<br />
<br />
=== But won't the resampler hurt the quality? Isn't it better to use 44.1 kHz directly? ===<br />
<br />
Not really. The quality degradation caused by any reasonable resampler (SoX, libspeexdsp, libsamplerate, ...) is far less than the distortion caused by the best lossy codec at its highest bitrate. If you can't tolerate the quality degradation caused by a good 44.1 ↔ 48 kHz resampler, then you shouldn't be using a lossy codec in the first place. Similarly, the extra CPU spent in the resampler is small compared to the rest of the codec. Not only that, but many soundcards only support 48 kHz on playback, so players can directly play the output rather than resample it to 48 kHz (e.g. for a 44.1 kHz MP3). So effectively, Opus is only shifting the burden of resampling from the decoder side to the encoder side.<br />
<br />
One advantage of supporting only one internal rate is that it makes it possible for Opus to support many features, including efficient speech compression (through SILK) and real-time applications. It also means all the quality tuning effort can be spent on a single configuration, which helps bring even better quality.<br />
<br />
=== How is the bitrate setting used in VBR mode? ===<br />
<br />
Variable bitrate (VBR) mode allows the bitrate to automatically vary over time based on the audio being encoded, in order to achieve a consistent quality.<br />
<br />
The bitrate setting controls the desired quality, on a scale that is calibrated to closely approximate the average bitrate that would be obtained over a large and diverse collection of audio. The actual bitrate of any particular audio stream may be higher or lower than this average.<br />
<br />
=== What frame size should I use? ===<br />
<br />
A '''20ms''' frame size works well for most applications. Smaller frame sizes may be used to achieve lower latency, but have lower quality at a given bitrate.<br />
<br />
Sizes greater than 20 ms increase latency and are generally beneficial only at fairly low bitrates, or when used to reduce external overhead (e.g. by reducing the number of packets that are sent). 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.<br />
<br />
=== Forward Error correction (FEC) doesn't appear to do anything! HELP! ===<br />
<br />
The in-band FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.<br />
<br />
In order to make use of in-band FEC the decoder must delay its output by at least one frame so that it can call the decoder with the decode_fec argument on the ''next'' frame in order to reconstruct the missed frame. This works best if it's integrated with a jitter buffer.<br />
<br />
FEC is only used by the encoder under certain conditions:<br />
* the feature must be enabled via the '''OPUS_SET_INBAND_FEC''' CTL<br />
* the encoder must be told to expect loss via the '''OPUS_SET_PACKET_LOSS_PERC''' CTL<br />
* the codec must be operated in any of the '''Linear Prediction''' or '''Hybrid''' modes<br />
<br />
Frame durations shorter than 10ms and very high bitrates will use the MDCT modes, where FEC is not available.<br />
<br />
Even when FEC is not used, telling the encoder about the expected level of loss will help it make more intelligent decisions. By default, the implementation assumes there is no loss.<br />
<br />
=== I can't use malloc or much stack on my embedded platform. How do I make Opus work? ===<br />
<br />
A normal build of libopus only uses <tt>malloc/free</tt> in the <tt>_create()</tt> and <tt>_destroy()</tt> calls, making it safe for realtime use as long as the codec state is pre-created.<br />
<br />
To build Opus without the references to <tt>malloc/free</tt>, you must:<br />
<br />
* use <tt>init()</tt> calls rather than <tt>create()</tt> calls in your application<br />
* compile with <tt>CFLAGS="-DOVERRIDE_OPUS_ALLOC -DOVERRIDE_OPUS_FREE -D'opus_alloc(x)=NULL' -D'opus_free(x)=NULL' "</tt>.<br />
<br />
If libopus is built with <tt>-DNONTHREADSAFE_PSEUDOSTACK</tt> (instead of <tt>VAR_ARRAYS</tt>, or <tt>USE_ALLOCA</tt>), it will use a user-provided block of heap instead of stack for many things, resulting in much lower stack usage.<br><br />
This makes the resulting library '''non-threadsafe''' and is '''not recommended''' on anything except limited embedded platforms.<br />
<br />
=== How can I ensure that my software interoperates with other software implementing Opus? ===<br />
<br />
For applications using Ogg files, there are some [https://people.xiph.org/~greg/opus_testvectors/ Ogg Opus testvectors] to test decoders and you can test encoders with opusdec. For RTP applications, the opusrtp tool can be useful.<br />
<br />
In general, here's a list of specific issues to check:<br />
* Can your application handle all frame sizes, including changing the frame size from frame to frame?<br />
* Does your application react properly to lost packets, by calling the decoder with a NULL packet?<br />
<br />
=== What is the complexity of Opus? ===<br />
<br />
The complexity of Opus varies by a large amount based on the settings used.<br />
<br />
It depends on the mode, audio bandwidth, number of channels, and even a "complexity knob" that can trade complexity for quality. It will run easily on any recent PC or smartphone. <br />
<br />
For slower embedded CPUs/DSPs, the amount of CPU required will vary depending on the configuration and the exact CPU, so you will need to experiment. Do not expect Opus to run quickly on really slow devices like 8-bit micro-controllers.<br />
<br />
=== Opus is using too much CPU for my application. What can I do? ===<br />
<br />
First don't panic and don't start writing assembly just yet.<br />
<br />
It's possible that you're just not using the right set of options.<br />
<br />
If you're targeting an embedded/mobile platform, chances are the fixed-point build will be faster, so make sure you're using '''--enable-fixed-point''' or defining '''FIXED_POINT''' in the build system.<br />
<br />
Opus also has a complexity option that can trade quality for complexity. The default is highest quality and highest complexity. You can control this using '''OPUS_SET_COMPLEXITY()''' (see the '''[https://www.opus-codec.org/docs/ Documentation]''' for details).<br />
<br />
If all else fails and you need to optimize the Opus code, see the next question.<br />
<br />
=== I would like to optimize/improve/help with Opus. Where should I start? ===<br />
<br />
Please '''[https://www.opus-codec.org/contact/ contact us]''' before you start, or at least before you get too far.<br />
<br />
This will help coordinate the efforts made on Opus and reduce the probability of wasting your time on duplicated effort or going down the wrong path. More details in the '''[[OpusContributing|contributing page]]'''.<br />
<br />
=== Does Opus have an echo canceller like Speex does? ===<br />
<br />
Echo cancellation is completely independent from codecs.<br />
<br />
You can use any echo canceller (including the one from libspeexdsp) along with Opus.<br />
<br />
That being said, among the free acoustic echo cancelers (AEC) we're aware of, the best is probably the Google AEC from the [https://code.google.com/p/webrtc/ WebRTC codebase].<br />
<br />
[[Category:Opus]]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=Opus_Recommended_Settings&diff=16573Opus Recommended Settings2017-05-30T18:34:01Z<p>Jmspeex: </p>
<hr />
<div>= Recommended Bitrates =<br />
Depending on the kind of audio you want to encode with Opus, you may want to use different bitrate (quality) settings.<br />
<br />
The settings in the table below are meant to '''start you off''' with a decent tradeoff between '''good quality''' and '''small file size''' (or '''bitrate usage''', if you're streaming).<br />
<br />
You should test the suggested bitrate by actually '''listening''' to your encoded audio and then:<br />
* tweaking the bitrate '''down''' if you think the quality is good, but the file size (or bitrate) is too big,<br />
* tweaking the bitrate '''up''' if you think the quality is bad, and you can afford having bigger files (or a larger streaming bitrate).<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|-<br />
!Use Case<br />
!Channels<br />
!Bitrate (Kb/s)<br />
!Notes<br />
|-<br />
|Low bandwidth HF/VHF digital radio<br />
|1 (mono)<br />
|Use '''[http://www.rowetel.com/?page_id=452 Codec&nbsp;2]'''<br />
|Opus only supports bitrates '''down to 6&nbsp;Kb/s'''.<br><br />
Codec 2 handles ultra low bitrate speech at '''0.7&nbsp;-&nbsp;3.2&nbsp;Kb/s'''.<br />
|-<br />
|VoIP<br />
|1<br />
|10&nbsp;-&nbsp;24<br />
|10&nbsp;Kb/s will deliver narrowband most of the time, 24&nbsp;Kb/s should give fullband.<br><br />
More details in '''[[Opus_Recommended_Settings#Bandwidth_Transition_Thresholds|the relevant table]]''' further down this page.<br />
|-<br />
|rowspan="2"|Audiobooks / Podcasts<br />
|1<br />
|24<br />
|Bitrates from here on up tend to deliver fullband audio.<br />
|-<br />
|2 (stereo)<br />
|32<br />
|<br />
|-<br />
|Music Streaming / Radio<br />
|2<br />
|64&nbsp;-&nbsp;96<br />
|Opus has better quality than MP3, AAC and [[Vorbis]] at these rates.<br><br />
(listening test results: '''[http://listening-tests.hydrogenaud.io/igorc/results.html 64&nbsp;Kb/s]''', '''[http://listening-test.coresv.net/results.htm 96&nbsp;Kb/s]''')<br />
|-<br />
|rowspan="3"|Music Storage<br />
|2<br />
|96&nbsp;-&nbsp;128<br />
|Opus at 128&nbsp;KB/s (VBR) is pretty much '''[https://en.wikipedia.org/wiki/Transparency_(data_compression) transparent]'''.<br />
|-<br />
|6 (5.1 surround)<br />
|128&nbsp;-&nbsp;256<br />
|rowspan="2"|For surround sound, Opus uses '''[https://xiph.org/~xiphmont/demo/opus/demo3.shtml surround-sound bitrate allocation]'''.<br />
|-<br />
|8 (7.1 surround)<br />
|256&nbsp;-&nbsp;450<br />
|-<br />
|Music Archiving<br />
|1&nbsp;-&nbsp;8<br />
|Use '''[[FLAC]]'''<br />
|If you are archiving audio, use a '''[https://en.wikipedia.org/wiki/Audio_file_format#Lossless_compressed_audio_format lossless audio format]''' to prevent '''[https://en.wikipedia.org/wiki/Generation_loss generation loss]'''.<br />
|}<br />
<br />
= Technical Details =<br />
For the more technical Opus users, here are some details to help you fine-tune your decision on which bitrate best fits your needs.<br />
<br />
== Mono or Stereo ==<br />
Opus tends to start '''downmixing stereo inputs to mono''' from roughly '''24&nbsp;Kb/s and lower'''.<br />
You can check the details in the '''[https://github.com/xiph/opus/blob/master/src/opus_encoder.c#L148 opus_encoder.c]''' source file.<br />
<br />
You can force downmixing at any bitrate by using the following command-line parameters:<br />
<br />
<code>--downmix-mono</code> - downmixes all input channels to mono<br />
<br />
<code>--downmix-stereo</code> - downmixes all input channels to stereo (if there are more than 2 input channels, e.g. surround sound)<br />
<br />
== Bandwidth Transition Thresholds ==<br />
The following table shows rough bitrates that you might want to use to encode audio that has '''[https://tools.ietf.org/html/rfc6716#section-2 limited frequency bandwidths]'''.<br />
This could be useful if your audio has already been bandpassed, or should go through a bandpass filter (e.g. VoIP speech).<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|-<br />
!rowspan="3"|Bandpass Range (Hz)<br />
!colspan="4"|Rough Bitrate Required (Kb/s)<br />
|-<br />
!colspan="2"|Mono<br />
!colspan="2"|Stereo<br />
|-<br />
!Voice<br />
!Music<br />
!Voice<br />
!Music<br />
|-<br />
|style="text-align:right;"|NarrowBand (3&nbsp;-&nbsp;4000)<br />
|12<br />
|15<br />
|?<br />
|?<br />
|-<br />
|style="text-align:right;"|MediumBand (3&nbsp;-&nbsp;6000)<br />
|15<br />
|18-22<br />
|?<br />
|?<br />
|-<br />
|style="text-align:right;"|WideBand (3&nbsp;-&nbsp;8000)<br />
|16-20<br />
|22-28<br />
|?<br />
|?<br />
|-<br />
|style="text-align:right;"|SuperWideBand (3-12000)<br />
|24-28<br />
|28-32<br />
|?<br />
|?<br />
|-<br />
|style="text-align:right;"|FullBand (3-20000)<br />
|28-40<br />
|32-64<br />
|32-64<br />
|64-128<br />
|}<br />
<br />
The details of Opus' bandpass thresholds can be found in the '''[https://github.com/xiph/opus/blob/master/src/opus_encoder.c#L121 opus_encoder.c]''' source file.<br />
<br />
The '''[http://wiki.hydrogenaud.io/index.php?title=Opus HydrogenAudio]''' wiki also has some great information on Opus and its usage.<br />
<br />
== Framesize Tweaking ==<br />
Opus can encode frames of '''2.5''', '''5''', '''10''', '''20''', '''40''', or '''60&nbsp;ms'''. It can also combine multiple frames into packets of '''up to 120&nbsp;ms'''.<br />
<br />
Opus uses a '''20&nbsp;ms''' frame size '''[https://tools.ietf.org/html/rfc6716#section-2.1.4 by default]''', as it gives a decent mix of low latency and good quality.<br />
<br />
For real-time applications, sending fewer packets per second reduces the overall bitrate, since it reduces the overhead from '''[https://en.wikipedia.org/wiki/IPv6_packet#Fixed_header IP]''', '''[https://en.wikipedia.org/wiki/User_Datagram_Protocol#Packet_structure UDP]''', and '''[https://en.wikipedia.org/wiki/Real-time_Transport_Protocol#Packet_header RTP headers]'''.<br />
However, it increases latency and sensitivity to packet losses, as losing one packet constitutes a loss of a bigger chunk of audio.<br />
Unless operating at very low bitrates over RTP, there is no reason to use frame sizes above 20 ms, as those will have slightly lower quality for music encoding.<br />
<br />
For these reasons, the default 20&nbsp;ms frames are a good choice for most applications.<br />
<br />
== Trading Coding Efficiency with CPU Time ==<br />
The Opus encoder uses its maximum algorithmic '''complexity''' setting of '''10''' '''[https://tools.ietf.org/html/rfc6716#section-2.1.5 by default]'''. This means that it does not hesitate to use CPU to give you the best quality encoding at a given bitrate.<br />
<br />
If the CPU usage is too high for the system you are using Opus on, you can try a lower complexity setting. The allowed values span from '''10''' (highest CPU usage and quality) down to '''0''' (lowest CPU usage and quality).<br />
<br />
[[Category:Opus]]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusFAQ&diff=16558OpusFAQ2017-02-14T07:13:28Z<p>Jmspeex: </p>
<hr />
<div>[[Image:Opus logo trans.png]]<br />
<br />
If you are looking for info not covered in this FAQ, try the '''[https://opus-codec.org main Opus website]''' or the pages included in the '''[[:Category:Opus|Opus category]]''' of this wiki.<br />
<br />
== General Questions ==<br />
<br />
=== What is Opus? Who created it? ===<br />
<br />
Opus is a totally open, royalty-free, highly versatile audio codec.<br />
<br />
It is primarily designed for interactive speech and music transmission over the Internet, but is also applicable to storage and streaming applications. It incorporates technology from Skype's '''[https://en.wikipedia.org/wiki/SILK SILK]''' codec and Xiph.Org's '''[http://celt-codec.org/ CELT]''' codec. It has been standardized by the '''[https://www.ietf.org/ Internet Engineering Task Force]''' (IETF) as '''[https://tools.ietf.org/html/rfc6716 RFC 6716]'''. <br />
<br />
Opus has been in development since early 2007. Programmers associated with '''[https://xiph.org/ Xiph.Org]''', '''[https://www.skype.com/ Skype]''' and several other organizations have contributed to its development and to the standardization process as part of the '''[https://datatracker.ietf.org/wg/codec/charter/ IETF's Codec Working Group]'''.<br />
<br />
=== How does Opus compare to other codecs? ===<br />
<br />
Opus is distinguished from most high quality formats (eg: [[Vorbis]], AAC, MP3) by having '''[https://tools.ietf.org/html/rfc6716#section-2 low delay]''' (5 ~ 66.5 ms) and distinguished from most low delay formats (eg: [[Speex]], G.711, GSM) by supporting '''[https://tools.ietf.org/html/rfc6716#section-2.1.1 high audio quality]''' (supports narrow-band all the way to full-band audio).<br />
<br />
It '''[https://opus-codec.org/comparison meets or exceeds existing codecs' quality]''' across a wide range of bitrates, and it operates at lower delay than virtually any existing compressed format.<br />
<br />
Most importantly, the Opus format and its reference implementation are both available under '''[https://opus-codec.org/license/ liberal, royalty-free licenses]'''.<br /><br />
This makes it:<br />
* easy to adopt<br />
* compatible with free software<br />
* suitable for use as part of the basic infrastructure of the Internet<br />
<br />
=== Does Opus make all those other lossy codecs obsolete? ===<br />
<br />
Yes.<br />
<br />
From a technical point of view (loss, delay, bitrates, ...) Opus renders '''[[Speex]]''' obsolete and should also replace '''[[Vorbis]]''' and the common proprietary codecs too (e.g. AAC, MP3, ...).<br />
<br />
=== Will Opus replace Vorbis in video files? ===<br />
<br />
For '''[[Ogg]]''' video files (which use the '''[[Theora]]''' video codec), you ''can'' use Opus instead of Vorbis, but the overall size reduction will be minimal and it will break compatibility with existing players.<br />
<br />
For WebM video files, the convention is to use the '''[http://www.webmproject.org/vp9/ VP9 video codec]''' when using Opus as an audio codec.<br />
<br />
=== How do I use Opus? ===<br />
<br />
For now, the best way to '''encode''' audio into Opus files is to use the '''opusenc''' command-line tool from the '''[https://opus-codec.org/downloads/ opus-tools package]'''.<br />
<br />
If you want to encode many files at once (e.g. your music library), try the applications listed in the '''[[OpusSupport|Opus Support]]''' page.<br />
<br />
For rough guidelines on encoding settings, see the '''[[Opus Recommended Settings]]''' page.<br />
<br />
=== What programs support Opus? ===<br />
<br />
Opus decoding support is now included in '''[http://caniuse.com/opus some Internet browsers]''' and '''[[OpusSupport|many applications]]''', including '''[https://www.mozilla.org/firefox Firefox]''', '''[https://www.foobar2000.org/ foobar2000]''' and '''[https://www.videolan.org/vlc/ VLC]''', as well as in frameworks such as '''[https://gstreamer.freedesktop.org/ GStreamer]''' and '''[https://ffmpeg.org/ FFmpeg]'''.<br />
<br />
For real-time applications, Opus support is available in '''[https://www.webrtc.org/ Google's WebRTC codebase]'''.<br />
<br />
Opus is a relatively new codec: '''[[OpusSupport|many more applications]]''' will support it in the near future.<br />
<br />
=== Does Opus support higher sampling rates, such as 96 kHz or 192 kHz? ===<br />
<br />
Yes and no.<br />
<br />
Opus encoding tools like opusenc will happily encode input files that are sampled at 96 or 192 kHz.<br />
<br />
However, files at these rates are internally '''converted to 48 kHz''' and then only frequencies '''up to 20 kHz''' are encoded.<br />
<br />
The reason is simple: lossy codecs are designed to preserve audible details while discarding irrelevant information. Since the human ear can only hear up to 20 kHz at best (usually lower than that), frequency content above 20 kHz is the first thing to go.<br />
<br />
See Monty's '''[https://people.xiph.org/~xiphmont/demo/neil-young.html article]''' for more details.<br />
<br />
If you want a codec to handle higher sampling rates losslessly, use '''[[FLAC]]'''!<br />
<br />
=== What are the licensing requirements? ===<br />
<br />
The reference Opus source code is released under a three-clause BSD license, which is a very permissive Open Source license. Commercial use and distribution (including in proprietary software) is permitted, provided that some basic conditions specified in the license are met. <br />
<br />
Opus is also covered by some patents, for which royalty-free usage rights are granted, under conditions that the authors believe are compatible with (hopefully) all open source licenses, including the GPL (v2 and v3).<br />
<br />
See the '''[https://www.opus-codec.org/license/ Opus Licensing]''' page for details.<br />
<br />
=== Why make Opus free? ===<br />
<br />
On the Internet, protocol and codec standards are part of the common infrastructure everyone builds upon.<br />
<br />
Most of the value of a high-quality standard is the innovation and inter-operation provided by the systems built on top of it. When a few parties have monopoly rights to monetize a standard, that infrastructure stops being so common and everyone else has more reason to use their own solution instead, increasing cost and reducing efficiency.<br />
<br />
Imagine a road system where each type of car could only drive on its own manufacturer's pavement. We all benefit from living in a world where all the roads are connected.<br />
<br />
This is why Opus, unlike many codecs, is free.<br />
<br />
=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===<br />
<br />
No.<br />
<br />
The SILK codec, as submitted by Skype to the IETF, was heavily modified as part of its integration within Opus. The modifications are significant enough that it is not possible to just write a "translator". Even sharing code between Opus and the "old SILK" would be highly complex.<br />
<br />
=== Why not keep the SILK and CELT codecs separate? ===<br />
Opus is more than just two independent codecs with a switch.<br />
<br />
In addition to a [https://en.wikipedia.org/wiki/Linear_predictive_coding Linear Prediction] '''SILK mode''' and an [https://en.wikipedia.org/wiki/Modified_discrete_cosine_transform MDCT] '''CELT mode''' it has a '''hybrid mode''', where speech frequencies up to 8 kHz are encoded with LP while those between 8 and 20 kHz are encoded with MDCT. This is what allows Opus to have such high speech quality around 32 kbps.<br />
<br />
Another advantage of the integration is the ability to switch between these 3 modes seamlessly, without any audible "glitches" and without any out-of-band signalling.<br />
<br />
=== Now that Opus is standardized, will its development stop or can it be further improved? ===<br />
Yes, Opus '''can''' and '''should''' be improved, because unlike most '''[https://en.wikipedia.org/wiki/ITU-T#Key_standards_published_by_ITU ITU-T codecs]''', Opus is only defined in terms of its decoder.<br />
<br />
The encoder can keep evolving as long as the bitstream it produces can be decoded by the reference decoder. This is what made it possible for modern MP3 encoders (e.g. '''[https://en.wikipedia.org/wiki/LAME LAME]''') to improve far beyond the original '''[https://en.wikipedia.org/wiki/L3enc L3enc]''' and '''dist10''' reference implementations.<br />
<br />
Although it is unlikely that Opus encoders will see such a spectacular evolution, we certainly hope that future encoders will become much better than the reference encoder.<br />
<br />
In fact, the 1.1 libopus release significantly improves on the reference encoder's quality. See '''[https://people.xiph.org/~xiphmont/demo/opus/demo3.shtml Monty's demo]''' for more details.<br />
<br />
=== Will all future Opus releases comply with the [https://tools.ietf.org/html/rfc6716 Opus specification]? ===<br />
<br />
Yes.<br />
<br />
=== In what ways is Opus optimized for the Internet? ===<br />
<br />
Opus has good packet loss robustness and concealment, but its optimisations go further.<br />
<br />
One of the first things we've been asked when designing Opus was to make the rate '''really''' adaptable because we never know what kind of rates will be available. This not only meant having a wide range of bitrates, but also being able to vary in small increments.<br />
<br />
This is why Opus scales from about '''6 ''' to '''512 kb/s''', in increments of '''0.4 kb/s''' (one byte with 20 ms frames). Opus can have '''more than 1200 possible bitrates''' while spending only '''11 bits''' signalling the bitrate because UDP already encodes the packet size.<br />
<br />
One last aspect is that Opus is simple to transport over RTP, as can be seen from the [https://tools.ietf.org/html/rfc7587 Opus RTP payload format]. For example, it's possible to decode RTP packets without having even seen the SDP or any out-of-band signalling.<br />
<br />
=== What applications for Android can play Opus? ===<br />
<br />
Right now, there are just a few but that list is fast growing. Please reference [https://android.stackexchange.com/q/37970/7425 this question on android.stackexchange.com]. Feel free to suggest other applications.<br />
<br />
=== When will the next version be released? ===<br />
<br />
When it's done. Seriously, we do not know.<br />
<br />
Opus is not a large project with a fixed release schedule.<br />
<br />
That being said, our '''[https://www.opus-codec.org/downloads/ pre-releases]''' and even the git repositories ('''[https://git.xiph.org/?p=opus.git Xiph]''', '''[https://github.com/xiph/opus GitHub]''') are pretty stable and given proper testing (which you should always do anyway), are safe to distribute.<br />
<br />
Just be aware that the API of new features (that have never been included in a stable release) could potentially still change.<br />
<br />
== Software Developers' Questions ==<br />
<br />
=== On what platforms does Opus run? ===<br />
<br />
The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs.<br />
<br />
Some of the platforms '''[https://mf4.xiph.org/jenkins/view/opus/ on which Opus has been tested]''' include x86, x86-64, ARM, Itanium, Blackfin, and SPARC.<br />
<br />
=== Is there a fixed-point implementation? ===<br />
<br />
Yes.<br />
<br />
The fixed-point and floating-point decoder and encoder implementations are part of the same code base.<br />
<br />
The code defaults to float, so you need to configure with '''--enable-fixed-point''' (or define '''FIXED_POINT''' if not using the configure script) to build the code for fixed-point.<br />
<br />
=== Which implementation should I use? ===<br />
<br />
While the implementation in RFC 6716 is what ''defines'' the standard, it is likely not the best and most up-to-date implementation.<br />
<br />
The [https://opus-codec.org/ Opus] website was set up for the purpose of continually improving the implementation — in terms of speed, encoding quality, device compatibility, etc — while still conforming to the standard.<br />
<br />
All Opus implementations are compatible by definition.<br />
<br />
=== How is supporting Opus different from supporting Speex/G.711/MP3? ===<br />
<br />
Opus has variable frame durations which can change on the fly, so an Opus decoder needs to be ready to accept packets with durations that are '''any multiple of 2.5ms''' up to a '''maximum of 120ms'''. <br />
<br />
The opus encoder and decoder do not need to have matched sampling rates or channel counts. It is recommended to always just decode at the highest rate the hardware supports (e.g. 48kHz stereo) so the user gets the full quality of whatever the far end is sending.<br />
<br />
=== My application doesn't work. Can anyone help me? ===<br />
<br />
It's possible to get help, but before doing so, there are a few basic things to try:<br />
<br />
* Implement your application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus.<br />
* Read the [https://www.opus-codec.org/docs/ Opus documentation].<br />
* Read the [https://git.xiph.org/?p=opus.git;a=blob;f=src/opus_demo.c opus_demo.c] source code to see how to use the encoder and decoder.<br />
<br />
If you still can't solve the problem, the best option is to ask for help on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on the '''#opus''' IRC channel on '''irc.freenode.net'''.<br />
<br />
=== How do I report a bug? ===<br />
<br />
If you think you have found a bug in Opus (and not in your application), please [https://trac.xiph.org/newticket?component=Opus file a bug report].<br />
<br />
Please include a way for us to reproduce the problem. The best way to do this is to provide an input file, along with the opusenc/opusdec/opus_demo command line that causes the bug to occur.<br />
<br />
If the bug cannot be triggered by the command line tools, please provide a simple patch or C file that can help reproduce it. Please also provide any other relevant information, such as OS, CPU, build options, etc.<br />
<br />
Don't hesitate to also contact us on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on [irc://irc.freenode.net/opus IRC].<br />
<br />
=== What is Opus Custom? ===<br />
<br />
Opus Custom is an '''optional''' part of the Opus standard that allows for sampling rates other than 8, 12, 16, 24, or 48 kHz and frame sizes other than multiples of 2.5 ms.<br />
<br />
Opus Custom requires additional out-of-band signalling that Opus does not normally require and disables many of Opus' coding modes. Also, because it is an optional part of the specification, using Opus Custom may lead to compatibility problems.<br />
<br />
For these reasons, '''its use is discouraged''' outside of very specific applications. <br />
<br />
You may want to use Opus Custom for:<br />
<br />
* ultra-low-delay applications, where synchronization with the soundcard buffer is important. <br />
* low-power embedded applications, where compatibility with others is not important.<br />
<br />
For almost all other types of applications, Opus Custom should not be used.<br />
<br />
=== How do I use 44.1 kHz or some other sampling rate not directly supported by Opus? ===<br />
<br />
Tools which read or write Opus should inter-operate with other sampling rates by transparently performing sample rate conversion behind the scenes whenever necessary. In particular, software developers should not use Opus Custom for 44.1 kHz support, except in the very specific circumstances outlined above.<br />
<br />
Note that it's generally preferable for a decoder to output at 48kHz, even when you know the original input was 44.1kHz. This is not only because you can skip resampling, but also because many cheaper audio interfaces have poor quality output for 44.1kHz.<br />
<br />
The '''[https://opus-codec.org/downloads/ opus-tools]''' package source code contains a small, high quality, high performance, BSD licensed '''[https://github.com/xiph/opus-tools/blob/master/src/resample.c resampler]''' which can be used where resampling is required.<br />
<br />
=== But won't the resampler hurt the quality? Isn't it better to use 44.1 kHz directly? ===<br />
<br />
Not really.<br />
<br />
If you can't tolerate the quality degradation caused by a good 44.1 ↔ 48 kHz resampler, then you shouldn't be using a lossy codec in the first place. Any reasonable resampler will cause far less distortion than even the best lossy codec at its highest bitrate.<br />
<br />
Not only that, but even if you could run Opus at 44.1 kHz, it wouldn't help you. 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. This would result in worse quality than a 48 kHz encoding with resampling. If you've ever noticed that an MP3 encoder sounds worse at 48 kHz than at 44.1 kHz, then it's mostly likely not because of the resampling, but because most MP3 encoders are tuned for 44.1 kHz rather than for 48 kHz.<br />
<br />
=== How is the bitrate setting used in VBR mode? ===<br />
<br />
Variable bitrate (VBR) mode allows the bitrate to automatically vary over time based on the audio being encoded, in order to achieve a consistent quality.<br />
<br />
The bitrate setting controls the desired quality, on a scale that is calibrated to closely approximate the average bitrate that would be obtained over a large and diverse collection of audio. The actual bitrate of any particular audio stream may be higher or lower than this average.<br />
<br />
=== What frame size should I use? ===<br />
<br />
A '''20ms''' frame size works well for most applications. Smaller frame sizes may be used to achieve lower latency, but have lower quality at a given bitrate.<br />
<br />
Sizes greater than 20 ms increase latency and are generally beneficial only at fairly low bitrates, or when used to reduce external overhead (e.g. by reducing the number of packets that are sent). 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.<br />
<br />
=== Forward Error correction (FEC) doesn't appear to do anything! HELP! ===<br />
<br />
The in-band FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.<br />
<br />
In order to make use of in-band FEC the decoder must delay its output by at least one frame so that it can call the decoder with the decode_fec argument on the ''next'' frame in order to reconstruct the missed frame. This works best if it's integrated with a jitter buffer.<br />
<br />
FEC is only used by the encoder under certain conditions:<br />
* the feature must be enabled via the '''OPUS_SET_INBAND_FEC''' CTL<br />
* the encoder must be told to expect loss via the '''OPUS_SET_PACKET_LOSS_PERC''' CTL<br />
* the codec must be operated in any of the '''Linear Prediction''' or '''Hybrid''' modes<br />
<br />
Frame durations shorter than 10ms and very high bitrates will use the MDCT modes, where FEC is not available.<br />
<br />
Even when FEC is not used, telling the encoder about the expected level of loss will help it make more intelligent decisions. By default, the implementation assumes there is no loss.<br />
<br />
=== I can't use malloc or much stack on my embedded platform. How do I make Opus work? ===<br />
<br />
A normal build of libopus only uses <tt>malloc/free</tt> in the <tt>_create()</tt> and <tt>_destroy()</tt> calls, making it safe for realtime use as long as the codec state is pre-created.<br />
<br />
To build Opus without the references to <tt>malloc/free</tt>, you must:<br />
<br />
* use <tt>init()</tt> calls rather than <tt>create()</tt> calls in your application<br />
* compile with <tt>CFLAGS="-DOVERRIDE_OPUS_ALLOC -DOVERRIDE_OPUS_FREE -D'opus_alloc(x)=NULL' -D'opus_free(x)=NULL' "</tt>.<br />
<br />
If libopus is built with <tt>-DNONTHREADSAFE_PSEUDOSTACK</tt> (instead of <tt>VAR_ARRAYS</tt>, or <tt>USE_ALLOCA</tt>), it will use a user-provided block of heap instead of stack for many things, resulting in much lower stack usage.<br><br />
This makes the resulting library '''non-threadsafe''' and is '''not recommended''' on anything except limited embedded platforms.<br />
<br />
=== How can I ensure that my software interoperates with other software implementing Opus? ===<br />
<br />
For applications using Ogg files, there are some [https://people.xiph.org/~greg/opus_testvectors/ Ogg Opus testvectors] to test decoders and you can test encoders with opusdec. For RTP applications, the opusrtp tool can be useful.<br />
<br />
In general, here's a list of specific issues to check:<br />
* Can your application handle all frame sizes, including changing the frame size from frame to frame?<br />
* Does your application react properly to lost packets, by calling the decoder with a NULL packet?<br />
<br />
=== What is the complexity of Opus? ===<br />
<br />
The complexity of Opus varies by a large amount based on the settings used.<br />
<br />
It depends on the mode, audio bandwidth, number of channels, and even a "complexity knob" that can trade complexity for quality. It will run easily on any recent PC or smartphone. <br />
<br />
For slower embedded CPUs/DSPs, the amount of CPU required will vary depending on the configuration and the exact CPU, so you will need to experiment. Do not expect Opus to run quickly on really slow devices like 8-bit micro-controllers.<br />
<br />
=== Opus is using too much CPU for my application. What can I do? ===<br />
<br />
First don't panic and don't start writing assembly just yet.<br />
<br />
It's possible that you're just not using the right set of options.<br />
<br />
If you're targeting an embedded/mobile platform, chances are the fixed-point build will be faster, so make sure you're using '''--enable-fixed-point''' or defining '''FIXED_POINT''' in the build system.<br />
<br />
Opus also has a complexity option that can trade quality for complexity. The default is highest quality and highest complexity. You can control this using '''OPUS_SET_COMPLEXITY()''' (see the '''[https://www.opus-codec.org/docs/ Documentation]''' for details).<br />
<br />
If all else fails and you need to optimize the Opus code, see the next question.<br />
<br />
=== I would like to optimize/improve/help with Opus. Where should I start? ===<br />
<br />
Please '''[https://www.opus-codec.org/contact/ contact us]''' before you start, or at least before you get too far.<br />
<br />
This will help coordinate the efforts made on Opus and reduce the probability of wasting your time on duplicated effort or going down the wrong path. More details in the '''[[OpusContributing|contributing page]]'''.<br />
<br />
=== Does Opus have an echo canceller like Speex does? ===<br />
<br />
Echo cancellation is completely independent from codecs.<br />
<br />
You can use any echo canceller (including the one from libspeexdsp) along with Opus.<br />
<br />
That being said, among the free acoustic echo cancelers (AEC) we're aware of, the best is probably the Google AEC from the [https://code.google.com/p/webrtc/ WebRTC codebase].<br />
<br />
[[Category:Opus]]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusFAQ&diff=16486OpusFAQ2016-11-04T21:44:03Z<p>Jmspeex: </p>
<hr />
<div>[[Image:Opus logo trans.png]]<br />
<br />
If you are looking for info not covered in this FAQ, try the '''[https://opus-codec.org main Opus website]''' or the pages included in the '''[[:Category:Opus|Opus category]]''' of this wiki.<br />
<br />
== General Questions ==<br />
<br />
=== What is Opus? Who created it? ===<br />
<br />
Opus is a totally open, royalty-free, highly versatile audio codec.<br />
<br />
It is primarily designed for interactive speech and music transmission over the Internet, but is also applicable to storage and streaming applications. It incorporates technology from Skype's '''[https://en.wikipedia.org/wiki/SILK SILK]''' codec and Xiph.Org's '''[http://celt-codec.org/ CELT]''' codec. It has been standardized by the '''[https://www.ietf.org/ Internet Engineering Task Force]''' (IETF) as '''[https://tools.ietf.org/html/rfc6716 RFC 6716]'''. <br />
<br />
Opus has been in development since early 2007. Programmers associated with '''[https://xiph.org/ Xiph.Org]''', '''[https://www.skype.com/ Skype]''' and several other organizations have contributed to its development and to the standardization process as part of the '''[https://datatracker.ietf.org/wg/codec/charter/ IETF's Codec Working Group]'''.<br />
<br />
=== How does Opus compare to other codecs? ===<br />
<br />
Opus is distinguished from most high quality formats (eg: [[Vorbis]], AAC, MP3) by having '''[https://tools.ietf.org/html/rfc6716#section-2 low delay]''' (5 ~ 66.5 ms) and distinguished from most low delay formats (eg: [[Speex]], G.711, GSM) by supporting '''[https://tools.ietf.org/html/rfc6716#section-2.1.1 high audio quality]''' (supports narrow-band all the way to full-band audio).<br />
<br />
It '''[https://opus-codec.org/comparison meets or exceeds existing codecs' quality]''' across a wide range of bitrates, and it operates at lower delay than virtually any existing compressed format.<br />
<br />
Most importantly, the Opus format and its reference implementation are both available under '''[https://opus-codec.org/license/ liberal, royalty-free licenses]'''.<br /><br />
This makes it:<br />
* easy to adopt<br />
* compatible with free software<br />
* suitable for use as part of the basic infrastructure of the Internet<br />
<br />
=== Does Opus make all those other lossy codecs obsolete? ===<br />
<br />
Yes.<br />
<br />
From a technical point of view (loss, delay, bitrates, ...) Opus renders '''[[Speex]]''' obsolete and should also replace '''[[Vorbis]]''' and the common proprietary codecs too (e.g. AAC, MP3, ...).<br />
<br />
=== Will Opus replace Vorbis in video files? ===<br />
<br />
For '''[[Ogg]]''' video files (which use the '''[[Theora]]''' video codec), you ''can'' use Opus instead of Vorbis, but the overall size reduction will be minimal and it will break compatibility with existing players.<br />
<br />
For WebM video files, the convention is to use the '''[http://www.webmproject.org/vp9/ VP9 video codec]''' when using Opus as an audio codec.<br />
<br />
=== How do I use Opus? ===<br />
<br />
For now, the best way to '''encode''' audio into Opus files is to use the '''opusenc''' command-line tool from the '''[https://opus-codec.org/downloads/ opus-tools package]'''.<br />
<br />
If you want to encode many files at once (e.g. your music library), try the applications listed in the '''[[OpusSupport|Opus Support]]''' page.<br />
<br />
For rough guidelines on encoding settings, see the '''[[Opus Recommended Settings]]''' page.<br />
<br />
=== What programs support Opus? ===<br />
<br />
Opus decoding support is now included in '''[http://caniuse.com/opus some Internet browsers]''' and '''[[OpusSupport|many applications]]''', including '''[https://www.mozilla.org/firefox Firefox]''', '''[https://www.foobar2000.org/ foobar2000]''' and '''[https://www.videolan.org/vlc/ VLC]''', as well as in frameworks such as '''[https://gstreamer.freedesktop.org/ GStreamer]''' and '''[https://ffmpeg.org/ FFmpeg]'''.<br />
<br />
For real-time applications, Opus support is available in '''[https://www.webrtc.org/ Google's WebRTC codebase]'''.<br />
<br />
Opus is a relatively new codec: '''[[OpusSupport|many more applications]]''' will support it in the near future.<br />
<br />
=== Does Opus support higher sampling rates, such as 96 kHz or 192 kHz? ===<br />
<br />
Yes and no.<br />
<br />
Opus encoding tools like opusenc will happily encode input files that are sampled at 96 or 192 kHz.<br />
<br />
However, files at these rates are internally '''converted to 48 kHz''' and then only frequencies '''up to 20 kHz''' are encoded.<br />
<br />
The reason is simple: lossy codecs are designed to preserve audible details while discarding irrelevant information. Since the human ear can only hear up to 20 kHz at best (usually lower than that), frequency content above 20 kHz is the first thing to go.<br />
<br />
See Monty's '''[https://people.xiph.org/~xiphmont/demo/neil-young.html article]''' for more details.<br />
<br />
If you want a codec to handle higher sampling rates losslessly, use '''[[FLAC]]'''!<br />
<br />
=== What are the licensing requirements? ===<br />
<br />
The reference Opus source code is released under a three-clause BSD license, which is a very permissive Open Source license. Commercial use and distribution (including in proprietary software) is permitted, provided that some basic conditions specified in the license are met. <br />
<br />
Opus is also covered by some patents, for which royalty-free usage rights are granted, under conditions that the authors believe are compatible with (hopefully) all open source licenses, including the GPL (v2 and v3).<br />
<br />
See the '''[https://www.opus-codec.org/license/ Opus Licensing]''' page for details.<br />
<br />
=== Why make Opus free? ===<br />
<br />
On the Internet, protocol and codec standards are part of the common infrastructure everyone builds upon.<br />
<br />
Most of the value of a high-quality standard is the innovation and inter-operation provided by the systems built on top of it. When a few parties have monopoly rights to monetize a standard, that infrastructure stops being so common and everyone else has more reason to use their own solution instead, increasing cost and reducing efficiency.<br />
<br />
Imagine a road system where each type of car could only drive on its own manufacturer's pavement. We all benefit from living in a world where all the roads are connected.<br />
<br />
This is why Opus, unlike many codecs, is free.<br />
<br />
=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===<br />
<br />
No.<br />
<br />
The SILK codec, as submitted by Skype to the IETF, was heavily modified as part of its integration within Opus. The modifications are significant enough that it is not possible to just write a "translator". Even sharing code between Opus and the "old SILK" would be highly complex.<br />
<br />
=== Why not keep the SILK and CELT codecs separate? ===<br />
Opus is more than just two independent codecs with a switch.<br />
<br />
In addition to a [https://en.wikipedia.org/wiki/Linear_predictive_coding Linear Prediction] '''SILK mode''' and an [https://en.wikipedia.org/wiki/Modified_discrete_cosine_transform MDCT] '''CELT mode''' it has a '''hybrid mode''', where speech frequencies up to 8 kHz are encoded with LP while those between 8 and 20 kHz are encoded with MDCT. This is what allows Opus to have such high speech quality around 32 kbps.<br />
<br />
Another advantage of the integration is the ability to switch between these 3 modes seamlessly, without any audible "glitches" and without any out-of-band signalling.<br />
<br />
=== Now that Opus is standardized, will its development stop or can it be further improved? ===<br />
Yes, Opus '''can''' and '''should''' be improved, because unlike most '''[https://en.wikipedia.org/wiki/ITU-T#Key_standards_published_by_ITU ITU-T codecs]''', Opus is only defined in terms of its decoder.<br />
<br />
The encoder can keep evolving as long as the bitstream it produces can be decoded by the reference decoder. This is what made it possible for modern MP3 encoders (e.g. '''[https://en.wikipedia.org/wiki/LAME LAME]''') to improve far beyond the original '''[https://en.wikipedia.org/wiki/L3enc L3enc]''' and '''dist10''' reference implementations.<br />
<br />
Although it is unlikely that Opus encoders will see such a spectacular evolution, we certainly hope that future encoders will become much better than the reference encoder.<br />
<br />
In fact, the 1.1 libopus release significantly improves on the reference encoder's quality. See '''[https://people.xiph.org/~xiphmont/demo/opus/demo3.shtml Monty's demo]''' for more details.<br />
<br />
=== Will all future Opus releases comply with the [https://tools.ietf.org/html/rfc6716 Opus specification]? ===<br />
<br />
Yes.<br />
<br />
=== In what ways is Opus optimized for the Internet? ===<br />
<br />
Opus has good packet loss robustness and concealment, but its optimisations go further.<br />
<br />
One of the first things we've been asked when designing Opus was to make the rate '''really''' adaptable because we never know what kind of rates will be available. This not only meant having a wide range of bitrates, but also being able to vary in small increments.<br />
<br />
This is why Opus scales from about '''6 ''' to '''512 kb/s''', in increments of '''0.4 kb/s''' (one byte with 20 ms frames). Opus can have '''more than 1200 possible bitrates''' while spending only '''11 bits''' signalling the bitrate because UDP already encodes the packet size.<br />
<br />
One last aspect is that Opus is simple to transport over RTP, as can be seen from the [https://tools.ietf.org/html/rfc7587 Opus RTP payload format]. For example, it's possible to decode RTP packets without having even seen the SDP or any out-of-band signalling.<br />
<br />
=== What applications for Android can play Opus? ===<br />
<br />
Right now, there are just a few but that list is fast growing. Please reference [https://android.stackexchange.com/q/37970/7425 this question on android.stackexchange.com]. Feel free to suggest other applications.<br />
<br />
=== When will the next version be released? ===<br />
<br />
When it's done. Seriously, we do not know.<br />
<br />
Opus is not a large project with a fixed release schedule.<br />
<br />
That being said, our '''[https://www.opus-codec.org/downloads/ pre-releases]''' and even the git repositories ('''[https://git.xiph.org/?p=opus.git Xiph]''', '''[https://github.com/xiph/opus GitHub]''') are pretty stable and given proper testing (which you should always do anyway), are safe to distribute.<br />
<br />
Just be aware that the API of new features (that have never been included in a stable release) could potentially still change.<br />
<br />
== Software Developers' Questions ==<br />
<br />
=== On what platforms does Opus run? ===<br />
<br />
The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs.<br />
<br />
Some of the platforms '''[https://mf4.xiph.org/jenkins/view/opus/ on which Opus has been tested]''' include x86, x86-64, ARM, Itanium, Blackfin, and SPARC.<br />
<br />
=== Is there a fixed-point implementation? ===<br />
<br />
Yes.<br />
<br />
The fixed-point and floating-point decoder and encoder implementations are part of the same code base.<br />
<br />
The code defaults to float, so you need to configure with '''--enable-fixed-point''' (or define '''FIXED_POINT''' if not using the configure script) to build the code for fixed-point.<br />
<br />
=== Which implementation should I use? ===<br />
<br />
While the implementation in RFC 6716 is what ''defines'' the standard, it is likely not the best and most up-to-date implementation.<br />
<br />
The [https://opus-codec.org/ Opus] website was set up for the purpose of continually improving the implementation — in terms of speed, encoding quality, device compatibility, etc — while still conforming to the standard.<br />
<br />
All Opus implementations are compatible by definition.<br />
<br />
=== How is supporting Opus different from supporting Speex/G.711/MP3? ===<br />
<br />
Opus has variable frame durations which can change on the fly, so an Opus decoder needs to be ready to accept packets with durations that are '''any multiple of 2.5ms''' up to a '''maximum of 120ms'''. <br />
<br />
The opus encoder and decoder do not need to have matched sampling rates or channel counts. It is recommended to always just decode at the highest rate the hardware supports (e.g. 48kHz stereo) so the user gets the full quality of whatever the far end is sending.<br />
<br />
=== My application doesn't work. Can anyone help me? ===<br />
<br />
It's possible to get help, but before doing so, there are a few basic things to try:<br />
<br />
* Implement your application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus.<br />
* Read the [https://www.opus-codec.org/docs/ Opus documentation].<br />
* Read the [https://git.xiph.org/?p=opus.git;a=blob;f=src/opus_demo.c opus_demo.c] source code to see how to use the encoder and decoder.<br />
<br />
If you still can't solve the problem, the best option is to ask for help on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on the '''#opus''' IRC channel on '''irc.freenode.net'''.<br />
<br />
=== How do I report a bug? ===<br />
<br />
If you think you have found a bug in Opus (and not in your application), please [https://trac.xiph.org/newticket?component=Opus file a bug report].<br />
<br />
Please include a way for us to reproduce the problem. The best way to do this is to provide an input file, along with the opusenc/opusdec/opus_demo command line that causes the bug to occur.<br />
<br />
If the bug cannot be triggered by the command line tools, please provide a simple patch or C file that can help reproduce it. Please also provide any other relevant information, such as OS, CPU, build options, etc.<br />
<br />
Don't hesitate to also contact us on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on [irc://irc.freenode.net/opus IRC].<br />
<br />
=== What is Opus Custom? ===<br />
<br />
Opus Custom is an '''optional''' part of the Opus standard that allows for sampling rates other than 8, 12, 16, 24, or 48 kHz and frame sizes other than multiples of 2.5 ms.<br />
<br />
Opus Custom requires additional out-of-band signalling that Opus does not normally require and disables many of Opus' coding modes. Also, because it is an optional part of the specification, using Opus Custom may lead to compatibility problems.<br />
<br />
For these reasons, '''its use is discouraged''' outside of very specific applications. <br />
<br />
You may want to use Opus Custom for:<br />
<br />
* ultra-low-delay applications, where synchronization with the soundcard buffer is important. <br />
* low-power embedded applications, where compatibility with others is not important.<br />
<br />
For almost all other types of applications, Opus Custom should not be used.<br />
<br />
=== How do I use 44.1 kHz or some other sampling rate not directly supported by Opus? ===<br />
<br />
Tools which read or write Opus should inter-operate with other sampling rates by transparently performing sample rate conversion behind the scenes whenever necessary. In particular, software developers should not use Opus Custom for 44.1 kHz support, except in the very specific circumstances outlined above.<br />
<br />
Note that it's generally preferable for a decoder to output at 48kHz, even when you know the original input was 44.1kHz. This is not only because you can skip resampling, but also because many cheaper audio interfaces have poor quality output for 44.1kHz.<br />
<br />
The '''[https://opus-codec.org/downloads/ opus-tools]''' package source code contains a small, high quality, high performance, BSD licensed resampler which can be used where resampling is required.<br />
<br />
=== But won't the resampler hurt the quality? Isn't it better to use 44.1 kHz directly? ===<br />
<br />
Short answer: No.<br />
<br />
Longer answer: If you can't tolerate the quality degradation caused by a good 44.1->48 kHz resampler, then you shouldn't be using a lossy codec in the first place. Any reasonable resampler will cause far less distortion that even the best lossy codec at high bitrate. Not only that, but even if you could run Opus at 44.1 kHz, it wouldn't help you. 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. This would result in worse quality than a 48 kHz encoding with resampling. If you've ever noticed that an MP3 encoder sounds worse at 48 kHz than at 44.1 kHz, then it's mostly likely not because of the resampling, but because most MP3 encoders are tuned for 44.1 kHz rather than for 48 kHz.<br />
<br />
=== How is the bitrate setting used in VBR mode? ===<br />
<br />
Variable bitrate (VBR) mode allows the bitrate to automatically vary over time based on the audio being encoded, in order to achieve a consistent quality.<br />
<br />
The bitrate setting controls the desired quality, on a scale that is calibrated to closely approximate the average bitrate that would be obtained over a large and diverse collection of audio. The actual bitrate of any particular audio stream may be higher or lower than this average.<br />
<br />
=== What frame size should I use? ===<br />
<br />
A '''20ms''' frame size works well for most applications.<br />
<br />
Smaller frame sizes may be used to achieve lower latency, but have lower quality at a given bitrate.<br />
<br />
Sizes greater than 20 ms increase latency and are generally beneficial only at fairly low bitrates, or when used to reduce external overhead (e.g. by reducing the number of packets that are sent).<br />
<br />
=== Forward Error correction (FEC) doesn't appear to do anything! HELP! ===<br />
<br />
The in-band FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.<br />
<br />
In order to make use of in-band FEC the decoder must delay its output by at least one frame so that it can call the decoder with the decode_fec argument on the ''next'' frame in order to reconstruct the missed frame. This works best if it's integrated with a jitter buffer.<br />
<br />
FEC is only used by the encoder under certain conditions:<br />
* the feature must be enabled via the '''OPUS_SET_INBAND_FEC''' CTL<br />
* the encoder must be told to expect loss via the '''OPUS_SET_PACKET_LOSS_PERC''' CTL<br />
* the codec must be operated in any of the '''Linear Prediction''' or '''Hybrid''' modes<br />
<br />
Frame durations shorter than 10ms and very high bitrates will use the MDCT modes, where FEC is not available.<br />
<br />
Even when FEC is not used, telling the encoder about the expected level of loss will help it make more intelligent decisions. By default, the implementation assumes there is no loss.<br />
<br />
=== I can't use malloc or much stack on my embedded platform. How do I make Opus work? ===<br />
<br />
A normal build of libopus only uses <tt>malloc/free</tt> in the <tt>_create()</tt> and <tt>_destroy()</tt> calls, making it safe for realtime use as long as the codec state is pre-created.<br />
<br />
To build Opus without the references to <tt>malloc/free</tt>, you must:<br />
<br />
* use <tt>init()</tt> calls rather than <tt>create()</tt> calls in your application<br />
* compile with <tt>CFLAGS="-DOVERRIDE_OPUS_ALLOC -DOVERRIDE_OPUS_FREE -D'opus_alloc(x)=NULL' -D'opus_free(x)=NULL' "</tt>.<br />
<br />
If libopus is built with <tt>-DNONTHREADSAFE_PSEUDOSTACK</tt> (instead of <tt>VAR_ARRAYS</tt>, or <tt>USE_ALLOCA</tt>), it will use a user-provided block of heap instead of stack for many things, resulting in much lower stack usage.<br><br />
This makes the resulting library '''non-threadsafe''' and is '''not recommended''' on anything except limited embedded platforms.<br />
<br />
=== How can I ensure that my software interoperates with other software implementing Opus? ===<br />
<br />
For applications using Ogg files, there are some [https://people.xiph.org/~greg/opus_testvectors/ Ogg Opus testvectors] to test decoders and you can test encoders with opusdec. For RTP applications, the opusrtp tool can be useful.<br />
<br />
In general, here's a list of specific issues to check:<br />
* Can your application handle all frame sizes, including changing the frame size from frame to frame?<br />
* Does your application react properly to lost packets, by calling the decoder with a NULL packet?<br />
<br />
=== What is the complexity of Opus? ===<br />
<br />
The complexity of Opus varies by a large amount based on the settings used.<br />
<br />
It depends on the mode, audio bandwidth, number of channels, and even a "complexity knob" that can trade complexity for quality. It will run easily on any recent PC or smartphone. <br />
<br />
For slower embedded CPUs/DSPs, the amount of CPU required will vary depending on the configuration and the exact CPU, so you will need to experiment. Do not expect Opus to run quickly on really slow devices like 8-bit micro-controllers.<br />
<br />
=== Opus is using too much CPU for my application. What can I do? ===<br />
<br />
First don't panic and don't start writing assembly just yet.<br />
<br />
It's possible that you're just not using the right set of options.<br />
<br />
If you're targeting an embedded/mobile platform, chances are the fixed-point build will be faster, so make sure you're using '''--enable-fixed-point''' or defining '''FIXED_POINT''' in the build system.<br />
<br />
Opus also has a complexity option that can trade quality for complexity. The default is highest quality and highest complexity. You can control this using '''OPUS_SET_COMPLEXITY()''' (see the '''[https://www.opus-codec.org/docs/ Documentation]''' for details).<br />
<br />
If all else fails and you need to optimize the Opus code, see the next question.<br />
<br />
=== I would like to optimize/improve/help with Opus. Where should I start? ===<br />
<br />
Please '''[https://www.opus-codec.org/contact/ contact us]''' before you start, or at least before you get too far.<br />
<br />
This will help coordinate the efforts made on Opus and reduce the probability of wasting your time on duplicated effort or going down the wrong path. More details in the '''[[OpusContributing|contributing page]]'''.<br />
<br />
=== Does Opus have an echo canceller like Speex does? ===<br />
<br />
Echo cancellation is completely independent from codecs.<br />
<br />
You can use any echo canceller (including the one from libspeexdsp) along with Opus.<br />
<br />
That being said, among the free acoustic echo cancelers (AEC) we're aware of, the best is probably the Google AEC from the [https://code.google.com/p/webrtc/ WebRTC codebase].<br />
<br />
[[Category:Opus]]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusFAQ&diff=16485OpusFAQ2016-11-04T21:43:28Z<p>Jmspeex: 44.1 vs 48 kHz</p>
<hr />
<div>[[Image:Opus logo trans.png]]<br />
<br />
If you are looking for info not covered in this FAQ, try the '''[https://opus-codec.org main Opus website]''' or the pages included in the '''[[:Category:Opus|Opus category]]''' of this wiki.<br />
<br />
== General Questions ==<br />
<br />
=== What is Opus? Who created it? ===<br />
<br />
Opus is a totally open, royalty-free, highly versatile audio codec.<br />
<br />
It is primarily designed for interactive speech and music transmission over the Internet, but is also applicable to storage and streaming applications. It incorporates technology from Skype's '''[https://en.wikipedia.org/wiki/SILK SILK]''' codec and Xiph.Org's '''[http://celt-codec.org/ CELT]''' codec. It has been standardized by the '''[https://www.ietf.org/ Internet Engineering Task Force]''' (IETF) as '''[https://tools.ietf.org/html/rfc6716 RFC 6716]'''. <br />
<br />
Opus has been in development since early 2007. Programmers associated with '''[https://xiph.org/ Xiph.Org]''', '''[https://www.skype.com/ Skype]''' and several other organizations have contributed to its development and to the standardization process as part of the '''[https://datatracker.ietf.org/wg/codec/charter/ IETF's Codec Working Group]'''.<br />
<br />
=== How does Opus compare to other codecs? ===<br />
<br />
Opus is distinguished from most high quality formats (eg: [[Vorbis]], AAC, MP3) by having '''[https://tools.ietf.org/html/rfc6716#section-2 low delay]''' (5 ~ 66.5 ms) and distinguished from most low delay formats (eg: [[Speex]], G.711, GSM) by supporting '''[https://tools.ietf.org/html/rfc6716#section-2.1.1 high audio quality]''' (supports narrow-band all the way to full-band audio).<br />
<br />
It '''[https://opus-codec.org/comparison meets or exceeds existing codecs' quality]''' across a wide range of bitrates, and it operates at lower delay than virtually any existing compressed format.<br />
<br />
Most importantly, the Opus format and its reference implementation are both available under '''[https://opus-codec.org/license/ liberal, royalty-free licenses]'''.<br /><br />
This makes it:<br />
* easy to adopt<br />
* compatible with free software<br />
* suitable for use as part of the basic infrastructure of the Internet<br />
<br />
=== Does Opus make all those other lossy codecs obsolete? ===<br />
<br />
Yes.<br />
<br />
From a technical point of view (loss, delay, bitrates, ...) Opus renders '''[[Speex]]''' obsolete and should also replace '''[[Vorbis]]''' and the common proprietary codecs too (e.g. AAC, MP3, ...).<br />
<br />
=== Will Opus replace Vorbis in video files? ===<br />
<br />
For '''[[Ogg]]''' video files (which use the '''[[Theora]]''' video codec), you ''can'' use Opus instead of Vorbis, but the overall size reduction will be minimal and it will break compatibility with existing players.<br />
<br />
For WebM video files, the convention is to use the '''[http://www.webmproject.org/vp9/ VP9 video codec]''' when using Opus as an audio codec.<br />
<br />
=== How do I use Opus? ===<br />
<br />
For now, the best way to '''encode''' audio into Opus files is to use the '''opusenc''' command-line tool from the '''[https://opus-codec.org/downloads/ opus-tools package]'''.<br />
<br />
If you want to encode many files at once (e.g. your music library), try the applications listed in the '''[[OpusSupport|Opus Support]]''' page.<br />
<br />
For rough guidelines on encoding settings, see the '''[[Opus Recommended Settings]]''' page.<br />
<br />
=== What programs support Opus? ===<br />
<br />
Opus decoding support is now included in '''[http://caniuse.com/opus some Internet browsers]''' and '''[[OpusSupport|many applications]]''', including '''[https://www.mozilla.org/firefox Firefox]''', '''[https://www.foobar2000.org/ foobar2000]''' and '''[https://www.videolan.org/vlc/ VLC]''', as well as in frameworks such as '''[https://gstreamer.freedesktop.org/ GStreamer]''' and '''[https://ffmpeg.org/ FFmpeg]'''.<br />
<br />
For real-time applications, Opus support is available in '''[https://www.webrtc.org/ Google's WebRTC codebase]'''.<br />
<br />
Opus is a relatively new codec: '''[[OpusSupport|many more applications]]''' will support it in the near future.<br />
<br />
=== Does Opus support higher sampling rates, such as 96 kHz or 192 kHz? ===<br />
<br />
Yes and no.<br />
<br />
Opus encoding tools like opusenc will happily encode input files that are sampled at 96 or 192 kHz.<br />
<br />
However, files at these rates are internally '''converted to 48 kHz''' and then only frequencies '''up to 20 kHz''' are encoded.<br />
<br />
The reason is simple: lossy codecs are designed to preserve audible details while discarding irrelevant information. Since the human ear can only hear up to 20 kHz at best (usually lower than that), frequency content above 20 kHz is the first thing to go.<br />
<br />
See Monty's '''[https://people.xiph.org/~xiphmont/demo/neil-young.html article]''' for more details.<br />
<br />
If you want a codec to handle higher sampling rates losslessly, use '''[[FLAC]]'''!<br />
<br />
=== What are the licensing requirements? ===<br />
<br />
The reference Opus source code is released under a three-clause BSD license, which is a very permissive Open Source license. Commercial use and distribution (including in proprietary software) is permitted, provided that some basic conditions specified in the license are met. <br />
<br />
Opus is also covered by some patents, for which royalty-free usage rights are granted, under conditions that the authors believe are compatible with (hopefully) all open source licenses, including the GPL (v2 and v3).<br />
<br />
See the '''[https://www.opus-codec.org/license/ Opus Licensing]''' page for details.<br />
<br />
=== Why make Opus free? ===<br />
<br />
On the Internet, protocol and codec standards are part of the common infrastructure everyone builds upon.<br />
<br />
Most of the value of a high-quality standard is the innovation and inter-operation provided by the systems built on top of it. When a few parties have monopoly rights to monetize a standard, that infrastructure stops being so common and everyone else has more reason to use their own solution instead, increasing cost and reducing efficiency.<br />
<br />
Imagine a road system where each type of car could only drive on its own manufacturer's pavement. We all benefit from living in a world where all the roads are connected.<br />
<br />
This is why Opus, unlike many codecs, is free.<br />
<br />
=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===<br />
<br />
No.<br />
<br />
The SILK codec, as submitted by Skype to the IETF, was heavily modified as part of its integration within Opus. The modifications are significant enough that it is not possible to just write a "translator". Even sharing code between Opus and the "old SILK" would be highly complex.<br />
<br />
=== Why not keep the SILK and CELT codecs separate? ===<br />
Opus is more than just two independent codecs with a switch.<br />
<br />
In addition to a [https://en.wikipedia.org/wiki/Linear_predictive_coding Linear Prediction] '''SILK mode''' and an [https://en.wikipedia.org/wiki/Modified_discrete_cosine_transform MDCT] '''CELT mode''' it has a '''hybrid mode''', where speech frequencies up to 8 kHz are encoded with LP while those between 8 and 20 kHz are encoded with MDCT. This is what allows Opus to have such high speech quality around 32 kbps.<br />
<br />
Another advantage of the integration is the ability to switch between these 3 modes seamlessly, without any audible "glitches" and without any out-of-band signalling.<br />
<br />
=== Now that Opus is standardized, will its development stop or can it be further improved? ===<br />
Yes, Opus '''can''' and '''should''' be improved, because unlike most '''[https://en.wikipedia.org/wiki/ITU-T#Key_standards_published_by_ITU ITU-T codecs]''', Opus is only defined in terms of its decoder.<br />
<br />
The encoder can keep evolving as long as the bitstream it produces can be decoded by the reference decoder. This is what made it possible for modern MP3 encoders (e.g. '''[https://en.wikipedia.org/wiki/LAME LAME]''') to improve far beyond the original '''[https://en.wikipedia.org/wiki/L3enc L3enc]''' and '''dist10''' reference implementations.<br />
<br />
Although it is unlikely that Opus encoders will see such a spectacular evolution, we certainly hope that future encoders will become much better than the reference encoder.<br />
<br />
In fact, the 1.1 libopus release significantly improves on the reference encoder's quality. See '''[https://people.xiph.org/~xiphmont/demo/opus/demo3.shtml Monty's demo]''' for more details.<br />
<br />
=== Will all future Opus releases comply with the [https://tools.ietf.org/html/rfc6716 Opus specification]? ===<br />
<br />
Yes.<br />
<br />
=== In what ways is Opus optimized for the Internet? ===<br />
<br />
Opus has good packet loss robustness and concealment, but its optimisations go further.<br />
<br />
One of the first things we've been asked when designing Opus was to make the rate '''really''' adaptable because we never know what kind of rates will be available. This not only meant having a wide range of bitrates, but also being able to vary in small increments.<br />
<br />
This is why Opus scales from about '''6 ''' to '''512 kb/s''', in increments of '''0.4 kb/s''' (one byte with 20 ms frames). Opus can have '''more than 1200 possible bitrates''' while spending only '''11 bits''' signalling the bitrate because UDP already encodes the packet size.<br />
<br />
One last aspect is that Opus is simple to transport over RTP, as can be seen from the [https://tools.ietf.org/html/rfc7587 Opus RTP payload format]. For example, it's possible to decode RTP packets without having even seen the SDP or any out-of-band signalling.<br />
<br />
=== What applications for Android can play Opus? ===<br />
<br />
Right now, there are just a few but that list is fast growing. Please reference [https://android.stackexchange.com/q/37970/7425 this question on android.stackexchange.com]. Feel free to suggest other applications.<br />
<br />
=== When will the next version be released? ===<br />
<br />
When it's done. Seriously, we do not know.<br />
<br />
Opus is not a large project with a fixed release schedule.<br />
<br />
That being said, our '''[https://www.opus-codec.org/downloads/ pre-releases]''' and even the git repositories ('''[https://git.xiph.org/?p=opus.git Xiph]''', '''[https://github.com/xiph/opus GitHub]''') are pretty stable and given proper testing (which you should always do anyway), are safe to distribute.<br />
<br />
Just be aware that the API of new features (that have never been included in a stable release) could potentially still change.<br />
<br />
== Software Developers' Questions ==<br />
<br />
=== On what platforms does Opus run? ===<br />
<br />
The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs.<br />
<br />
Some of the platforms '''[https://mf4.xiph.org/jenkins/view/opus/ on which Opus has been tested]''' include x86, x86-64, ARM, Itanium, Blackfin, and SPARC.<br />
<br />
=== Is there a fixed-point implementation? ===<br />
<br />
Yes.<br />
<br />
The fixed-point and floating-point decoder and encoder implementations are part of the same code base.<br />
<br />
The code defaults to float, so you need to configure with '''--enable-fixed-point''' (or define '''FIXED_POINT''' if not using the configure script) to build the code for fixed-point.<br />
<br />
=== Which implementation should I use? ===<br />
<br />
While the implementation in RFC 6716 is what ''defines'' the standard, it is likely not the best and most up-to-date implementation.<br />
<br />
The [https://opus-codec.org/ Opus] website was set up for the purpose of continually improving the implementation — in terms of speed, encoding quality, device compatibility, etc — while still conforming to the standard.<br />
<br />
All Opus implementations are compatible by definition.<br />
<br />
=== How is supporting Opus different from supporting Speex/G.711/MP3? ===<br />
<br />
Opus has variable frame durations which can change on the fly, so an Opus decoder needs to be ready to accept packets with durations that are '''any multiple of 2.5ms''' up to a '''maximum of 120ms'''. <br />
<br />
The opus encoder and decoder do not need to have matched sampling rates or channel counts. It is recommended to always just decode at the highest rate the hardware supports (e.g. 48kHz stereo) so the user gets the full quality of whatever the far end is sending.<br />
<br />
=== My application doesn't work. Can anyone help me? ===<br />
<br />
It's possible to get help, but before doing so, there are a few basic things to try:<br />
<br />
* Implement your application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus.<br />
* Read the [https://www.opus-codec.org/docs/ Opus documentation].<br />
* Read the [https://git.xiph.org/?p=opus.git;a=blob;f=src/opus_demo.c opus_demo.c] source code to see how to use the encoder and decoder.<br />
<br />
If you still can't solve the problem, the best option is to ask for help on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on the '''#opus''' IRC channel on '''irc.freenode.net'''.<br />
<br />
=== How do I report a bug? ===<br />
<br />
If you think you have found a bug in Opus (and not in your application), please [https://trac.xiph.org/newticket?component=Opus file a bug report].<br />
<br />
Please include a way for us to reproduce the problem. The best way to do this is to provide an input file, along with the opusenc/opusdec/opus_demo command line that causes the bug to occur.<br />
<br />
If the bug cannot be triggered by the command line tools, please provide a simple patch or C file that can help reproduce it. Please also provide any other relevant information, such as OS, CPU, build options, etc.<br />
<br />
Don't hesitate to also contact us on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on [irc://irc.freenode.net/opus IRC].<br />
<br />
=== What is Opus Custom? ===<br />
<br />
Opus Custom is an '''optional''' part of the Opus standard that allows for sampling rates other than 8, 12, 16, 24, or 48 kHz and frame sizes other than multiples of 2.5 ms.<br />
<br />
Opus Custom requires additional out-of-band signalling that Opus does not normally require and disables many of Opus' coding modes. Also, because it is an optional part of the specification, using Opus Custom may lead to compatibility problems.<br />
<br />
For these reasons, '''its use is discouraged''' outside of very specific applications. <br />
<br />
You may want to use Opus Custom for:<br />
<br />
* ultra-low-delay applications, where synchronization with the soundcard buffer is important. <br />
* low-power embedded applications, where compatibility with others is not important.<br />
<br />
For almost all other types of applications, Opus Custom should not be used.<br />
<br />
=== How do I use 44.1 kHz or some other sampling rate not directly supported by Opus? ===<br />
<br />
Tools which read or write Opus should inter-operate with other sampling rates by transparently performing sample rate conversion behind the scenes whenever necessary. In particular, software developers should not use Opus Custom for 44.1 kHz support, except in the very specific circumstances outlined above.<br />
<br />
Note that it's generally preferable for a decoder to output at 48kHz, even when you know the original input was 44.1kHz. This is not only because you can skip resampling, but also because many cheaper audio interfaces have poor quality output for 44.1kHz.<br />
<br />
The '''[https://opus-codec.org/downloads/ opus-tools]''' package source code contains a small, high quality, high performance, BSD licensed resampler which can be used where resampling is required.<br />
<br />
=== But won't the resampler hurt the quality? Isn't it better to use 44.1 kHz directly? ==<br />
<br />
Short answer: No.<br />
<br />
Longer answer: If you can't tolerate the quality degradation caused by a good 44.1->48 kHz resampler, then you shouldn't be using a lossy codec in the first place. Any reasonable resampler will cause far less distortion that even the best lossy codec at high bitrate. Not only that, but even if you could run Opus at 44.1 kHz, it wouldn't help you. 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. This would result in worse quality than a 48 kHz encoding with resampling. If you've ever noticed that an MP3 encoder sounds worse at 48 kHz than at 44.1 kHz, then it's mostly likely not because of the resampling, but because most MP3 encoders are tuned for 44.1 kHz rather than for 48 kHz.<br />
<br />
=== How is the bitrate setting used in VBR mode? ===<br />
<br />
Variable bitrate (VBR) mode allows the bitrate to automatically vary over time based on the audio being encoded, in order to achieve a consistent quality.<br />
<br />
The bitrate setting controls the desired quality, on a scale that is calibrated to closely approximate the average bitrate that would be obtained over a large and diverse collection of audio. The actual bitrate of any particular audio stream may be higher or lower than this average.<br />
<br />
=== What frame size should I use? ===<br />
<br />
A '''20ms''' frame size works well for most applications.<br />
<br />
Smaller frame sizes may be used to achieve lower latency, but have lower quality at a given bitrate.<br />
<br />
Sizes greater than 20 ms increase latency and are generally beneficial only at fairly low bitrates, or when used to reduce external overhead (e.g. by reducing the number of packets that are sent).<br />
<br />
=== Forward Error correction (FEC) doesn't appear to do anything! HELP! ===<br />
<br />
The in-band FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.<br />
<br />
In order to make use of in-band FEC the decoder must delay its output by at least one frame so that it can call the decoder with the decode_fec argument on the ''next'' frame in order to reconstruct the missed frame. This works best if it's integrated with a jitter buffer.<br />
<br />
FEC is only used by the encoder under certain conditions:<br />
* the feature must be enabled via the '''OPUS_SET_INBAND_FEC''' CTL<br />
* the encoder must be told to expect loss via the '''OPUS_SET_PACKET_LOSS_PERC''' CTL<br />
* the codec must be operated in any of the '''Linear Prediction''' or '''Hybrid''' modes<br />
<br />
Frame durations shorter than 10ms and very high bitrates will use the MDCT modes, where FEC is not available.<br />
<br />
Even when FEC is not used, telling the encoder about the expected level of loss will help it make more intelligent decisions. By default, the implementation assumes there is no loss.<br />
<br />
=== I can't use malloc or much stack on my embedded platform. How do I make Opus work? ===<br />
<br />
A normal build of libopus only uses <tt>malloc/free</tt> in the <tt>_create()</tt> and <tt>_destroy()</tt> calls, making it safe for realtime use as long as the codec state is pre-created.<br />
<br />
To build Opus without the references to <tt>malloc/free</tt>, you must:<br />
<br />
* use <tt>init()</tt> calls rather than <tt>create()</tt> calls in your application<br />
* compile with <tt>CFLAGS="-DOVERRIDE_OPUS_ALLOC -DOVERRIDE_OPUS_FREE -D'opus_alloc(x)=NULL' -D'opus_free(x)=NULL' "</tt>.<br />
<br />
If libopus is built with <tt>-DNONTHREADSAFE_PSEUDOSTACK</tt> (instead of <tt>VAR_ARRAYS</tt>, or <tt>USE_ALLOCA</tt>), it will use a user-provided block of heap instead of stack for many things, resulting in much lower stack usage.<br><br />
This makes the resulting library '''non-threadsafe''' and is '''not recommended''' on anything except limited embedded platforms.<br />
<br />
=== How can I ensure that my software interoperates with other software implementing Opus? ===<br />
<br />
For applications using Ogg files, there are some [https://people.xiph.org/~greg/opus_testvectors/ Ogg Opus testvectors] to test decoders and you can test encoders with opusdec. For RTP applications, the opusrtp tool can be useful.<br />
<br />
In general, here's a list of specific issues to check:<br />
* Can your application handle all frame sizes, including changing the frame size from frame to frame?<br />
* Does your application react properly to lost packets, by calling the decoder with a NULL packet?<br />
<br />
=== What is the complexity of Opus? ===<br />
<br />
The complexity of Opus varies by a large amount based on the settings used.<br />
<br />
It depends on the mode, audio bandwidth, number of channels, and even a "complexity knob" that can trade complexity for quality. It will run easily on any recent PC or smartphone. <br />
<br />
For slower embedded CPUs/DSPs, the amount of CPU required will vary depending on the configuration and the exact CPU, so you will need to experiment. Do not expect Opus to run quickly on really slow devices like 8-bit micro-controllers.<br />
<br />
=== Opus is using too much CPU for my application. What can I do? ===<br />
<br />
First don't panic and don't start writing assembly just yet.<br />
<br />
It's possible that you're just not using the right set of options.<br />
<br />
If you're targeting an embedded/mobile platform, chances are the fixed-point build will be faster, so make sure you're using '''--enable-fixed-point''' or defining '''FIXED_POINT''' in the build system.<br />
<br />
Opus also has a complexity option that can trade quality for complexity. The default is highest quality and highest complexity. You can control this using '''OPUS_SET_COMPLEXITY()''' (see the '''[https://www.opus-codec.org/docs/ Documentation]''' for details).<br />
<br />
If all else fails and you need to optimize the Opus code, see the next question.<br />
<br />
=== I would like to optimize/improve/help with Opus. Where should I start? ===<br />
<br />
Please '''[https://www.opus-codec.org/contact/ contact us]''' before you start, or at least before you get too far.<br />
<br />
This will help coordinate the efforts made on Opus and reduce the probability of wasting your time on duplicated effort or going down the wrong path. More details in the '''[[OpusContributing|contributing page]]'''.<br />
<br />
=== Does Opus have an echo canceller like Speex does? ===<br />
<br />
Echo cancellation is completely independent from codecs.<br />
<br />
You can use any echo canceller (including the one from libspeexdsp) along with Opus.<br />
<br />
That being said, among the free acoustic echo cancelers (AEC) we're aware of, the best is probably the Google AEC from the [https://code.google.com/p/webrtc/ WebRTC codebase].<br />
<br />
[[Category:Opus]]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusContributing&diff=16484OpusContributing2016-11-01T20:51:53Z<p>Jmspeex: </p>
<hr />
<div>== Community ==<br />
<br />
Development discussions and questions take place on the Xiph.Org Opus mailing list ([mailto:opus@xiph.org opus@xiph.org]).<br />
<br />
Discussions related to the IETF process happen on the IETF codec working group mailing list ([mailto:codec@ietf.org codec@ietf.org]).<br />
<br />
For archives of recent discussions, try:<br />
<br />
* Xiph.Org [http://lists.xiph.org/pipermail/opus/ Opus mailing list archives]<br />
* IETF [https://www.ietf.org/mail-archive/web/codec/current/maillist.html codec mailing list archives]<br />
<br />
Informal development chat and support happens in #opus on irc.freenode.net. You can join the chat room through a '''[https://webchat.freenode.net/ web interface]''' if you don't have an IRC client.<br />
<br />
== How To Contribute ==<br />
<br />
There are many ways to contribute to Opus development:<br />
* Reporting and fixing bugs<br />
* Improving tools<br />
* Improving testing framework<br />
* Optimizations (assembly/intrinsics)<br />
* Encoding quality improvements (listening/tuning)<br />
* Mapping to new containers<br />
<br />
It is generally advisable to contact the developers on the mailing list or the IRC channel<br />
before taking on new work on Opus, to avoid duplicating work and to<br />
make sure you're doing things the right way from the start.<br />
<br />
== How to report bugs ==<br />
<br />
You can report bugs in '''[https://trac.xiph.org/report/25 trac]'''. Please also notify developers on the [mailto:opus@xiph.org mailing list].<br />
<br />
For sensitive (security-related) bugs, please '''[https://www.opus-codec.org/contact/ contact the developers]''' directly.<br />
<br />
== How to submit a patch ==<br />
<br />
If you have a patch you would like to contribute, just send it to the mailing list.<br />
We can also take [https://github.com/xiph/opus/ Github] pull requests,<br />
but please send a note to the mailing list since the GitHub Opus repository is only a mirror.<br />
<br />
== Coding style ==<br />
<br />
Opus is the result of merging three different codebases and therefore does not<br />
have a consistent coding style. For example, the SILK code uses 4-space<br />
indentation, while the rest of the code is mostly 3-space, except the entropy<br />
coder, which is 2-space.<br />
<br />
The general rule is that you should follow the style of the code you're modifying.<br />
* '''Do not''' reformat the code in your "functional change" patches, as it mostly makes it harder to review changes.<br />
* '''Do''' send separate "format-fixing" patches, making sure they don't change Opus' functionality at all.<br />
<br />
== Testing ==<br />
<br />
For any new feature, it is strongly suggested to also include tests for the new code to make sure it works and keeps working in the future.<br />
<br />
== Language ==<br />
<br />
Opus only requires a C89 compiler, so any use of C99 and later constructs has<br />
to be optional (e.g. OPUS_INLINE). This is also why we do not use C++-style<br />
// comments.<br />
<br />
To reduce the risk of exploitable memory errors, we do not use any function<br />
pointers in the code unless they are declared as static const. We also<br />
have "flat" objects, which can be copied using a "shallow copy", so do not add<br />
pointers to non-static data in the data structures.</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusContributing&diff=16437OpusContributing2016-07-05T20:42:15Z<p>Jmspeex: </p>
<hr />
<div>== Community ==<br />
<br />
Development discussions and questions take place on the Xiph.Org Opus mailing list (opus@xiph.org). Discussion related to the IETF process happen on the IETF codec working group mailing list (codec@ietf.org).<br />
<br />
For archives of recent discussions, try:<br />
<br />
* Xiph.Org [http://lists.xiph.org/pipermail/opus/ Opus mailing list archives]<br />
* IETF [https://www.ietf.org/mail-archive/web/codec/current/maillist.html codec mailing list archives]<br />
<br />
Informal development chat and support happens in #opus on irc.freenode.net. You can join the chat room through a web interface if you don't have an IRC client.<br />
<br />
== How to contribute ==<br />
<br />
There are many ways to contribute to Opus development:<br />
* Reporting and fixing bugs<br />
* Improving tools<br />
* Improving testing framework<br />
* Optimizations (assembly/intrinsics)<br />
* Encoding quality improvements (listening/tuning)<br />
* Mapping to new containers<br />
<br />
It is generally advisable to contact the developers on the mailing list or<br />
on IRC before taking on new work on Opus to avoid duplicating work and to<br />
make sure you're doing things the right way from the start.<br />
<br />
== How to report bugs ==<br />
<br />
You can report bugs in [https://trac.xiph.org/report/25 trac]. Please also notify developers on the mailing list. <br />
<br />
For sensitive (security-related) bugs, please [https://www.opus-codec.org/contact/ contact] the developers<br />
directly.<br />
<br />
== How to submit a patch ==<br />
<br />
If you have a patch you would like to contribute, just send it to the mailing<br />
list. We can also take [https://github.com/xiph/opus/ Github] pull requests, but please send a note to the mailing<br />
list since the Github Opus repository is only a mirror.<br />
<br />
== Coding style ==<br />
<br />
Opus is the result of merging three different codebases and therefore does not<br />
have a consistent coding style. For example, the SILK code uses 4-space<br />
indentation, while the rest of the code is mostly 3-space, except the entropy<br />
coder, which is 2-space. The general rule is that you should follow the<br />
style of the code you're modifying. Do '''not''' reformat the code in your<br />
patches, as it mostly makes it harder to review changes. <br />
<br />
== Language ==<br />
<br />
Opus only requires a C89 compiler, so any use of C99 and later constructs has<br />
to be optional (e.g. OPUS_INLINE). This is also why we do not use C++-style<br />
// comments.<br />
<br />
To reduce the risk of exploitable memory errors, we do not use any function<br />
pointers in the code unless they are declared as static const. We also<br />
have "flat" objects, which can be copied using a "shallow copy", so do not add<br />
pointers to non-static data in the data structures.</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusContributing&diff=16436OpusContributing2016-07-05T20:38:03Z<p>Jmspeex: </p>
<hr />
<div>== Community ==<br />
<br />
Development discussions and questions take place on the Xiph.Org Opus mailing list (opus@xiph.org). Discussion related to the IETF process happen on the IETF codec working group mailing list (codec@ietf.org).<br />
<br />
For archives of recent discussions, try:<br />
<br />
* Xiph.Org [http://lists.xiph.org/pipermail/opus/ Opus mailing list archives]<br />
* IETF [https://www.ietf.org/mail-archive/web/codec/current/maillist.html codec mailing list archives]<br />
<br />
Informal development chat and support happens in #opus on irc.freenode.net. You can join the chat room through a web interface if you don't have an IRC client.<br />
<br />
== How to contribute ==<br />
<br />
* Reporting and fixing bugs<br />
* Improving tools<br />
* Improving testing framework<br />
* Optimizations (assembly/intrinsics)<br />
* Encoding quality improvements (listening/tuning)<br />
* Mapping to new containers<br />
<br />
It is generally advisable to contact the developers on the mailing list or<br />
IRC *before* taking on new work on Opus to avoid duplicating work and to<br />
make sure you're doing things the right way from the start.<br />
<br />
== How to report bugs ==<br />
<br />
You can report bugs in [https://trac.xiph.org/report/25 trac]. Please also notify developers on the mailing list. <br />
<br />
For sensitive (security-related) bugs, please [https://www.opus-codec.org/contact/ contact] the developers<br />
directly.<br />
<br />
== How to submit a patch ==<br />
<br />
If you have a patch you would like to contribute, just send it to the mailing<br />
list. We can also take pull requests, but please send a note to the mailing<br />
list since the github repository is only a mirror.<br />
<br />
== Coding style ==<br />
<br />
Opus is the result of merging three different codebases and therefore does not<br />
have a consistent coding style. For example, the SILK code uses 4-space<br />
indentation, while the rest of the code is mostly 3-space, except the entropy<br />
coder, which is 2-space. The general rule is that you should follow the<br />
style of the code you're modifying. Do *not* reformat the code in your<br />
patches, as it mostly makes it harder to review changes. <br />
<br />
== Language ==<br />
<br />
Opus only requires a C89 compiler, so any use of C99 and later constructs has<br />
to be optional (e.g. OPUS_INLINE). This is also why we do not use C++-style<br />
// comments.<br />
<br />
To reduce the risk of exploitable memory errors, we do not use any function<br />
pointers in the code unless they are declared as static const. We also<br />
have "flat" objects, which can be copied using a "shallow copy".</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusContributing&diff=16435OpusContributing2016-07-05T20:36:19Z<p>Jmspeex: </p>
<hr />
<div>== Community ==<br />
<br />
Development discussions and questions take place on the Xiph.Org Opus mailing list (opus@xiph.org). Discussion related to the IETF process happen on the IETF codec working group mailing list (codec@ietf.org).<br />
<br />
For archives of recent discussions, try:<br />
<br />
* Xiph.Org [http://lists.xiph.org/pipermail/opus/ Opus mailing list archives]<br />
* IETF [https://www.ietf.org/mail-archive/web/codec/current/maillist.html codec mailing list archives]<br />
<br />
Informal development chat and support happens in #opus on irc.freenode.net. You can join the chat room through a web interface if you don't have an IRC client.<br />
<br />
== How to contribute ==<br />
<br />
* Reporting and fixing bugs<br />
* Improving tools<br />
* Improving testing framework<br />
* Optimizations (assembly/intrinsics)<br />
* Encoding quality improvements (listening/tuning)<br />
* Mapping to new containers<br />
<br />
It is generally advisable to contact the developers on the mailing list or<br />
IRC *before* taking on new work on Opus to avoid duplicating work and to<br />
make sure you're doing things the right way from the start.<br />
<br />
== How to report bugs ==<br />
<br />
You can report bugs in trac at this address https://trac.xiph.org/report/25<br />
Please also notify developers on the mailing list. <br />
<br />
For sensitive (security-related) bugs, please contact the developers<br />
directly <link to contacts>.<br />
<br />
== How to submit a patch ==<br />
<br />
If you have a patch you would like to contribute, just send it to the mailing<br />
list. We can also take pull requests, but please send a note to the mailing<br />
list since the github repository is only a mirror.<br />
<br />
== Coding style ==<br />
<br />
Opus is the result of merging three different codebases and therefore does not<br />
have a consistent coding style. For example, the SILK code uses 4-space<br />
indentation, while the rest of the code is mostly 3-space, except the entropy<br />
coder, which is 2-space. The general rule is that you should follow the<br />
style of the code you're modifying. Do *not* reformat the code in your<br />
patches, as it mostly makes it harder to review changes. <br />
<br />
== Language ==<br />
<br />
Opus only requires a C89 compiler, so any use of C99 and later constructs has<br />
to be optional (e.g. OPUS_INLINE). This is also why we do not use C++-style<br />
// comments.<br />
<br />
To reduce the risk of exploitable memory errors, we do not use any function<br />
pointers in the code unless they are declared as static const. We also<br />
have "flat" objects, which can be copied using a "shallow copy".</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusContributing&diff=16434OpusContributing2016-07-05T20:36:02Z<p>Jmspeex: </p>
<hr />
<div>== Community ==<br />
<br />
Development discussions and questions take place on the Xiph.Org Opus mailing list (opus@xiph.org). Discussion related to the IETF process happen on the IETF codec working group mailing list (codec@ietf.org).<br />
<br />
For archives of recent discussions, try:<br />
<br />
* Xiph.Org [http://lists.xiph.org/pipermail/opus/ Opus mailing list archives]<br />
* [https://www.ietf.org/mail-archive/web/codec/current/maillist.html IETF codec mailing list archives]<br />
<br />
Informal development chat and support happens in #opus on irc.freenode.net. You can join the chat room through a web interface if you don't have an IRC client.<br />
<br />
== How to contribute ==<br />
<br />
* Reporting and fixing bugs<br />
* Improving tools<br />
* Improving testing framework<br />
* Optimizations (assembly/intrinsics)<br />
* Encoding quality improvements (listening/tuning)<br />
* Mapping to new containers<br />
<br />
It is generally advisable to contact the developers on the mailing list or<br />
IRC *before* taking on new work on Opus to avoid duplicating work and to<br />
make sure you're doing things the right way from the start.<br />
<br />
== How to report bugs ==<br />
<br />
You can report bugs in trac at this address https://trac.xiph.org/report/25<br />
Please also notify developers on the mailing list. <br />
<br />
For sensitive (security-related) bugs, please contact the developers<br />
directly <link to contacts>.<br />
<br />
== How to submit a patch ==<br />
<br />
If you have a patch you would like to contribute, just send it to the mailing<br />
list. We can also take pull requests, but please send a note to the mailing<br />
list since the github repository is only a mirror.<br />
<br />
== Coding style ==<br />
<br />
Opus is the result of merging three different codebases and therefore does not<br />
have a consistent coding style. For example, the SILK code uses 4-space<br />
indentation, while the rest of the code is mostly 3-space, except the entropy<br />
coder, which is 2-space. The general rule is that you should follow the<br />
style of the code you're modifying. Do *not* reformat the code in your<br />
patches, as it mostly makes it harder to review changes. <br />
<br />
== Language ==<br />
<br />
Opus only requires a C89 compiler, so any use of C99 and later constructs has<br />
to be optional (e.g. OPUS_INLINE). This is also why we do not use C++-style<br />
// comments.<br />
<br />
To reduce the risk of exploitable memory errors, we do not use any function<br />
pointers in the code unless they are declared as static const. We also<br />
have "flat" objects, which can be copied using a "shallow copy".</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusContributing&diff=16433OpusContributing2016-07-05T20:34:55Z<p>Jmspeex: Created page with "== Community == Development discussions and questions take place on the Xiph.Org Opus mailing list (opus@xiph.org). Discussion related to the IETF process happen on the IETF..."</p>
<hr />
<div>== Community ==<br />
<br />
Development discussions and questions take place on the Xiph.Org Opus mailing list (opus@xiph.org). Discussion related to the IETF process happen on the IETF codec working group mailing list (codec@ietf.org).<br />
<br />
For archives of recent discussions, try:<br />
<br />
Xiph.Org Opus mailing list archives<br />
IETF codec mailing list archives<br />
Meeting minutes<br />
<br />
Informal development chat and support happens in #opus on irc.freenode.net. You can join the chat room through a web interface if you don't have an IRC client.<br />
<br />
== How to contribute ==<br />
<br />
* Reporting and fixing bugs<br />
* Improving tools<br />
* Improving testing framework<br />
* Optimizations (assembly/intrinsics)<br />
* Encoding quality improvements (listening/tuning)<br />
* Mapping to new containers<br />
<br />
It is generally advisable to contact the developers on the mailing list or<br />
IRC *before* taking on new work on Opus to avoid duplicating work and to<br />
make sure you're doing things the right way from the start.<br />
<br />
== How to report bugs ==<br />
<br />
You can report bugs in trac at this address https://trac.xiph.org/report/25<br />
Please also notify developers on the mailing list. <br />
<br />
For sensitive (security-related) bugs, please contact the developers<br />
directly <link to contacts>.<br />
<br />
== How to submit a patch ==<br />
<br />
If you have a patch you would like to contribute, just send it to the mailing<br />
list. We can also take pull requests, but please send a note to the mailing<br />
list since the github repository is only a mirror.<br />
<br />
== Coding style ==<br />
<br />
Opus is the result of merging three different codebases and therefore does not<br />
have a consistent coding style. For example, the SILK code uses 4-space<br />
indentation, while the rest of the code is mostly 3-space, except the entropy<br />
coder, which is 2-space. The general rule is that you should follow the<br />
style of the code you're modifying. Do *not* reformat the code in your<br />
patches, as it mostly makes it harder to review changes. <br />
<br />
== Language ==<br />
<br />
Opus only requires a C89 compiler, so any use of C99 and later constructs has<br />
to be optional (e.g. OPUS_INLINE). This is also why we do not use C++-style<br />
// comments.<br />
<br />
To reduce the risk of exploitable memory errors, we do not use any function<br />
pointers in the code unless they are declared as static const. We also<br />
have "flat" objects, which can be copied using a "shallow copy".</div>Jmspeexhttps://wiki.xiph.org/index.php?title=DaalaTodo&diff=15475DaalaTodo2015-02-18T20:06:14Z<p>Jmspeex: </p>
<hr />
<div>== Simple Things ==<br />
<br />
* Overflow checking for allocations in od_state_ref_imgs_init().<br />
* Implement [https://www.bugzilla.org/download/ Bugzilla] for Daala users to report bugs and enhancements.<br />
<br />
== Tuning ==<br />
<br />
* Quantization matrix<br />
** Rate-dependent QMs<br />
* Beta (activity masking)<br />
* PVQ RDO<br />
* Better MV cost estimates<br />
* Better MC distortion metrics (SATD, some MSE/SATD hybrid, no-ref-aware, maybe table driven Theora-style, etc.)<br />
* Better MV split flag rate estimates<br />
* Does the 8-pixel MV offset influence quality in any way?<br />
* Tuning for new lapping<br />
** quantization matrices<br />
** lambda<br />
** Haar DC<br />
<br />
== Known Broken/Suboptimal ==<br />
<br />
* Block size decision<br />
** Never tuned on inter<br />
** Not considering chroma<br />
* Investigate bias introduced by coefficient scaling<br />
* Take into account scaling differences from lapping on variable block size<br />
** Including Haar DC<br />
* Finish "skip higher bands" flags<br />
* Re-train zig-zags (particularly on inter)<br />
* Implement RDO for "skip_rest" decisions.<br />
* Better RDO rates for gain/theta/noref<br />
* Don't code blocks that are outside the image<br />
<br />
== New Work ==<br />
<br />
* Motion vector "mask" based on previous frame<br />
* Use coeff magnitude correlation for modelling<br />
* Per SB/MB/block/something quantizer changes<br />
* Variable Framerate support<br />
* Dynamic frame size changes (without keyframes)<br />
* Land paint-based deringing<br />
* SPIHT as k-tokenizer<br />
* MV prediction clustering<br />
* Special case for K=2<br />
* Train Laplace tables<br />
<br />
== Entropy Coding ==<br />
<br />
* Make the Laplace vector encoder (aka k-tokenizer) faster<br />
* Add "skip-all remaining bands" flag<br />
* Better encoding of the CfL sign<br />
* Add SIMD to the decoder search<br />
<br />
== Minor things ==<br />
<br />
* Code quantizers on a log scale<br />
<br />
== Visualization ==<br />
<br />
* Add ability to display decoder side information to player_example<br />
** Block size split decision<br />
** Cost in bits per block (use log scale)<br />
** No-ref and skip flags<br />
** Mode information (if we signal intra)<br />
** Motion vectors<br />
** Display prediction residual<br />
<br />
== Bit-stream work (no expected quality improvement) ==<br />
<br />
* Need a bugzilla instance for issue tracking<br />
* Re-order bitstream (e.g., don't code all MVs at the front, etc.)<br />
<br />
== AreWeCompressedYet ==<br />
Wiki page: [[AreWeCompressedYet]]<br />
<br />
Website: https://arewecompressedyet.com<br />
<br />
Bug tracker: https://github.com/tdaede/awcy/issues<br />
<br />
* Huge batch run of all versions of Daala<br />
* Look at rd_tool options and improve<br />
* Add realtime constraint options for x265<br />
<br />
[[Category:Daala]]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=DaalaTodo&diff=15474DaalaTodo2015-02-17T22:25:24Z<p>Jmspeex: </p>
<hr />
<div>== Simple Things ==<br />
<br />
* Overflow checking for allocations in od_state_ref_imgs_init().<br />
* Implement [https://www.bugzilla.org/download/ Bugzilla] for Daala users to report bugs and enhancements.<br />
<br />
== Tuning ==<br />
<br />
* Quantization matrix<br />
** Rate-dependent QMs<br />
* Beta (activity masking)<br />
* PVQ RDO<br />
* Better MV cost estimates<br />
* Better MC distortion metrics (SATD, some MSE/SATD hybrid, no-ref-aware, maybe table driven Theora-style, etc.)<br />
* Better MV split flag rate estimates<br />
* Does the 8-pixel MV offset influence quality in any way?<br />
<br />
== Known Broken/Suboptimal ==<br />
<br />
* Block size decision<br />
** Never tuned on inter<br />
** Not considering chroma<br />
* Investigate bias introduced by coefficient scaling<br />
* Take into account scaling differences from lapping on variable block size<br />
** Including Haar DC<br />
* Finish "skip higher bands" flags<br />
* Re-train zig-zags (particularly on inter)<br />
* Implement RDO for "skip_rest" decisions.<br />
* Better RDO rates for gain/theta/noref<br />
* Don't code blocks that are outside the image<br />
<br />
== New Work ==<br />
<br />
* Motion vector "mask" based on previous frame<br />
* Use coeff magnitude correlation for modelling<br />
* Per SB/MB/block/something quantizer changes<br />
* Variable Framerate support<br />
* Dynamic frame size changes (without keyframes)<br />
* Land paint-based deringing<br />
* SPIHT as k-tokenizer<br />
* MV prediction clustering<br />
* Special case for K=2<br />
* Train Laplace tables<br />
<br />
== Entropy Coding ==<br />
<br />
* Make the Laplace vector encoder (aka k-tokenizer) faster<br />
* Add "skip-all remaining bands" flag<br />
* Better encoding of the CfL sign<br />
* Add SIMD to the decoder search<br />
<br />
== Minor things ==<br />
<br />
* Code quantizers on a log scale<br />
<br />
== Visualization ==<br />
<br />
* Add ability to display decoder side information to player_example<br />
** Block size split decision<br />
** Cost in bits per block (use log scale)<br />
** No-ref and skip flags<br />
** Mode information (if we signal intra)<br />
** Motion vectors<br />
** Display prediction residual<br />
<br />
== Bit-stream work (no expected quality improvement) ==<br />
<br />
* Need a bugzilla instance for issue tracking<br />
* Re-order bitstream (e.g., don't code all MVs at the front, etc.)<br />
<br />
== AreWeCompressedYet ==<br />
Wiki page: [[AreWeCompressedYet]]<br />
<br />
Website: https://arewecompressedyet.com<br />
<br />
Bug tracker: https://github.com/tdaede/awcy/issues<br />
<br />
* Huge batch run of all versions of Daala<br />
* Look at rd_tool options and improve<br />
* Add realtime constraint options for x265<br />
<br />
[[Category:Daala]]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=DaalaTodo&diff=15445DaalaTodo2015-02-08T12:35:31Z<p>Jmspeex: </p>
<hr />
<div>== Simple Things ==<br />
<br />
* Overflow checking for allocations in od_state_ref_imgs_init().<br />
<br />
== Tuning ==<br />
<br />
* Quantization matrix<br />
** Rate-dependent QMs<br />
* Beta (activity masking)<br />
* PVQ RDO<br />
* Better MV cost estimates<br />
* Better MC distortion metrics (SATD, some MSE/SATD hybrid, no-ref-aware, maybe table driven Theora-style, etc.)<br />
* Better MV split flag rate estimates<br />
* Does the 8-pixel MV offset influence quality in any way?<br />
<br />
== Known Broken/Suboptimal ==<br />
<br />
* Block size decision<br />
** Never tuned on inter<br />
** Not considering chroma<br />
* Code quantizers on a log scale<br />
* Re-order bitstream (e.g., don't code all MVs at the front, etc.)<br />
* Investigate bias introduced by coefficient scaling<br />
* Take into account scaling differences from lapping on variable block size<br />
** Including Haar DC<br />
* Need "skip higher bands" flag<br />
* Re-train zig-zags (particularly on inter)<br />
* Implement RDO for "skip_rest" decisions.<br />
* Better RDO rates for gain/theta/noref<br />
<br />
== New Work ==<br />
<br />
* Motion vector "mask" based on previous frame<br />
* Use coeff magnitude correlation for modelling<br />
* Per SB/MB/block/something quantizer changes<br />
* Variable Framerate support<br />
* Dynamic frame size changes (without keyframes)<br />
* Land paint-based deringing<br />
* SPIHT as k-tokenizer<br />
* MV prediction clustering<br />
* Special case for K=2<br />
* Train Laplace tables<br />
<br />
== Entropy Coding ==<br />
<br />
* Make the Laplace vector encoder (aka k-tokenizer) faster<br />
* Add "skip-all remaining bands" flag<br />
* Better encoding of the CfL sign<br />
* Add SIMD to the decoder search<br />
<br />
== Visualization ==<br />
<br />
* Add ability to display decoder side information to player_example<br />
** Block size split decision<br />
** Cost in bits per block (use log scale)<br />
** No-ref and skip flags<br />
** Mode information (if we signal intra)<br />
** Motion vectors<br />
** Display prediction residual<br />
<br />
== Infrastructure ==<br />
<br />
* Need a bugzilla instance for issue tracking<br />
<br />
== AreWeCompressedYet ==<br />
Wiki page: [[AreWeCompressedYet]]<br />
<br />
Website: https://arewecompressedyet.com<br />
<br />
Bug tracker: https://github.com/tdaede/awcy/issues<br />
<br />
* Huge batch run of all versions of Daala<br />
* Look at rd_tool options and improve<br />
* Add realtime constraint options for x265<br />
<br />
[[Category:Daala]]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=DaalaTodo&diff=15380DaalaTodo2015-02-06T12:37:24Z<p>Jmspeex: </p>
<hr />
<div>== Simple Things ==<br />
<br />
* Overflow checking for allocations in od_state_ref_imgs_init().<br />
<br />
== Tuning ==<br />
<br />
* Quantization matrix<br />
** Rate-dependent QMs<br />
* Beta (activity masking)<br />
* PVQ RDO<br />
* Better MV cost estimates<br />
* Better MC distortion metrics (SATD, some MSE/SATD hybrid, no-ref-aware, maybe table driven Theora-style, etc.)<br />
* Better MV split flag rate estimates<br />
* Does the 8-pixel MV offset influence quality in any way?<br />
<br />
== Known Broken/Suboptimal ==<br />
<br />
* Block size decision<br />
** Never tuned on inter<br />
** Not considering chroma<br />
* Code quantizers on a log scale<br />
* Re-order bitstream (e.g., don't code all MVs at the front, etc.)<br />
* Investigate bias introduced by coefficient scaling<br />
* Take into account scaling differences from lapping on variable block size<br />
** Including Haar DC<br />
* Need "skip higher bands" flag<br />
* Re-train zig-zags (particularly on inter)<br />
* Implement RDO for "skip_rest" decisions.<br />
<br />
== New Work ==<br />
<br />
* Motion vector "mask" based on previous frame<br />
* Use coeff magnitude correlation for modelling<br />
* Per SB/MB/block/something quantizer changes<br />
* Variable Framerate support<br />
* Dynamic frame size changes (without keyframes)<br />
* Land paint-based deringing<br />
* SPIHT as k-tokenizer<br />
* MV prediction clustering<br />
* Special case for K=2<br />
* Train Laplace tables<br />
<br />
== Entropy Coding ==<br />
<br />
* Make the Laplace vector encoder (aka k-tokenizer) faster<br />
* Add "skip-all remaining bands" flag<br />
* Better encoding of the CfL sign<br />
* Add SIMD to the decoder search<br />
<br />
== Visualization ==<br />
<br />
* Add ability to display decoder side information to player_example<br />
** Block size split decision<br />
** Cost in bits per block (use log scale)<br />
** No-ref and skip flags<br />
** Mode information (if we signal intra)<br />
** Motion vectors<br />
** Display prediction residual<br />
<br />
== Infrastructure ==<br />
<br />
* Need a bugzilla instance for issue tracking<br />
<br />
== AreWeCompressedYet ==<br />
Wiki page: [[AreWeCompressedYet]]<br />
<br />
Website: https://arewecompressedyet.com<br />
<br />
Bug tracker: https://github.com/tdaede/awcy/issues<br />
<br />
* Huge batch run of all versions of Daala<br />
* Look at rd_tool options and improve<br />
* Add realtime constraint options for x265<br />
<br />
[[Category:Daala]]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=DaalaTodo&diff=15379DaalaTodo2015-02-06T00:10:44Z<p>Jmspeex: </p>
<hr />
<div>== Simple Things ==<br />
<br />
* Overflow checking for allocations in od_state_ref_imgs_init().<br />
<br />
== Tuning ==<br />
<br />
* Quantization matrix<br />
** Rate-dependent QMs<br />
* Beta (activity masking)<br />
* PVQ RDO<br />
* Better MV cost estimates<br />
* Better MC distortion metrics (SATD, some MSE/SATD hybrid, no-ref-aware, maybe table driven Theora-style, etc.)<br />
* Better MV split flag rate estimates<br />
* Does the 8-pixel MV offset influence quality in any way?<br />
<br />
== Known Broken/Suboptimal ==<br />
<br />
* Block size decision<br />
** Never tuned on inter<br />
** Not considering chroma<br />
* Code quantizers on a log scale<br />
* Re-order bitstream (e.g., don't code all MVs at the front, etc.)<br />
* Investigate bias introduced by coefficient scaling<br />
* Take into account scaling differences from lapping on variable block size<br />
** Including Haar DC<br />
* Need "skip higher bands" flag<br />
* Re-train zig-zags (particularly on inter)<br />
<br />
== New Work ==<br />
<br />
* Motion vector "mask" based on previous frame<br />
* Use coeff magnitude correlation for modelling<br />
* Per SB/MB/block/something quantizer changes<br />
* Variable Framerate support<br />
* Dynamic frame size changes (without keyframes)<br />
* Land paint-based deringing<br />
* SPIHT as k-tokenizer<br />
* MV prediction clustering<br />
* Special case for K=2<br />
* Train Laplace tables<br />
<br />
== Entropy Coding ==<br />
<br />
* Make the Laplace vector encoder (aka k-tokenizer) faster<br />
* Add "skip-all remaining bands" flag<br />
* Better encoding of the CfL sign<br />
* Add SIMD to the decoder search<br />
<br />
== Visualization ==<br />
<br />
* Add ability to display decoder side information to player_example<br />
** Block size split decision<br />
** Cost in bits per block (use log scale)<br />
** No-ref and skip flags<br />
** Mode information (if we signal intra)<br />
** Motion vectors<br />
** Display prediction residual<br />
<br />
== Infrastructure ==<br />
<br />
* Need a bugzilla instance for issue tracking<br />
<br />
== AreWeCompressedYet ==<br />
Wiki page: [[AreWeCompressedYet]]<br />
<br />
Website: https://arewecompressedyet.com<br />
<br />
Bug tracker: https://github.com/tdaede/awcy/issues<br />
<br />
* Huge batch run of all versions of Daala<br />
* Look at rd_tool options and improve<br />
* Add realtime constraint options for x265<br />
<br />
[[Category:Daala]]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=DaalaTodo&diff=15378DaalaTodo2015-02-05T23:41:43Z<p>Jmspeex: </p>
<hr />
<div>== Simple Things ==<br />
<br />
* Overflow checking for allocations in od_state_ref_imgs_init().<br />
<br />
== Tuning ==<br />
<br />
* Quantization matrix<br />
** Rate-dependent QMs<br />
* Beta (activity masking)<br />
* PVQ RDO<br />
* Better MV cost estimates<br />
* Better MC distortion metrics (SATD, some MSE/SATD hybrid, no-ref-aware, maybe table driven Theora-style, etc.)<br />
* Better MV split flag rate estimates<br />
* Does the 8-pixel MV offset influence quality in any way?<br />
<br />
== Known Broken/Suboptimal ==<br />
<br />
* Block size decision<br />
** Never tuned on inter<br />
** Not considering chroma<br />
* Code quantizers on a log scale<br />
* Re-order bitstream (e.g., don't code all MVs at the front, etc.)<br />
* Investigate bias introduced by coefficient scaling<br />
* Take into account scaling differences from lapping on variable block size<br />
** Including Haar DC<br />
* Need "skip higher bands" flag<br />
<br />
== New Work ==<br />
<br />
* Motion vector "mask" based on previous frame<br />
* Use coeff magnitude correlation for modelling<br />
* Per SB/MB/block/something quantizer changes<br />
* Variable Framerate support<br />
* Dynamic frame size changes (without keyframes)<br />
* Land paint-based deringing<br />
* SPIHT as k-tokenizer<br />
* MV prediction clustering<br />
* Special case for K=2<br />
* Train Laplace tables<br />
<br />
== Entropy Coding ==<br />
<br />
* Make the Laplace vector encoder (aka k-tokenizer) faster<br />
* Add "skip-all remaining bands" flag<br />
* Better encoding of the CfL sign<br />
* Add SIMD to the decoder search<br />
<br />
== Visualization ==<br />
<br />
* Add ability to display decoder side information to player_example<br />
** Block size split decision<br />
** Cost in bits per block (use log scale)<br />
** No-ref and skip flags<br />
** Mode information (if we signal intra)<br />
** Motion vectors<br />
** Display prediction residual<br />
<br />
== Infrastructure ==<br />
<br />
* Need a bugzilla instance for issue tracking<br />
<br />
== AreWeCompressedYet ==<br />
Wiki page: [[AreWeCompressedYet]]<br />
<br />
Website: https://arewecompressedyet.com<br />
<br />
Bug tracker: https://github.com/tdaede/awcy/issues<br />
<br />
* Huge batch run of all versions of Daala<br />
* Look at rd_tool options and improve<br />
* Add realtime constraint options for x265<br />
<br />
[[Category:Daala]]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=DaalaTodo&diff=15374DaalaTodo2015-02-03T12:00:20Z<p>Jmspeex: </p>
<hr />
<div>== Simple Things ==<br />
<br />
* Overflow checking for allocations in od_state_ref_imgs_init().<br />
<br />
== Tuning ==<br />
<br />
* Quantization matrix<br />
** Rate-dependent QMs<br />
* Beta (activity masking)<br />
* PVQ RDO<br />
* Better MV cost estimates<br />
* Better MC distortion metrics (SATD, some MSE/SATD hybrid, no-ref-aware, maybe table driven Theora-style, etc.)<br />
* Better MV split flag rate estimates<br />
* Does the 8-pixel MV offset influence quality in any way?<br />
<br />
== Known Broken/Suboptimal ==<br />
<br />
* Block size decision<br />
** Never tuned on inter<br />
** Not considering chroma<br />
* Code quantizers on a log scale<br />
* Re-order bitstream (e.g., don't code all MVs at the front, etc.)<br />
* Investigate bias introduced by coefficient scaling<br />
* Take into account scaling differences from lapping on variable block size<br />
** Including Haar DC<br />
* Need "skip higher bands" flag<br />
<br />
== New Work ==<br />
<br />
* Motion vector "mask" based on previous frame<br />
* Use coeff magnitude correlation for modelling<br />
* Per SB/MB/block/something quantizer changes<br />
* Variable Framerate support<br />
* Dynamic frame size changes (without keyframes)<br />
* Land paint-based deringing<br />
* SPIHT as k-tokenizer<br />
* MV prediction clustering<br />
<br />
== Entropy Coding ==<br />
<br />
* Make the Laplace vector encoder (aka k-tokenizer) faster<br />
* Add "skip-all remaining bands" flag<br />
* Better encoding of the CfL sign<br />
* Add SIMD to the decoder search<br />
<br />
== Visualization ==<br />
<br />
* Add ability to display decoder side information to player_example<br />
** Block size split decision<br />
** Cost in bits per block (use log scale)<br />
** No-ref and skip flags<br />
** Mode information (if we signal intra)<br />
** Motion vectors<br />
** Display prediction residual<br />
<br />
== Infrastructure ==<br />
<br />
* Need a bugzilla instance for issue tracking<br />
<br />
== AreWeCompressedYet ==<br />
Wiki page: [[AreWeCompressedYet]]<br />
<br />
Website: https://arewecompressedyet.com<br />
<br />
Bug tracker: https://github.com/tdaede/awcy/issues<br />
<br />
* Huge batch run of all versions of Daala<br />
* Look at rd_tool options and improve<br />
* Add realtime constraint options for x265<br />
<br />
[[Category:Daala]]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=People&diff=15135People2014-12-12T21:12:35Z<p>Jmspeex: </p>
<hr />
<div>This page is meant to help with nickname to person lookup. ''Nickname'' can be a mail alias, an IRC nick, or a Subversion user &mdash; in most cases several of these. Please help to fill this table. Keeping your own entry up to date is a good start.<br />
<br />
{| border="1" cellspacing="1" cellpadding="4" width="100%"<br />
|+ Who is who<br />
! Nickname<br />
! Real name<br />
! Keywords<br />
|-<br />
| arkadini<br />
| Arek Korbik<br />
| Quicktime, XiphQT<br />
|-<br />
| basilgohar<br />
| Basil Mohamed Gohar<br />
| opus, legal<br />
|-<br />
| ben<br />
| Benjamin Gérard<br />
| libao<br />
|- <br />
| BjornW<br />
| Björn Wijers<br />
| [[Spread Open Media]], [[XSPF]]<br />
|-<br />
| [[User:Conrad|conrad]]<br />
| [http://blog.kfish.org/ Conrad Parker]<br />
| see ''[[#nick_kfish|kfish]]''<br />
|-<br />
| <span id="nick_derf">derf</span><br />
| [http://people.xiph.org/~tterribe/ Timothy B. Terriberry]<br />
| theora, CELT, video, daala<br />
|-<br />
| dllmain<br />
| Sebastian Pipping<br />
| see ''[[#nick_sping|sping]]'', nick not used anymore<br />
|-<br />
| dm8tbr<br />
| Thomas B. Rücker<br />
| icecast<br />
|-<br />
| doublec<br />
| Chris Double<br />
| firefox, theora, Mozilla<br />
|-<br />
| drac667<br />
| Cristian Adam<br />
| DirectShow, oggcodecs, Windows<br />
|-<br />
| ds<br />
| David Schleef<br />
| theora, dirac, gstreamer<br />
|-<br />
| [[User:GChriss|gchriss]]<br />
| George Chriss<br />
| gstreamer, Elphel, event videography<br />
|-<br />
| giles<br />
| [http://people.xiph.org/~giles/ Ralph Giles]<br />
| see ''[[#nick_rillian|rillian]]''<br />
|-<br />
| gmaxwell<br />
| Gregory Maxwell<br />
| Wikimedia, CELT, theora, daala<br />
|-<br />
| gnafu<br />
| Gideon Mayhak<br />
| community, testing<br />
|-<br />
| [[User:Silvia|ginger]]<br />
| Silvia Pfeiffer<br />
| see ''[[#nick_nessy|nessy]]''<br />
|-<br />
| [[User:Imalone|imalone]]<br />
| Ian Malone<br />
| metadata<br />
|-<br />
| <span id="nick_illi"></span>illiminable<br />
| Zentaro Kavanagh<br />
| DirectShow, dsfilters, Microsoft<br />
|-<br />
| <span id="nick_ivo"></span>[[User:Saoshyant|ivo]]<br />
| Ivo Emanuel Gonçalves<br />
| advocacy, [[Spread Open Media]], [[XSPF]], wiki mod, vorbis-tools<br />
|-<br />
| jack<br />
| Jack Moffitt<br />
| libao, treasurer, Icecast<br />
|-<br />
| jcoalson<br />
| Josh Coalson<br />
| FLAC author<br />
|-<br />
| j, j^<br />
| Jan Gerber<br />
| v2v, ffmpeg2theora, sysadmin<br />
|-<br />
| [[User:jmspeex|jmspeex]]<br />
| [http://jmvalin.ca/ Jean-Marc Valin]<br />
| Opus (CELT), Daala, Speex<br />
|-<br />
| jmworx<br />
| Jean-Marc Valin<br />
| see ''[[#nick_jmspeex|jmspeex]]''<br />
|-<br />
| JoeyBorn<br />
| Joe Born<br />
| neuros<br />
|-<br />
| karl<br />
| Karl Heyes<br />
| Icecast<br />
|-<br />
| <span id="nick_kfish"></span>[[User:Conrad|kfish]]<br />
| [http://www.kfish.org/ Conrad Parker]<br />
| annodex, fishsound, hogg, oggz, vorbis-tools<br />
|-<br />
| laser13<br />
| Marcin Lubonski<br />
| annodex, oggplay, win32<br />
|-<br />
| lgonze<br />
| Lucas Gonze<br />
| [[XSPF]]<br />
|-<br />
| lu_zero<br />
| Luca Barbato <br />
| RTP Vorbis, RTP Theora, Gentoo<br />
|-<br />
| maikmerten<br />
| Maik Merten<br />
| theora, java, macos<br />
|-<br />
| <span id="nick_mikes"></span>MikeS<br />
| Michael Smith<br />
| fluendo, gstreamer, sysadmin, IceS<br />
|-<br />
| Monty<br />
| Christopher Montgomery<br />
| see ''[[#nick_xiphmont|xiphmont]]''<br />
|-<br />
| msmith<br />
| Michael Smith<br />
| see ''[[#nick_mikes|MikeS]]''<br />
|-<br />
| <span id="nick_nessy"></span>nessy<br />
| Silvia Pfeiffer<br />
| annodex, vquence, sysadmin, CMML<br />
|-<br />
| ozone<br />
| Andr&eacute; Pang<br />
| annodex, macos<br />
|-<br />
| pjones<br />
| Peter Jones<br />
| cdparanoia, redhat<br />
|-<br />
| <span id="nick_rillian"></span>rillian<br />
| [http://people.xiph.org/~giles/ Ralph Giles]<br />
| metadata, video, theora, MNG, sysadmin<br />
|-<br />
| ribamar<br />
| Ribamar Santarosa<br />
| etheora<br />
|-<br />
| Saoshyant<br />
| Ivo Emanuel Gonçalves<br />
| see ''[[#nick_ivo|ivo]]''<br />
|-<br />
| segher<br />
| Segher Boessenkool<br />
| vorbis, audio<br />
|-<br />
| shans<br />
| Shane Stephens<br />
| annodex, oggplay<br />
|-<br />
| silvia<br />
| Silvia Pfeiffer<br />
| see ''[[#nick_nessy|nessy]]''<br />
|-<br />
| smarter<br />
| Guillaume Martres<br />
| libvpx<br />
|-<br />
| <span id="nick_sping"></span>[[User:sping|sping]]<br />
| Sebastian Pipping<br />
| [[XSPF]], [http://libspiff.sourceforge.net/ libSpiff], [http://validator.xspf.org/ XSPF Validator]<br />
|-<br />
| TD-Linux<br />
| [http://thomasdaede.com/ Thomas Daede]<br />
| Daala hardware<br />
|-<br />
| tmatth<br />
| Tristan Matthews<br />
| VLC, speex<br />
|-<br />
| tterribe<br />
| [http://people.xiph.org/~tterribe/ Timothy B. Terriberry]<br />
| See ''[[#nick_derf|derf]]''<br />
|-<br />
| thomasvs<br />
| Thomas Vander Stichele<br />
| fluendo, flumotion, gstreamer<br />
|-<br />
| unlord<br />
| Nathan Egge<br />
| daala<br />
|-<br />
| volsung<br />
| Stan Seibert<br />
| libao<br />
|-<br />
| <span id="nick_xiphmont">xiphmont<br />
| Christopher Montgomery<br />
| vorbis, ghost, audio, Ogg, cdparanoia, daala<br />
|-<br />
| zen<br />
| Zentaro Kavanagh<br />
| see ''[[#nick_illi|illi]]''<br />
|-<br />
|}<br />
<br />
[[Category:Developers stuff]]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=People&diff=15134People2014-12-12T21:10:53Z<p>Jmspeex: </p>
<hr />
<div>This page is meant to help with nickname to person lookup. ''Nickname'' can be a mail alias, an IRC nick, or a Subversion user &mdash; in most cases several of these. Please help to fill this table. Keeping your own entry up to date is a good start.<br />
<br />
{| border="1" cellspacing="1" cellpadding="4" width="100%"<br />
|+ Who is who<br />
! Nickname<br />
! Real name<br />
! Keywords<br />
|-<br />
| arkadini<br />
| Arek Korbik<br />
| Quicktime, XiphQT<br />
|-<br />
| basilgohar<br />
| Basil Mohamed Gohar<br />
| opus, legal<br />
|-<br />
| ben<br />
| Benjamin Gérard<br />
| libao<br />
|- <br />
| BjornW<br />
| Björn Wijers<br />
| [[Spread Open Media]], [[XSPF]]<br />
|-<br />
| [[User:Conrad|conrad]]<br />
| [http://blog.kfish.org/ Conrad Parker]<br />
| see ''[[#nick_kfish|kfish]]''<br />
|-<br />
| <span id="nick_derf">derf</span><br />
| [http://people.xiph.org/~tterribe/ Timothy B. Terriberry]<br />
| theora, CELT, video, daala<br />
|-<br />
| dllmain<br />
| Sebastian Pipping<br />
| see ''[[#nick_sping|sping]]'', nick not used anymore<br />
|-<br />
| dm8tbr<br />
| Thomas B. Rücker<br />
| icecast<br />
|-<br />
| doublec<br />
| Chris Double<br />
| firefox, theora, Mozilla<br />
|-<br />
| drac667<br />
| Cristian Adam<br />
| DirectShow, oggcodecs, Windows<br />
|-<br />
| ds<br />
| David Schleef<br />
| theora, dirac, gstreamer<br />
|-<br />
| [[User:GChriss|gchriss]]<br />
| George Chriss<br />
| gstreamer, Elphel, event videography<br />
|-<br />
| giles<br />
| [http://people.xiph.org/~giles/ Ralph Giles]<br />
| see ''[[#nick_rillian|rillian]]''<br />
|-<br />
| gmaxwell<br />
| Gregory Maxwell<br />
| Wikimedia, CELT, theora, daala<br />
|-<br />
| gnafu<br />
| Gideon Mayhak<br />
| community, testing<br />
|-<br />
| [[User:Silvia|ginger]]<br />
| Silvia Pfeiffer<br />
| see ''[[#nick_nessy|nessy]]''<br />
|-<br />
| [[User:Imalone|imalone]]<br />
| Ian Malone<br />
| metadata<br />
|-<br />
| <span id="nick_illi"></span>illiminable<br />
| Zentaro Kavanagh<br />
| DirectShow, dsfilters, Microsoft<br />
|-<br />
| <span id="nick_ivo"></span>[[User:Saoshyant|ivo]]<br />
| Ivo Emanuel Gonçalves<br />
| advocacy, [[Spread Open Media]], [[XSPF]], wiki mod, vorbis-tools<br />
|-<br />
| jack<br />
| Jack Moffitt<br />
| libao, treasurer, Icecast<br />
|-<br />
| jcoalson<br />
| Josh Coalson<br />
| FLAC author<br />
|-<br />
| j, j^<br />
| Jan Gerber<br />
| v2v, ffmpeg2theora, sysadmin<br />
|-<br />
| [[User:jmspeex|jmspeex]]<br />
| [http://jmvalin.ca/ Jean-Marc Valin]<br />
| speex, ghost, VoIP, daala<br />
|-<br />
| jmworx<br />
| Jean-Marc Valin<br />
| see ''[[#nick_jmspeex|jmspeex]]''<br />
|-<br />
| JoeyBorn<br />
| Joe Born<br />
| neuros<br />
|-<br />
| karl<br />
| Karl Heyes<br />
| Icecast<br />
|-<br />
| <span id="nick_kfish"></span>[[User:Conrad|kfish]]<br />
| [http://www.kfish.org/ Conrad Parker]<br />
| annodex, fishsound, hogg, oggz, vorbis-tools<br />
|-<br />
| laser13<br />
| Marcin Lubonski<br />
| annodex, oggplay, win32<br />
|-<br />
| lgonze<br />
| Lucas Gonze<br />
| [[XSPF]]<br />
|-<br />
| lu_zero<br />
| Luca Barbato <br />
| RTP Vorbis, RTP Theora, Gentoo<br />
|-<br />
| maikmerten<br />
| Maik Merten<br />
| theora, java, macos<br />
|-<br />
| <span id="nick_mikes"></span>MikeS<br />
| Michael Smith<br />
| fluendo, gstreamer, sysadmin, IceS<br />
|-<br />
| Monty<br />
| Christopher Montgomery<br />
| see ''[[#nick_xiphmont|xiphmont]]''<br />
|-<br />
| msmith<br />
| Michael Smith<br />
| see ''[[#nick_mikes|MikeS]]''<br />
|-<br />
| <span id="nick_nessy"></span>nessy<br />
| Silvia Pfeiffer<br />
| annodex, vquence, sysadmin, CMML<br />
|-<br />
| ozone<br />
| Andr&eacute; Pang<br />
| annodex, macos<br />
|-<br />
| pjones<br />
| Peter Jones<br />
| cdparanoia, redhat<br />
|-<br />
| <span id="nick_rillian"></span>rillian<br />
| [http://people.xiph.org/~giles/ Ralph Giles]<br />
| metadata, video, theora, MNG, sysadmin<br />
|-<br />
| ribamar<br />
| Ribamar Santarosa<br />
| etheora<br />
|-<br />
| Saoshyant<br />
| Ivo Emanuel Gonçalves<br />
| see ''[[#nick_ivo|ivo]]''<br />
|-<br />
| segher<br />
| Segher Boessenkool<br />
| vorbis, audio<br />
|-<br />
| shans<br />
| Shane Stephens<br />
| annodex, oggplay<br />
|-<br />
| silvia<br />
| Silvia Pfeiffer<br />
| see ''[[#nick_nessy|nessy]]''<br />
|-<br />
| smarter<br />
| Guillaume Martres<br />
| libvpx<br />
|-<br />
| <span id="nick_sping"></span>[[User:sping|sping]]<br />
| Sebastian Pipping<br />
| [[XSPF]], [http://libspiff.sourceforge.net/ libSpiff], [http://validator.xspf.org/ XSPF Validator]<br />
|-<br />
| TD-Linux<br />
| [http://thomasdaede.com/ Thomas Daede]<br />
| Daala hardware<br />
|-<br />
| tmatth<br />
| Tristan Matthews<br />
| VLC, speex<br />
|-<br />
| tterribe<br />
| [http://people.xiph.org/~tterribe/ Timothy B. Terriberry]<br />
| See ''[[#nick_derf|derf]]''<br />
|-<br />
| thomasvs<br />
| Thomas Vander Stichele<br />
| fluendo, flumotion, gstreamer<br />
|-<br />
| unlord<br />
| Nathan Egge<br />
| daala<br />
|-<br />
| volsung<br />
| Stan Seibert<br />
| libao<br />
|-<br />
| <span id="nick_xiphmont">xiphmont<br />
| Christopher Montgomery<br />
| vorbis, ghost, audio, Ogg, cdparanoia, daala<br />
|-<br />
| zen<br />
| Zentaro Kavanagh<br />
| see ''[[#nick_illi|illi]]''<br />
|-<br />
|}<br />
<br />
[[Category:Developers stuff]]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=DaalaTodo&diff=15059DaalaTodo2014-10-30T15:43:15Z<p>Jmspeex: </p>
<hr />
<div>== Simple Things ==<br />
* Overflow checking for allocations in od_state_ref_imgs_init().<br />
<br />
== Tuning ==<br />
* Quantization matrix<br />
** Rate-dependent QMs<br />
* Beta (activity masking)<br />
* PVQ RDO<br />
* Better MV cost estimates<br />
* Better MC distortion metrics (SATD, some MSE/SATD hybrid, no-ref-aware, maybe table driven Theora-style, etc.)<br />
* Better MV split flag rate estimates<br />
<br />
== Known broken/suboptimal ==<br />
* Block size decision<br />
** Never tuned on inter<br />
** Not considering chroma<br />
* Code quantizers on a log scale<br />
* Re-order bitstream (e.g., don't code all MVs at the front, etc.)<br />
* Investigate bias introduced by coefficient scaling<br />
* Take into account scaling differences from lapping on variable block size<br />
** Including Haar DC<br />
* Need "skip higher bands" flag<br />
<br />
== New work ==<br />
<br />
* Motion vector "mask" based on previous frame<br />
* Use coeff magnitude correlation for modelling<br />
* Per SB/MB/block/something quantizer changes<br />
* Variable Framerate support<br />
* Dynamic frame size changes (without keyframes)<br />
* Land paint-based deringing<br />
* SPIHT as k-tokenizer<br />
* MV prediction clustering<br />
<br />
== Entropy coding ==<br />
<br />
* Make the Laplace vector encoder (aka k-tokenizer) faster<br />
* Add "skip-all remaining bands" flag<br />
* Better encoding of the CfL sign<br />
* Add SIMD to the decoder search<br />
<br />
== Visualization ==<br />
<br />
* Add ability to display decoder side information to player_example<br />
** Block size split decision<br />
** Cost in bits per block (use log scale)<br />
** No-ref and skip flags<br />
** Mode information (if we signal intra)<br />
** Motion vectors<br />
** Display prediction residual<br />
** Show only one plane (Y, Cb, Cr)<br />
<br />
== Infrastructure ==<br />
<br />
* Need a bugzilla instance for issue tracking<br />
<br />
== AreWeCompressedYet ==<br />
Bug tracker: https://github.com/tdaede/awcy/issues<br />
* Huge batch run of all versions of Daala<br />
* Look at rd_tool options and improve<br />
* Add realtime constraint options for x265</div>Jmspeexhttps://wiki.xiph.org/index.php?title=DaalaTodo&diff=15058DaalaTodo2014-10-30T15:42:10Z<p>Jmspeex: </p>
<hr />
<div>== Simple Things ==<br />
* Overflow checking for allocations in od_state_ref_imgs_init().<br />
<br />
== Tuning ==<br />
* Quantization matrix<br />
** Rate-dependent QMs<br />
* Beta (activity masking)<br />
* PVQ RDO<br />
* Better MV cost estimates<br />
* Better MC distortion metrics (SATD, some MSE/SATD hybrid, no-ref-aware, maybe table driven Theora-style, etc.)<br />
* Better MV split flag rate estimates<br />
<br />
== Known broken/suboptimal ==<br />
* Block size decision<br />
** Never tuned on inter<br />
** Not considering chroma<br />
* Code quantizers on a log scale<br />
* Re-order bitstream (e.g., don't code all MVs at the front, etc.)<br />
* Investigate bias introduced by coefficient scaling<br />
* Take into account scaling differences from lapping on variable block size<br />
** Including Haar DC<br />
<br />
== New work ==<br />
<br />
* Motion vector "mask" based on previous frame<br />
* Use coeff magnitude correlation for modelling<br />
* Per SB/MB/block/something quantizer changes<br />
* Variable Framerate support<br />
* Dynamic frame size changes (without keyframes)<br />
* Land paint-based deringing<br />
* SPIHT as k-tokenizer<br />
* MV prediction clustering<br />
<br />
== Entropy coding ==<br />
<br />
* Make the Laplace vector encoder (aka k-tokenizer) faster<br />
* Add "skip-all remaining bands" flag<br />
* Better encoding of the CfL sign<br />
* Add SIMD to the decoder search<br />
<br />
== Visualization ==<br />
<br />
* Add ability to display decoder side information to player_example<br />
** Block size split decision<br />
** Cost in bits per block (use log scale)<br />
** No-ref and skip flags<br />
** Mode information (if we signal intra)<br />
** Motion vectors<br />
** Display prediction residual<br />
** Show only one plane (Y, Cb, Cr)<br />
<br />
== Infrastructure ==<br />
<br />
* Need a bugzilla instance for issue tracking<br />
<br />
== AreWeCompressedYet ==<br />
Bug tracker: https://github.com/tdaede/awcy/issues<br />
* Huge batch run of all versions of Daala<br />
* Look at rd_tool options and improve<br />
* Add realtime constraint options for x265</div>Jmspeexhttps://wiki.xiph.org/index.php?title=DaalaTodo&diff=15057DaalaTodo2014-10-30T15:40:08Z<p>Jmspeex: </p>
<hr />
<div>== Simple Things ==<br />
* Overflow checking for allocations in od_state_ref_imgs_init().<br />
<br />
== Tuning ==<br />
* Quantization matrix<br />
** Rate-dependent QMs<br />
* Beta (activity masking)<br />
* PVQ RDO<br />
* Better MV cost estimates<br />
* Better MC distortion metrics (SATD, some MSE/SATD hybrid, no-ref-aware, maybe table driven Theora-style, etc.)<br />
* Better MV split flag rate estimates<br />
<br />
== Known broken/suboptimal ==<br />
* Block size decision<br />
** Never tuned on inter<br />
** Not considering chroma<br />
* Code quantizers on a log scale<br />
* Re-order bitstream (e.g., don't code all MVs at the front, etc.)<br />
* Investigate bias introduced by coefficient scaling<br />
* Take into account scaling differences from lapping on variable block size<br />
** Including Haar DC<br />
<br />
== New work ==<br />
<br />
* Motion vector "mask" based on previous frame<br />
* Use coeff magnitude correlation for modelling<br />
* Per SB/MB/block/something quantizer changes<br />
* Variable Framerate support<br />
* Dynamic frame size changes (without keyframes)<br />
* SPIHT as k-tokenizer<br />
<br />
== Entropy coding ==<br />
<br />
* Make the Laplace vector encoder (aka k-tokenizer) faster<br />
* Add "skip-all remaining bands" flag<br />
* Better encoding of the CfL sign<br />
* Add SIMD to the decoder search<br />
<br />
== Visualization ==<br />
<br />
* Add ability to display decoder side information to player_example<br />
** Block size split decision<br />
** Cost in bits per block (use log scale)<br />
** No-ref and skip flags<br />
** Mode information (if we signal intra)<br />
** Motion vectors<br />
** Display prediction residual<br />
** Show only one plane (Y, Cb, Cr)<br />
<br />
== Infrastructure ==<br />
<br />
* Need a bugzilla instance for issue tracking<br />
<br />
== AreWeCompressedYet ==<br />
Bug tracker: https://github.com/tdaede/awcy/issues<br />
* Huge batch run of all versions of Daala<br />
* Look at rd_tool options and improve<br />
* Add realtime constraint options for x265</div>Jmspeexhttps://wiki.xiph.org/index.php?title=DaalaTodo&diff=15035DaalaTodo2014-10-14T19:50:42Z<p>Jmspeex: </p>
<hr />
<div>= Simple Things =<br />
* Overflow checking for allocations in od_state_ref_imgs_init().<br />
<br />
= Tuning =<br />
* Quantization matrix<br />
* Beta (activity masking)<br />
* Inter band masking<br />
* PVQ RDO<br />
* Better MV cost estimates<br />
* Better MC distortion metrics (SATD, some MSE/SATD hybrid, no-ref-aware, maybe table driven Theora-style, etc.)<br />
* Better MV split flag rate estimates<br />
<br />
= Known broken/suboptimal =<br />
* Block size decision<br />
** Never tuned on inter<br />
** Not considering chroma<br />
* Code quantizers on a log scale<br />
* Re-order bitstream (e.g., don't code all MVs at the front, etc.)<br />
* Investigate bias introduced by coefficient scaling<br />
<br />
= New work =<br />
<br />
* VQ for inter frames, with codebook selected based on dim m<br />
* Motion vector "mask" based on previous frame<br />
* Use coeff magnitude correlation for modelling<br />
* Per SB/MB/block/something quantizer changes<br />
* Variable Framerate support<br />
* Dynamic frame size changes (without keyframes)<br />
* SPIHT as k-tokenizer<br />
<br />
= Entropy coding =<br />
<br />
* Make the Laplace vector encoder (aka k-tokenizer) faster<br />
* Add "skip-all remaining bands" flag<br />
* Better encoding of the CfL sign<br />
* Add SIMD to the decoder search<br />
<br />
= Visualization =<br />
<br />
* Add ability to display decoder side information to player_example<br />
** Block size split decision<br />
** Cost in bits per block (use log scale)<br />
** No-ref and skip flags<br />
** Mode information (if we signal intra)<br />
** Motion vectors<br />
** Display prediction residual<br />
** Show only one plane (Y, Cb, Cr)</div>Jmspeexhttps://wiki.xiph.org/index.php?title=DaalaTodo&diff=15017DaalaTodo2014-10-07T18:04:06Z<p>Jmspeex: </p>
<hr />
<div>= Tuning =<br />
* Quantization matrix<br />
* Beta<br />
* Inter band masking<br />
* PVQ RDO<br />
<br />
= Known broken/suboptimal =<br />
* Block size decision<br />
** Never tuned on inter<br />
** Not considering chroma<br />
<br />
= New ideas =<br />
<br />
* VQ for inter frames, with codebook selected based on dim m<br />
* Motion vector "mask" based on previous frame<br />
* Use coeff magnitude correlation for modelling<br />
<br />
= Entropy coding =<br />
<br />
* Make the Laplace vector encoder (aka k-tokenizer) faster<br />
* Add "skip-all remaining bands" flag<br />
* Better encoding of the CfL sign</div>Jmspeexhttps://wiki.xiph.org/index.php?title=DaalaTodo&diff=15016DaalaTodo2014-10-07T18:02:40Z<p>Jmspeex: Created page with "= Tuning = * Quantization matrix * Beta * Inter band masking * PVQ RDO = Known broken/suboptimal == * Block size decision ** Never tuned on inter ** Not considering chroma = Ne..."</p>
<hr />
<div>= Tuning =<br />
* Quantization matrix<br />
* Beta<br />
* Inter band masking<br />
* PVQ RDO<br />
<br />
= Known broken/suboptimal ==<br />
* Block size decision<br />
** Never tuned on inter<br />
** Not considering chroma<br />
<br />
= New ideas =<br />
<br />
* VQ for inter frames, with codebook selected based on dim m<br />
* Motion vector "mask" based on previous frame<br />
* Use coeff magnitude correlation for modelling</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=14333OpusTodo2013-11-22T14:49:11Z<p>Jmspeex: </p>
<hr />
<div>== For 1.1-final ==<br />
<br />
* surround improvements<br />
<br />
== Moved to 1.1.1 ==<br />
* Unconstrained SILK VBR<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]]<br />
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]<br />
<br />
== Website ==<br />
* De-uglify webpage - some suggestions: write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?), and the prop. ones), write about implementations (is there only one so far?), comparison table (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...), future use in video files (Theora? Dirac? WebM? other future codecs...), audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ... <br />
* Promotional material (some nice free or Public domain sounds in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* A simple real time streaming example tool<br />
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]<br />
** Make <code>opusrtp rtp://example.com:5431/</code> listen to that host and port and mux packets from there. Generalize the cpac bases --sniff implementation<br />
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?<br />
** Make --sniff save one file per<br />
** Implement DTLS-SRTP. See webrtc.<br />
** audio capture/encode, decode/playback?<br />
** Parse and act on sdp for convenience and testing.<br />
<br />
* Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Experiments ==<br />
<br />
* Test exp_analysis and void_my_warranty.patch<br />
<br />
== Optimisations ==<br />
<br />
* Vectorising comb_filter()<br />
* Use 16-bit mul plus shift in denormalise_bands()<br />
* Optimise MDCT somehow<br />
* Merge ARM optimisations<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusSupport&diff=14324OpusSupport2013-11-15T20:12:35Z<p>Jmspeex: </p>
<hr />
<div>= List of software and services supporting Opus =<br />
<br />
== VoIP/videoconference ==<br />
<br />
=== Soft clients ===<br />
<br />
* [http://https://jitsi.org/ Jitsi]<br />
* [http://www.meetecho.com Meetecho]<br />
* [http://http://www.counterpath.com/bria-android-edition.html CounterPath]<br />
* [http://icanblink.com/ Blink]<br />
* [http://www.freeswitch.org Freeswitch]<br />
<br />
=== Gaming ===<br />
* [http://mumble.sourceforge.net Mumble]<br />
* [http://www.teamspeak.com Teamspeak]<br />
* [http://www.scei.co.jp/ps4-license/opus.html Sony PS4]<br />
<br />
=== Hardware phones ===<br />
* [http://www.audiocodes.com/press-releases/audiocodes-announces-webrtc-phone AudioCodes]<br />
<br />
=== WebRTC ===<br />
<br />
* [http://getfirefox.net Firefox]<br />
* [http://www.google.com/chrome Chrome]<br />
<br />
== Files and HTTP Streaming==<br />
<br />
=== Browsers ===<br />
<br />
* [http://getfirefox.net Firefox]<br />
* [http://www.google.com/chrome Chrome] (needs flag)<br />
* [http://www.opera.com Opera] (needs flag)<br />
<br />
=== Clients ===<br />
<br />
* [http://www.ffmpeg.org FFMpeg]<br />
* [http://www.gstreamer.net GStreamer]<br />
* [http://www.videolan.org/vlc/ VLC]<br />
* [http://www.foobar2000.org Foobar2000]<br />
* Winamp (with plugin)<br />
* [http://amarok.kde.org Amarok]<br />
<br />
=== Server/Source ===<br />
<br />
* [http://www.icecast.org Icecast]<br />
* [http://xeocoder.com/ XeoCoder]<br />
<br />
=== Hardware Players ===<br />
<br />
* [http://www.rockbox.org Rockbox]<br />
<br />
== Distribution ==<br />
<br />
* [http://blog.magnatune.com/2013/09/opus-format-audio-files-now-available-at-magnatune.html Magnatune music store]<br />
<br />
* [http://www.streamguys.com/news.php?id=116 StreamGuys CDN]<br />
<br />
== Broadcast ==<br />
<br />
=== Equipment ===<br />
<br />
* [http://tieline.com Tieline]<br />
* [http://mayah.com Mayah]<br />
* [http://harrisbroadcast.com Harris Broadcast]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=14309OpusTodo2013-11-09T01:00:17Z<p>Jmspeex: </p>
<hr />
<div>== For 1.1-final ==<br />
<br />
* Test surround improvements<br />
* Land ARM/Neon optimizations<br />
* Testing, especially<br />
** CBR/CVBR<br />
** Smaller frame sizes<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]]<br />
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]<br />
<br />
== Website ==<br />
* De-uglify webpage - some suggestions: write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?), and the prop. ones), write about implementations (is there only one so far?), comparison table (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...), future use in video files (Theora? Dirac? WebM? other future codecs...), audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ... <br />
* Promotional material (some nice free or Public domain sounds in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* A simple real time streaming example tool<br />
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]<br />
** Make <code>opusrtp rtp://example.com:5431/</code> listen to that host and port and mux packets from there. Generalize the cpac bases --sniff implementation<br />
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?<br />
** Make --sniff save one file per<br />
** Implement DTLS-SRTP. See webrtc.<br />
** audio capture/encode, decode/playback?<br />
** Parse and act on sdp for convenience and testing.<br />
<br />
* Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Experiments ==<br />
<br />
* Test exp_analysis and void_my_warranty.patch<br />
<br />
== Optimisations ==<br />
<br />
* Vectorising comb_filter()<br />
* Use 16-bit mul plus shift in denormalise_bands()<br />
* Optimise MDCT somehow<br />
* Merge ARM optimisations<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=14308OpusTodo2013-11-08T21:41:49Z<p>Jmspeex: </p>
<hr />
<div>== For 1.1-final ==<br />
<br />
* Test surround improvements<br />
* Land ARM/Neon optimizations<br />
* Testing, especially<br />
** CBR/CVBR<br />
** Smaller frame sizes<br />
* Minor<br />
** Change stereo threshold for smaller frame sizes<br />
** Hide variable framesize API (until it works)<br />
** Make surround bandwidth decision depend on channels too<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]]<br />
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]<br />
<br />
== Website ==<br />
* De-uglify webpage - some suggestions: write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?), and the prop. ones), write about implementations (is there only one so far?), comparison table (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...), future use in video files (Theora? Dirac? WebM? other future codecs...), audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ... <br />
* Promotional material (some nice free or Public domain sounds in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* A simple real time streaming example tool<br />
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]<br />
** Make <code>opusrtp rtp://example.com:5431/</code> listen to that host and port and mux packets from there. Generalize the cpac bases --sniff implementation<br />
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?<br />
** Make --sniff save one file per<br />
** Implement DTLS-SRTP. See webrtc.<br />
** audio capture/encode, decode/playback?<br />
** Parse and act on sdp for convenience and testing.<br />
<br />
* Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Experiments ==<br />
<br />
* Test exp_analysis and void_my_warranty.patch<br />
<br />
== Optimisations ==<br />
<br />
* Vectorising comb_filter()<br />
* Use 16-bit mul plus shift in denormalise_bands()<br />
* Optimise MDCT somehow<br />
* Merge ARM optimisations<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=14306OpusTodo2013-11-08T18:48:05Z<p>Jmspeex: </p>
<hr />
<div>== For 1.1-final ==<br />
<br />
* Test surround improvements<br />
* Land ARM/Neon optimizations<br />
* Testing, especially<br />
** CBR/CVBR<br />
** Smaller frame sizes<br />
* Minor<br />
** Change stereo threshold for smaller frame sizes<br />
** Hide variable framesize API (until it works)<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]]<br />
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]<br />
<br />
== Website ==<br />
* De-uglify webpage - some suggestions: write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?), and the prop. ones), write about implementations (is there only one so far?), comparison table (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...), future use in video files (Theora? Dirac? WebM? other future codecs...), audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ... <br />
* Promotional material (some nice free or Public domain sounds in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* A simple real time streaming example tool<br />
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]<br />
** Make <code>opusrtp rtp://example.com:5431/</code> listen to that host and port and mux packets from there. Generalize the cpac bases --sniff implementation<br />
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?<br />
** Make --sniff save one file per<br />
** Implement DTLS-SRTP. See webrtc.<br />
** audio capture/encode, decode/playback?<br />
** Parse and act on sdp for convenience and testing.<br />
<br />
* Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Experiments ==<br />
<br />
* Test exp_analysis and void_my_warranty.patch<br />
<br />
== Optimisations ==<br />
<br />
* Vectorising comb_filter()<br />
* Use 16-bit mul plus shift in denormalise_bands()<br />
* Optimise MDCT somehow<br />
* Merge ARM optimisations<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=14284OpusTodo2013-10-29T05:35:05Z<p>Jmspeex: </p>
<hr />
<div>== For 1.1-final ==<br />
<br />
* Test surround improvements<br />
* Land ARM/Neon optimizations<br />
* Testing, especially<br />
** CBR/CVBR<br />
** Smaller frame sizes<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]]<br />
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]<br />
<br />
== Website ==<br />
* De-uglify webpage - some suggestions: write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?), and the prop. ones), write about implementations (is there only one so far?), comparison table (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...), future use in video files (Theora? Dirac? WebM? other future codecs...), audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ... <br />
* Promotional material (some nice free or Public domain sounds in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* A simple real time streaming example tool<br />
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]<br />
** Make <code>opusrtp rtp://example.com:5431/</code> listen to that host and port and mux packets from there. Generalize the cpac bases --sniff implementation<br />
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?<br />
** Make --sniff save one file per<br />
** Implement DTLS-SRTP. See webrtc.<br />
** audio capture/encode, decode/playback?<br />
** Parse and act on sdp for convenience and testing.<br />
<br />
* Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Experiments ==<br />
<br />
* Test exp_analysis and void_my_warranty.patch<br />
<br />
== Optimisations ==<br />
<br />
* Vectorising comb_filter()<br />
* Use 16-bit mul plus shift in denormalise_bands()<br />
* Optimise MDCT somehow<br />
* Merge ARM optimisations<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=14283OpusTodo2013-10-29T05:34:45Z<p>Jmspeex: </p>
<hr />
<div>== For 1.1-final ==<br />
<br />
* Test surround improvements<br />
* Land ARM/Neon optimizations<br />
* Testing, especially<br />
** CVBR<br />
** Smaller frame sizes<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]]<br />
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]<br />
<br />
== Website ==<br />
* De-uglify webpage - some suggestions: write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?), and the prop. ones), write about implementations (is there only one so far?), comparison table (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...), future use in video files (Theora? Dirac? WebM? other future codecs...), audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ... <br />
* Promotional material (some nice free or Public domain sounds in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* A simple real time streaming example tool<br />
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]<br />
** Make <code>opusrtp rtp://example.com:5431/</code> listen to that host and port and mux packets from there. Generalize the cpac bases --sniff implementation<br />
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?<br />
** Make --sniff save one file per<br />
** Implement DTLS-SRTP. See webrtc.<br />
** audio capture/encode, decode/playback?<br />
** Parse and act on sdp for convenience and testing.<br />
<br />
* Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Experiments ==<br />
<br />
* Test exp_analysis and void_my_warranty.patch<br />
<br />
== Optimisations ==<br />
<br />
* Vectorising comb_filter()<br />
* Use 16-bit mul plus shift in denormalise_bands()<br />
* Optimise MDCT somehow<br />
* Merge ARM optimisations<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusSupport&diff=14264OpusSupport2013-09-30T20:37:00Z<p>Jmspeex: </p>
<hr />
<div>= List of software and services supporting Opus =<br />
<br />
== VoIP/videoconference ==<br />
<br />
=== Soft clients ===<br />
<br />
* [http://https://jitsi.org/ Jitsi]<br />
* [http://www.meetecho.com Meetecho]<br />
* [http://http://www.counterpath.com/bria-android-edition.html CounterPath]<br />
* [http://icanblink.com/ Blink]<br />
* [http://www.freeswitch.org Freeswitch]<br />
<br />
=== Gaming ===<br />
* [http://mumble.sourceforge.net Mumble]<br />
* [http://www.teamspeak.com Teamspeak]<br />
<br />
=== Hardware phones ===<br />
* [http://www.audiocodes.com/press-releases/audiocodes-announces-webrtc-phone AudioCodes]<br />
<br />
=== WebRTC ===<br />
<br />
* [http://getfirefox.net Firefox]<br />
* [http://www.google.com/chrome Chrome]<br />
<br />
== Files and HTTP Streaming==<br />
<br />
=== Browsers ===<br />
<br />
* [http://getfirefox.net Firefox]<br />
* [http://www.google.com/chrome Chrome] (needs flag)<br />
* [http://www.opera.com Opera] (needs flag)<br />
<br />
=== Clients ===<br />
<br />
* [http://www.ffmpeg.org FFMpeg]<br />
* [http://www.gstreamer.net GStreamer]<br />
* [http://www.videolan.org/vlc/ VLC]<br />
* [http://www.foobar2000.org Foobar2000]<br />
* Winamp (with plugin)<br />
* [http://amarok.kde.org Amarok]<br />
<br />
=== Server/Source ===<br />
<br />
* [http://www.icecast.org Icecast]<br />
* [http://xeocoder.com/ XeoCoder]<br />
<br />
=== Hardware Players ===<br />
<br />
* [http://www.rockbox.org Rockbox]<br />
<br />
== Distribution ==<br />
<br />
* [http://blog.magnatune.com/2013/09/opus-format-audio-files-now-available-at-magnatune.html Magnatune music store]<br />
<br />
* [http://www.streamguys.com/news.php?id=116 StreamGuys CDN]<br />
<br />
== Broadcast ==<br />
<br />
=== Equipment ===<br />
<br />
* [http://tieline.com Tieline]<br />
* [http://mayah.com Mayah]<br />
* [http://harrisbroadcast.com Harris Broadcast]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusSupport&diff=14263OpusSupport2013-09-30T20:34:07Z<p>Jmspeex: </p>
<hr />
<div>= List of software and services supporting Opus =<br />
<br />
== VoIP/videoconference ==<br />
<br />
=== Soft clients ===<br />
<br />
* [http://https://jitsi.org/ Jitsi]<br />
* [http://www.meetecho.com Meetecho]<br />
* [http://http://www.counterpath.com/bria-android-edition.html CounterPath]<br />
* [http://icanblink.com/ Blink]<br />
<br />
=== Gaming ===<br />
* [http://mumble.sourceforge.net Mumble]<br />
* [http://www.teamspeak.com Teamspeak]<br />
<br />
=== Hardware phones ===<br />
* [http://www.audiocodes.com/press-releases/audiocodes-announces-webrtc-phone AudioCodes]<br />
<br />
=== WebRTC ===<br />
<br />
* [http://getfirefox.net Firefox]<br />
* [http://www.google.com/chrome Chrome]<br />
<br />
== HTTP Streaming ==<br />
<br />
=== Browsers ===<br />
<br />
* [http://getfirefox.net Firefox]<br />
* [http://www.google.com/chrome Chrome] (needs flag)<br />
* [http://www.opera.com Opera] (needs flag)<br />
<br />
=== Clients ===<br />
<br />
* [http://www.ffmpeg.org FFMpeg]<br />
* [http://www.gstreamer.net GStreamer]<br />
* [http://www.videolan.org/vlc/ VLC]<br />
* [http://www.foobar2000.org Foobar2000]<br />
* Winamp (with plugin)<br />
* [http://amarok.kde.org Amarok]<br />
<br />
=== Server/Source ===<br />
<br />
* [http://www.icecast.org Icecast]<br />
* [http://xeocoder.com/ XeoCoder]<br />
<br />
== Distribution ==<br />
<br />
* [http://blog.magnatune.com/2013/09/opus-format-audio-files-now-available-at-magnatune.html Magnatune music store]<br />
<br />
* [http://www.streamguys.com/news.php?id=116 StreamGuys CDN]<br />
<br />
== Broadcast ==<br />
<br />
=== Equipment ===<br />
<br />
* [http://tieline.com Tieline]<br />
* [http://mayah.com Mayah]<br />
* [http://harrisbroadcast.com Harris Broadcast]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusSupport&diff=14262OpusSupport2013-09-30T18:00:56Z<p>Jmspeex: adds links</p>
<hr />
<div>= List of software and services supporting Opus =<br />
<br />
== VoIP/videoconference ==<br />
<br />
* [http://https://jitsi.org/ Jitsi]<br />
* [http://www.meetecho.com Meetecho]<br />
* [http://http://www.counterpath.com/bria-android-edition.html CounterPath]<br />
* [http://mumble.sourceforge.net Mumble]<br />
* [http://www.teamspeak.com Teamspeak]<br />
<br />
=== WebRTC ===<br />
<br />
* [http://getfirefox.net Firefox]<br />
* [http://www.google.com/chrome Chrome]<br />
<br />
== HTTP Streaming ==<br />
<br />
=== Browsers ===<br />
<br />
* [http://getfirefox.net Firefox]<br />
* [http://www.google.com/chrome Chrome] (needs flag)<br />
* [http://www.opera.com Opera] (needs flag)<br />
<br />
=== Clients ===<br />
<br />
* [http://www.ffmpeg.org FFMpeg]<br />
* [http://www.gstreamer.net GStreamer]<br />
* [http://www.videolan.org/vlc/ VLC]<br />
* [http://www.foobar2000.org Foobar2000]<br />
* Winamp (with plugin)<br />
* [http://amarok.kde.org Amarok]<br />
<br />
=== Server/Source ===<br />
<br />
* [http://xeocoder.com/ XeoCoder]<br />
<br />
== Distribution ==<br />
<br />
* [http://blog.magnatune.com/2013/09/opus-format-audio-files-now-available-at-magnatune.html Magnatune music store]<br />
<br />
* [http://www.streamguys.com/news.php?id=116 StreamGuys CDN]<br />
<br />
== Broadcast ==<br />
<br />
=== Equipment ===<br />
<br />
* [http://tieline.com Tieline]<br />
* [http://mayah.com Mayah]<br />
* [http://harrisbroadcast.com Harris Broadcast]</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusSupport&diff=14261OpusSupport2013-09-30T16:34:19Z<p>Jmspeex: Created page with "= List of software and services supporting Opus = == VoIP/videoconference == * Jitsi * Meetecho * CounterPath * Mumble * Teamspeak === WebRTC === * Firefox * Chrome == HTTP ..."</p>
<hr />
<div>= List of software and services supporting Opus =<br />
<br />
== VoIP/videoconference ==<br />
<br />
* Jitsi<br />
* Meetecho<br />
* CounterPath<br />
* Mumble<br />
* Teamspeak<br />
<br />
=== WebRTC ===<br />
<br />
* Firefox<br />
* Chrome<br />
<br />
== HTTP Streaming ==<br />
<br />
=== Browsers ===<br />
<br />
* Firefox<br />
* Chrome (needs flag)<br />
* Opera (needs flag)<br />
<br />
=== Clients ===<br />
<br />
* FFMpeg<br />
* GStreamer<br />
* VLC<br />
* Foobar2000<br />
* Winamp (with plugin)<br />
* Amarok<br />
<br />
== Distribution ==<br />
<br />
* Magnatune music store<br />
<br />
* StreamGuys CDN<br />
<br />
== Broadcast ==<br />
<br />
=== Equipment ===<br />
<br />
* Tieline<br />
* Mayah<br />
* Harris Broadcast</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusFAQ&diff=14252OpusFAQ2013-09-21T00:25:24Z<p>Jmspeex: </p>
<hr />
<div>[[Image:Opus logo trans.png|right]]<br />
<br />
== General Questions ==<br />
<br />
=== What is Opus? Who created it? ===<br />
<br />
Opus is a totally open, royalty-free, highly versatile audio codec. It is primarily designed for interactive speech and music transmission over the Internet, but is also applicable to storage and streaming applications. It incorporates technology from Skype's SILK codec and Xiph.Org's CELT codec. It has been standardized by the Internet Engineering Task Force (IETF) as '''[http://tools.ietf.org/html/rfc6716 RFC 6716]'''. <br />
<br />
Opus has been in development since early 2007. Programmers associated with Xiph.Org, Skype, and several other organizations have contributed to its development and to the standardization process as part of the IETF's codec working group.<br />
<br />
=== How does Opus compare to other codecs? ===<br />
<br />
Opus is distinguished from most formats for high quality audio (AAC, Vorbis, MP3) by having low delay and it is distinguished from most low delay formats (G.711, GSM, Speex) by supporting high audio quality. It meets or exceeds existing codecs' quality across a wide range of bitrates, and it operates at lower delay than virtually any existing compressed format. Further, the Opus format itself and the reference implementation are available under liberal royalty-free licenses, making it easy to adopt, compatible with free software, and suitable for usage as part of the basic infrastructure of the Internet. See the Opus [http://opus-codec.org/comparison comparison page] for more details.<br />
<br />
=== Does Opus make all those other lossy codecs obsolete? ===<br />
<br />
Theoretically, yes. From technical point of view (loss, delay, bitrates, ...) it can replace both Vorbis and Speex, and the common proprietary codecs too.<br />
<br />
=== Will Opus replace Vorbis in video files? ===<br />
<br />
For OGG Theora video files, it can, just the overall size reduction will be minimal, and it will break compatibility with existing players.<br />
<br />
For WebM video files, same does apply, but additionally this would need a change of the spec, as the current spec says that the only allowed video codec is VP8 and the only allowed audio codec is Vorbis.<br />
<br />
=== How do I use Opus? What programs support Opus? ===<br />
<br />
Opus decoding support is now included in many applications, including Firefox, foobar2000, and VLC, as well as in frameworks such as GStreamer and FFmpeg. For now, the best way to '''encode''' Opus files is to use the opusenc command-line tool from the opus-tools package. For real-time applications, Opus support should soon be available in the Google webrtc codebase. Opus is still a new codec, expect many more applications to support it in the near future.<br />
<br />
=== Does Opus support higher sampling rates, such as 96 kHz or 192 kHz? ===<br />
<br />
Yes and no. Opus encoding tools like opusenc will happily encode files that are sampled at 96 or 192 kHz. However, input files at these rates are internally converted to 48 kHz, and then only frequencies up to 20 kHz are encoded. The reason is simple: lossy codecs are designed to preserve audible details while discarding irrelevant information. Since the human ear can only hear up to 20 kHz at best (usually lower than that), frequency content above 20 kHz is the first thing to go. See Monty's [http://people.xiph.org/~xiphmont/demo/neil-young.html 24/192 Music Downloads ...and why they make no sense] for more details. <br />
<br />
=== What are the licensing requirements? ===<br />
<br />
The reference Opus source code is released under a three-clause BSD license, which is a very permissive Open Source license. Commercial use and distribution (including in proprietary software) is permitted, provided that some basic conditions specified in the license are met. <br />
<br />
Opus is also covered by some patents, for which royalty-free usage rights are granted, under conditions that the authors believe are compatible with most (all?) open source licenses, including the GPL (v2 and v3). See the [http://www.opus-codec.org/license/ licensing page] for details.<br />
<br />
=== Why make Opus free? ===<br />
<br />
On the Internet, protocol and codec standards are part of the common infrastructure everyone builds upon. Most of the value of a high quality standard is the innovation and interoperation provided by the systems built on top of it. When a few parties have monopoly rights to monetize a standard, that infrastructure stops being so common—everyone else has more reason to use their own solution instead, increasing cost and reducing efficiency. Imagine a road system where each type of car could only drive on its own manufacturer's pavement. We all benefit from living in a world where all the roads are connected. This is why Opus, unlike many codecs, is free.<br />
<br />
=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===<br />
<br />
No. The SILK codec, as submitted by Skype to the IETF, was heavily modified as part of its integration within Opus. The modifications are significant enough that it is not possible to just write a "translator" and even sharing code between Opus and the "old SILK" would be highly non-trivial.<br />
<br />
=== Why not keep the SILK and CELT codecs separate? ===<br />
<br />
Opus is more than just two independent codecs with a switch. In addition to a linear prediction "SILK mode" and a MDCT "CELT mode" it has a "hybrid mode," where speech frequencies up to 8 kHz are encoded with LP while those above 8 kHz are encoded with MDCT. This is what allows Opus to have such high speech quality around 32 kb/s. Another advantage of the integration is the ability to switch between these modes seamlessly, without any "glitch" and without any out-of-band signalling.<br />
<br />
=== Now that Opus is standardized, will its development stop, or can it be further improved? ===<br />
<br />
Unlike most ITU-T codecs, Opus is only defined in terms of its decoder. The encoder can keep evolving as long as the bitstream it produces can be decoded by the reference decoder. This is what made it possible for MP3 encoders to improve far beyond the original l3enc and the dist10 reference implementation. Although it is unlikely that Opus encoders will see such spectacular evolution, we certainly hope that future encoders will become much better than the reference encoder. In fact, there is already an [http://www.opus-codec.org/development/ experimental branch] that significantly improves on the reference encoder's quality.<br />
<br />
=== Will all future Opus releases comply with the [http://tools.ietf.org/html/rfc6716 Opus specification]? ===<br />
<br />
Yes.<br />
<br />
=== In what ways is Opus optimized for the Internet? ===<br />
<br />
Opus being optimized for the Internet obviously means that it has good packet loss robustness and concealment, but it goes further. One of the first things we've been asked when designing Opus was to make the rate '''really''' adaptable because we never know what kind of rates will be available. This not only meant having a wide range of bitrates, but also being able to vary in small increments. This is why Opus scales from about 6 kb/s to 512 kb/s, in increments of 0.4 kb/s (one byte with 20 ms frames). The reason Opus can have more than 1200 possible bitrates spending 11 bits signalling the bitrate is because UDP already encodes the packet size. One last aspect is that Opus is simple to transport over RTP, as can be seen from [http://tools.ietf.org/html/draft-spittka-payload-rtp-opus Opus RTP payload format]. For example, it's possible to decode RTP packets without having even seen the SDP or any out-of-band signalling. <br />
<br />
=== What applications for Android can play Opus? ===<br />
<br />
Right now, there are just a few but that list is fast growing. Please reference [http://android.stackexchange.com/q/37970/7425 this question on android.stackexchange.com]. Feel free to suggest other applications.<br />
<br />
=== When will the next version be released? ===<br />
<br />
When it's done. Seriously. We do not know. Opus is not a large project with a fixed release schedule. That being said, our pre-releases and even the git repository are generally pretty stable and given proper testing (which you should always do anyway), are safe to distribute. Just be aware that the API of new features (that have never been included in a stable release) could potentially still change.<br />
<br />
== Opus for Software developers ==<br />
<br />
=== On what platforms does Opus run? ===<br />
<br />
The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs. A few of the platforms on which Opus has been tested and is known to run include x86, x86-64, ARM, Itanium, Blackfin, and SPARC.<br />
<br />
=== Is there a fixed-point implementation? ===<br />
<br />
Yes; the fixed-point and floating-point decoder and encoder implementations are part of the same code base. The code defaults to float, so you need to configure with --enable-fixed-point (or defining FIXED_POINT if not using the configure script) to build the code for fixed-point.<br />
<br />
=== Which implementation should I use? ===<br />
<br />
While the implementation in RFC 6716 is what ''defines'' the standard, it is likely not the best and most up-to-date implementation. The [http://opus-codec.org/ Opus] website was set up for the purpose of continually improving the implementation— in terms of speed, encoding quality, device compatibility, etc— while still conforming to the standard. All Opus implementations are compatible by definition.<br />
<br />
=== How is supporting Opus different from supporting Speex/G.711/MP3? ===<br />
<br />
Opus has variable frame durations which can change on the fly, so an Opus decoder needs to be ready to accept packets with durations that are any multiple of 2.5ms up to a maximum of 120ms. <br />
<br />
The opus encoder and decoder do not need to have matched sampling rates or channel counts. It is recommended to always just decode at the highest rate the hardware supports (e.g. 48kHz stereo) so the user gets the full quality of whatever the far end is sending.<br />
<br />
=== My application doesn't work. Can anyone help me? ===<br />
<br />
It's possible to get help, but before doing so, there are a few basic things to try:<br />
<br />
* Implement the application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus.<br />
* Read the [http://www.opus-codec.org/docs/ documentation].<br />
* Read the opus_demo.c source code to see how to use the encoder and decoder.<br />
<br />
If you still can't solve the problem, the best option is to ask for help on the [http://lists.xiph.org/mailman/listinfo/opus mailing list].<br />
<br />
=== How do I report a bug? ===<br />
<br />
If you think you have found a bug in Opus (and not in your application), please [https://trac.xiph.org/newticket?component=Opus file a bug report]. Please include a way for us to reproduce the problem. The best way to do this is to provide an input file, along with the opusenc/opusdec/opus_demo command line that causes the bug to occur. If the bug cannot be triggered by the command line tools, please provide a simple patch or C file that can help reproduce it. Please also provide any other relevant information, such as OS, CPU, build options, etc. Also, don't hesitate to also contact us on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on [irc://irc.freenode.net/opus IRC].<br />
<br />
=== What is Opus Custom? ===<br />
<br />
Opus Custom is an '''optional''' part of the Opus standard that allows for sampling rates other than 8, 12, 16, 24, or 48 kHz and frame sizes other than multiples of 2.5 ms. Opus Custom requires additional out-of-band signalling that Opus does not normally require and disables many of Opus' coding modes. Also, because it is an optional part of the specification, using Opus Custom may lead to compatibility problems. For these reasons, its use is discouraged outside of very specific applications, e.g.:<br />
* ultra low delay applications where synchronization with the soundcard buffer is important. <br />
* low-power embedded applications where compatibility with others is not important.<br />
<br />
For almost all other types of applications, Opus Custom should not be used.<br />
<br />
=== How do I use 44.1 kHz or some other sampling rate not directly supported by Opus? ===<br />
<br />
Tools which read or write Opus should interoperate with other sampling rates by transparently performing sample rate conversion behind the scenes whenever necessary. In particular, software developers should not use Opus Custom for 44.1 kHz support, except in the very specific circumstances outlined above.<br />
<br />
Note that it's generally preferable for a decoder to output at 48kHz even when you know the original input was 44.1kHz, not only because you can skip resampling but also because many inexpensive audio interfaces have poor quality output for 44.1k.<br />
<br />
The opus-tools package source code contains a small, high quality, high performance, BSD licensed resampler which can be used where resampling is required.<br />
<br />
=== Forward Error correction (FEC) doesn't appear to do anything! HELP! ===<br />
<br />
The inband FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.<br />
<br />
In order to make use of inband FEC the decoder must delay its output by at least one frame so that it can call the decoder with the decode_fec argument on the ''next'' frame in order to reconstruct the missed frame. This works best if it's integrated with a jitter buffer.<br />
<br />
FEC is only used by the encoder under certain conditions: the feature must be enabled via the OPUS_SET_INBAND_FEC CTL, the encoder must be told to expect loss via the OPUS_SET_PACKET_LOSS_PERC CTL, and the codec must be operated in any of the linear prediction or Hybrid modes. Frame durations of <10ms and very high bitrates will use the MDCT modes, where FEC is not available.<br />
<br />
Even when FEC is not used, telling the encoder about the expected level of loss will help it make more intelligent decisions. By default the implementation assumes there is no loss.<br />
<br />
=== I can't use malloc or much stack on my embedded platform. How do I make Opus work? ===<br />
<br />
A normal build of libopus only uses malloc/free in the _create() and _destroy() calls, so Opus is safe for realtime use so long as the codec state is pre-created.<br />
<br />
In order to build Opus without any reference to malloc/free at all use init() calls rather than the create() calls in your application and compile with <tt>CFLAGS="-DOVERRIDE_OPUS_ALLOC -DOVERRIDE_OPUS_FREE -D'opus_alloc(x)=NULL' -D'opus_free(x)=NULL' "</tt> you will get a build which does not use malloc/free.<br />
<br />
If libopus is built with -DNONTHREADSAFE_PSEUDOSTACK (instead of VAR_ARRAYS, or USE_ALLOCA) it will use a user provided block of heap instead of stack for many things resulting in much lower the stack usage. However this makes the resulting library non-threadsafe and is not recommend on anything except limited embedded platforms.<br />
<br />
=== How can I ensure that my software interoperates with other software implementing Opus? ===<br />
<br />
For applications using Ogg files, there are some [http://people.xiph.org/~greg/opus_testvectors/ Ogg Opus testvectors] to test decoders and you can test encoders with opusdec. For RTP applications, the opusrtp tool can be useful. In general, here's a list of specific issues to check:<br />
* Can your application handle all frame sizes, including changing the frame size from frame to frame?<br />
* Does your application properly react to lost packet by calling the decoder with a NULL packet?<br />
<br />
=== What is the complexity of Opus? ===<br />
<br />
The complexity of Opus varies by a large amount based on the settings used. It depends on the mode, audio bandwidth, number of channels, and even a "complexity knob" that can trade complexity for quality. It will run easily on any recent PC or smartphone. For slower embedded CPUs/DSPs, the amount of CPU required will vary depending on the configuration and the exact CPU, so you will need to experiment. Do not expect Opus to run on really slow devices like 8-bit micro-controllers.<br />
<br />
=== Opus is using too much CPU for my application. What can I do? ===<br />
<br />
First don't panic and don't start writing assembly just yet. It's possible that you're just not using the right set of options. If you're targeting an embedded/mobile platform, chances are the fixed-point build will be faster, so make you you're using --enable-fixed-point or defining FIXED_POINT in the build system. Opus also has a complexity option that can trade quality for complexity. The default is highest quality and highest complexity. You can control this using OPUS_SET_COMPLEXITY() (see doc for details). If all else fails and you need to optimize the Opus code, see the next question.<br />
<br />
=== I would like to optimize Opus. Where should I start? ===<br />
<br />
Please [http://www.opus-codec.org/contact/ contact us] before you start, or at least before you get too far. This will help coordinate the optimization effort and generally reduce the probability of wasting your time on duplicated effort or generally going on the wrong path. <br />
<br />
=== Does Opus have an echo canceller like Speex does? ===<br />
<br />
Echo cancellation is completely independent from codecs. You can use any echo canceller (including the one from libspeexdsp) along with Opus. That being said, among the free acoustic echo cancelers (AEC) we're aware of, the best is probably the Google AEC from the [https://code.google.com/p/webrtc/ WebRTC codebase].</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusFAQ&diff=14239OpusFAQ2013-09-04T04:06:32Z<p>Jmspeex: </p>
<hr />
<div>[[Image:Opus logo trans.png|right]]<br />
<br />
== General Questions ==<br />
<br />
=== What is Opus? Who created it? ===<br />
<br />
Opus is a totally open, royalty-free, highly versatile audio codec. It is primarily designed for interactive speech and music transmission over the Internet, but is also applicable to storage and streaming applications. It incorporates technology from Skype's SILK codec and Xiph.Org's CELT codec. It has been standardized by the Internet Engineering Task Force (IETF) as '''[http://tools.ietf.org/html/rfc6716 RFC 6716]'''. <br />
<br />
Opus has been in development since early 2007. Programmers associated with Xiph.Org, Skype, and several other organizations have contributed to its development and to the standardization process as part of the IETF's codec working group.<br />
<br />
=== How does Opus compare to other codecs? ===<br />
<br />
Opus is distinguished from most formats for high quality audio (AAC, Vorbis, MP3) by having low delay and it is distinguished from most low delay formats (G.711, GSM, Speex) by supporting high audio quality. It meets or exceeds existing codecs' quality across a wide range of bitrates, and it operates at lower delay than virtually any existing compressed format. Further, the Opus format itself and the reference implementation are available under liberal royalty-free licenses, making it easy to adopt, compatible with free software, and suitable for usage as part of the basic infrastructure of the Internet. See the Opus [http://opus-codec.org/comparison comparison page] for more details.<br />
<br />
=== Does Opus make all those other lossy codecs obsolete? ===<br />
<br />
Theoretically, yes. From technical point of view (loss, delay, bitrates, ...) it can replace both Vorbis and Speex, and the common proprietary codecs too.<br />
<br />
=== Will Opus replace Vorbis in video files? ===<br />
<br />
For OGG Theora video files, it can, just the overall size reduction will be minimal, and it will break compatibility with existing players.<br />
<br />
For WebM video files, same does apply, but additionally this would need a change of the spec, as the current spec says that the only allowed video codec is VP8 and the only allowed audio codec is Vorbis.<br />
<br />
=== How do I use Opus? What programs support Opus? ===<br />
<br />
Opus decoding support is now included in many applications, including Firefox, foobar2000, and VLC, as well as in frameworks such as GStreamer and FFmpeg. For now, the best way to '''encode''' Opus files is to use the opusenc command-line tool from the opus-tools package. For real-time applications, Opus support should soon be available in the Google webrtc codebase. Opus is still a new codec, expect many more applications to support it in the near future.<br />
<br />
=== Does Opus support higher sampling rates, such as 96 kHz or 192 kHz? ===<br />
<br />
Yes and no. Opus encoding tools like opusenc will happily encode files that are sampled at 96 or 192 kHz. However, input files at these rates are internally converted to 48 kHz, and then only frequencies up to 20 kHz are encoded. The reason is simple: lossy codecs are designed to preserve audible details while discarding irrelevant information. Since the human ear can only hear up to 20 kHz at best (usually lower than that), frequency content above 20 kHz is the first thing to go. See Monty's [http://people.xiph.org/~xiphmont/demo/neil-young.html 24/192 Music Downloads ...and why they make no sense] for more details. <br />
<br />
=== What are the licensing requirements? ===<br />
<br />
The reference Opus source code is released under a three-clause BSD license, which is a very permissive Open Source license. Commercial use and distribution (including in proprietary software) is permitted, provided that some basic conditions specified in the license are met. <br />
<br />
Opus is also covered by some patents, for which royalty-free usage rights are granted, under conditions that the authors believe are compatible with most (all?) open source licenses, including the GPL (v2 and v3). See the [http://www.opus-codec.org/license/ licensing page] for details.<br />
<br />
=== Why make Opus free? ===<br />
<br />
On the Internet, protocol and codec standards are part of the common infrastructure everyone builds upon. Most of the value of a high quality standard is the innovation and interoperation provided by the systems built on top of it. When a few parties have monopoly rights to monetize a standard, that infrastructure stops being so common—everyone else has more reason to use their own solution instead, increasing cost and reducing efficiency. Imagine a road system where each type of car could only drive on its own manufacturer's pavement. We all benefit from living in a world where all the roads are connected. This is why Opus, unlike many codecs, is free.<br />
<br />
=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===<br />
<br />
No. The SILK codec, as submitted by Skype to the IETF, was heavily modified as part of its integration within Opus. The modifications are significant enough that it is not possible to just write a "translator" and even sharing code between Opus and the "old SILK" would be highly non-trivial.<br />
<br />
=== Why not keep the SILK and CELT codecs separate? ===<br />
<br />
Opus is more than just two independent codecs with a switch. In addition to a linear prediction "SILK mode" and a MDCT "CELT mode" it has a "hybrid mode," where speech frequencies up to 8 kHz are encoded with LP while those above 8 kHz are encoded with MDCT. This is what allows Opus to have such high speech quality around 32 kb/s. Another advantage of the integration is the ability to switch between these modes seamlessly, without any "glitch" and without any out-of-band signalling.<br />
<br />
=== Now that Opus is standardized, will its development stop, or can it be further improved? ===<br />
<br />
Unlike most ITU-T codecs, Opus is only defined in terms of its decoder. The encoder can keep evolving as long as the bitstream it produces can be decoded by the reference decoder. This is what made it possible for MP3 encoders to improve far beyond the original l3enc and the dist10 reference implementation. Although it is unlikely that Opus encoders will see such spectacular evolution, we certainly hope that future encoders will become much better than the reference encoder. In fact, there is already an [http://www.opus-codec.org/development/ experimental branch] that significantly improves on the reference encoder's quality.<br />
<br />
=== Will all future Opus releases comply with the [http://tools.ietf.org/html/rfc6716 Opus specification]? ===<br />
<br />
Yes.<br />
<br />
=== In what ways is Opus optimized for the Internet? ===<br />
<br />
Opus being optimized for the Internet obviously means that it has good packet loss robustness and concealment, but it goes further. One of the first things we've been asked when designing Opus was to make the rate '''really''' adaptable because we never know what kind of rates will be available. This not only meant having a wide range of bitrates, but also being able to vary in small increments. This is why Opus scales from about 6 kb/s to 512 kb/s, in increments of 0.4 kb/s (one byte with 20 ms frames). The reason Opus can have more than 1200 possible bitrates spending 11 bits signalling the bitrate is because UDP already encodes the packet size. One last aspect is that Opus is simple to transport over RTP, as can be seen from [http://tools.ietf.org/html/draft-spittka-payload-rtp-opus Opus RTP payload format]. For example, it's possible to decode RTP packets without having even seen the SDP or any out-of-band signalling. <br />
<br />
=== What applications for Android can play Opus? ===<br />
<br />
Right now, there are just a few but that list is fast growing. Please reference [http://android.stackexchange.com/q/37970/7425 this question on android.stackexchange.com]. Feel free to suggest other applications.<br />
<br />
=== When will the next version be released? ===<br />
<br />
When it's done. Seriously. We do not know. Opus is not a large project with a fixed release schedule. That being said, our pre-releases and even the git repository are generally pretty stable and given proper testing (which you should always do anyway), are safe to distribute. Just be aware that the API of new features (that have never been included in a stable release) could potentially still change.<br />
<br />
== Opus for Software developers ==<br />
<br />
=== On what platforms does Opus run? ===<br />
<br />
The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs. A few of the platforms on which Opus has been tested and is known to run include x86, x86-64, ARM, Itanium, Blackfin, and SPARC.<br />
<br />
=== Is there a fixed-point implementation? ===<br />
<br />
Yes; the fixed-point and floating-point decoder and encoder implementations are part of the same code base. The code defaults to float, so you need to configure with --enable-fixed-point (or defining FIXED_POINT if not using the configure script) to build the code for fixed-point.<br />
<br />
=== Which implementation should I use? ===<br />
<br />
While the implementation in RFC 6716 is what ''defines'' the standard, it is likely not the best and most up-to-date implementation. The [http://opus-codec.org/ Opus] website was set up for the purpose of continually improving the implementation— in terms of speed, encoding quality, device compatibility, etc— while still conforming to the standard. All Opus implementations are compatible by definition.<br />
<br />
=== How is supporting Opus different from supporting Speex/G.711/MP3? ===<br />
<br />
Opus has variable frame durations which can change on the fly, so an Opus decoder needs to be ready to accept packets with durations that are any multiple of 2.5ms up to a maximum of 120ms. <br />
<br />
The opus encoder and decoder do not need to have matched sampling rates or channel counts. It is recommended to always just decode at the highest rate the hardware supports (e.g. 48kHz stereo) so the user gets the full quality of whatever the far end is sending.<br />
<br />
=== My application doesn't work. Can anyone help me? ===<br />
<br />
It's possible to get help, but before doing so, there are a few basic things to try:<br />
<br />
* Implement the application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus.<br />
* Read the [http://www.opus-codec.org/docs/ documentation].<br />
* Read the opus_demo.c source code to see how to use the encoder and decoder.<br />
<br />
If you still can't solve the problem, the best option is to ask for help on the [http://lists.xiph.org/mailman/listinfo/opus mailing list].<br />
<br />
=== How do I report a bug? ===<br />
<br />
If you think you have found a bug in Opus (and not in your application), please [https://trac.xiph.org/newticket?component=Opus file a bug report]. Please include a way for us to reproduce the problem. The best way to do this is to provide an input file, along with the opusenc/opusdec/opus_demo command line that causes the bug to occur. If the bug cannot be triggered by the command line tools, please provide a simple patch or C file that can help reproduce it. Please also provide any other relevant information, such as OS, CPU, build options, etc. Also, don't hesitate to also contact us on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on [irc://irc.freenode.net/opus IRC].<br />
<br />
=== What is Opus Custom? ===<br />
<br />
Opus Custom is an '''optional''' part of the Opus standard that allows for sampling rates other than 8, 12, 16, 24, or 48 kHz and frame sizes other than multiples of 2.5 ms. Opus Custom requires additional out-of-band signalling that Opus does not normally require and disables many of Opus' coding modes. Also, because it is an optional part of the specification, using Opus Custom may lead to compatibility problems. For these reasons, its use is discouraged outside of very specific applications, e.g.:<br />
* ultra low delay applications where synchronization with the soundcard buffer is important. <br />
* low-power embedded applications where compatibility with others is not important.<br />
<br />
For almost all other types of applications, Opus Custom should not be used.<br />
<br />
=== How do I use 44.1 kHz or some other sampling rate not directly supported by Opus? ===<br />
<br />
Tools which read or write Opus should interoperate with other sampling rates by transparently performing sample rate conversion behind the scenes whenever necessary. In particular, software developers should not use Opus Custom for 44.1 kHz support, except in the very specific circumstances outlined above.<br />
<br />
Note that it's generally preferable for a decoder to output at 48kHz even when you know the original input was 44.1kHz, not only because you can skip resampling but also because many inexpensive audio interfaces have poor quality output for 44.1k.<br />
<br />
The opus-tools package source code contains a small, high quality, high performance, BSD licensed resampler which can be used where resampling is required.<br />
<br />
=== Forward Error correction (FEC) doesn't appear to do anything! HELP! ===<br />
<br />
The inband FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.<br />
<br />
In order to make use of inband FEC the decoder must delay its output by at least one frame so that it can call the decoder with the decode_fec argument on the ''next'' frame in order to reconstruct the missed frame. This works best if it's integrated with a jitter buffer.<br />
<br />
FEC is only used by the encoder under certain conditions: the feature must be enabled via the OPUS_SET_INBAND_FEC CTL, the encoder must be told to expect loss via the OPUS_SET_PACKET_LOSS_PERC CTL, and the codec must be operated in any of the linear prediction or Hybrid modes. Frame durations of <10ms and very high bitrates will use the MDCT modes, where FEC is not available.<br />
<br />
Even when FEC is not used, telling the encoder about the expected level of loss will help it make more intelligent decisions. By default the implementation assumes there is no loss.<br />
<br />
=== I can't use malloc or much stack on my embedded platform. How do I make Opus work? ===<br />
<br />
A normal build of libopus only uses malloc/free in the _create() and _destroy() calls, so Opus is safe for realtime use so long as the codec state is pre-created.<br />
<br />
In order to build Opus without any reference to malloc/free at all use init() calls rather than the create() calls in your application and compile with <tt>CFLAGS="-DOVERRIDE_OPUS_ALLOC -DOVERRIDE_OPUS_FREE -D'opus_alloc(x)=NULL' -D'opus_free(x)=NULL' "</tt> you will get a build which does not use malloc/free.<br />
<br />
If libopus is built with -DNONTHREADSAFE_PSEUDOSTACK (instead of VAR_ARRAYS, or USE_ALLOCA) it will use a user provided block of heap instead of stack for many things resulting in much lower the stack usage. However this makes the resulting library non-threadsafe and is not recommend on anything except limited embedded platforms.<br />
<br />
=== How can I ensure that my software interoperates with other software implementing Opus? ===<br />
<br />
For applications using Ogg files, there are some [http://people.xiph.org/~greg/opus_testvectors/ Ogg Opus testvectors] to test decoders and you can test encoders with opusdec. For RTP applications, the opusrtp tool can be useful. In general, here's a list of specific issues to check:<br />
* Can your application handle all frame sizes, including changing the frame size from frame to frame?<br />
* Does your application properly react to lost packet by calling the decoder with a NULL packet?<br />
<br />
=== What is the complexity of Opus? ===<br />
<br />
The complexity of Opus varies by a large amount based on the settings used. It depends on the mode, audio bandwidth, number of channels, and even a "complexity knob" that can trade complexity for quality. It will run easily on any recent PC or smartphone. For slower embedded CPUs/DSPs, the amount of CPU required will vary depending on the configuration and the exact CPU, so you will need to experiment. Do not expect Opus to run on really slow devices like 8-bit micro-controllers.<br />
<br />
=== I would like to optimize Opus. Where should I start? ===<br />
<br />
Please [http://www.opus-codec.org/contact/ contact us] before you start, or at least before you get too far. This will help coordinate the optimization effort and generally reduce the probability of wasting your time on duplicated effort or generally going on the wrong path. <br />
<br />
=== Does Opus have an echo canceller like Speex does? ===<br />
<br />
Echo cancellation is completely independent from codecs. You can use any echo canceller (including the one from libspeexdsp) along with Opus. That being said, among the free acoustic echo cancelers (AEC) we're aware of, the best is probably the Google AEC from the [https://code.google.com/p/webrtc/ WebRTC codebase].</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusFAQ&diff=14238OpusFAQ2013-09-04T03:54:32Z<p>Jmspeex: /* What is the complexity of Opus? */</p>
<hr />
<div>[[Image:Opus logo trans.png|right]]<br />
<br />
== General Questions ==<br />
<br />
=== What is Opus? Who created it? ===<br />
<br />
Opus is a totally open, royalty-free, highly versatile audio codec. It is primarily designed for interactive speech and music transmission over the Internet, but is also applicable to storage and streaming applications. It incorporates technology from Skype's SILK codec and Xiph.Org's CELT codec. It has been standardized by the Internet Engineering Task Force (IETF) as '''[http://tools.ietf.org/html/rfc6716 RFC 6716]'''. <br />
<br />
Opus has been in development since early 2007. Programmers associated with Xiph.Org, Skype, and several other organizations have contributed to its development and to the standardization process as part of the IETF's codec working group.<br />
<br />
=== How does Opus compare to other codecs? ===<br />
<br />
Opus is distinguished from most formats for high quality audio (AAC, Vorbis, MP3) by having low delay and it is distinguished from most low delay formats (G.711, GSM, Speex) by supporting high audio quality. It meets or exceeds existing codecs' quality across a wide range of bitrates, and it operates at lower delay than virtually any existing compressed format. Further, the Opus format itself and the reference implementation are available under liberal royalty-free licenses, making it easy to adopt, compatible with free software, and suitable for usage as part of the basic infrastructure of the Internet. See the Opus [http://opus-codec.org/comparison comparison page] for more details.<br />
<br />
=== Does Opus make all those other lossy codecs obsolete? ===<br />
<br />
Theoretically, yes. From technical point of view (loss, delay, bitrates, ...) it can replace both Vorbis and Speex, and the common proprietary codecs too.<br />
<br />
=== Will Opus replace Vorbis in video files? ===<br />
<br />
For OGG Theora video files, it can, just the overall size reduction will be minimal, and it will break compatibility with existing players.<br />
<br />
For WebM video files, same does apply, but additionally this would need a change of the spec, as the current spec says that the only allowed video codec is VP8 and the only allowed audio codec is Vorbis.<br />
<br />
=== How do I use Opus? What programs support Opus? ===<br />
<br />
Opus decoding support is now included in many applications, including Firefox, foobar2000, and VLC, as well as in frameworks such as GStreamer and FFmpeg. For now, the best way to '''encode''' Opus files is to use the opusenc command-line tool from the opus-tools package. For real-time applications, Opus support should soon be available in the Google webrtc codebase. Opus is still a new codec, expect many more applications to support it in the near future.<br />
<br />
=== Does Opus support higher sampling rates, such as 96 kHz or 192 kHz? ===<br />
<br />
Yes and no. Opus encoding tools like opusenc will happily encode files that are sampled at 96 or 192 kHz. However, input files at these rates are internally converted to 48 kHz, and then only frequencies up to 20 kHz are encoded. The reason is simple: lossy codecs are designed to preserve audible details while discarding irrelevant information. Since the human ear can only hear up to 20 kHz at best (usually lower than that), frequency content above 20 kHz is the first thing to go. See Monty's [http://people.xiph.org/~xiphmont/demo/neil-young.html 24/192 Music Downloads ...and why they make no sense] for more details. <br />
<br />
=== What are the licensing requirements? ===<br />
<br />
The reference Opus source code is released under a three-clause BSD license, which is a very permissive Open Source license. Commercial use and distribution (including in proprietary software) is permitted, provided that some basic conditions specified in the license are met. <br />
<br />
Opus is also covered by some patents, for which royalty-free usage rights are granted, under conditions that the authors believe are compatible with most (all?) open source licenses, including the GPL (v2 and v3). See the [http://www.opus-codec.org/license/ licensing page] for details.<br />
<br />
=== Why make Opus free? ===<br />
<br />
On the Internet, protocol and codec standards are part of the common infrastructure everyone builds upon. Most of the value of a high quality standard is the innovation and interoperation provided by the systems built on top of it. When a few parties have monopoly rights to monetize a standard, that infrastructure stops being so common—everyone else has more reason to use their own solution instead, increasing cost and reducing efficiency. Imagine a road system where each type of car could only drive on its own manufacturer's pavement. We all benefit from living in a world where all the roads are connected. This is why Opus, unlike many codecs, is free.<br />
<br />
=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===<br />
<br />
No. The SILK codec, as submitted by Skype to the IETF, was heavily modified as part of its integration within Opus. The modifications are significant enough that it is not possible to just write a "translator" and even sharing code between Opus and the "old SILK" would be highly non-trivial.<br />
<br />
=== Why not keep the SILK and CELT codecs separate? ===<br />
<br />
Opus is more than just two independent codecs with a switch. In addition to a linear prediction "SILK mode" and a MDCT "CELT mode" it has a "hybrid mode," where speech frequencies up to 8 kHz are encoded with LP while those above 8 kHz are encoded with MDCT. This is what allows Opus to have such high speech quality around 32 kb/s. Another advantage of the integration is the ability to switch between these modes seamlessly, without any "glitch" and without any out-of-band signalling.<br />
<br />
=== Now that Opus is standardized, will its development stop, or can it be further improved? ===<br />
<br />
Unlike most ITU-T codecs, Opus is only defined in terms of its decoder. The encoder can keep evolving as long as the bitstream it produces can be decoded by the reference decoder. This is what made it possible for MP3 encoders to improve far beyond the original l3enc and the dist10 reference implementation. Although it is unlikely that Opus encoders will see such spectacular evolution, we certainly hope that future encoders will become much better than the reference encoder. In fact, there is already an [http://www.opus-codec.org/development/ experimental branch] that significantly improves on the reference encoder's quality.<br />
<br />
=== Will all future Opus releases comply with the [http://tools.ietf.org/html/rfc6716 Opus specification]? ===<br />
<br />
Yes.<br />
<br />
=== In what ways is Opus optimized for the Internet? ===<br />
<br />
Opus being optimized for the Internet obviously means that it has good packet loss robustness and concealment, but it goes further. One of the first things we've been asked when designing Opus was to make the rate '''really''' adaptable because we never know what kind of rates will be available. This not only meant having a wide range of bitrates, but also being able to vary in small increments. This is why Opus scales from about 6 kb/s to 512 kb/s, in increments of 0.4 kb/s (one byte with 20 ms frames). The reason Opus can have more than 1200 possible bitrates spending 11 bits signalling the bitrate is because UDP already encodes the packet size. One last aspect is that Opus is simple to transport over RTP, as can be seen from [http://tools.ietf.org/html/draft-spittka-payload-rtp-opus Opus RTP payload format]. For example, it's possible to decode RTP packets without having even seen the SDP or any out-of-band signalling. <br />
<br />
=== What applications for Android can play Opus? ===<br />
<br />
Right now, there are just a few but that list is fast growing. Please reference [http://android.stackexchange.com/q/37970/7425 this question on android.stackexchange.com]. Feel free to suggest other applications.<br />
<br />
<br />
<br />
== Opus for Software developers ==<br />
<br />
=== On what platforms does Opus run? ===<br />
<br />
The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs. A few of the platforms on which Opus has been tested and is known to run include x86, x86-64, ARM, Itanium, Blackfin, and SPARC.<br />
<br />
=== Is there a fixed-point implementation? ===<br />
<br />
Yes; the fixed-point and floating-point decoder and encoder implementations are part of the same code base. The code defaults to float, so you need to configure with --enable-fixed-point (or defining FIXED_POINT if not using the configure script) to build the code for fixed-point.<br />
<br />
=== Which implementation should I use? ===<br />
<br />
While the implementation in RFC 6716 is what ''defines'' the standard, it is likely not the best and most up-to-date implementation. The [http://opus-codec.org/ Opus] website was set up for the purpose of continually improving the implementation— in terms of speed, encoding quality, device compatibility, etc— while still conforming to the standard. All Opus implementations are compatible by definition.<br />
<br />
=== How is supporting Opus different from supporting Speex/G.711/MP3? ===<br />
<br />
Opus has variable frame durations which can change on the fly, so an Opus decoder needs to be ready to accept packets with durations that are any multiple of 2.5ms up to a maximum of 120ms. <br />
<br />
The opus encoder and decoder do not need to have matched sampling rates or channel counts. It is recommended to always just decode at the highest rate the hardware supports (e.g. 48kHz stereo) so the user gets the full quality of whatever the far end is sending.<br />
<br />
=== My application doesn't work. Can anyone help me? ===<br />
<br />
It's possible to get help, but before doing so, there are a few basic things to try:<br />
<br />
* Implement the application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus.<br />
* Read the [http://www.opus-codec.org/docs/ documentation].<br />
* Read the opus_demo.c source code to see how to use the encoder and decoder.<br />
<br />
If you still can't solve the problem, the best option is to ask for help on the [http://lists.xiph.org/mailman/listinfo/opus mailing list].<br />
<br />
=== How do I report a bug? ===<br />
<br />
If you think you have found a bug in Opus (and not in your application), please [https://trac.xiph.org/newticket?component=Opus file a bug report]. Please include a way for us to reproduce the problem. The best way to do this is to provide an input file, along with the opusenc/opusdec/opus_demo command line that causes the bug to occur. If the bug cannot be triggered by the command line tools, please provide a simple patch or C file that can help reproduce it. Please also provide any other relevant information, such as OS, CPU, build options, etc. Also, don't hesitate to also contact us on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on [irc://irc.freenode.net/opus IRC].<br />
<br />
=== What is Opus Custom? ===<br />
<br />
Opus Custom is an '''optional''' part of the Opus standard that allows for sampling rates other than 8, 12, 16, 24, or 48 kHz and frame sizes other than multiples of 2.5 ms. Opus Custom requires additional out-of-band signalling that Opus does not normally require and disables many of Opus' coding modes. Also, because it is an optional part of the specification, using Opus Custom may lead to compatibility problems. For these reasons, its use is discouraged outside of very specific applications, e.g.:<br />
* ultra low delay applications where synchronization with the soundcard buffer is important. <br />
* low-power embedded applications where compatibility with others is not important.<br />
<br />
For almost all other types of applications, Opus Custom should not be used.<br />
<br />
=== How do I use 44.1 kHz or some other sampling rate not directly supported by Opus? ===<br />
<br />
Tools which read or write Opus should interoperate with other sampling rates by transparently performing sample rate conversion behind the scenes whenever necessary. In particular, software developers should not use Opus Custom for 44.1 kHz support, except in the very specific circumstances outlined above.<br />
<br />
Note that it's generally preferable for a decoder to output at 48kHz even when you know the original input was 44.1kHz, not only because you can skip resampling but also because many inexpensive audio interfaces have poor quality output for 44.1k.<br />
<br />
The opus-tools package source code contains a small, high quality, high performance, BSD licensed resampler which can be used where resampling is required.<br />
<br />
=== Forward Error correction (FEC) doesn't appear to do anything! HELP! ===<br />
<br />
The inband FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.<br />
<br />
In order to make use of inband FEC the decoder must delay its output by at least one frame so that it can call the decoder with the decode_fec argument on the ''next'' frame in order to reconstruct the missed frame. This works best if it's integrated with a jitter buffer.<br />
<br />
FEC is only used by the encoder under certain conditions: the feature must be enabled via the OPUS_SET_INBAND_FEC CTL, the encoder must be told to expect loss via the OPUS_SET_PACKET_LOSS_PERC CTL, and the codec must be operated in any of the linear prediction or Hybrid modes. Frame durations of <10ms and very high bitrates will use the MDCT modes, where FEC is not available.<br />
<br />
Even when FEC is not used, telling the encoder about the expected level of loss will help it make more intelligent decisions. By default the implementation assumes there is no loss.<br />
<br />
=== I can't use malloc or much stack on my embedded platform. How do I make Opus work? ===<br />
<br />
A normal build of libopus only uses malloc/free in the _create() and _destroy() calls, so Opus is safe for realtime use so long as the codec state is pre-created.<br />
<br />
In order to build Opus without any reference to malloc/free at all use init() calls rather than the create() calls in your application and compile with <tt>CFLAGS="-DOVERRIDE_OPUS_ALLOC -DOVERRIDE_OPUS_FREE -D'opus_alloc(x)=NULL' -D'opus_free(x)=NULL' "</tt> you will get a build which does not use malloc/free.<br />
<br />
If libopus is built with -DNONTHREADSAFE_PSEUDOSTACK (instead of VAR_ARRAYS, or USE_ALLOCA) it will use a user provided block of heap instead of stack for many things resulting in much lower the stack usage. However this makes the resulting library non-threadsafe and is not recommend on anything except limited embedded platforms.<br />
<br />
=== How can I ensure that my software interoperates with other software implementing Opus? ===<br />
<br />
For applications using Ogg files, there are some [http://people.xiph.org/~greg/opus_testvectors/ Ogg Opus testvectors] to test decoders and you can test encoders with opusdec. For RTP applications, the opusrtp tool can be useful. In general, here's a list of specific issues to check:<br />
* Can your application handle all frame sizes, including changing the frame size from frame to frame?<br />
* Does your application properly react to lost packet by calling the decoder with a NULL packet?<br />
<br />
=== What is the complexity of Opus? ===<br />
<br />
The complexity of Opus varies by a large amount based on the settings used. It depends on the mode, audio bandwidth, number of channels, and even a "complexity knob" that can trade complexity for quality. It will run easily on any recent PC or smartphone. For slower embedded CPUs/DSPs, the amount of CPU required will vary depending on the configuration and the exact CPU, so you will need to experiment. Do not expect Opus to run on really slow devices like 8-bit micro-controllers.<br />
<br />
=== Does Opus have an echo canceller like Speex does? ===<br />
<br />
Echo cancellation is completely independent from codecs. You can use any echo canceller (including the one from libspeexdsp) along with Opus. That being said, among the free acoustic echo cancelers (AEC) we're aware of, the best is probably the Google AEC from the [https://code.google.com/p/webrtc/ WebRTC codebase].</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusFAQ&diff=14233OpusFAQ2013-08-25T16:47:22Z<p>Jmspeex: </p>
<hr />
<div>[[Image:Opus logo trans.png|right]]<br />
<br />
== General Questions ==<br />
<br />
=== What is Opus? Who created it? ===<br />
<br />
Opus is a totally open, royalty-free, highly versatile audio codec. It is primarily designed for interactive speech and music transmission over the Internet, but is also applicable to storage and streaming applications. It incorporates technology from Skype's SILK codec and Xiph.Org's CELT codec. It has been standardized by the Internet Engineering Task Force (IETF) as '''[http://tools.ietf.org/html/rfc6716 RFC 6716]'''. <br />
<br />
Opus has been in development since early 2007. Programmers associated with Xiph.Org, Skype, and several other organizations have contributed to its development and to the standardization process as part of the IETF's codec working group.<br />
<br />
=== How does Opus compare to other codecs? ===<br />
<br />
Opus is distinguished from most formats for high quality audio (AAC, Vorbis, MP3) by having low delay and it is distinguished from most low delay formats (G.711, GSM, Speex) by supporting high audio quality. It meets or exceeds existing codecs' quality across a wide range of bitrates, and it operates at lower delay than virtually any existing compressed format. Further, the Opus format itself and the reference implementation are available under liberal royalty-free licenses, making it easy to adopt, compatible with free software, and suitable for usage as part of the basic infrastructure of the Internet. See the Opus [http://opus-codec.org/comparison comparison page] for more details.<br />
<br />
=== Does Opus make all those other lossy codecs obsolete? ===<br />
<br />
Theoretically, yes. From technical point of view (loss, delay, bitrates, ...) it can replace both Vorbis and Speex, and the common proprietary codecs too.<br />
<br />
=== Will Opus replace Vorbis in video files? ===<br />
<br />
For OGG Theora video files, it can, just the overall size reduction will be minimal, and it will break compatibility with existing players.<br />
<br />
For WebM video files, same does apply, but additionally this would need a change of the spec, as the current spec says that the only allowed video codec is VP8 and the only allowed audio codec is Vorbis.<br />
<br />
=== How do I use Opus? What programs support Opus? ===<br />
<br />
Opus decoding support is now included in many applications, including Firefox, foobar2000, and VLC, as well as in frameworks such as GStreamer and FFmpeg. For now, the best way to '''encode''' Opus files is to use the opusenc command-line tool from the opus-tools package. For real-time applications, Opus support should soon be available in the Google webrtc codebase. Opus is still a new codec, expect many more applications to support it in the near future.<br />
<br />
=== Does Opus support higher sampling rates, such as 96 kHz or 192 kHz? ===<br />
<br />
Yes and no. Opus encoding tools like opusenc will happily encode files that are sampled at 96 or 192 kHz. However, input files at these rates are internally converted to 48 kHz, and then only frequencies up to 20 kHz are encoded. The reason is simple: lossy codecs are designed to preserve audible details while discarding irrelevant information. Since the human ear can only hear up to 20 kHz at best (usually lower than that), frequency content above 20 kHz is the first thing to go. See Monty's [http://people.xiph.org/~xiphmont/demo/neil-young.html 24/192 Music Downloads ...and why they make no sense] for more details. <br />
<br />
=== What are the licensing requirements? ===<br />
<br />
The reference Opus source code is released under a three-clause BSD license, which is a very permissive Open Source license. Commercial use and distribution (including in proprietary software) is permitted, provided that some basic conditions specified in the license are met. <br />
<br />
Opus is also covered by some patents, for which royalty-free usage rights are granted, under conditions that the authors believe are compatible with most (all?) open source licenses, including the GPL (v2 and v3). See the [http://www.opus-codec.org/license/ licensing page] for details.<br />
<br />
=== Why make Opus free? ===<br />
<br />
On the Internet, protocol and codec standards are part of the common infrastructure everyone builds upon. Most of the value of a high quality standard is the innovation and interoperation provided by the systems built on top of it. When a few parties have monopoly rights to monetize a standard, that infrastructure stops being so common—everyone else has more reason to use their own solution instead, increasing cost and reducing efficiency. Imagine a road system where each type of car could only drive on its own manufacturer's pavement. We all benefit from living in a world where all the roads are connected. This is why Opus, unlike many codecs, is free.<br />
<br />
=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===<br />
<br />
No. The SILK codec, as submitted by Skype to the IETF, was heavily modified as part of its integration within Opus. The modifications are significant enough that it is not possible to just write a "translator" and even sharing code between Opus and the "old SILK" would be highly non-trivial.<br />
<br />
=== Why not keep the SILK and CELT codecs separate? ===<br />
<br />
Opus is more than just two independent codecs with a switch. In addition to a linear prediction "SILK mode" and a MDCT "CELT mode" it has a "hybrid mode," where speech frequencies up to 8 kHz are encoded with LP while those above 8 kHz are encoded with MDCT. This is what allows Opus to have such high speech quality around 32 kb/s. Another advantage of the integration is the ability to switch between these modes seamlessly, without any "glitch" and without any out-of-band signalling.<br />
<br />
=== Now that Opus is standardized, will its development stop, or can it be further improved? ===<br />
<br />
Unlike most ITU-T codecs, Opus is only defined in terms of its decoder. The encoder can keep evolving as long as the bitstream it produces can be decoded by the reference decoder. This is what made it possible for MP3 encoders to improve far beyond the original l3enc and the dist10 reference implementation. Although it is unlikely that Opus encoders will see such spectacular evolution, we certainly hope that future encoders will become much better than the reference encoder. In fact, there is already an [http://www.opus-codec.org/development/ experimental branch] that significantly improves on the reference encoder's quality.<br />
<br />
=== Will all future Opus releases comply with the [http://tools.ietf.org/html/rfc6716 Opus specification]? ===<br />
<br />
Yes.<br />
<br />
=== In what ways is Opus optimized for the Internet? ===<br />
<br />
Opus being optimized for the Internet obviously means that it has good packet loss robustness and concealment, but it goes further. One of the first things we've been asked when designing Opus was to make the rate '''really''' adaptable because we never know what kind of rates will be available. This not only meant having a wide range of bitrates, but also being able to vary in small increments. This is why Opus scales from about 6 kb/s to 512 kb/s, in increments of 0.4 kb/s (one byte with 20 ms frames). The reason Opus can have more than 1200 possible bitrates spending 11 bits signalling the bitrate is because UDP already encodes the packet size. One last aspect is that Opus is simple to transport over RTP, as can be seen from [http://tools.ietf.org/html/draft-spittka-payload-rtp-opus Opus RTP payload format]. For example, it's possible to decode RTP packets without having even seen the SDP or any out-of-band signalling. <br />
<br />
=== What applications for Android can play Opus? ===<br />
<br />
Right now, there are just a few but that list is fast growing. Please reference [http://android.stackexchange.com/q/37970/7425 this question on android.stackexchange.com]. Feel free to suggest other applications.<br />
<br />
<br />
<br />
== Opus for Software developers ==<br />
<br />
=== On what platforms does Opus run? ===<br />
<br />
The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs. A few of the platforms on which Opus has been tested and is known to run include x86, x86-64, ARM, Itanium, Blackfin, and SPARC.<br />
<br />
=== Is there a fixed-point implementation? ===<br />
<br />
Yes; the fixed-point and floating-point decoder and encoder implementations are part of the same code base. The code defaults to float, so you need to configure with --enable-fixed-point (or defining FIXED_POINT if not using the configure script) to build the code for fixed-point.<br />
<br />
=== Which implementation should I use? ===<br />
<br />
While the implementation in RFC 6716 is what ''defines'' the standard, it is likely not the best and most up-to-date implementation. The [http://opus-codec.org/ Opus] website was set up for the purpose of continually improving the implementation— in terms of speed, encoding quality, device compatibility, etc— while still conforming to the standard. All Opus implementations are compatible by definition.<br />
<br />
=== How is supporting Opus different from supporting Speex/G.711/MP3? ===<br />
<br />
Opus has variable frame durations which can change on the fly, so an Opus decoder needs to be ready to accept packets with durations that are any multiple of 2.5ms up to a maximum of 120ms. <br />
<br />
The opus encoder and decoder do not need to have matched sampling rates or channel counts. It is recommended to always just decode at the highest rate the hardware supports (e.g. 48kHz stereo) so the user gets the full quality of whatever the far end is sending.<br />
<br />
=== My application doesn't work. Can anyone help me? ===<br />
<br />
It's possible to get help, but before doing so, there are a few basic things to try:<br />
<br />
* Implement the application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus.<br />
* Read the [http://www.opus-codec.org/docs/ documentation].<br />
* Read the opus_demo.c source code to see how to use the encoder and decoder.<br />
<br />
If you still can't solve the problem, the best option is to ask for help on the [http://lists.xiph.org/mailman/listinfo/opus mailing list].<br />
<br />
=== How do I report a bug? ===<br />
<br />
If you think you have found a bug in Opus (and not in your application), please [https://trac.xiph.org/newticket?component=Opus file a bug report]. Please include a way for us to reproduce the problem. The best way to do this is to provide an input file, along with the opusenc/opusdec/opus_demo command line that causes the bug to occur. If the bug cannot be triggered by the command line tools, please provide a simple patch or C file that can help reproduce it. Please also provide any other relevant information, such as OS, CPU, build options, etc. Also, don't hesitate to also contact us on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on [irc://irc.freenode.net/opus IRC].<br />
<br />
=== What is Opus Custom? ===<br />
<br />
Opus Custom is an '''optional''' part of the Opus standard that allows for sampling rates other than 8, 12, 16, 24, or 48 kHz and frame sizes other than multiples of 2.5 ms. Opus Custom requires additional out-of-band signalling that Opus does not normally require and disables many of Opus' coding modes. Also, because it is an optional part of the specification, using Opus Custom may lead to compatibility problems. For these reasons, its use is discouraged outside of very specific applications, e.g.:<br />
* ultra low delay applications where synchronization with the soundcard buffer is important. <br />
* low-power embedded applications where compatibility with others is not important.<br />
<br />
For almost all other types of applications, Opus Custom should not be used.<br />
<br />
=== How do I use 44.1 kHz or some other sampling rate not directly supported by Opus? ===<br />
<br />
Tools which read or write Opus should interoperate with other sampling rates by transparently performing sample rate conversion behind the scenes whenever necessary. In particular, software developers should not use Opus Custom for 44.1 kHz support, except in the very specific circumstances outlined above.<br />
<br />
Note that it's generally preferable for a decoder to output at 48kHz even when you know the original input was 44.1kHz, not only because you can skip resampling but also because many inexpensive audio interfaces have poor quality output for 44.1k.<br />
<br />
The opus-tools package source code contains a small, high quality, high performance, BSD licensed resampler which can be used where resampling is required.<br />
<br />
=== Forward Error correction (FEC) doesn't appear to do anything! HELP! ===<br />
<br />
The inband FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.<br />
<br />
In order to make use of inband FEC the decoder must delay its output by at least one frame so that it can call the decoder with the decode_fec argument on the ''next'' frame in order to reconstruct the missed frame. This works best if it's integrated with a jitter buffer.<br />
<br />
FEC is only used by the encoder under certain conditions: the feature must be enabled via the OPUS_SET_INBAND_FEC CTL, the encoder must be told to expect loss via the OPUS_SET_PACKET_LOSS_PERC CTL, and the codec must be operated in any of the linear prediction or Hybrid modes. Frame durations of <10ms and very high bitrates will use the MDCT modes, where FEC is not available.<br />
<br />
Even when FEC is not used, telling the encoder about the expected level of loss will help it make more intelligent decisions. By default the implementation assumes there is no loss.<br />
<br />
=== I can't use malloc or much stack on my embedded platform. How do I make Opus work? ===<br />
<br />
A normal build of libopus only uses malloc/free in the _create() and _destroy() calls, so Opus is safe for realtime use so long as the codec state is pre-created.<br />
<br />
In order to build Opus without any reference to malloc/free at all use init() calls rather than the create() calls in your application and compile with <tt>CFLAGS="-DOVERRIDE_OPUS_ALLOC -DOVERRIDE_OPUS_FREE -D'opus_alloc(x)=NULL' -D'opus_free(x)=NULL' "</tt> you will get a build which does not use malloc/free.<br />
<br />
If libopus is built with -DNONTHREADSAFE_PSEUDOSTACK (instead of VAR_ARRAYS, or USE_ALLOCA) it will use a user provided block of heap instead of stack for many things resulting in much lower the stack usage. However this makes the resulting library non-threadsafe and is not recommend on anything except limited embedded platforms.<br />
<br />
=== How can I ensure that my software interoperates with other software implementing Opus? ===<br />
<br />
For applications using Ogg files, there are some [http://people.xiph.org/~greg/opus_testvectors/ Ogg Opus testvectors] to test decoders and you can test encoders with opusdec. For RTP applications, the opusrtp tool can be useful. In general, here's a list of specific issues to check:<br />
* Can your application handle all frame sizes, including changing the frame size from frame to frame?<br />
* Does your application properly react to lost packet by calling the decoder with a NULL packet?<br />
<br />
=== What is the complexity of Opus? ===<br />
<br />
The complexity of Opus varies by a large amount based on the settings used. It depends on the mode, audio bandwidth, number of channels, and even a "complexity knob" that can trade complexity for quality.<br />
<br />
=== Does Opus have an echo canceller like Speex does? ===<br />
<br />
Echo cancellation is completely independent from codecs. You can use any echo canceller (including the one from libspeexdsp) along with Opus. That being said, among the free acoustic echo cancelers (AEC) we're aware of, the best is probably the Google AEC from the [https://code.google.com/p/webrtc/ WebRTC codebase].</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=14213OpusTodo2013-07-20T01:15:41Z<p>Jmspeex: </p>
<hr />
<div>== For 1.1-final ==<br />
<br />
* Surround improvements<br />
** Stand-alone MDCT<br />
** Better channel masking<br />
** Per-channel surround mode selection (i.e. allow SILK mode for centre channel)<br />
* ARM/Neon optimizations<br />
* Make tonality analysis available in fixed point (even if code is still float)<br />
* Testing, especially<br />
** CVBR<br />
** Smaller frame sizes<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]]<br />
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]<br />
<br />
== Website ==<br />
* De-uglify webpage - some suggestions: write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?), and the prop. ones), write about implementations (is there only one so far?), comparison table (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...), future use in video files (Theora? Dirac? WebM? other future codecs...), audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ... <br />
* Promotional material (some nice free or Public domain sounds in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* A simple real time streaming example tool<br />
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]<br />
** Make <code>opusrtp rtp://example.com:5431/</code> listen to that host and port and mux packets from there. Generalize the cpac bases --sniff implementation<br />
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?<br />
** Make --sniff save one file per<br />
** Implement DTLS-SRTP. See webrtc.<br />
** audio capture/encode, decode/playback?<br />
** Parse and act on sdp for convenience and testing.<br />
<br />
* Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Experiments ==<br />
<br />
* Test exp_analysis and void_my_warranty.patch<br />
<br />
== Optimisations ==<br />
<br />
* Vectorising comb_filter()<br />
* Use 16-bit mul plus shift in denormalise_bands()<br />
* Optimise MDCT somehow<br />
* Merge ARM optimisations<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=14212OpusTodo2013-07-20T01:15:18Z<p>Jmspeex: </p>
<hr />
<div>== 1.1-beta ==<br />
<br />
* Surround improvements<br />
** Stand-alone MDCT<br />
** Better channel masking<br />
** Per-channel surround mode selection (i.e. allow SILK mode for centre channel)<br />
* ARM/Neon optimizations<br />
* Make tonality analysis available in fixed point (even if code is still float)<br />
* Testing, especially<br />
** CVBR<br />
** Smaller frame sizes<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]]<br />
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]<br />
<br />
== Website ==<br />
* De-uglify webpage - some suggestions: write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?), and the prop. ones), write about implementations (is there only one so far?), comparison table (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...), future use in video files (Theora? Dirac? WebM? other future codecs...), audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ... <br />
* Promotional material (some nice free or Public domain sounds in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* A simple real time streaming example tool<br />
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]<br />
** Make <code>opusrtp rtp://example.com:5431/</code> listen to that host and port and mux packets from there. Generalize the cpac bases --sniff implementation<br />
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?<br />
** Make --sniff save one file per<br />
** Implement DTLS-SRTP. See webrtc.<br />
** audio capture/encode, decode/playback?<br />
** Parse and act on sdp for convenience and testing.<br />
<br />
* Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Experiments ==<br />
<br />
* Test exp_analysis and void_my_warranty.patch<br />
<br />
== Optimisations ==<br />
<br />
* Vectorising comb_filter()<br />
* Use 16-bit mul plus shift in denormalise_bands()<br />
* Optimise MDCT somehow<br />
* Merge ARM optimisations<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size</div>Jmspeexhttps://wiki.xiph.org/index.php?title=DaalaReview&diff=14205DaalaReview2013-06-19T18:30:07Z<p>Jmspeex: </p>
<hr />
<div>This is a '''proposal''' for a more flexible review process. It is a set of guidelines for the most appropriate approach for different types of changes. Above all, use your judgement.<br />
<br />
== Definitions ==<br />
*A) Full review: Same as current process. Can be based on Rietveld, "git format-patch", or a pull request<br />
*B) Post-review: Code gets committed to repo first, committer nags reviewer weekly if necessary<br />
*C) Design review: Discuss with original author (and possibly others) for the principle of a change, can (and probably should) be done even before doing the work<br />
*D) No review: self-explanatory<br />
<br />
== Guidelines ==<br />
*0) Full-review on anything the committer has reasons to believe would be controversial, buggy, ...<br />
*1) Generally no review on comments/whitespace/style/documentation<br />
** Except potentially when changing Doxygen API comments<br />
*2)Post-review on code that is already badly broken, or on simple bug fixes<br />
*3) No review on initial commit of new stuff that isn't being called<br />
** Full-review required to hook any code not reviewed because of 3)<br />
** If code in 3) breaks the build, it gets fixed immediately or removed<br />
** No review on new tools until they get used by other people<br />
*4) Code that is (according to the committer) highly unlikely to break things or that is trivially testable gets post-review<br />
*5) Code that may have subtle implications gets full review<br />
*6) Refactoring of someone else's code gets design review, followed by either post-review (or full review if requested during design review)<br />
*7) Disruptive work (e.g. block switching) gets both design review and full review.<br />
*8) Most build system changes get no review (unless 0) applies)<br />
*9) Post-review on test code<br />
<br />
== Examples ==<br />
1) [https://git.xiph.org/?p=daala.git;a=commitdiff;h=da726b32 da726b32], [https://git.xiph.org/?p=daala.git;a=commitdiff;h=53362b77 53362b77]<br />
2) [https://git.xiph.org/?p=daala.git;a=commitdiff;h=212d13b3 212d13b3], <br />
3) [https://git.xiph.org/?p=daala.git;a=commitdiff;h=76ee32c8 76ee32c8], [https://git.xiph.org/?p=daala.git;a=commitdiff;h=75b62b23 75b62b23]<br />
4) [https://git.xiph.org/?p=daala.git;a=commitdiff;h=7c102188 7c102188], [https://git.xiph.org/?p=daala.git;a=commitdiff;h=50732d66 50732d66]<br />
5) [https://git.xiph.org/?p=daala.git;a=commitdiff;h=8cd46564 8cd46564], [https://git.xiph.org/?p=daala.git;a=commitdiff;h=74dc3616 74dc3616]<br />
6) [https://git.xiph.org/?p=daala.git;a=commitdiff;h=208ea300 208ea300]<br />
7) [https://git.xiph.org/?p=daala.git;a=commitdiff;h=b4bfee65 b4bfee65]<br />
8) [https://git.xiph.org/?p=daala.git;a=commitdiff;h=7cc3cc5f 7cc3cc5f], [https://git.xiph.org/?p=daala.git;a=commitdiff;h=487fe063 487fe063]<br />
<br />
== Team reviews ==<br />
*1) Once in a while, we should pick a piece of code<br />
*2) Original author cleans up code, adds comments<br />
*3) Code discussed with entire team<br />
*4) Suggestions for improvement (with emphasis on algo)</div>Jmspeexhttps://wiki.xiph.org/index.php?title=DaalaReview&diff=14203DaalaReview2013-06-19T18:05:48Z<p>Jmspeex: Created page with "This is a '''proposal''' for a more flexible review process. It is a set of guidelines for the most appropriate approach for different types of changes. Above all, use your judge..."</p>
<hr />
<div>This is a '''proposal''' for a more flexible review process. It is a set of guidelines for the most appropriate approach for different types of changes. Above all, use your judgement.<br />
<br />
== Definitions ==<br />
*A) Full review: Same as current process. Can be based on Rietveld, "git format-patch", or a pull request<br />
*B) Post-review: Code gets committed to repo first, committer nags reviewer weekly if necessary<br />
*C) Design review: Discuss with original author (and possibly others) for the principle of a change, can (and probably should) be done even before doing the work<br />
*D) No review: self-explanatory<br />
<br />
== Guidelines ==<br />
*0) Full-review on anything the committer has reasons to believe would be controversial, buggy, ...<br />
*1) Generally no review on comments/whitespace/style/documentation<br />
** Except potentially when changing Doxygen API comments<br />
*2)Post-review on code that is already badly broken, or on simple bug fixes<br />
*3) No review on initial commit of new stuff that isn't being called<br />
** Full-review required to hook any code not reviewed because of 3)<br />
** If code in 3) breaks the build, it gets fixed immediately or removed<br />
** No review on new tools until they get used by other people<br />
*4) Code that is "obviously correct" or that is trivially testable gets post-review<br />
*5) Code that may have subtle implications gets full review<br />
*6) Refactoring of someone else's code gets design review, followed by either post-review (or full review if requested during design review)<br />
*7) Disruptive work (e.g. block switching) gets both design review and full review.<br />
*8) Most build system changes get no review (unless 0) applies)<br />
*9) Post-review on test code<br />
<br />
== Examples ==<br />
1) da726b32, 53362b77<br />
2) 212d13b3, <br />
3) 76ee32c8, 75b62b23<br />
4) 7c102188, 50732d66<br />
5) 8cd46564, 74dc3616<br />
6) 208ea300<br />
7) b4bfee65<br />
8) 7cc3cc5f, 487fe063<br />
<br />
== Team reviews ==<br />
*1) Once in a while, we should pick a piece of code<br />
*2) Original author cleans up code, adds comments<br />
*3) Code discussed with entire team<br />
*4) Suggestions for improvement (with emphasis on algo)</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=14192OpusTodo2013-06-16T07:09:59Z<p>Jmspeex: </p>
<hr />
<div>== 1.1-beta ==<br />
<br />
* Vary tf_analysis end band based on complexity<br />
* Use pitch down to complexity 4 instead of 5?<br />
* Testing<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]]<br />
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]<br />
<br />
== Website ==<br />
* De-uglify webpage - some suggestions: write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?), and the prop. ones), write about implementations (is there only one so far?), comparison table (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...), future use in video files (Theora? Dirac? WebM? other future codecs...), audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ... <br />
* Promotional material (some nice free or Public domain sounds in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* A simple real time streaming example tool<br />
* Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Experiments ==<br />
<br />
* Test exp_analysis and void_my_warranty.patch<br />
<br />
== Optimisations ==<br />
<br />
* Vectorising comb_filter()<br />
* Use 16-bit mul plus shift in denormalise_bands()<br />
* Optimise MDCT somehow<br />
* Merge ARM optimisations<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=14186OpusTodo2013-06-14T04:39:47Z<p>Jmspeex: </p>
<hr />
<div>== 1.1-beta ==<br />
<br />
* Vary tf_analysis end band based on complexity<br />
* Use pitch down to complexity 4 instead of 5?<br />
* Testing<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]]<br />
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]<br />
<br />
== Website ==<br />
* De-uglify webpage - some suggestions: write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?), and the prop. ones), write about implementations (is there only one so far?), comparison table (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...), future use in video files (Theora? Dirac? WebM? other future codecs...), audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ... <br />
* Promotional material (some nice free or Public domain sounds in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* A simple real time streaming example tool<br />
* Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Experiments ==<br />
<br />
* Test exp_analysis and void_my_warranty.patch<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=14185OpusTodo2013-06-14T02:42:52Z<p>Jmspeex: </p>
<hr />
<div>== 1.1-beta ==<br />
<br />
* Use pitch down to complexity 4 instead of 5?<br />
* Testing<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]]<br />
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]<br />
<br />
== Website ==<br />
* De-uglify webpage - some suggestions: write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?), and the prop. ones), write about implementations (is there only one so far?), comparison table (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...), future use in video files (Theora? Dirac? WebM? other future codecs...), audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ... <br />
* Promotional material (some nice free or Public domain sounds in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* A simple real time streaming example tool<br />
* Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Experiments ==<br />
<br />
* Test exp_analysis and void_my_warranty.patch<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=14114OpusTodo2013-05-03T21:13:20Z<p>Jmspeex: </p>
<hr />
<div>== 1.1-beta ==<br />
<br />
* Tune mode switching decisions<br />
** <s>Use SILK up to higher rates on voice</s><br />
** <s>Adapt stereo SILK/CELT threshold based on stereo width</s><br />
* Tune hybrid rate allocation?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size<br />
* Tune transient detector?<br />
* Use ALLOC in tonality analysis<br />
* LOTS of testing<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]]<br />
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]<br />
<br />
== Website ==<br />
* De-uglify webpage - some suggestions: write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?), and the prop. ones), write about implementations (is there only one so far?), comparison table (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...), future use in video files (Theora? Dirac? WebM? other future codecs...), audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ... <br />
* Promotional material (some nice free or Public domain sounds in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* A simple real time streaming example tool<br />
* Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Experiments ==<br />
<br />
* Test exp_analysis and void_my_warranty.patch<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?</div>Jmspeexhttps://wiki.xiph.org/index.php?title=OpusFAQ&diff=14095OpusFAQ2013-04-13T06:37:49Z<p>Jmspeex: </p>
<hr />
<div>[[Image:Opus logo trans.png|right]]<br />
<br />
== General Questions ==<br />
<br />
=== What is Opus? Who created it? ===<br />
<br />
Opus is a totally open, royalty-free, highly versatile audio codec. It is primarily designed for interactive speech and music transmission over the Internet, but is also applicable to storage and streaming applications. It incorporates technology from Skype's SILK codec and Xiph.Org's CELT codec. It has been standardized by the Internet Engineering Task Force (IETF) as '''[http://tools.ietf.org/html/rfc6716 RFC 6716]'''. <br />
<br />
Opus has been in development since early 2007. Programmers associated with Xiph.Org, Skype, and several other organizations have contributed to its development and to the standardization process as part of the IETF's codec working group.<br />
<br />
=== How does Opus compare to other codecs? ===<br />
<br />
Opus is distinguished from most formats for high quality audio (AAC, Vorbis, MP3) by having low delay and it is distinguished from most low delay formats (G.711, GSM, Speex) by supporting high audio quality. It meets or exceeds existing codecs' quality across a wide range of bitrates, and it operates at lower delay than virtually any existing compressed format. Further, the Opus format itself and the reference implementation are available under liberal royalty-free licenses, making it easy to adopt, compatible with free software, and suitable for usage as part of the basic infrastructure of the Internet. See the Opus [http://opus-codec.org/comparison comparison page] for more details.<br />
<br />
=== Does Opus make all those other lossy codecs obsolete? ===<br />
<br />
Theoretically, yes. From technical point of view (loss, delay, bitrates, ...) it can replace both Vorbis and Speex, and the common proprietary codecs too.<br />
<br />
=== Will Opus replace Vorbis in video files? ===<br />
<br />
For OGG Theora video files, it can, just the overall size reduction will be minimal, and it will break compatibility with existing players.<br />
<br />
For WebM video files, same does apply, but additionally this would need a change of the spec, as the current spec says that the only allowed video codec is VP8 and the only allowed audio codec is Vorbis.<br />
<br />
=== How do I use Opus? What programs support Opus? ===<br />
<br />
Opus decoding support is now included in many applications, including Firefox, foobar2000, and VLC, as well as in frameworks such as GStreamer and FFmpeg. For now, the best way to '''encode''' Opus files is to use the opusenc command-line tool from the opus-tools package. For real-time applications, Opus support should soon be available in the Google webrtc codebase. Opus is still a new codec, expect many more applications to support it in the near future.<br />
<br />
=== Does Opus support higher sampling rates, such as 96 kHz or 192 kHz? ===<br />
<br />
Yes and no. Opus encoding tools like opusenc will happily encode files that are sampled at 96 or 192 kHz. However, input files at these rates are internally converted to 48 kHz, and then only frequencies up to 20 kHz are encoded. The reason is simple: lossy codecs are designed to preserve audible details while discarding irrelevant information. Since the human ear can only hear up to 20 kHz at best (usually lower than that), frequency content above 20 kHz is the first thing to go. See Monty's [http://people.xiph.org/~xiphmont/demo/neil-young.html 24/192 Music Downloads ...and why they make no sense] for more details. <br />
<br />
=== What are the licensing requirements? ===<br />
<br />
The reference Opus source code is released under a three-clause BSD license, which is a very permissive Open Source license. Commercial use and distribution (including in proprietary software) is permitted, provided that some basic conditions specified in the license are met. <br />
<br />
Opus is also covered by some patents, for which royalty-free usage rights are granted, under conditions that the authors believe are compatible with most (all?) open source licenses, including the GPL (v2 and v3). See the [http://www.opus-codec.org/license/ licensing page] for details.<br />
<br />
=== Why make Opus free? ===<br />
<br />
On the Internet, protocol and codec standards are part of the common infrastructure everyone builds upon. Most of the value of a high quality standard is the innovation and interoperation provided by the systems built on top of it. When a few parties have monopoly rights to monetize a standard, that infrastructure stops being so common—everyone else has more reason to use their own solution instead, increasing cost and reducing efficiency. Imagine a road system where each type of car could only drive on its own manufacturer's pavement. We all benefit from living in a world where all the roads are connected. This is why Opus, unlike many codecs, is free.<br />
<br />
=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===<br />
<br />
No. The SILK codec, as submitted by Skype to the IETF, was heavily modified as part of its integration within Opus. The modifications are significant enough that it is not possible to just write a "translator" and even sharing code between Opus and the "old SILK" would be highly non-trivial.<br />
<br />
=== Why not keep the SILK and CELT codecs separate? ===<br />
<br />
Opus is more than just two independent codecs with a switch. In addition to a linear prediction "SILK mode" and a MDCT "CELT mode" it has a "hybrid mode," where speech frequencies up to 8 kHz are encoded with LP while those above 8 kHz are encoded with MDCT. This is what allows Opus to have such high speech quality around 32 kb/s. Another advantage of the integration is the ability to switch between these modes seamlessly, without any "glitch" and without any out-of-band signalling.<br />
<br />
=== Now that Opus is standardized, will its development stop, or can it be further improved? ===<br />
<br />
Unlike most ITU-T codecs, Opus is only defined in terms of its decoder. The encoder can keep evolving as long as the bitstream it produces can be decoded by the reference decoder. This is what made it possible for MP3 encoders to improve far beyond the original l3enc and the dist10 reference implementation. Although it is unlikely that Opus encoders will see such spectacular evolution, we certainly hope that future encoders will become much better than the reference encoder. In fact, there is already an [http://www.opus-codec.org/development/ experimental branch] that significantly improves on the reference encoder's quality.<br />
<br />
=== Will all future Opus releases comply with the [http://tools.ietf.org/html/rfc6716 Opus specification]? ===<br />
<br />
Yes.<br />
<br />
=== In what ways is Opus optimized for the Internet? ===<br />
<br />
Opus being optimized for the Internet obviously means that it has good packet loss robustness and concealment, but it goes further. One of the first things we've been asked when designing Opus was to make the rate '''really''' adaptable because we never know what kind of rates will be available. This not only meant having a wide range of bitrates, but also being able to vary in small increments. This is why Opus scales from about 6 kb/s to 512 kb/s, in increments of 0.4 kb/s (one byte with 20 ms frames). The reason Opus can have more than 1200 possible bitrates spending 11 bits signalling the bitrate is because UDP already encodes the packet size. One last aspect is that Opus is simple to transport over RTP, as can be seen from [http://tools.ietf.org/html/draft-spittka-payload-rtp-opus Opus RTP payload format]. For example, it's possible to decode RTP packets without having even seen the SDP or any out-of-band signalling. <br />
<br />
=== What applications for Android can play Opus? ===<br />
<br />
Right now, there are just a few but that list is fast growing. Please reference [http://android.stackexchange.com/q/37970/7425 this question on android.stackexchange.com]. Feel free to suggest other applications.<br />
<br />
<br />
<br />
== Opus for Software developers ==<br />
<br />
=== On what platforms does Opus run? ===<br />
<br />
The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs. A few of the platforms on which Opus has been tested and is known to run include x86, x86-64, ARM, Itanium, Blackfin, and SPARC.<br />
<br />
=== Is there a fixed-point implementation? ===<br />
<br />
Yes; the fixed-point and floating-point decoder and encoder implementations are part of the same code base. The code defaults to float, so you need to configure with --enable-fixed-point (or defining FIXED_POINT if not using the configure script) to build the code for fixed-point.<br />
<br />
=== Which implementation should I use? ===<br />
<br />
While the implementation in RFC 6716 is what ''defines'' the standard, it is likely not the best and most up-to-date implementation. The [http://opus-codec.org/ Opus] website was set up for the purpose of continually improving the implementation— in terms of speed, encoding quality, device compatibility, etc— while still conforming to the standard. All Opus implementations are compatible by definition.<br />
<br />
=== How is supporting Opus different from supporting Speex/G.711/MP3? ===<br />
<br />
Opus has variable frame durations which can change on the fly, so an Opus decoder needs to be ready to accept packets with durations that are any multiple of 2.5ms up to a maximum of 120ms. <br />
<br />
The opus encoder and decoder do not need to have matched sampling rates or channel counts. It is recommended to always just decode at the highest rate the hardware supports (e.g. 48kHz stereo) so the user gets the full quality of whatever the far end is sending.<br />
<br />
=== My application doesn't work. Can anyone help me? ===<br />
<br />
It's possible to get help, but before doing so, there are a few basic things to try:<br />
<br />
* Implement the application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus.<br />
* Read the [http://www.opus-codec.org/docs/ documentation].<br />
* Read the opus_demo.c source code to see how to use the encoder and decoder.<br />
<br />
If you still can't solve the problem, the best option is to ask for help on the [http://lists.xiph.org/mailman/listinfo/opus mailing list].<br />
<br />
=== How do I report a bug? ===<br />
<br />
If you think you have found a bug in Opus (and not in your application), please [https://trac.xiph.org/newticket?component=Opus file a bug report]. Please include a way for us to reproduce the problem. The best way to do this is to provide an input file, along with the opusenc/opusdec/opus_demo command line that causes the bug to occur. If the bug cannot be triggered by the command line tools, please provide a simple patch or C file that can help reproduce it. Please also provide any other relevant information, such as OS, CPU, build options, etc. Also, don't hesitate to also contact us on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on [irc://irc.freenode.net/opus IRC].<br />
<br />
=== What is Opus Custom? ===<br />
<br />
Opus Custom is an '''optional''' part of the Opus standard that allows for sampling rates other than 8, 12, 16, 24, or 48 kHz and frame sizes other than multiples of 2.5 ms. Opus Custom requires additional out-of-band signalling that Opus does not normally require and disables many of Opus' coding modes. Also, because it is an optional part of the specification, using Opus Custom may lead to compatibility problems. For these reasons, its use is discouraged outside of very specific applications, e.g.:<br />
* ultra low delay applications where synchronization with the soundcard buffer is important. <br />
* low-power embedded applications where compatibility with others is not important.<br />
<br />
For almost all other types of applications, Opus Custom should not be used.<br />
<br />
=== How do I use 44.1 kHz or some other sampling rate not directly supported by Opus? ===<br />
<br />
Tools which read or write Opus should interoperate with other sampling rates by transparently performing sample rate conversion behind the scenes whenever necessary. In particular, software developers should not use Opus Custom for 44.1 kHz support, except in the very specific circumstances outlined above.<br />
<br />
Note that it's generally preferable for a decoder to output at 48kHz even when you know the original input was 44.1kHz, not only because you can skip resampling but also because many inexpensive audio interfaces have poor quality output for 44.1k.<br />
<br />
The opus-tools package source code contains a small, high quality, high performance, BSD licensed resampler which can be used where resampling is required.<br />
<br />
=== Forward Error correction (FEC) doesn't appear to do anything! HELP! ===<br />
<br />
The inband FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.<br />
<br />
In order to make use of inband FEC the decoder must delay its output by at least one frame so that it can call the decoder with the decode_fec argument on the ''next'' frame in order to reconstruct the missed frame. This works best if it's integrated with a jitter buffer.<br />
<br />
FEC is only used by the encoder under certain conditions: the feature must be enabled via the OPUS_SET_INBAND_FEC CTL, the encoder must be told to expect loss via the OPUS_SET_PACKET_LOSS_PERC CTL, and the codec must be operated in any of the linear prediction or Hybrid modes. Frame durations of <10ms and very high bitrates will use the MDCT modes, where FEC is not available.<br />
<br />
Even when FEC is not used, telling the encoder about the expected level of loss will help it make more intelligent decisions. By default the implementation assumes there is no loss.<br />
<br />
=== I can't use malloc or much stack on my embedded platform. How do I make Opus work? ===<br />
<br />
A normal build of libopus only uses malloc/free in the _create() and _destroy() calls, so Opus is safe for realtime use so long as the codec state is pre-created.<br />
<br />
In order to build Opus without any reference to malloc/free at all use init() calls rather than the create() calls in your application and compile with <tt>CFLAGS="-DOVERRIDE_OPUS_ALLOC -DOVERRIDE_OPUS_FREE -D'opus_alloc(x)=NULL' -D'opus_free(x)=NULL' "</tt> you will get a build which does not use malloc/free.<br />
<br />
If libopus is built with -DNONTHREADSAFE_PSEUDOSTACK (instead of VAR_ARRAYS, or USE_ALLOCA) it will use a user provided block of heap instead of stack for many things resulting in much lower the stack usage. However this makes the resulting library non-threadsafe and is not recommend on anything except limited embedded platforms.<br />
<br />
=== How can I ensure that my software interoperates with other software implementing Opus? ===<br />
<br />
For applications using Ogg files, there are some [http://people.xiph.org/~greg/opus_testvectors/ Ogg Opus testvectors] to test decoders and you can test encoders with opusdec. For RTP applications, the opusrtp tool can be useful. In general, here's a list of specific issues to check:<br />
* Can your application handle all frame sizes, including changing the frame size from frame to frame?<br />
* Does your application properly react to lost packet by calling the decoder with a NULL packet?</div>Jmspeex