Opus is a format for compressing audio to efficiently transmit it across networks. Opus allows for music-grade high quality audio at low data rates while not delaying the signal much. 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. 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 for usage as part of the basic infrastructure of the Internet.

+

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]'''.

−

=== Who created Opus? ===

+

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.

−

Opus was created by combining Xiph.Org's CELT development codec and Skype's SILK codec as part of a cooperative effort in the IETF codec working group. Opus has been in development since early 2007, and <!-- as of ???? is an IETF proposed standard: '''RFC TBD''' --> has been recommended by the working group for promotion as a proposed standard.

+

=== How does Opus compare to other codecs? ===

+

+

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.

+

+

=== Does Opus make all those other lossy codecs obsolete? ===

+

+

Theoretically, yes. From technical point of view (loss, delay, bitrates, ...) it can replace both Vorbis and Speex, and the common proprietary codecs too.

+

+

=== Will Opus replace Vorbis in video files? ===

+

+

For OGG Theora video files, it can, just the overall size reduction will be minimal, and it will break compatibility with existing players.

+

+

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.

+

+

=== How do I use Opus? What programs support Opus? ===

+

+

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.

+

+

=== Does Opus support higher sampling rates, such as 96 kHz or 192 kHz? ===

+

+

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.

+

+

=== What are the licensing requirements? ===

+

+

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.

+

+

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.

+

+

=== Why make Opus free? ===

+

+

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.

=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===

=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===

Line 15:

Line 45:

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.

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.

−

=== How do I use Opus / What programs use Opus? ===

+

=== Why not keep the SILK and CELT codecs separate? ===

+

+

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.

+

+

=== Now that Opus is standardized, will its development stop, or can it be further improved? ===

+

+

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.

+

+

=== Will all future Opus releases comply with the [http://tools.ietf.org/html/rfc6716 Opus specification]? ===

+

+

Yes.

+

+

=== In what ways is Opus optimized for the Internet? ===

+

+

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.

−

=== What are the licensing requirements? ===

+

=== What applications for Android can play Opus? ===

−

The reference Opus source code is released under the BSD license, which is a very permissive Open Source license. Commercial use and distribution (including in proprietary software) is permitted, provided that some conditions specified in the license are met.

+

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.

−

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).

−

=== How does the quality of Opus compare to other codecs? ===

−

See the Opus [http://opus-codec.org/comparison comparison page] for more on this.

+

== Opus for Software developers ==

=== On what platforms does Opus run? ===

=== On what platforms does Opus run? ===

−

The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs. Opus has been tested and is known to run on the following (non-exhaustive list) platforms: x86, x86-64, ARM, Itanium, Blackfin, SPARC.

+

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.

=== Is there a fixed-point implementation? ===

=== Is there a fixed-point implementation? ===

−

Yes, the fixed-point and floating-point 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.

+

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.

+

=== Which implementation should I use? ===

−

== Opus for Software developers ==

+

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.

−

=== What is difference between supporting Opus and supporting Speex/G.711/MP3? ===

+

=== How is supporting Opus different from supporting Speex/G.711/MP3? ===

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.

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.

−

The opus encoder and decoder do not need to have matched sampling rates, bandwidths, or channel counts. Its 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.

+

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.

It's possible to get help, but before doing so, there are a few basic things to try:

−

The inband FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.

+

* Implement the application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus.

+

* Read the [http://www.opus-codec.org/docs/ documentation].

+

* Read the opus_demo.c source code to see how to use the encoder and decoder.

−

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.

+

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].

−

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.

+

=== How do I report a bug? ===

−

Even when FEC is not used, telling the encoder about the level of loss will help it make more intelligent decisions. By default the implementation assumes there is no loss.

+

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].

=== What is Opus Custom? ===

=== What is Opus Custom? ===

Line 65:

Line 111:

=== How do I use 44.1 kHz or some other sampling rate not directly supported by Opus? ===

=== How do I use 44.1 kHz or some other sampling rate not directly supported by Opus? ===

−

Tools which read or write Opus should inter-work with other sampling rate by transparently performing sample rate conversion behind the scenes. It's generally preferable to run the output at 48kHz even when you know the original input was 44.1kHz because many inexpensive audio interfaces have poor quality output for 44.1k.

+

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.

+

+

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.

+

+

The opus-tools package source code contains a small, high quality, high performance, BSD licensed resampler which can be used where resampling is required.

The inband FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.

−

In particular, software developers should not use Opus Custom for 44.1 kHz support, except in the very specific circumstances outlined above.

+

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.

−

=== I can't use malloc or much stack on my embedded platform how do I make Opus work? ===

+

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.

+

+

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.

+

+

=== I can't use malloc or much stack on my embedded platform. How do I make Opus work? ===

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.

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.

Line 76:

Line 134:

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.

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.

−

−

=== Which implementation should I use? ===

−

−

While the implementation in the latest IETF draft (and eventually RFC) of Opus 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.

General Questions

What is Opus? Who created it?

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 RFC 6716.

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.

How does Opus compare to other codecs?

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 comparison page for more details.

Does Opus make all those other lossy codecs obsolete?

Theoretically, yes. From technical point of view (loss, delay, bitrates, ...) it can replace both Vorbis and Speex, and the common proprietary codecs too.

Will Opus replace Vorbis in video files?

For OGG Theora video files, it can, just the overall size reduction will be minimal, and it will break compatibility with existing players.

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.

How do I use Opus? What programs support Opus?

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.

Does Opus support higher sampling rates, such as 96 kHz or 192 kHz?

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 24/192 Music Downloads ...and why they make no sense for more details.

What are the licensing requirements?

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.

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 licensing page for details.

Why make Opus free?

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.

Is the SILK part of Opus compatible with the SILK implementation shipped in Skype?

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.

Why not keep the SILK and CELT codecs separate?

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.

Now that Opus is standardized, will its development stop, or can it be further improved?

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 experimental branch that significantly improves on the reference encoder's quality.

In what ways is Opus optimized for the Internet?

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 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.

What applications for Android can play Opus?

Opus for Software developers

On what platforms does Opus run?

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.

Is there a fixed-point implementation?

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.

Which implementation should I use?

While the implementation in RFC 6716 is what defines the standard, it is likely not the best and most up-to-date implementation. The 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.

How is supporting Opus different from supporting Speex/G.711/MP3?

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.

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.

My application doesn't work. Can anyone help me?

It's possible to get help, but before doing so, there are a few basic things to try:

Implement the application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus.

Read the opus_demo.c source code to see how to use the encoder and decoder.

If you still can't solve the problem, the best option is to ask for help on the mailing list.

How do I report a bug?

If you think you have found a bug in Opus (and not in your application), please 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 mailing list or on IRC.

What is Opus Custom?

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.:

ultra low delay applications where synchronization with the soundcard buffer is important.

low-power embedded applications where compatibility with others is not important.

For almost all other types of applications, Opus Custom should not be used.

How do I use 44.1 kHz or some other sampling rate not directly supported by Opus?

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.

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.

The opus-tools package source code contains a small, high quality, high performance, BSD licensed resampler which can be used where resampling is required.

Forward Error correction (FEC) doesn't appear to do anything! HELP!

The inband FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.

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.

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.

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.

I can't use malloc or much stack on my embedded platform. How do I make Opus work?

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.

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 CFLAGS="-DOVERRIDE_OPUS_ALLOC -DOVERRIDE_OPUS_FREE -D'opus_alloc(x)=NULL' -D'opus_free(x)=NULL' " you will get a build which does not use malloc/free.

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.