Opus Codec Explained: Bitrate, FEC, DTX, Opus vs AAC

Updated October 2026: libopus 1.6 (Opus HD at 96 kHz, smaller DRED, neural bandwidth extension), DRED in IETF Working Group Last Call, a corrected browser-support history, practical bitrates for voice, music and 5.1, plus an FAQ that covers Opus DRC on YouTube, Opus in MP4 and AOMedia’s OAC.

Opus codec explained: the short answer

Opus is a free, open audio codec, standardized by the IETF as RFC 6716 in 2012, that compresses both speech and music in one format. When a file, a browser or a YouTube stream says “audio: Opus”, it means the sound was compressed with this codec. It runs from 6 to 510 kbit/s with frames as short as 2.5 ms, which is why WebRTC makes it mandatory and every major browser uses it for calls. Its files usually end in .opus (Ogg container, RFC 7845), and the current reference library is libopus 1.6.1, released on 14 January 2026.

• For calls: 20 ms frames and 24–32 kbit/s mono for voice (down to about 16 kbit/s on weak networks), with loss protection (in-band FEC) and silence suppression (DTX) switched on at both ends.
• For music: 64–96 kbit/s stereo for streaming; Xiph.Org calls 128 kbit/s VBR stereo “pretty much transparent”.
• Opus vs AAC: live two-way audio → Opus; one-way playback to TVs and set-top boxes → AAC.

Why this matters

If your product has a "join call" button — video conferencing, telemedicine, an e-learning classroom, an in-game voice channel — the audio leaving your users' microphones is, in practice, Opus. The web standard that powers browser calling, WebRTC, requires every browser to support Opus, so it is the default and you rarely get a choice. This article is written for a product manager, founder, or operations lead with no audio background: by the end you will understand why Opus won real-time audio, what its key settings (FEC, DTX, bitrate, frame size) actually do to a call, and when Opus is the right choice versus AAC. Every claim traces back to the IETF specifications, the codec maintainers' own release notes, or another named primary source.

The forty-year split that Opus closed

For most of audio history, engineers kept two separate toolboxes. One held speech codecs — the ones inside a phone call. They work by modelling the human voice box: the throat, the vocal cords, the shape of the mouth. That model is extraordinarily efficient for a single talking voice, squeezing intelligible speech into a few kilobits per second, but it mangles music, because a violin is nothing like a larynx. The other toolbox held music codecs like MP3 and AAC. They work by analysing the sound's frequencies and throwing away the parts your ear cannot hear — covered in how audio compression works. They sound superb on music but waste bits on plain speech and add too much delay for a live conversation.

A real-time product that carried both — a video call where someone talks, then shares a music video, then talks again — had to pick one toolbox and live with its weakness, or switch codecs mid-stream and risk a glitch. Opus ended that compromise. It packs both toolboxes into one codec and decides, many times per second, which one fits the sound in front of it. That single design choice is the thing to hold onto for the rest of this article: Opus is a speech codec and a music codec wearing one coat, with a switch that flips automatically.

Opus was standardized by the Internet Engineering Task Force — the same body that standardizes the protocols of the internet itself — as RFC 6716 in September 2012. Its authors came from Mozilla (the Firefox maker), Skype, and Xiph.Org, the nonprofit behind several open media formats. That pedigree matters for a reason we will return to at the end: Opus was built to be open and free, not to be licensed.

Figure 1. One codec, two engines, three modes. Opus inspects the incoming sound and routes it to SILK (speech), CELT (music), or a hybrid that runs both at once. The listener only ever sees one Opus bitstream.

SILK, CELT, and the switch in the middle

Open up Opus and you find two engines bolted to one frame.

The first engine is SILK, which came from Skype, where it had already carried billions of minutes of voice calls. SILK is a linear-prediction coder, which is the technical name for the voice-box-modelling approach: it predicts each moment of the waveform from the moments just before it, the way you can predict the next note of a familiar tune, and only sends the small prediction error. That is brilliant for speech and for the lower frequencies of any sound, and it is cheap on bits. SILK handles Opus's lower internal sample rates, up to wideband.

The second engine is CELT, which came from Xiph.Org. CELT is a transform coder built on the Modified Discrete Cosine Transform, or MDCT — the same family of frequency analysis that AAC uses. CELT is designed for very low delay, which is unusual for a music-style codec, and it handles the full audible frequency range and music-like sound.

Between them sits a mode selector. Opus runs in one of three modes, chosen automatically based on the bitrate, the bandwidth, and the content:

• SILK-only mode — pure speech engine, for voice at low bitrates and narrower frequency ranges.
• CELT-only mode — pure music engine, for music and for the lowest-latency settings.
• Hybrid mode — both at once: SILK codes the low frequencies, CELT codes the high frequencies on top. This is how Opus delivers full-band speech that sounds natural without paying full music-codec cost.

The reader does not need to track which mode is active at any instant; the encoder decides and the decoder follows, all signalled inside the bitstream. What matters is the result: one codec that handles whatever kind of sound it is given.

The numbers that make Opus flexible

Opus's reputation rests on its range. Three dials explain almost everything.

The first dial is bitrate — how many bits per second you spend. Opus supports 6 kbit/s at the low end up to 510 kbit/s at the top, and it can change the rate at any instant without restarting the stream (RFC 7587, §3.1). To make that range concrete, the specification publishes "sweet spot" bitrates — the rate at which each kind of content sounds good for its cost, at the standard 20-millisecond frame:

Table 1. Opus recommended bitrates, from RFC 7587, §3.1.1. "Full-band" means the codec is carrying the entire audible frequency range up to 20 kHz; "narrowband" is telephone-quality speech up to 4 kHz.

What bitrate should you actually use for Opus? For VoIP, 10–24 kbit/s mono; for stereo music streaming, 64–96 kbit/s; for stored music, 96–128 kbit/s stereo; for 5.1 surround, 128–256 kbit/s (Xiph.Org, Opus Recommended Settings, checked October 2026). The RFC figures above are what each audio bandwidth needs to sound good; the Xiph.Org VoIP range starts lower because it accepts a narrower bandwidth to save bits. These are the maintainers’ everyday encoding settings:

Table 2. Everyday Opus bitrates from Xiph.Org’s Opus Recommended Settings (VBR). On music quality, the same page reports that Opus at 128 kbit/s VBR stereo is “pretty much transparent” — most listeners cannot tell it from the source.

The second dial is audio bandwidth — how much of the frequency range the codec carries. Opus offers five settings, from narrowband (telephone speech, up to 4 kHz) through wideband and super-wideband to fullband (the whole audible range up to 20 kHz, at a 48 kHz sampling rate). The encoder can narrow the bandwidth to save bits when the network is weak, then widen it again when capacity returns, mid-call, with no audible seam.

The third dial is frame size — how much sound goes into each packet. Opus can encode frames of 2.5, 5, 10, 20, 40, or 60 milliseconds, and pack several frames into one packet up to 120 ms (RFC 7587, §4.2). This dial is the heart of why Opus owns real-time audio, so it deserves its own arithmetic.

A short frame means the encoder waits less time to fill a packet before sending it. That waiting time is pure, unavoidable delay added to every word spoken. Compare a music-codec frame with an Opus real-time frame:

AAC-LC frame  = 1024 samples ÷ 48,000 samples per second ≈ 21.3 ms per frame
Opus frame    = 20 ms (typical real-time setting)
Opus minimum  = 2.5 ms (lowest-latency setting)

Twenty-one milliseconds of forced delay before a single packet leaves the encoder may not sound like much, but in a two-way conversation it stacks on top of network delay, the jitter buffer, and the decoder, and the total is what makes a call feel laggy or natural. Low-delay frames, a royalty-free licence and the WebRTC mandate together are why Opus, not AAC, sits in nearly every calling app. We unpack the full delay chain in the WebRTC audio pipeline end to end.

Pitfall — chasing the shortest frame can cost you more than it saves. A shorter frame lowers encoder delay, but it also raises overhead, because every packet carries the same fixed network headers (IP, UDP, RTP) regardless of how little audio is inside. Halve the frame size and you double the number of packets and the header tax. On a congested network that extra packet rate can trigger the very loss you were trying to avoid. The common real-time setting is 20 ms precisely because it balances delay against overhead; go shorter only when you have measured that the latency win is worth the cost.

The two features that save a bad call: FEC and DTX

Two Opus settings do more for call quality than any amount of raw bitrate, because they address what actually breaks live audio: lost packets and wasted bandwidth.

The first is in-band Forward Error Correction, or FEC. On the internet, audio travels as a stream of packets, and some packets simply never arrive. Normally a lost packet means a gap — a click, a dropped syllable. FEC fixes this with a clever trick: when the encoder thinks the network is lossy, it tucks (in SILK and hybrid modes) a low-quality copy of the previous packet's audio inside the current packet (RFC 7587, §3.3). So if packet number 5 is lost, packet number 6 arrives carrying a backup copy of 5, and the decoder reconstructs the missing audio instead of leaving a hole. The cost is a few extra kilobits; the payoff is speech that stays intelligible through packet loss that would otherwise shred it. We cover the full family of loss-recovery techniques in forward error correction, in-band FEC, and RED redundancy and how players hide the gaps that slip through in packet loss concealment.

The second is Discontinuous Transmission, or DTX. When you stop talking, there is nothing useful to send — yet a naive codec keeps transmitting silence at full rate. DTX detects the pause and stops sending audio packets, sending only an occasional tiny update so the far end knows the line is still alive (RFC 7587, §3.1.3). On a typical call where each person talks less than half the time, DTX can cut the average bandwidth substantially. Opus also generates its own comfort noise — a faint, natural-sounding hiss — during the silence, because total digital silence feels unnervingly dead to the listener, as if the call had dropped. The mechanics of detecting speech and suppressing transmission are covered in voice activity detection and discontinuous transmission.

A short worked example shows the combined effect on a two-person call:

Both mics streaming continuously at 32 kbit/s each = 64 kbit/s total
Each person actually talks ~40% of the time
With DTX, average sent ≈ 0.40 × 64 ≈ 26 kbit/s
FEC adds back a few kbit/s for loss protection on the active speech
Net: a robust call for roughly the bandwidth of one continuous stream

Pitfall — turning on FEC the receiver cannot use just wastes bandwidth. FEC only helps if the decoding side knows to look for the backup copy in the next packet. If FEC is enabled on the sender but the receiver is not configured to use it, the redundant data is sent and then thrown away — pure waste (RFC 7587, §3.3 recommends not using FEC when the receiver cannot take advantage of it). Each receiver signals what it wants at call setup through the SDP parameters (useinbandfec, usedtx); make sure both sides agree, rather than flipping them on blindly.

Why every browser ships Opus

Opus did not become universal by being marketed. It became universal because the standard that powers in-browser calling made it mandatory.

WebRTC is the technology that lets a web page open a microphone and camera and place a call with no plugin. Its audio rules are written in IETF RFC 7874 (May 2016), and they are blunt: every WebRTC endpoint is required to implement Opus, plus the old telephone codec G.711 for compatibility with legacy phone systems. When the device can handle more than telephone quality — which is almost always — the specification recommends offering Opus first. The practical result is that Chrome, Firefox, Safari, and Edge all encode microphone audio as Opus by default. As of October 2026, MDN’s WebRTC codec tables list Opus in all four browsers and list no AAC at all: WebRTC does not use AAC, so a call that must carry AAC has to be transcoded at a server.

Because the browsers agreed on Opus, so did the server software that routes calls between them — mediasoup, Pion, LiveKit, Janus, and the rest. A codec that is guaranteed present on every endpoint is a codec you never have to transcode, and transcoding audio in the middle of a call costs CPU and adds delay. Opus being everywhere is therefore not just convenient; it removes an entire class of work from a real-time system. How those servers route audio without re-encoding it is the subject of audio in SFU vs MCU vs P2P.

Opus reaches beyond real-time, too. It rides inside several containers — Ogg (defined in RFC 7845), WebM and Matroska, MP4/ISOBMFF, and MPEG-TS — so it also appears in on-demand streaming, mainly over DASH (see HLS and DASH) and in audio containers generally. Its weak spot historically was hardware playback devices and broadcast chains, which standardised on AAC and Dolby years before Opus existed — which is exactly where AAC still wins.

Opus in MP4 and Opus 5.1 surround

Yes, Opus can go in MP4. The Encapsulation of Opus in ISO Base Media File Format specification maps it with an Opus sample entry and a dOps configuration box. “Opus 5.1” means six-channel surround in one Opus stream. RFC 7845 channel mapping family 1 carries 1 to 8 channels in Vorbis order — for 5.1: front left, center, front right, rear left, rear right, LFE — by coupling channel pairs into several internal Opus streams that share one packet. Plan 128–256 kbit/s for 5.1 and 256–450 kbit/s for 7.1 (Xiph.Org, 2026).

Opus versus AAC: a choice with a clear rule

The two codecs that dominate modern audio are Opus and the AAC family. They are not really competitors so much as specialists, and the choice between them usually answers itself once you ask what the audio is for.

Table 3. Opus and AAC compared on the axes that actually decide a project. "Frame / delay" is the minimum encoder delay before a packet can be sent — the figure that matters for live conversation.

The rule that falls out of the table: if the audio is a live, two-way conversation, choose Opus; if it is one-way playback to a wide range of devices and TVs, lean to AAC. A telemedicine call uses Opus. A movie streamed to a smart TV uses AAC. A product that does both — an e-learning platform with live classes and a recorded-lecture library — sensibly uses Opus for the live side and AAC for the on-demand side, which is a common and correct pattern, not a failure to standardise.

On pure quality at the same bitrate for music, the two are close enough that the decision should rest on the factors above — delay, device support, licensing — rather than on a quality contest most listeners would fail.

What Opus 1.5 and 1.6 added: machine learning and Opus HD

Opus is a living codec. Its open-source reference implementation keeps improving without changing the on-the-wire format, so newer encoders produce better-sounding audio that older decoders can still play.

The 2017 update RFC 8251 was housekeeping: it fixed two security issues found by fuzzing the decoder and corrected minor quality bugs, while staying fully compatible with the original RFC 6716. Any decoder that passed the original tests still works.

The bigger leap came with Opus 1.5, released by Xiph.Org in March 2024, which brought neural audio generation inside the codec for the first time. Two features stand out. Deep PLC uses a neural network to fill in lost packets with reconstructed audio that sounds far more natural than the old repeat-and-fade trick. Deep Redundancy (DRED) pushes FEC much further, letting the decoder recover speech even through long bursts of loss that would normally destroy a call. Deep PLC works at the receiver alone; DRED needs the sender to add the redundancy and the receiver to decode it.

libopus 1.6, released on 15 December 2025, is the current major version (1.6.1 followed on 14 January 2026 with minor fixes). It adds four things a product team should know about:

• A new DRED model trained on clean, noisy and reverberant speech, about 3× smaller than in 1.5 (600 kB instead of 1,800 kB) and more intelligible at very low bitrates. It is not interoperable with 1.5 DRED, so upgrade both ends together.
• Opus HD (experimental): 96 kHz audio and bitrates up to 2 Mb/s, built as an extension layer. A regular Opus decoder still plays the stream and simply ignores the extra layer.
• Neural bandwidth extension (BWE) at the decoder: it rebuilds 8–20 kHz from wideband speech. Xiph.Org reports that at 9 kbit/s it sounds about as good as Opus 1.4 fullband at 18 kbit/s.
• A 24-bit encoder and decoder API, plus fixed-point speed-ups for phones and embedded chips.

Standardization is catching up. As of October 2026, DRED is specified in the IETF Internet-Draft draft-ietf-mlcodec-opus-dred-07 (August 2026), which is in Working Group Last Call on the way to Proposed Standard; Opus HD is in a separate draft. Ship DRED where you control both ends; keep classic in-band FEC as the default everywhere else.

The next step may carry a new name. In February 2026 the Alliance for Open Media (AOMedia) started the Open Audio Codec (OAC), whose liboac is based on libopus and is meant as Opus’s successor. It is at an early stage and not for production files, so Opus remains the codec to ship in 2026.

Frequently asked questions

What does Opus mean in audio?

In audio, Opus is the name of a lossy codec, not a format brand or a quality level: “audio: Opus” means the sound is compressed with the IETF Opus codec (RFC 6716). It is the audio codec of WebRTC calls and of YouTube’s WebM audio streams.

Is Opus better than AAC?

For live, two-way audio, yes: Opus has 2.5–20 ms frames against about 21 ms for AAC-LC, is mandatory in WebRTC and is royalty-free. For one-way playback to TVs and set-top boxes, AAC is the safer choice because hardware decoders are universal; at matched music bitrates the two are close.

What is the recommended bitrate for Opus?

Use 10–24 kbit/s for voice, 64–96 kbit/s for stereo music streaming, 96–128 kbit/s for stored stereo music and 128–256 kbit/s for 5.1 (Xiph.Org recommended settings). For WebRTC, the RFC 7587 sweet spot for full-band speech is 28–40 kbit/s.

Is Opus good for music?

Yes. Its CELT engine is a full-band music coder, and Xiph.Org reports that 128 kbit/s VBR stereo Opus is close to transparent.

What is Opus DRC on YouTube, and Opus DRC vs Opus?

“DRC” is not an Opus feature. YouTube serves some videos with an extra audio track tagged DRC (for example format 251-drc next to the regular Opus format 251) for its Stable volume setting: the same Opus codec, with dynamic range compression applied so quiet and loud parts sit closer together. Choose plain Opus for the original dynamics.

What is Opus DTX?

DTX (discontinuous transmission) makes Opus stop sending audio packets while a speaker is silent, sending only occasional comfort-noise updates. It is negotiated with usedtx=1 in SDP and can roughly halve the bandwidth of a typical two-person call.

Does WebRTC support AAC?

No. RFC 7874 makes Opus and G.711 mandatory for WebRTC, and no major browser lists AAC among its WebRTC codecs as of 2026. To bridge an AAC source into a WebRTC call, transcode it to Opus on a server.

Is Opus an open codec?

Yes. Opus is an open IETF standard with a BSD-licensed reference implementation and royalty-free patent grants from its contributors. It is not the same thing as “OpenCodec”, a third-party codec pack for the PotPlayer media player, or AOMedia’s Open Audio Codec (OAC), an early-stage successor built on libopus.

Where Fora Soft fits in

We have built real-time audio into video products since 2005 — video conferencing, telemedicine consultations, e-learning classrooms, and AR/VR experiences — and Opus is the codec under almost all of it, because WebRTC hands it to us by default and it is free to use. In production the recurring lesson is not about choosing Opus but about tuning it: setting a sensible 20 ms frame, enabling FEC and DTX on both ends, and letting the bitrate adapt to the network rather than nailing it to a fixed number. When a client also needs an on-demand library alongside live sessions, we pair Opus for the calls with AAC for the recordings, which is the same split this article recommends. The failures we are called in to fix are rarely "wrong codec" and usually "Opus with the wrong settings" — FEC off on a lossy network, or a frame size chosen without measuring its overhead. If you need that tuning done in your own product, our WebRTC development team and audio and video processing engineers ship Opus with FEC, DTX and adaptive bitrate configured and tested on lossy real-world networks. If the product is already live and calls sound choppy, a WebRTC consulting review finds where the audio breaks, from codec settings to the media server.

The book

Audio for Video: A Complete Guide to Sound in Video Products: From PCM and Codecs to Loudness, Accessibility, and Real-Time Voice Processing

This article gives you the three Opus dials and the rule that picks Opus over AAC; the volume spends 1,229 pages on what sits either side of them — sampling and bit depth, channels and loudness, then the codecs themselves, with Opus set against AAC and the speech codecs on measured evidence rather than blog consensus. The second half covers the voice processing that runs before the encoder ever sees a frame: echo cancellation, gain control, noise suppression and VAD, which is where most of the audio complaints in a real product actually come from. Written by Nikolay Sapunov, CEO at Fora Soft.

Read it on Amazon →Kindle & paperback · Fora Soft Video Engineering Handbook

See our case studies

References

1. IETF RFC 6716, Definition of the Opus Audio Codec (Valin, Vos, Terriberry; September 2012) — the controlling standard. Defines the SILK + CELT hybrid architecture, the 6–510 kbit/s range, and the normative reference decoder. https://www.rfc-editor.org/rfc/rfc6716.html
2. IETF RFC 8251, Updates to the Opus Audio Codec (Valin, Vos; October 2017) — updates RFC 6716 with decoder fixes for two CVEs (CVE-2013-0899, CVE-2017-0381) and minor quality issues; remains fully compatible with RFC 6716. https://www.rfc-editor.org/rfc/rfc8251.html
3. IETF RFC 7587, RTP Payload Format for the Opus Speech and Audio Codec (Spittka, Vos, Valin; June 2015) — bitrate sweet spots (§3.1.1), frame sizes and the 120 ms maximum packet (§4.2), FEC (§3.3), DTX (§3.1.3), the 48000 Hz RTP clock, and the SDP parameters (useinbandfec, usedtx, stereo, maxaveragebitrate). https://www.rfc-editor.org/rfc/rfc7587.html
4. IETF RFC 7874, WebRTC Audio Codec and Processing Requirements (Valin, Bran; May 2016) — requires WebRTC endpoints to implement Opus and G.711, and recommends offering Opus first above 8 kHz. https://www.rfc-editor.org/rfc/rfc7874.html
5. IETF RFC 7845, Ogg Encapsulation for the Opus Audio Codec (Terriberry, Lee, Giles; April 2016) — the Ogg container mapping for Opus. https://www.rfc-editor.org/rfc/rfc7845.html
6. Xiph.Org, Opus Codec — License — the BSD-style license and royalty-free patent grants for Opus. https://opus-codec.org/license/
7. Xiph.Org, Opus 1.5 Released (March 2024) — the first Opus release with machine learning in the encoder and decoder: Deep PLC and Deep Redundancy (DRED). https://opus-codec.org/demo/opus-1.5/
8. MDN Web Docs, Codecs used by WebRTC — current browser support for Opus in WebRTC, used for orientation; the mandatory-codec claim is taken from RFC 7874 (reference 4), not from MDN. https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/WebRTC_codecs
9. Valin, Maxwell, Terriberry, Vos, High-Quality, Low-Delay Music Coding in the Opus Codec (135th AES Convention, 2013; arXiv preprint 2016) — the CELT music-coding design from the codec's authors. https://arxiv.org/pdf/1602.04845
10. Xiph.Org, libopus 1.6 (15 December 2025) and libopus 1.6.1 (14 January 2026) release announcements — BWE, Opus HD (96 kHz), improved DRED, 24-bit API. https://opus-codec.org/release/stable/2025/12/15/libopus-1_6.html
11. Xiph.Org, Opus 1.6 demo — DRED model size (1,800 kB → 600 kB) and compatibility, Opus HD extension layer up to 2 Mb/s, BWE results at 9 kbit/s. https://opus-codec.org/demo/opus-1.6
12. IETF, draft-ietf-mlcodec-opus-dred-07, Deep Audio Redundancy (DRED) extension for Opus (August 2026; Working Group Last Call, intended Proposed Standard). https://datatracker.ietf.org/doc/draft-ietf-mlcodec-opus-dred/
13. Xiph.Org Wiki, Opus Recommended Settings — recommended bitrates for VoIP, music, 5.1 and 7.1, and the 128 kbit/s transparency note. https://wiki.xiph.org/Opus_Recommended_Settings
14. Nakamura, Encapsulation of Opus in ISO Base Media File Format, v0.6.8 — the Opus sample entry and dOps box for MP4. https://opus-codec.org/docs/opus_in_isobmff.html
15. Via Licensing Alliance, Advanced Audio Coding patent pool — current AAC licensing (2026). https://via-la.com/via-licensing-alliance-welcomes-honor-as-advanced-audio-coding-patent-pool-licensee/
16. VoiceAge, xHE-AAC — xHE-AAC operating range down to about 8 kbit/s. https://www.voiceage.com/xHE-AAC.html
17. yt-dlp issue #11145 — YouTube “DRC” audio formats (251-drc) tied to the Stable volume setting. https://github.com/yt-dlp/yt-dlp/issues/11145
18. Alliance for Open Media, liboac repository README — reference implementation of the Open Audio Codec (OAC), built on libopus, work in progress (repository opened February 2026). https://github.com/AOMediaCodec/oac

A note on sources: where popular blogs claim Opus "always beats AAC at the same bitrate", this article follows the more careful position of the codec authors' own papers (reference 9) and the standards: Opus's decisive advantage is delay and openness for real-time use, while music quality at matched bitrate is close to AAC rather than uniformly superior.