rfc-8486

Ambisonics in an Ogg Opus Container

J. Skoglund, M. Graczyk
date2018-10 streamIETF areaart wgcodec statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc8486 doi10.17487/RFC8486 errataview
This document defines an extension to the Opus audio codec to encapsulate coded Ambisonics using the Ogg format. It also contains updates to RFC 7845 to reflect necessary changes in the description of channel mapping families.

updates

Extracted elements (20)

design-rationale §3.1

Channel Mapping Family 2 allows mixed-order Ambisonic representation, where only a subset of the full Ambisonic channel set is encoded. Inactive ACN channels are indicated using the index value 255 in the channel mapping field.

design-rationale §3.2

Channel Mapping Family 3 adds flexibility over family 2 by supporting a demixing matrix, enabling mixed-order Ambisonics, non-diegetic stereo, and arbitrary channel mixing. Silent ACN channels in mixed-order representations are indicated by all-zero rows in the demixing matrix.

design-rationale §6

The experimental range 240-254 was introduced to make development of new mapping families easier while reducing compatibility risk with non-final versions. The Ambisonics mapping experiments that led to this document used family 254 for family 2 and family 253 for family 3.

interoperability-note §3.2

The identification header in the Ogg format cannot exceed one page (65,025 octets), which limits the maximum Ambisonic order for family 3 full-order representations to below 12 when the stream count equals the Ambisonic order plus two non-diegetic channels.

interoperability-note §5.1

This document updates RFC 7845 to clarify that the channel mapping table format may depend on the channel mapping family, rather than being fixed for all families. Families 1 and 255 continue to use the format specified in RFC 7845 Figure 3.

normative-requirement §5.2 SHOULD NOT

A demuxer encountering a channel mapping family value it does not recognize SHOULD NOT attempt to decode the packets and SHOULD NOT use any information except the first 19 octets of the ID header packet and the comment header. This updates RFC 7845 Section 5.1.1.4.

normative-requirement §3 MUST

A demuxer implementation encountering channel mapping family 2 or 3 MUST interpret the Opus stream as containing Ambisonics with the format described in Sections 3.1 or 3.2, respectively.

normative-requirement §3.2 MUST

For channel mapping family 3, the Ambisonic order MUST be lower than 12 if full order is utilized and the number of coded streams equals the Ambisonic order plus two non-diegetic channels, due to the identification header page limit of 65,025 octets.

normative-requirement §3.2 MUST

For channel mapping family 3, the demixing matrix MUST be provided in the channel mapping table part of the identification header. The total output channel number C MUST be set in the third field of the identification header.

normative-requirement §6 SHOULD

Implementers using experimental mapping families (240-254) SHOULD attempt to use family numbers that have not recently been used and SHOULD advertise what experimental numbers they use.

protocol-element §3.1

A non-diegetic stereo stream (two channels: left and right) may be appended after the Ambisonic channels in both family 2 and family 3 to carry audio that should remain unchanged by head rotation, such as narration or stereo music.

protocol-element §3.1

Ambisonic channels in family 2 are normalized using Schmidt Semi-Normalization (SN3D), with ACN channel ordering and SN3D normalization defined per the AmbiX specification, Section 2.1.

protocol-element §3.1

Channel Mapping Family 2 encodes Ambisonic components in Ambisonic Channel Number (ACN) order, optionally followed by two non-diegetic stereo channels (left, right). ACN is defined as n*(n+1)+m for Ambisonic order n and degree m.

protocol-element §3.2

Channel Mapping Family 3 generates C output channels by multiplying K=N+M decoded channels with a demixing matrix D (C rows, K columns). The matrix must be provided in the channel mapping table of the identification header, replacing the standard channel mapping field.

protocol-element §3.3

For both channel mapping families 2 and 3, the allowed numbers of channels are (1+n)^2 + 2j for n=0..14 and j=0 or 1, yielding values 1, 3, 4, 6, 9, 11, 16, 18, 25, 27, ... up to 227, representing periphonic Ambisonics from zeroth to fourteenth order with optional non-diegetic stereo.

protocol-element §4

For stereo downmixing from Ambisonics without non-diegetic stereo, a player MAY use: L = 0.5*W + 0.5*Y, R = 0.5*W - 0.5*Y, where W is the first (omnidirectional) and Y the second Ambisonic channel. With non-diegetic stereo Ls/Rs, the W/Y coefficients are halved (0.25) and Ls/Rs are added with weight 0.5.

protocol-element §6

Mapping families 240 through 254 (inclusive) are reserved for experimental use, allowing development of new mapping families while reducing compatibility risks. These experiments are not restricted to Ambisonics.

registry §8

IANA added 17 new assignments to the 'Opus Channel Mapping Families' registry: value 2 (Ambisonics as individual channels, Section 3.1), value 3 (Ambisonics with demixing matrix, Section 3.2), and values 240-254 (Experimental use, Section 6). Values 0, 1, and 255 are also formally documented.

registry

security-consideration §7 MUST NOT

Implementations MUST NOT overrun their allocated memory nor read from uninitialized memory when managing the Ambisonic channel mapping. Because the extension requires semantic meaning for more channels than standard Ogg, care must be taken in new allocation paths.

security

wire-format §3.2

The channel mapping table for family 3 contains: Stream Count N (8 bits unsigned), Coupled Count M (8 bits unsigned), and a Demixing Matrix (16*K*C bits) stored in column-major order as Q15 signed 16-bit little-endian fixed-point values.