Opus MIME Type

What does audio/opus mean?

audio/opus is the registered media type for Opus audio carried as framed data, especially in RTP sessions used by conferencing, Voice over IP, and real-time streaming. The registration requires a 48 kHz RTP clock and defines parameters for packet duration, playback rate, stereo, constant or variable bitrate, in-band forward error correction, and discontinuous transmission.¹²

Opus itself is a lossy audio codec designed to cover both speech and music. It combines a linear-prediction layer that is efficient for speech with a transform layer suited to music and higher audio frequencies. The codec can change mode, bitrate, bandwidth, and frame size while a stream is running.³

This distinction matters on the web. Use audio/opus when describing framed Opus media as registered by RFC 7587. For the common downloadable .opus file, send audio/ogg; codecs=opus unless a particular API explicitly asks for audio/opus.

Why are .opus files usually Ogg files?

Raw Opus packets do not provide everything a stored recording needs. Ogg supplies page boundaries, checksums, metadata, seeking, error recovery, and timestamps. An Ogg Opus stream begins with an Ogg page and a mandatory OpusHead identification packet, followed by an OpusTags comment packet and the encoded audio packets.⁴

That also explains why there is no single magic number for audio/opus. The registered media type describes framed codec data, not one file container. A typical .opus file has the Ogg capture pattern OggS near its beginning and OpusHead in its first packet, but OggS alone only identifies the Ogg container. It does not prove that the contained codec is Opus.

Opus may also appear inside WebM, Matroska, MP4, MPEG-TS, or other containers. Those files should use the container's extension and media type, not .opus merely because one track uses the codec.⁵

History and standardization

The IETF published the Opus codec as RFC 6716 in September 2012. The design brought together complementary linear-prediction and modified discrete cosine transform techniques so one codec could handle narrowband speech, fullband music, and low-delay interactive use.³

RFC 7587 followed in June 2015. It defined the RTP payload format and registered audio/opus, including how Opus parameters map into Session Description Protocol offers and answers.² RFC 7845 standardized Ogg encapsulation in April 2016 and assigned the .opus extension to audio/ogg.⁴

The timeline is why this page lists 2015 as the media type's first standardization date even though the underlying codec was standardized in 2012.

Bitrates, bandwidth, and delay

Opus can scale from 6 kbit/s narrowband mono speech to 510 kbit/s fullband stereo music. Its effective sample rates range from 8 kHz for narrowband through 48 kHz for fullband, while its coded audio bandwidth tops out at 20 kHz. Algorithmic delay ranges from 5 ms to 65.2 ms.³

RFC 7587 gives practical starting ranges for 20 ms frames:²

These are recommendations, not fixed quality levels. The source, encoder settings, packet-loss conditions, and intended playback equipment all affect the result. Variable bitrate usually produces better quality than constant bitrate at the same average rate, but traffic analysis can reveal information through changing packet sizes even when the payload is encrypted.²

Browser and application support

Current Chrome, Edge, Firefox, Opera, and Safari releases support Opus. Container support is the important qualifier. MDN reports Opus playback in Ogg and WebM across the major browser engines, with Ogg Opus arriving in Safari 18.4 on the corresponding 2025 Apple operating-system releases.⁵ WebRTC implementations also use Opus as a mandatory audio codec.⁶

For a stored .opus file, VLC media player and the official opus-tools utilities can decode it. opus-tools includes commands for encoding, inspecting, and decoding Ogg Opus files.⁷⁸

<audio controls>
  <source src="interview.opus" type="audio/ogg; codecs=opus">
</audio>

Support in Poly

Poly recognizes both the internal audio/opus identifier and .opus filenames. It classifies them as audio and routes them through the same pipeline as other decodable recordings. That pipeline:

• Probes the container for duration and available tags.
• Extracts embedded cover art when one is present.
• Generates a timestamped WebVTT transcript and indexes its text.
• Creates 15-second audio-similarity segments when the recording is long enough.
• Opens the original file in Poly's browser-based audio player.

Audio-similarity embeddings require at least eight seconds of usable duration. A shorter clip can still be found by name, metadata, and transcript text. The agent reads the generated transcript, so its access depends on transcription completing successfully. Previewing uses the original file and therefore still depends on the current browser supporting its container and codec.

Poly maps .opus to audio/opus for ingestion even though RFC 7845 registers that extension under audio/ogg. This is a deliberate internal file-type mapping, not a change to the IANA registration.

Converting Opus audio

Choose the output based on the next step:

• WAV or FLAC for editing, analysis, or a lossless working copy. The decoded samples are preserved, but detail already discarded by Opus cannot be restored.
• Ogg Opus for a standards-defined .opus delivery file.
• AAC in M4A when compatibility with older Apple software matters more than keeping Opus.
• MP3 for older players and interchange workflows.

With FFmpeg, these examples create an Ogg Opus file and a lossless working copy:

ffmpeg -i input.wav -c:a libopus -b:a 96k output.opus
ffmpeg -i input.opus output.flac

Avoid converting an Opus file directly to another lossy codec when a lossless source is available. Lossy-to-lossy transcoding decodes one approximation and compresses it again, which can add artifacts.

Security and privacy considerations

Treat Opus parsers like other media decoders: reject unreasonable packet sizes, malformed Ogg page structures, and untrusted metadata. RFC 7845 discusses integer-overflow, memory-exhaustion, and pathological-seeking risks in damaged or hostile files.⁴

For encrypted real-time calls, the audio payload may be confidential while packet timing and variable sizes still expose patterns. RFC 7587 points to separate guidance for VBR traffic-analysis risks and recommends normal RTP security mechanisms such as SRTP where appropriate.²