Opus documentation

Developing with libopus (API reference)

Libopus is the reference implementation of the Opus Codec.

Developing with opusfile and opusenc (API reference)

Opusfile and libopusenc are a easy to use libraries that encapsulates everything you need beyond libopus to correctly and completely support the playback and creation of .opus (OggOpus) files.

Opus-tools man-pages

IETF specifications

Other specifications

Tutorials

Inside Opus

Beyond the RFC itself, there are a several documents out there that describe Opus or parts of Opus. Not everything in them applies to the final version of Opus, but they should still be useful to those who want to understand how Opus works. For an overview of the codec, see the linux.conf.au 2012 Opus presentation.

The most accessible descriptions of Opus are probaly Monty’s demos. We have also written some papers describing the algorithm in details:

Older contents

For historical reasons, some of the information on the algorithmic details is specific to either SILK or CELT.

For more information on SILK, see the slides by Koen Vos from the 79th IETF meeting.

You can see Tim Terriberry’s linux.conf.au 2009 CELT presentation. Those with a signal processing background can also read two papers that were published on CELT:

Paper 1 describes CELT version 0.3.2, while paper 2 applies to 0.5.2. The main things that changed since these papers were written are the pitch prediction/filtering and the birdie avoidance method.

Test Vectors

Test files to verify that the Opus decoders are operating properly (updated for RFC 8251).

Bitstream conformance set for the codec.

This set of bitstreams is used to measure codec implementations for conformance with the specification. Also available from Mozilla and the IETF.

The old test vectors are stll available (Xiph.Org, Mozilla, IETF)

The .opus test set is an in-development larger test suite for .opus files. These are suitable for testing opusdec and other media-player software. Files prefixed with ‘broken’ and ‘failure’ are intentionally malformed and at least the latter should be rejected.

Note that these files are designed to exercise all aspects of an implementation, the fact that they sound terrible is an intended consequence.