OggOpus

From XiphWiki
Revision as of 12:56, 18 August 2011 by Bemasc (talk | contribs) (Fix list syntax)
Jump to navigation Jump to search

Ogg mapping for Opus

The IETF Opus codec is a low-latency audio codec optimized for both voice and general-purpose audio. See [tools.ietf.org/html/draft-ietf-codec-opus the spec] for technical details.

Almost everything about this codec is either fixed or dynamically switchable, so the usual id and setup header parameters in the header packets of an Ogg encapsulation aren't useful. In particular, bitrate, frame size, mono/stereo, and coding modes are all dynamically switchable from packet to packet. A one-byte header on each data packet defines the parameters for that particular packet.

Remaining parameters we need to signal are:

  • magic number for stream identification
  • comment/metadata tags

Additionally there's been a desire to support some kind of channel bonding for surround, and some kind of option signalling for "Opus Custom", in particular the granulerate.

Draft spec

Granulepos is the count of decodeable samples at a fixed rate of 48 kHz.

Two headers: id, comment

Id header: 

- "OpusHead" (64 bits)
- version number (8 bits) zero for this spec
- Number of channels 'c' (8 bits) (must be > 0)
- Pre-skip (16 bits)
- Input sample rate (32 bits) (informational only)
- Output gain (16 bits, signed Q7.8 in dB) to apply when decoding
- channel mapping (8 bits)
 --  0 = one stream, RTP order, 1 = channels in vorbis spec order, 2..254 reserved (treat as 255), 255 = no defined channel meaning
if channel mapping > 0
- Number of streams 'N'(8 bits) (must be > 0)
- Number of two-output streams 'M' (8 bits) (M+N strictly smaller than 255)
- for each output channel [0..c]
  -- read stream index (8 bits) (255 means silent through the file)

All two-output streams come first, so if the stream index is < 2*M, the channel decode the (index/2)th opus stream as stereo, selecting the (index%2)th output (left for even, right for odd). If index >= 2*M, decode the (index - M)th stream as mono and use that as the output. As a special case, a stream index of 255 means to write silence to that output channel.

Comment header: 

- 8 byte 'OpusTags' magic signature (64 bits)
- rest follows the vorbis-comment header design used in OggVorbis, OggTheora, and Speex.
 ** Vendor string (always present)
 ** tag=value metadata strings (zero or more)

One new comment field is introduced for Ogg Opus: 

R128_TRACK_GAIN=-573

representing the volume shift needed to normalize the track's volume. The gain is a Q7.8 fixed point number in dB, as in the OpusHead "output gain" field. This field acts similarly to the REPLAYGAIN_TRACK_GAIN field in Vorbis, although the normal volume reference is the EBU-R128 standard.

An Ogg Opus file MUST NOT have more than one such field, and if present its value MUST be an integer from -32768 to +32767 inclusive, represented in ASCII with no whitespace. When a player makes use of the TRACK_GAIN, it MUST be applied in addition to the OpusHead output gain, and MUST correctly represent the R128 normalization gain. If an encoder populates the TRACK_GAIN field, and the output gain is not otherwise constrained or specified, the encoder SHOULD write the R128 gain into the OpusHead output gain and set "R128_TRACK_GAIN=0". If a tool modifies the OpusHead "output gain" field, it MUST also update or remove the R128_TRACK_GAIN comment field.

There is no comment field corresponding to Replaygain's ALBUM_GAIN; that information should instead be stored in the OpusHead "output gain" field.

To avoid confusion with multiple normalization schemes, an OpusTags packet SHOULD NOT contain any of the REPLAYGAIN_TRACK_GAIN, REPLAYGAIN_TRACK_PEAK, REPLAYGAIN_ALBUM_GAIN, or REPLAYGAIN_ALBUM_PEAK fields.

Some discussion is in order.

  • magic signature

The signature magic values allow codec identification and are being human readable. Starting with 'Op' helps distinguish them from data packets.

  • version

Version number. Must always be zero for this version of the encapsulation spec. In general revising the spec later isn't a good idea, but this also acts as a null terminator for the signature bytes and helps align the rest of the fields.

  • channel mapping and number of channels

The channel mapping byte indicates the order and semantic meaning of the various channels encoded in each Opus packet. The number of channels byte specifies the number of output channels (1...255) for this Ogg Opus stream.

Each channel mapping byte indicates a mapping family, which defines a set of allowed numbers of channels, and the ordered set of channel names for each allowed number of channels. Currently there are three defined mapping families, although more may be added:

    • Family 0 (RTP mapping)
      • Allowed numbers of channels: 1 or 2
      • 1 channel: monophonic (mono)
      • 2 channels: stereo (left, right)
      • Special mapping: this channel mapping value also indicates that the contents consists of a single Opus stream that is stereo iff number of channels == 2, with stream index 0 mapped to channel 0, and (if stereo) stream index 1 mapped to channel 1. When the channel mapping byte has this value, no further fields are present in OpusHead.
    • Family 1 (Vorbis mapping)
      • Allowed numbers of channels: 1 ... 8
      • Channel meanings depend on the number of channels, see the Vorbis mapping for details.
    • Family 255 (no defined channel meaning)
      • Allowed numbers of channels: 1...255
      • Channels are unidentified. General-purpose players SHOULD NOT attempt to play these streams, and offline decoders MAY deinterleave the output into separate PCM files, one per channel. Decoders SHOULD NOT produce output for channels mapped to stream index 255 (pure silence) unless they have no other way to indicate the index of non-silent channels.

The remaining channel mapping values (2...254) are reserved. A decoder encountering a reserved mapping byte should act as though the mapping byte is 255.

An Ogg Opus player MUST play any Ogg Opus stream with channel mapping 0 or 1, even if the number of channels does not match the physically connected audio hardware. Players SHOULD perform channel mixing to increase or reduce the number of channels as needed.

Note: Any Opus stream may be decoded as mono (single output) or stereo (two outputs), regardless of its contents, by appropriate initialization of the decoder. The "number of two-output streams" field indicates that the first M Opus decoders should be initialized in stereo mode, and the remaining decoder should be initialized in mono mode.

  • pre-skip

This is the number of samples (at 48 kHz) to discard from the decoder output before starting playback.

The purpose of pre-skip is to allow a time-segment of an existing Opus stream to be saved as an independent Ogg file, with single-sample time granularity, without re-encoding. Opus is an asymptotically convergent predictive codec, so the decoded contents of each frame depend on the recent history of decoder inputs. Pre-skip can be used to provide sufficient history to the decoder so that it has already converged before the stream's output begins.

When constructing cropped Ogg Opus streams, we recommend a pre-skip of at least FIXME samples to ensure complete convergence.

  • output gain

This is a gain to be applied by the decoder. Virtually all players and media frameworks should apply it by default. Any volume adjustment or gain modification, such as the R128_TRACK_GAIN or a user-facing volume knob, MUST be applied in addition to this output gain in order to achieve playback at the desired volume.

An encoder SHOULD set the output gain to zero, and apply any gain prior to encoding, when this is possible and does not conflict with the user's wishes. The output gain should only be nonzero when the gain is adjusted after encoding, or when the user wishes to adjust the gain for playback while preserving the ability to recover the original signal amplitude.

Note that although the output gain has enormous range (+/- 128 dB, enough to amplify inaudible sounds to the threshold of physical pain), most applications can only reasonably use a small portion of this range around zero. The large range serves in part to ensure that gain can always be losslessly transferred between OpusHead and R128_TRACK_GAIN without saturating.

  • input rate

This is not the sample rate for playback of the encoded data.

Opus has a handful of coding modes, with internal samplerates of 8, 12, 16, 24, and 48 kHz. Each packet in the stream may have a different internal sample rate. Regardless of the internal sample rate, the reference decoder supports decoding any stream to any of these sample rates. The original sample rate of the encode input is not preserved by the lossy compression.

An Ogg Opus player SHOULD select the playback sample rate according to the following procedure:

    • If the hardware supports 48 kHz playback, decode at 48 kHz
    • else if the hardware's highest available sample rate is a supported rate, decode at this sample rate
    • else if the hardware's highest available sample rate is less than 48 kHz, decode at the next higher supported rate and resample
    • else decode at 48 kHz and resample.

However, the Ogg mapping allows the encoder to pass the sample rate of the original input stream as metadata. This may be useful when the user requires the output sample rate to match the input sample rate. For example, a non-player decoder writing PCM format to disk might choose to resample the output audio back to the original input rate to reduce surprise.

  • stream count

It is necessary to describe the number of streams so the decoder can correctly parse the packed frames inside the packet. We store the count-minus-one here, to remove invalid configuration of zero Opus streams in the this Ogg stream.

Test vectors

Retrieved from "https://wiki.xiph.org/index.php?title=OggOpus&oldid=12985"