Ambisonics in an Ogg Opus Container
draft-ietf-codec-ambisonics-05
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8486.
|
|
---|---|---|---|
Authors | Jan Skoglund , Michael Graczyk | ||
Last updated | 2018-05-01 | ||
Replaces | draft-graczyk-codec-ambisonics | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 8486 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-codec-ambisonics-05
codec J. Skoglund Internet-Draft Google Inc. Updates: 7845 (if approved) M. Graczyk Intended status: Standards Track May 01, 2018 Expires: November 2, 2018 Ambisonics in an Ogg Opus Container draft-ietf-codec-ambisonics-05 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 2, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Skoglund & Graczyk Expires November 2, 2018 [Page 1] Internet-Draft Opus Ambisonics May 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Ambisonics With Ogg Opus . . . . . . . . . . . . . . . . . . 3 3.1. Channel Mapping Family 2 . . . . . . . . . . . . . . . . 3 3.2. Channel Mapping Family 3 . . . . . . . . . . . . . . . . 4 4. Downmixing . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Updates to RFC 7845 . . . . . . . . . . . . . . . . . . . . . 6 5.1. Format of the Channel Mapping Table . . . . . . . . . . . 6 5.2. Unknown Mapping Families . . . . . . . . . . . . . . . . 7 6. Experimental Mapping Families . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Ambisonics is a representation format for three dimensional sound fields which can be used for surround sound and immersive virtual reality playback. See [gerzon75] and [daniel04] for technical details on the ambisonics format. For the purposes of the this document, ambisonics can be considered a multichannel audio stream. A separate stereo stream can be used alongside the ambisonics in a head-tracked virtual reality experience to provide so-called non- diegetic audio - audio which should remain unchanged by listener head rotation; e.g., narration or stereo music. Ogg is a general purpose container, supporting audio, video, and other media. It can be used to encapsulate audio streams coded using the Opus codec. See [RFC6716] and [RFC7845] for technical details on the Opus codec and its encapsulation in the Ogg container respectively. This document extends the Ogg Opus format by defining two new channel mapping families for encoding ambisonics. The Ogg Opus format is extended indirectly by adding an item with value 2 or 3 to the IANA "Opus Channel Mapping Families" registry. When 2 or 3 are used as the Channel Mapping Family Number in an Ogg stream, the semantic meaning of the channels in the multichannel Opus stream is one of the ambisonics layouts defined in this document. This mapping can also be used in other contexts which make use of the channel mappings defined by the Opus Channel Mapping Families registry. Furthermore, mapping families 240 through 254 (inclusively) are reserved for experimental use. Skoglund & Graczyk Expires November 2, 2018 [Page 2] Internet-Draft Opus Ambisonics May 2018 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Ambisonics With Ogg Opus Ambisonics can be encapsulated in the Ogg format by encoding with the Opus codec and setting the channel mapping family value to 2 or 3 in the Ogg identification header (ID). A demuxer implementation encountering Channel Mapping Family 2 or Family 3 MUST interpret the Opus stream as containing ambisonics with the format described in Section 3.1 or Section 3.2, respectively. 3.1. Channel Mapping Family 2 Allowed numbers of channels: (1 + n)^2 + 2j for n = 0...14 and j = 0 or 1, where n denotes the (highest) ambisonic order and j whether or not there is a separate non-diegetic stereo stream. This corresponds to periphonic ambisonics from zeroth to fourteenth order plus potentially two channels of non-diegetic stereo. Explicitly the allowed number of channels are 1, 3, 4, 6, 9, 11, 16, 18, 25, 27, 36, 38, 49, 51, 64, 66, 81, 83, 100, 102, 121, 123, 144, 146, 169, 171, 196, 198, 225, 227. This channel mapping uses the same channel mapping table format used by channel mapping family 1. The output channels are ambisonic components ordered in Ambisonic Channel Number (ACN) order, defined in Figure 1, followed by two optional channels of non-diegetic stereo indexed (left, right). ACN = n * (n + 1) + m, for order n and degree m. Figure 1: Ambisonic Channel Number (ACN) For the ambisonic channels the ACN component corresponds to channel index as k = ACN. The reverse correspondence can also be computed for an ambisonic channel with index k. order n = floor(sqrt(k)), degree m = k - n * (n + 1). Figure 2: Ambisonic Degree and Order from ACN Skoglund & Graczyk Expires November 2, 2018 [Page 3] Internet-Draft Opus Ambisonics May 2018 Note that channel mapping family 2 allows for so-called mixed order ambisonic representation where only a subset of the full ambisonic order number of channels. By specifying the full number in the channel count field, the inactive ACNs can then be indicated in the channel mapping field using the index 255. Ambisonic channels are normalized with Schmidt Semi-Normalization (SN3D). The interpretation of the ambisonics signal as well as detailed definitions of ACN channel ordering and SN3D normalization are described in [ambix] Section 2.1. 3.2. Channel Mapping Family 3 Allowed numbers of channels: (1 + n)^2 + 2j for n = 0...14 and j = 0 or 1, where n denotes the (highest) ambisonic order and j whether or not there is a separate non-diegetic stereo stream. This corresponds to periphonic ambisonics from zeroth to fourteenth order plus potentially two channels of non-diegetic stereo. Explicitly the allowed number of channels are 1, 3, 4, 6, 9, 11, 16, 18, 25, 27, 36, 38, 49, 51, 64, 66, 81, 83, 100, 102, 121, 123, 144, 146, 169, 171, 196, 198, 225, 227. In this mapping, C output channels (the channel count) are generated at the decoder by multiplying K = N + M decoded channels with a designated demixing matrix, D, having C rows and K columns. Here, N denotes the number of streams encoded and M the number of these which are coupled to produce two channels. As for channel mapping family 2 this mapping family also allows for encoding and decoding of full order ambisonics, mixed order ambisonics, and for non-diegetic stereo channels, but also has the added flexibility of mixing channels. Let X denote a column vector containing K decoded channels X1, X2, ..., XK (from N streams), and let S denote a column vector containing C output streams S1, S2, ..., SC. Then S = D X, i.e., / \ / \ / \ | S1 | | D11 D12 ... D1K | | X1 | | S2 | | D21 D22 ... D2K | | X2 | | ... | = | ... ... ... ... | | ... | | SC | | DC1 DC2 ... DCK | | XK | \ / \ / \ / Figure 3: Demixing in Channel Mapping Family 3 The matrix MUST be provided as side information and MUST be stored in the channel mapping table part of the identification header, c.f. section 5.1.1 in [RFC7845]. The matrix replaces the need for a channel mapping field and for channel mapping family 3 the mapping table has the following layout: Skoglund & Graczyk Expires November 2, 2018 [Page 4] Internet-Draft Opus Ambisonics May 2018 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Stream Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Coupled Count | Demixing Matrix : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Channel Mapping Table for Channel Mapping Family 3 The fields in the channel mapping table have the following meaning: 1. Stream Count 'N' (8 bits, unsigned): This is the total number of streams encoded in each Ogg packet. 2. Coupled Stream Count 'M' (8 bits, unsigned): This is the number of the N streams whose decoders are to be configured to produce two channels (stereo). 3. Demixing Matrix (16*K*C bits, signed): The coefficients of the demixing matrix stored column-wise as 16-bit, signed, two's complement fixed-point values with 15 fractional bits (Q15), little endian. If needed, the output gain field can be used for a normalization scale. For mixed order ambisonic representations, the silent ACN channels are indicated by all zeros in the corresponding rows of the mixing matrix. This allows also for mixed order with non-diegetic stereo as the number of columns implies the presence of non-diegetic channels. Note that [RFC7845] specifies that the identification header cannot exceed one "page", which is 65,025 octets. This limits the ambisonic order to be lower than 12, if full order is utilized and the number of coded streams is the same as the ambisonic order plus the two non- diegetic channels. Also note that the total output channel number, C, MUST be set in the 3rd field of the identification header. Skoglund & Graczyk Expires November 2, 2018 [Page 5] Internet-Draft Opus Ambisonics May 2018 4. Downmixing An Ogg Opus player MAY use the matrix in Figure 5 to implement downmixing from multichannel files using Channel Mapping Family 2 and 3, when there is no non-diegetic stereo. This downmixing is known to give acceptable results for stereo downmixing from ambisonics. The first and second ambisonic channels are known as "W" and "Y" respectively. / \ / \ / \ | L | | 0.5 0.5 0.0 ... | | W | | R | = | 0.5 -0.5 0.0 ... | | Y | \ / \ / | ... | \ / Figure 5: Stereo Downmixing Matrix for Channel Mapping Family 2 and 3 - only Ambisonic Channels The first ambisonic channel (W) is a mono audio stream which represents the average audio signal over all directions. Since W is not directional, Ogg Opus players MAY use W directly for mono playback. If a non-diegetic stereo track is present, the player MAY use the matrix in Figure 6 for downmixing. Ls and Rs denote the two non- diegetic stereo channels. / \ / \ / \ | L | | 0.25 0.25 0.0 ... 0.5 0.0 | | W | | R | = | 0.25 -0.25 0.0 ... 0.0 0.5 | | Y | \ / \ / | ... | | Ls | | Rs | \ / Figure 6: Stereo Downmixing Matrix for Channel Mapping Family 2 and 3 - Ambisonic Channels Plus a Non-diegetic Stereo Stream 5. Updates to RFC 7845 5.1. Format of the Channel Mapping Table The language in section 5.1.1 in [RFC7845] implies that the channel mapping table, when present, has a fixed format for all channel mapping families: The order and meaning of these channels are defined by a channel mapping, which consists of the 'channel mapping family' octet and, Skoglund & Graczyk Expires November 2, 2018 [Page 6] Internet-Draft Opus Ambisonics May 2018 for channel mapping families other than family 0, a 'channel mapping table', as illustrated in Figure 3. This document updates [RFC7845] to clarify that the format of the channel mapping table may depend on the channel mapping family: The order and meaning of these channels are defined by a channel mapping, which consists of the 'channel mapping family' octet and for channel mapping families other than family 0, a 'channel mapping table'. The format of the channel mapping table depends on the channel mapping family. Unless the channel mapping family requires a custom format for its channel mapping table, the RECOMMENDED channel mapping table format for new mapping families is illustrated in Figure 3. The change above is not meant to change how families 1 and 255 currently work. To ensure that, the first paragraph of Section 5.1.1.2 is changed from: Allowed numbers of channels: 1...8. Vorbis channel order (see below). to Allowed numbers of channels: 1...8, with the mapping specified according to Figure 3. Vorbis channel order (see below). Similary, the first paragraph of Section 5.1.1.4 is changed from: Allowed numbers of channels: 1...255. No defined channel meaning. to Allowed numbers of channels: 1...255, with the mapping specified according to Figure 3. No defined channel meaning. 5.2. Unknown Mapping Families Treatment of unknown mapping families is changed slightly. Section 5.1.1.4 of [RFC7845] states: The remaining channel mapping families (2...254) are reserved. A demuxer implementation encountering a reserved 'channel mapping family' value SHOULD act as though the value is 255. This is changed to: Skoglund & Graczyk Expires November 2, 2018 [Page 7]quot; in this document are to be interpreted as described in [RFC2119]. 2. Terminology This document uses the following terms: AIS Alarm Indication Signal MD Level Maintenance Domain (MD) Level which identifies a value in the range of 0-7 associated with Ethernet OAM frame. MD Level identifies the span of the Ethernet OAM frame. MEP Maintenance End Point is responsible for origination and termination of OAM frames for a given MEG Bitar, et al. Expires October 2012 [Page 7] Internet-Draft MPLS & Ethernet OAM Interworking April 2012 MIP Maintenance Intermediate Point is located between peer MEPs and can process OAM frames but does not initiate or terminate them RDI Remote Defect Indication Further, this document also uses the terminology and conventions used in [RFC6310]. 3. PW Status and Defects [RFC6310] introduces a range of defects that impact PW status. All these defect conditions are applicable for Ethernet PWs. Similarly, there are different mechanisms described in [RFC6310] to detect PW defects, depending on the PSN type (e.g. MPLS PSN, MPLS-IP PSN). Any of these mechanisms can be used when monitoring the state of Ethernet PWs. [RFC6310] also discusses the applicability of these failure detection mechanisms. 3.1. Use of Native Service (NS) notification When a MEP is defined on the PE and associated with an Ethernet PW,the PE can use native service OAM capabilities for failure notifications. Options include: - Sending of AIS frames from the local MEP to the MEP on the remote PE when the MEP needs to convey PE receive defects, and when CCM transmission is disabled. - Suspension of CCM frames transmission from the local MEP to the peer MEP on the remote PE to convey PE receive defects, when CCM transmission is enabled. - setting the RDI bit in transmitted CCM frames, when loss of CCMs from the peer MEP is detected or the PE needs to convey PW reverse defects. These NS OAM notifications are inserted into the corresponding PW. Similarly, when the defect conditions are cleared, a PE can take one of the following actions, depending on the mechanism that Bitar, et al. Expires October 2012 [Page 8] Internet-Draft MPLS & Ethernet OAM Interworking April 2012 was used for failure notification, to clear the defect sate on the peer PE: - Stopping AIS frame transmission from the local MEP to the MEP on the remote PE to clear PW receive defects. - Resuming CCM frames transmission from the local MEP to the peer MEP on the remote PE to clear PW forward defects notification, when CCM transmission is enabled. - Clearing the RDI bit in transmitted CCM frames, to clear PW transmit defects notification, when CCM transmission is enabled. 3.2. Use of PW Status notification for MPLS PSNs When PWs are established using LDP, LDP status notification signaling MUST be used as the default mechanism to signal AC and PW status and defects [RFC4447]. That is known as the "coupled loop mode". For PWs established over an MPLS or MPLS-IP PSN using other mechanisms (e.g. static configuration), inband signaling using VCCV-BFD [RFC5885] SHOULD be used to convey AC and PW status and defects. [RFC6310] identifies the following PW defect status codepoints: - Forward defect: corresponds to a logical OR of local AC (ingress) Receive fault, local PSN-facing PW (egress) transmit fault, and PW not forwarding fault. - Reverse defect: corresponds to a logical OR of local AC (egress) transmit fault and local PW PSN-facing (ingress) receive fault. There are also scenarios where a PE carries out PW label withdrawal instead of PW status notification. These include administrative disablement of the PW or loss of Target LDP session with the peer PE. 3.3. Use of BFD Diagnostic Codes When using VCCV, the control channel (CC) type and Connectivity Verification (CV) Type are agreed on between the peer PEs using Bitar, et al. Expires October 2012 [Page 9] Internet-Draft MPLS & Ethernet OAM Interworking April 2012 the OAM capability sub-TLV signaled as part of the interface parameter TLV when using FEC 129 and the interface parameter sub-TLV when using FEC 128. As defined in [RFC6310], when CV type of 0x04 0r 0x1 is used to indicate that BFD is used for PW fault detection only, PW defect is detected via the BFD session while other defects, such as AC defect or PE internal defects preventing it from forwarding traffic, are communicated via LDP Status notification message in MPLS and MPLS-IP PSNs or other mechanisms in L2TP-IP PSN. Similarly, when CV type of 0x08 or 0x20 is used to indicate that BFD is used for both PW fault detection and AC/PW Fault Notification, all defects are signaled via BFD. 4. Ethernet AC Defect States Entry or Exit Criteria 4.1. AC Receive Defect State Entry or Exit PE1 enters the AC Receive Defect state if any of the following conditions is met: - It detects or is notified of a physical layer fault on the Ethernet interface. Ethernet link failure can be detected based on loss of signal (LoS) or via Ethernet Link OAM [802.3] critical link event notifications generated at an upstream node CE1 with "Dying Gasp" or "Critical Event" indication. - A MEP associated with the local AC receives an Ethernet AIS frame. - A MEP associated with the local AC does not receive CCM frames from the peer MEP in the client domain (e.g. CE1) within an interval equal to 3.5 times the CCM transmission period configured for the MEP. This is the case when CCM transmission is enabled. - A CCM with interface status TLV indicating interface down. Other CCM interface status TLVs will not be used to indicate failure or recovery from failure. Bitar, et al. Expires October 2012 [Page 10] Internet-Draft MPLS & Ethernet OAM Interworking April 2012 PE1 exits the AC Receive Defect state if all of the conditions that resulted in entering the defect state are cleared. This includes all of the following conditions: - Any physical layer fault on the Ethernet interface, if detected or notified previously is renoved (e.g., loss of signal (LoS) cleared, or Ethernet Link OAM [802.3] critical link event notifications with "Dying Gasp" or "Critical Event" indication cleared at an upstream node CE1). - A MEP associated with the local AC does not receive any Ethernet AIS frame within a period indicated by previously received AIS, if AIS resulted in entering the defect state. - A MEP associated with the local AC and configured with CCM enabled receives a configured number (e.g., 3 or more) of consecutive CCM frames from the peer MEP on CE1 within an interval equal to a multiple (3.5) of the CCM transmission period configured for the MEP. - CCM indicates interface status up. 4.2. AC Transmit Defect State Entry or Exit PE1 enters the AC Transmit Defect state if any of the following conditions is met: - It detects or is notified of a physical layer fault on the Ethernet interface (e.g., via loss of signal (LoS) or Ethernet Link OAM [802.3] critical link event notifications generated at an upstream node CE1 with "Link Fault" indication). - A MEP configured with CCM transmission enabled and associated with the local AC receives a CCM frame, with its RDI bit set, from the peer MEP in the client domain (e.g., CE1). PE1 exits the AC Transmit Defect state if all of the conditions that resulted in entering the defect state are cleared. This includes all of the following conditions: Bitar, et al. Expires October 2012 [Page 11] Internet-Draft MPLS & Ethernet OAM Interworking April 2012 - Any physical layer fault on the Ethernet interface, if detected or notified previously is removed (e.g., LOS cleared, Ethernet Link OAM [802.3] critical link event notifications with "Link Fault" indication cleared at an upstream node CE1). - A MEP configured with CCM transmission enabled and associated with the local AC does not receive a CCM frame with RDI bit set, having received a previous CCM frame with RDI bit set from the peer MEP in the client domain (e.g. CE1). 5. Ethernet AC and PW Defect States Interworking 5.1. PW Receive Defect Entry Procedures When the PW status on PE1 transitions from working to PW Receive Defect state, PE1's ability to receive user traffic from CE2 is impacted. As a result, PE1 needs to notify CE1 about this problem. Upon entry to the PW Receive Defect state, the following must be done: - If PE1 is configured with a down MEP associated with the local AC and CCM transmission is not enabled, the MEP associated with the AC must transmit AIS frames periodically to the peer MEP in the client domain (e.g., on CE1) based on configured AIS transmission period. - If PE1 is configured with a down MEP associated with the local AC and CCM transmission is enabled, and the MEP associated with the AC is configured to support Interface Status TLV in CCM messages, the MEP associated with the AC must transmit CCM frames with Interface Status TLV as being down to the peer MEP in the client domain (e.g., on CE1). - If PE1 is configured with a down MEP associated with the local AC and CCM transmission is enabled, and the MEP associated with the AC is configured to not support Interface Status TLV in CCM messages, the MEP associated with the AC must stop transmitting CCM frames to the peer MEP in the client Bitar, et al. Expires October 2012 [Page 12] Internet-Draft MPLS & Ethernet OAM Interworking April 2012 domain (e.g., on CE1). - If PE1 is configured to run E-LMI [MEF16] with CE1 and if E-LMI is used for failure notification, PE1 must transmit E-LMI asynchronous STATUS message with report type Single EVC Asynchronous Status indicating that PW is Not Active. Further, when PE1 enters the Receive Defect state, it must assume that PE2 has no knowledge of the defect and must send reverse defect failure notification to PE2. For MPLS PSN or MPLS-IP PSN, this is done via either a PW Status notification message indicating a reverse defect; or via VCCV-BFD diagnostic code of reverse defect if VCCV CV type of 0x08 had been negotiated. When Native Service OAM mechanism is supported on PE1, it can also use the NS OAM notification as specified in Section 3.1. If PW receive defect is entered as a result of a forward defect notification from PE2 or via loss of control adjacency, no additional action is needed since PE2 is expected to be aware of the defect. 5.2. PW Receive Defect Exit Procedures When the PW status transitions from PW Receive Defect state to working, PE1's ability to receive user traffic from CE2 is restored. As a result, PE1 needs to cease defect notification to CE1 by performing the following: - If PE1 is configured with a down MEP associated with the local AC and CCM transmission is not enabled, the MEP associated with the AC must stop transmitting AIS frames towards the peer MEP in the client domain (e.g., on CE1). - If PE1 is configured with a down MEP associated with the local AC and CCM transmission is enabled, and the MEP associated with the AC is configured to support Interface Status TLV in CCM messages, the MEP associated with the AC must transmit CCM frames with Interface Status TLV as being Up to the peer MEP in the client domain (e.g., on CE1). Bitar, et al. Expires October 2012 [Page 13] Internet-Draft MPLS & Internet-Draft Opus Ambisonics May 2018 The remaining channel mapping families (2...254) are reserved. A demuxer implementation encountering a 'channel mapping family' value that it does not recognize SHOULD NOT attempt to decode the packets and SHOULD NOT use any information except for the first 19 octets of the ID header packet (Fig. 2) and the comment header (Fig. 10). 6. Experimental Mapping Families To make development of new mapping families easier while reducing the risk of creating compatibility issues with non-final version of mapping families, mapping families 240 through 254 (inclusively) are now reserved for experiments and implementations of in-development families. Implementers SHOULD attempt to use experimental family numbers that have not recently been used and SHOULD advertise what experimental numbers they use (e.g. for Internet-Drafts). The ambisonics mapping experiments that led to this document used experimental family 254 for family 2 and experimental family 253 for family 3. 7. Security Considerations Implementations of the Ogg container need take appropriate security considerations into account, as outlined in Section 10 of [RFC7845]. The extension defined in this document requires that semantic meaning be assigned to more channels than the existing Ogg format requires. Since more allocations will be required to encode and decode these semantically meaningful channels, care should be taken in any new allocation paths. Implementations MUST NOT overrun their allocated memory nor read from uninitialized memory when managing the ambisonic channel mapping. 8. IANA Considerations This document updates the IANA Media Types registry "Opus Channel Mapping Families" to add 17 new assignments. +---------+---------------------------+ | Value | Reference | +---------+---------------------------+ | 2 | This Document Section 3.1 | | | | | 3 | This Document Section 3.2 | | | | | 240-254 | This Document Section 6 | +---------+---------------------------+ Skoglund & Graczyk Expires November 2, 2018 [Page 8] Internet-Draft Opus Ambisonics May 2018 9. Acknowledgments Thanks to Timothy Terriberry, Jean-Marc Valin, Mark Harris, Marcin Gorzel, and Andrew Allen for their guidance and valuable contributions to this document. 10. References 10.1. Normative References [ambix] Nachbar, C., Zotter, F., Deleflie, E., and A. Sontacchi, "AMBIX - A SUGGESTED AMBISONICS FORMAT", June 2011, <http://iem.kug.ac.at/fileadmin/media/iem/projects/2011/ ambisonics11_nachbar_zotter_sontacchi_deleflie.pdf>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, <http://www.rfc-editor.org/info/rfc6716>. [RFC7845] Terriberry, T., Lee, R., and R. Giles, "Ogg Encapsulation for the Opus Audio Codec", RFC 7845, DOI 10.17487/RFC7845, April 2016, <http://www.rfc-editor.org/info/rfc7845>. 10.2. Informative References [daniel04] Daniel, J. and S. Moreau, "Further Study of Sound Field Coding with Higher Order Ambisonics", May 2004, <http://pcfarina.eng.unipr.it/Public/phd-thesis/ aes116%20high-passed%20hoa.pdf>. [gerzon75] Gerzon, M., "Ambisonics. Part one: General system description", August 1975, <http://www.michaelgerzonphotos.org.uk/articles/ Ambisonics%201.pdf>. Authors' Addresses Skoglund & Graczyk Expires November 2, 2018 [Page 9] Internet-Draft Opus Ambisonics May 2018 Jan Skoglund Google Inc. 345 Spear Street San Francisco, CA 94105 USA Email: jks@google.com Michael Graczyk Email: michael@graczyk.com Skoglund & Graczyk Expires November 2, 2018 [Page 10]