idnits 2.17.1 draft-ietf-codec-ambisonics-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 113 has weird spacing: '... order n = ...' == Line 114 has weird spacing: '... degree m = k...' -- The document date (July 19, 2016) is 2831 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 codec M. Graczyk 3 Internet-Draft Google Inc. 4 Intended status: Standards Track July 19, 2016 5 Expires: January 20, 2017 7 Ambisonics in an Ogg Opus Container 8 draft-ietf-codec-ambisonics-00 10 Abstract 12 This document defines an extension to the Ogg format to encapsulate 13 ambisonics coded using the Opus audio codec. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 20, 2017. 32 Copyright Notice 34 Copyright (c) 2016 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. Ambisonics With Ogg Opus . . . . . . . . . . . . . . . . . . 3 52 3.1. Channel Mapping Family 2 . . . . . . . . . . . . . . . . 3 53 3.2. Downmixing . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 59 7.2. Informative References . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 Ambisonics is a representation format for three dimensional sound 65 fields which can be used for surround sound and immersive virtual 66 reality playback. See [gerzon75] and [daniel04] for technical 67 details on the ambisonics format. For the purposes of the this 68 document, ambisonics can be considered a multichannel audio stream. 69 Ogg is a general purpose container, supporting audio, video, and 70 other media. It can be used to encapsulate audio streams coded using 71 the Opus codec. See [RFC6716] and [RFC7845] for technical details on 72 the Opus codec and its encapsulation in the Ogg container 73 respectively. 75 This document extends the Ogg format by defining a new channel 76 mapping family for encoding ambisonics. The Ogg Opus format is 77 extended indirectly by adding an item with value 2 to the IANA "Opus 78 Channel Mapping Families" registry. When 2 is used as the Channel 79 Mapping Family Number in an Ogg stream, the semantic meaning of the 80 channels in the multichannel Opus stream is the ambisonics layout 81 defined in this document. This mapping can also be used in other 82 contexts which make use of the channel mappings defined by the Opus 83 Channel Mapping Families registry. 85 2. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described in 90 [RFC2119]. 92 3. Ambisonics With Ogg Opus 94 Ambisonics MAY be encapsulated in the Ogg format by encoding with the 95 Opus codec and setting the Channel Mapping Family value to 2 in the 96 Ogg Identification Header. A demuxer implmentation encountering 97 Channel Mapping Family 2 MUST interpret the Opus stream as containing 98 ambisonics with the format described in Section 3.1. 100 3.1. Channel Mapping Family 2 102 Allowed numbers of channels: (1 + n)^2 for n = 0...14. Explicitly 1, 103 4, 9, 16, 25, 36, 49, 64, 81, 100, 121, 144, 169, 196, 225. 104 Periphonic ambisonics from zeroth to fourteenth order. 106 This channel mapping uses the same channel mapping table format used 107 by channel mapping families 1 and 255. Each output channel is 108 assigned to an ambisonic component in Ambisonic Channel Number (ACN) 109 order. The ambisonic component with order n and degree m corresponds 110 to channel (n * (n + 1) + m). The reverse correspondence can also be 111 computed for a channel with index k. 113 order n = ceil(sqrt(k)) - 1, 114 degree m = k - n * (n + 1). 116 Channels are normalized with Schmidt Semi-Normalization (SN3D). The 117 interpretation of the ambisonics signal as well as detailed 118 definitions of ACN channel ordering and SN3D normalization are 119 described in [ambix] Section 2.1. 121 3.2. Downmixing 123 An Ogg Opus player MAY use the matrix in Figure 1 to implement 124 downmixing from multichannel files using Channel Mapping Family 2 125 Section 3.1, which is known to give acceptable results for stereo. 126 The first and second ambisonic channels are known as "W" and "Y" 127 respectively. 129 / \ / \ / W \ 130 | L | | 0.5 0.5 0.0 ... | | Y | 131 | R | = | 0.5 -0.5 0.0 ... | | ... | 132 \ / \ / \ ... / 134 Figure 1: Stereo Downmixing Matrix 136 The first ambisonic channel (W) is a mono audio stream which 137 represents the average audio signal over all directions. Since W is 138 not directional, Ogg Opus players MAY use W directly for mono 139 playback. 141 4. Security Considerations 143 Implementations of the Ogg container need take appropriate security 144 considerations into account, as outlined in Section 10 of [RFC7845]. 145 The extension defined in this document requires that semantic meaning 146 be assigned to more channels than the existing Ogg format requires. 147 Since more allocations will be required to encode and decode these 148 semantically meaningful channels, care should be taken in any new 149 allocation paths. Implementations MUST NOT overrun their allocated 150 memory nor read from uninitialized memory when managing the ambisonic 151 channel mapping. 153 5. IANA Considerations 155 This document updates the IANA Media Types registry "Opus Channel 156 Mapping Families" to add a new assignment. 158 +-------+---------------------------+ 159 | Value | Reference | 160 +-------+---------------------------+ 161 | 2 | This Document Section 3.1 | 162 +-------+---------------------------+ 164 6. Acknowledgments 166 Thanks to Timothy Terriberry and Marcin Gorzel for their guidance and 167 valuable contributions to this document. 169 7. References 171 7.1. Normative References 173 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 174 Requirement Levels", BCP 14, RFC 2119, 175 DOI 10.17487/RFC2119, March 1997, 176 . 178 [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the 179 Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, 180 September 2012, . 182 [RFC7845] Terriberry, T., Lee, R., and R. Giles, "Ogg Encapsulation 183 for the Opus Audio Codec", RFC 7845, DOI 10.17487/RFC7845, 184 April 2016, . 186 [ambix] Nachbar, C., Zotter, F., Deleflie, E., and A. Sontacchi, 187 "AMBIX - A SUGGESTED AMBISONICS FORMAT", June 2011, 188 . 191 7.2. Informative References 193 [gerzon75] 194 Gerzon, M., "Ambisonics. Part one: General system 195 description", August 1975, 196 . 199 [daniel04] 200 Daniel, J. and S. Moreau, "Further Study of Sound Field 201 Coding with Higher Order Ambisonics", May 2004, 202 . 205 Author's Address 207 Michael Graczyk 208 Google Inc. 209 1600 Amphitheatre Parkway 210 Mountain View, CA 94043 211 USA 213 Email: mgraczyk@google.com