Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1 | <?xml version="1.0" encoding="utf-8"?> |
Timothy B. Terriberry | 50f214c | 2012-11-03 13:01:25 -0700 | [diff] [blame] | 2 | <!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [ |
Ralph Giles | 24aa867 | 2014-01-20 13:39:24 -0800 | [diff] [blame] | 3 | <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> |
| 4 | <!ENTITY rfc3533 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3533.xml'> |
| 5 | <!ENTITY rfc3629 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml'> |
| 6 | <!ENTITY rfc4732 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4732.xml'> |
| 7 | <!ENTITY rfc5334 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5334.xml'> |
| 8 | <!ENTITY rfc6381 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6381.xml'> |
| 9 | <!ENTITY rfc6716 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6716.xml'> |
Ralph Giles | 5742f10 | 2014-01-20 13:40:36 -0800 | [diff] [blame] | 10 | <!ENTITY rfc6982 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6982.xml'> |
Timothy B. Terriberry | 50f214c | 2012-11-03 13:01:25 -0700 | [diff] [blame] | 11 | ]> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 12 | <?rfc toc="yes" symrefs="yes" ?> |
| 13 | |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 14 | <rfc ipr="trust200902" category="std" docName="draft-ietf-codec-oggopus-03"> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 15 | |
| 16 | <front> |
| 17 | <title abbrev="Ogg Opus">Ogg Encapsulation for the Opus Audio Codec</title> |
| 18 | <author initials="T.B." surname="Terriberry" fullname="Timothy B. Terriberry"> |
| 19 | <organization>Mozilla Corporation</organization> |
| 20 | <address> |
| 21 | <postal> |
| 22 | <street>650 Castro Street</street> |
| 23 | <city>Mountain View</city> |
| 24 | <region>CA</region> |
| 25 | <code>94041</code> |
| 26 | <country>USA</country> |
| 27 | </postal> |
| 28 | <phone>+1 650 903-0800</phone> |
| 29 | <email>tterribe@xiph.org</email> |
| 30 | </address> |
| 31 | </author> |
| 32 | |
| 33 | <author initials="R." surname="Lee" fullname="Ron Lee"> |
| 34 | <organization>Voicetronix</organization> |
| 35 | <address> |
| 36 | <postal> |
| 37 | <street>246 Pulteney Street, Level 1</street> |
| 38 | <city>Adelaide</city> |
| 39 | <region>SA</region> |
| 40 | <code>5000</code> |
| 41 | <country>Australia</country> |
| 42 | </postal> |
| 43 | <phone>+61 8 8232 9112</phone> |
| 44 | <email>ron@debian.org</email> |
| 45 | </address> |
| 46 | </author> |
| 47 | |
Ralph Giles | 1935025 | 2012-07-16 11:41:27 -0400 | [diff] [blame] | 48 | <author initials="R." surname="Giles" fullname="Ralph Giles"> |
| 49 | <organization>Mozilla Corporation</organization> |
| 50 | <address> |
| 51 | <postal> |
| 52 | <street>163 West Hastings Street</street> |
| 53 | <city>Vancouver</city> |
| 54 | <region>BC</region> |
| 55 | <code>V6B 1H5</code> |
| 56 | <country>Canada</country> |
| 57 | </postal> |
Ralph Giles | 0f9c404 | 2014-01-17 11:15:34 -0800 | [diff] [blame] | 58 | <phone>+1 778 785 1540</phone> |
Ralph Giles | 1935025 | 2012-07-16 11:41:27 -0400 | [diff] [blame] | 59 | <email>giles@xiph.org</email> |
| 60 | </address> |
| 61 | </author> |
| 62 | |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 63 | <date day="7" month="February" year="2014"/> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 64 | <area>RAI</area> |
| 65 | <workgroup>codec</workgroup> |
| 66 | |
| 67 | <abstract> |
| 68 | <t> |
| 69 | This document defines the Ogg encapsulation for the Opus interactive speech and |
| 70 | audio codec. |
| 71 | This allows data encoded in the Opus format to be stored in an Ogg logical |
| 72 | bitstream. |
Ralph Giles | e515687 | 2012-07-06 12:17:23 -0700 | [diff] [blame] | 73 | Ogg encapsulation provides Opus with a long-term storage format supporting |
| 74 | all of the essential features, including metadata, fast and accurate seeking, |
| 75 | corruption detection, recapture after errors, low overhead, and the ability to |
| 76 | multiplex Opus with other codecs (including video) with minimal buffering. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 77 | It also provides a live streamable format, capable of delivery over a reliable |
| 78 | stream-oriented transport, without requiring all the data, or even the total |
| 79 | length of the data, up-front, in a form that is identical to the on-disk |
| 80 | storage format. |
| 81 | </t> |
| 82 | </abstract> |
| 83 | </front> |
| 84 | |
| 85 | <middle> |
| 86 | <section anchor="intro" title="Introduction"> |
| 87 | <t> |
| 88 | The IETF Opus codec is a low-latency audio codec optimized for both voice and |
| 89 | general-purpose audio. |
Timothy B. Terriberry | 50f214c | 2012-11-03 13:01:25 -0700 | [diff] [blame] | 90 | See <xref target="RFC6716"/> for technical details. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 91 | This document defines the encapsulation of Opus in a continuous, logical Ogg |
| 92 | bitstream <xref target="RFC3533"/>. |
| 93 | </t> |
| 94 | <t> |
| 95 | Ogg bitstreams are made up of a series of 'pages', each of which contains data |
| 96 | from one or more 'packets'. |
| 97 | Pages are the fundamental unit of multiplexing in an Ogg stream. |
| 98 | Each page is associated with a particular logical stream and contains a capture |
| 99 | pattern and checksum, flags to mark the beginning and end of the logical |
| 100 | stream, and a 'granule position' that represents an absolute position in the |
| 101 | stream, to aid seeking. |
| 102 | A single page can contain up to 65,025 octets of packet data from up to 255 |
| 103 | different packets. |
| 104 | Packets may be split arbitrarily across pages, and continued from one page to |
| 105 | the next (allowing packets much larger than would fit on a single page). |
| 106 | Each page contains 'lacing values' that indicate how the data is partitioned |
| 107 | into packets, allowing a demuxer to recover the packet boundaries without |
| 108 | examining the encoded data. |
| 109 | A packet is said to 'complete' on a page when the page contains the final |
| 110 | lacing value corresponding to that packet. |
| 111 | </t> |
| 112 | <t> |
| 113 | This encapsulation defines the required contents of the packet data, including |
| 114 | the necessary headers, the organization of those packets into a logical |
| 115 | stream, and the interpretation of the codec-specific granule position field. |
| 116 | It does not attempt to describe or specify the existing Ogg container format. |
| 117 | Readers unfamiliar with the basic concepts mentioned above are encouraged to |
| 118 | review the details in <xref target="RFC3533"/>. |
| 119 | </t> |
| 120 | |
| 121 | </section> |
| 122 | |
| 123 | <section anchor="terminology" title="Terminology"> |
| 124 | <t> |
| 125 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", |
Ralph Giles | 728938a | 2014-01-20 12:47:32 -0800 | [diff] [blame] | 126 | "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this |
| 127 | document are to be interpreted as described in <xref target="RFC2119"/>. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 128 | </t> |
| 129 | |
| 130 | <t> |
| 131 | Implementations that fail to satisfy one or more "MUST" requirements are |
| 132 | considered non-compliant. |
| 133 | Implementations that satisfy all "MUST" requirements, but fail to satisfy one |
| 134 | or more "SHOULD" requirements are said to be "conditionally compliant". |
| 135 | All other implementations are "unconditionally compliant". |
| 136 | </t> |
| 137 | |
| 138 | </section> |
| 139 | |
| 140 | <section anchor="packet_organization" title="Packet Organization"> |
| 141 | <t> |
| 142 | An Opus stream is organized as follows. |
| 143 | </t> |
| 144 | <t> |
| 145 | There are two mandatory header packets. |
| 146 | The granule position of the pages on which these packets complete MUST be zero. |
| 147 | </t> |
| 148 | <t> |
| 149 | The first packet in the logical Ogg bitstream MUST contain the identification |
| 150 | (ID) header, which uniquely identifies a stream as Opus audio. |
| 151 | The format of this header is defined in <xref target="id_header"/>. |
| 152 | It MUST be placed alone (without any other packet data) on the first page of |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 153 | the logical Ogg bitstream, and must complete on that page. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 154 | This page MUST have its 'beginning of stream' flag set. |
| 155 | </t> |
| 156 | <t> |
| 157 | The second packet in the logical Ogg bitstream MUST contain the comment header, |
| 158 | which contains user-supplied metadata. |
| 159 | The format of this header is defined in <xref target="comment_header"/>. |
| 160 | It MAY span one or more pages, beginning on the second page of the logical |
| 161 | stream. |
| 162 | However many pages it spans, the comment header packet MUST finish the page on |
| 163 | which it completes. |
| 164 | </t> |
| 165 | <t> |
Ralph Giles | 19658bd | 2012-07-16 12:34:04 -0400 | [diff] [blame] | 166 | All subsequent pages are audio data pages, and the Ogg packets they contain are |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 167 | audio data packets. |
| 168 | Each audio data packet contains one Opus packet for each of N different |
| 169 | streams, where N is typically one for mono or stereo, but may be greater than |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 170 | one for multichannel audio. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 171 | The value N is specified in the ID header (see |
| 172 | <xref target="channel_mapping"/>), and is fixed over the entire length of the |
| 173 | logical Ogg bitstream. |
| 174 | </t> |
| 175 | <t> |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 176 | The first N-1 Opus packets, if any, are packed one after another into the Ogg |
| 177 | packet, using the self-delimiting framing from Appendix B of |
Timothy B. Terriberry | 50f214c | 2012-11-03 13:01:25 -0700 | [diff] [blame] | 178 | <xref target="RFC6716"/>. |
Ralph Giles | 360a411 | 2012-07-16 13:53:29 -0400 | [diff] [blame] | 179 | The remaining Opus packet is packed at the end of the Ogg packet using the |
Timothy B. Terriberry | 50f214c | 2012-11-03 13:01:25 -0700 | [diff] [blame] | 180 | regular, undelimited framing from Section 3 of <xref target="RFC6716"/>. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 181 | All of the Opus packets in a single Ogg packet MUST be constrained to have the |
| 182 | same duration. |
| 183 | A decoder SHOULD treat any Opus packet whose duration is different from that of |
| 184 | the first Opus packet in an Ogg packet as if it were an Opus packet with an |
| 185 | illegal TOC sequence. |
| 186 | </t> |
| 187 | <t> |
Ron | e37262c | 2014-01-19 15:20:05 +1030 | [diff] [blame] | 188 | The coding mode (SILK, Hybrid, or CELT), audio bandwidth, channel count, |
| 189 | duration (frame size), and number of frames per packet, are indicated in the |
| 190 | TOC (table of contents) in the first byte of each Opus packet, as described |
Ron | deb46d1 | 2014-01-19 15:52:31 +1030 | [diff] [blame] | 191 | in Section 3.1 of <xref target="RFC6716"/>. |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 192 | The combination of mode, audio bandwidth, and frame size is referred to as |
Ron | e37262c | 2014-01-19 15:20:05 +1030 | [diff] [blame] | 193 | the configuration of an Opus packet. |
| 194 | </t> |
| 195 | <t> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 196 | The first audio data page SHOULD NOT have the 'continued packet' flag set |
Timothy B. Terriberry | ad333d0 | 2012-08-24 11:54:38 -0700 | [diff] [blame] | 197 | (which would indicate the first audio data packet is continued from a previous |
| 198 | page). |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 199 | Packets MUST be placed into Ogg pages in order until the end of stream. |
| 200 | Audio packets MAY span page boundaries. |
| 201 | A decoder MUST treat a zero-octet audio data packet as if it were an Opus |
| 202 | packet with an illegal TOC sequence. |
| 203 | The last page SHOULD have the 'end of stream' flag set, but implementations |
| 204 | should be prepared to deal with truncated streams that do not have a page |
| 205 | marked 'end of stream'. |
| 206 | The final packet on the last page SHOULD NOT be a continued packet, i.e., the |
| 207 | final lacing value should be less than 255. |
| 208 | There MUST NOT be any more pages in an Opus logical bitstream after a page |
| 209 | marked 'end of stream'. |
| 210 | </t> |
| 211 | </section> |
| 212 | |
| 213 | <section anchor="granpos" title="Granule Position"> |
| 214 | <t> |
| 215 | The granule position of an audio data page encodes the total number of PCM |
| 216 | samples in the stream up to and including the last fully-decodable sample from |
| 217 | the last packet completed on that page. |
| 218 | A page that is entirely spanned by a single packet (that completes on a |
| 219 | subsequent page) has no granule position, and the granule position field MUST |
| 220 | be set to the special value '-1' in two's complement. |
| 221 | </t> |
| 222 | |
| 223 | <t> |
| 224 | The granule position of an audio data page is in units of PCM audio samples at |
| 225 | a fixed rate of 48 kHz (per channel; a stereo stream's granule position |
| 226 | does not increment at twice the speed of a mono stream). |
| 227 | It is possible to run an Opus decoder at other sampling rates, but the value |
| 228 | in the granule position field always counts samples assuming a 48 kHz |
| 229 | decoding rate, and the rest of this specification makes the same assumption. |
| 230 | </t> |
| 231 | |
| 232 | <t> |
| 233 | The duration of an Opus packet may be any multiple of 2.5 ms, up to a |
| 234 | maximum of 120 ms. |
| 235 | This duration is encoded in the TOC sequence at the beginning of each packet. |
| 236 | The number of samples returned by a decoder corresponds to this duration |
| 237 | exactly, even for the first few packets. |
| 238 | For example, a 20 ms packet fed to a decoder running at 48 kHz will |
| 239 | always return 960 samples. |
| 240 | A demuxer can parse the TOC sequence at the beginning of each Ogg packet to |
| 241 | work backwards or forwards from a packet with a known granule position (i.e., |
| 242 | the last packet completed on some page) in order to assign granule positions |
| 243 | to every packet, or even every individual sample. |
| 244 | The one exception is the last page in the stream, as described below. |
| 245 | </t> |
| 246 | |
| 247 | <t> |
| 248 | All other pages with completed packets after the first MUST have a granule |
| 249 | position equal to the number of samples contained in packets that complete on |
| 250 | that page plus the granule position of the most recent page with completed |
| 251 | packets. |
| 252 | This guarantees that a demuxer can assign individual packets the same granule |
| 253 | position when working forwards as when working backwards. |
| 254 | For this to work, there cannot be any gaps. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 255 | </t> |
| 256 | |
Ralph Giles | 998e9e0 | 2014-01-14 15:40:16 -0800 | [diff] [blame] | 257 | <section anchor="gap-repair" title="Repairing Gaps in Real-time Streams"> |
| 258 | <t> |
Ralph Giles | 1e0b6fd | 2014-01-14 17:23:00 -0800 | [diff] [blame] | 259 | In order to support capturing a real-time stream that has lost or not |
| 260 | transmitted packets, a muxer SHOULD emit packets that explicitly request the |
| 261 | use of Packet Loss Concealment (PLC) in place of the missing packets. |
Ralph Giles | 998e9e0 | 2014-01-14 15:40:16 -0800 | [diff] [blame] | 262 | Only gaps that are a multiple of 2.5 ms are repairable, as these are the |
Ralph Giles | 1e0b6fd | 2014-01-14 17:23:00 -0800 | [diff] [blame] | 263 | only durations that can be created by packet loss or discontinuous |
| 264 | transmission. |
Ralph Giles | 998e9e0 | 2014-01-14 15:40:16 -0800 | [diff] [blame] | 265 | Muxers need not handle other gap sizes. |
| 266 | Creating the necessary packets involves synthesizing a TOC byte (defined in |
Ralph Giles | 1e0b6fd | 2014-01-14 17:23:00 -0800 | [diff] [blame] | 267 | Section 3.1 of <xref target="RFC6716"/>)—and whatever |
| 268 | additional internal framing is needed—to indicate the packet duration |
| 269 | for each stream. |
Ralph Giles | 998e9e0 | 2014-01-14 15:40:16 -0800 | [diff] [blame] | 270 | The actual length of each missing Opus frame inside the packet is zero bytes, |
| 271 | as defined in Section 3.2.1 of <xref target="RFC6716"/>. |
| 272 | </t> |
| 273 | |
| 274 | <t> |
Ralph Giles | b30b2ba | 2014-01-17 15:22:57 -0800 | [diff] [blame] | 275 | Zero-byte frames MAY be packed into packets using any of codes 0, 1, |
| 276 | 2, or 3. |
| 277 | When successive frames have the same configuration, the higher code packings |
| 278 | reduce overhead. |
| 279 | Likewise, if the TOC configuration matches, the muxer MAY further combine the |
| 280 | empty frames with previous or subsequent non-zero-length frames (using |
| 281 | code 2 or VBR code 3). |
| 282 | </t> |
| 283 | |
| 284 | <t> |
Ralph Giles | 998e9e0 | 2014-01-14 15:40:16 -0800 | [diff] [blame] | 285 | <xref target="RFC6716"/> does not impose any requirements on the PLC, but this |
| 286 | section outlines choices that are expected to have a positive influence on |
| 287 | most PLC implementations, including the reference implementation. |
Ralph Giles | 3ba1bb0 | 2014-01-17 12:09:45 -0800 | [diff] [blame] | 288 | Synthesized TOC bytes SHOULD maintain the same mode, audio bandwidth, |
Ralph Giles | 1e0b6fd | 2014-01-14 17:23:00 -0800 | [diff] [blame] | 289 | channel count, and frame size as the previous packet (if any). |
Ralph Giles | 998e9e0 | 2014-01-14 15:40:16 -0800 | [diff] [blame] | 290 | This is the simplest and usually the most well-tested case for the PLC to |
Ralph Giles | 1e0b6fd | 2014-01-14 17:23:00 -0800 | [diff] [blame] | 291 | handle and it covers all losses that do not include a configuration switch, |
| 292 | as defined in Section 4.5 of <xref target="RFC6716"/>. |
Ralph Giles | 998e9e0 | 2014-01-14 15:40:16 -0800 | [diff] [blame] | 293 | </t> |
| 294 | |
| 295 | <t> |
| 296 | When a previous packet is available, keeping the audio bandwidth and channel |
| 297 | count the same allows the PLC to provide maximum continuity in the concealment |
| 298 | data it generates. |
| 299 | However, if the size of the gap is not a multiple of the most recent frame |
| 300 | size, then the frame size will have to change for at least some frames. |
Ralph Giles | 3ba1bb0 | 2014-01-17 12:09:45 -0800 | [diff] [blame] | 301 | Such changes SHOULD be delayed as long as possible to simplify |
| 302 | things for PLC implementations. |
Ralph Giles | 1e0b6fd | 2014-01-14 17:23:00 -0800 | [diff] [blame] | 303 | </t> |
| 304 | |
| 305 | <t> |
| 306 | As an example, a 95 ms gap could be encoded as nineteen 5 ms frames |
| 307 | in two bytes with a single CBR code 3 packet. |
| 308 | If the previous frame size was 20 ms, using four 20 ms frames |
Ralph Giles | 998e9e0 | 2014-01-14 15:40:16 -0800 | [diff] [blame] | 309 | followed by three 5 ms frames requires 4 bytes (plus an extra byte |
| 310 | of Ogg lacing overhead), but allows the PLC to use its well-tested steady |
| 311 | state behavior for as long as possible. |
| 312 | The total bitrate of the latter approach, including Ogg overhead, is about |
| 313 | 0.4 kbps, so the impact on file size is minimal. |
| 314 | </t> |
| 315 | |
| 316 | <t> |
| 317 | Changing modes is discouraged, since this causes some decoder implementations |
| 318 | to reset their PLC state. |
Ralph Giles | 3ba1bb0 | 2014-01-17 12:09:45 -0800 | [diff] [blame] | 319 | However, SILK and Hybrid mode frames cannot fill gaps that are not a multiple |
| 320 | of 10 ms. |
| 321 | If switching to CELT mode is needed to match the gap size, a muxer SHOULD do |
| 322 | so at the end of the gap to allow the PLC to function for as long as possible. |
| 323 | </t> |
| 324 | |
| 325 | <t> |
| 326 | In the example above, if the previous frame was a 20 ms SILK mode frame, |
| 327 | the better solution is to synthesize a packet describing four 20 ms SILK |
| 328 | frames, followed by a packet with a single 10 ms SILK |
Ralph Giles | 1e0b6fd | 2014-01-14 17:23:00 -0800 | [diff] [blame] | 329 | frame, and finally a packet with a 5 ms CELT frame, to fill the 95 ms |
| 330 | gap. |
| 331 | This also requires four bytes to describe the synthesized packet data (two |
Ralph Giles | 3ba1bb0 | 2014-01-17 12:09:45 -0800 | [diff] [blame] | 332 | bytes for a CBR code 3 and one byte each for two code 0 packets) but three |
| 333 | bytes of Ogg lacing overhead are required to mark the packet boundaries. |
| 334 | At 0.6 kbps, this is still a minimal bitrate impact over a naive, low quality |
Ralph Giles | 1e0b6fd | 2014-01-14 17:23:00 -0800 | [diff] [blame] | 335 | solution. |
| 336 | </t> |
| 337 | |
| 338 | <t> |
Ron | e37262c | 2014-01-19 15:20:05 +1030 | [diff] [blame] | 339 | Since medium-band audio is an option only in the SILK mode, wideband frames |
Ron | b331167 | 2014-01-19 16:03:44 +1030 | [diff] [blame] | 340 | SHOULD be generated if switching from that configuration to CELT mode, to |
| 341 | ensure that any PLC implementation which does try to migrate state between |
| 342 | the modes will be able to preserve all of the available audio bandwidth. |
Ralph Giles | 998e9e0 | 2014-01-14 15:40:16 -0800 | [diff] [blame] | 343 | </t> |
| 344 | |
Ralph Giles | 998e9e0 | 2014-01-14 15:40:16 -0800 | [diff] [blame] | 345 | </section> |
| 346 | |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 347 | <section anchor="preskip" title="Pre-skip"> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 348 | <t> |
| 349 | There is some amount of latency introduced during the decoding process, to |
Ron | e37262c | 2014-01-19 15:20:05 +1030 | [diff] [blame] | 350 | allow for overlap in the CELT mode, stereo mixing in the SILK mode, and |
| 351 | resampling. |
Ralph Giles | bb68e11 | 2014-08-08 13:22:18 -0700 | [diff] [blame] | 352 | The encoder may introduce additional latency through its own resampling |
| 353 | and analysis (though the exact amount is not specified). |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 354 | Therefore, the first few samples produced by the decoder do not correspond to |
| 355 | real input audio, but are instead composed of padding inserted by the encoder |
| 356 | to compensate for this latency. |
| 357 | These samples need to be stored and decoded, as Opus is an asymptotically |
| 358 | convergent predictive codec, meaning the decoded contents of each frame depend |
| 359 | on the recent history of decoder inputs. |
| 360 | However, a decoder will want to skip these samples after decoding them. |
| 361 | </t> |
| 362 | |
| 363 | <t> |
| 364 | A 'pre-skip' field in the ID header (see <xref target="id_header"/>) signals |
Timothy B. Terriberry | dd2520c | 2012-11-19 15:01:01 -0800 | [diff] [blame] | 365 | the number of samples which SHOULD be skipped (decoded but discarded) at the |
Ralph Giles | 360a411 | 2012-07-16 13:53:29 -0400 | [diff] [blame] | 366 | beginning of the stream. |
Ralph Giles | bb68e11 | 2014-08-08 13:22:18 -0700 | [diff] [blame] | 367 | This amount MAY not be a multiple of 2.5 ms, MAY be smaller than a single |
| 368 | packet, or MAT span the contents of several packets. |
| 369 | These samples are not valid audio, and should not be played. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 370 | </t> |
Ralph Giles | bb68e11 | 2014-08-08 13:22:18 -0700 | [diff] [blame] | 371 | |
| 372 | <t> |
| 373 | For example, if the first Opus frame uses the CELT mode, it will always |
| 374 | produce 120 samples of windowed overlap-add data. |
| 375 | However, the overlap data is initially all zeros (since there is no prior |
| 376 | frame), meaning this cannot, in general, accurately represent the original |
| 377 | audio. |
| 378 | The SILK mode requires additional delay to account for its analysis and |
| 379 | resampling latency. |
| 380 | The encoder delays the original audio to avoid this problem. |
| 381 | </t> |
| 382 | |
| 383 | <t> |
| 384 | The pre-skip field MAY also be used to perform sample-accurate cropping of |
| 385 | already encoded streams. |
| 386 | In this case, a value of at least 3840 samples (80 ms) provides |
| 387 | sufficient history to the decoder that it will have converged |
| 388 | before the stream's output begins. |
| 389 | </t> |
| 390 | |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 391 | </section> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 392 | |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 393 | <section anchor="pcm_sample_position" title="PCM Sample Position"> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 394 | <t> |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 395 | <figure align="center"> |
| 396 | <preamble> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 397 | The PCM sample position is determined from the granule position using the |
| 398 | formula |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 399 | </preamble> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 400 | <artwork align="center"><![CDATA[ |
| 401 | 'PCM sample position' = 'granule position' - 'pre-skip' . |
| 402 | ]]></artwork> |
| 403 | </figure> |
| 404 | </t> |
| 405 | |
| 406 | <t> |
| 407 | For example, if the granule position of the first audio data page is 59,971, |
| 408 | and the pre-skip is 11,971, then the PCM sample position of the last decoded |
| 409 | sample from that page is 48,000. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 410 | <figure align="center"> |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 411 | <preamble> |
| 412 | This can be converted into a playback time using the formula |
| 413 | </preamble> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 414 | <artwork align="center"><![CDATA[ |
| 415 | 'PCM sample position' |
| 416 | 'playback time' = --------------------- . |
| 417 | 48000.0 |
| 418 | ]]></artwork> |
| 419 | </figure> |
| 420 | </t> |
| 421 | |
| 422 | <t> |
| 423 | The initial PCM sample position before any samples are played is normally '0'. |
| 424 | In this case, the PCM sample position of the first audio sample to be played |
| 425 | starts at '1', because it marks the time on the clock |
| 426 | <spanx style="emph">after</spanx> that sample has been played, and a stream |
| 427 | that is exactly one second long has a final PCM sample position of '48000', |
| 428 | as in the example here. |
| 429 | </t> |
| 430 | |
| 431 | <t> |
| 432 | Vorbis streams use a granule position smaller than the number of audio samples |
| 433 | contained in the first audio data page to indicate that some of those samples |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 434 | must be trimmed from the output (see <xref target="vorbis-trim"/>). |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 435 | However, to do so, Vorbis requires that the first audio data page contains |
| 436 | exactly two packets, in order to allow the decoder to perform PCM position |
| 437 | adjustments before needing to return any PCM data. |
| 438 | Opus uses the pre-skip mechanism for this purpose instead, since the encoder |
| 439 | may introduce more than a single packet's worth of latency, and since very |
Ralph Giles | b0794ba | 2012-07-16 17:37:54 -0400 | [diff] [blame] | 440 | large packets in streams with a very large number of channels might not fit |
| 441 | on a single page. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 442 | </t> |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 443 | </section> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 444 | |
Timothy B. Terriberry | 50f214c | 2012-11-03 13:01:25 -0700 | [diff] [blame] | 445 | <section anchor="end_trimming" title="End Trimming"> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 446 | <t> |
| 447 | The page with the 'end of stream' flag set MAY have a granule position that |
| 448 | indicates the page contains less audio data than would normally be returned by |
| 449 | decoding up through the final packet. |
| 450 | This is used to end the stream somewhere other than an even frame boundary. |
| 451 | The granule position of the most recent audio data page with completed packets |
| 452 | is used to make this determination, or '0' is used if there were no previous |
| 453 | audio data pages with a completed packet. |
| 454 | The difference between these granule positions indicates how many samples to |
| 455 | keep after decoding the packets that completed on the final page. |
| 456 | The remaining samples are discarded. |
| 457 | The number of discarded samples SHOULD be no larger than the number decoded |
| 458 | from the last packet. |
| 459 | </t> |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 460 | </section> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 461 | |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 462 | <section anchor="start_granpos_restrictions" |
| 463 | title="Restrictions on the Initial Granule Position"> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 464 | <t> |
| 465 | The granule position of the first audio data page with a completed packet MAY |
| 466 | be larger than the number of samples contained in packets that complete on |
| 467 | that page, however it MUST NOT be smaller, unless that page has the 'end of |
| 468 | stream' flag set. |
| 469 | Allowing a granule position larger than the number of samples allows the |
| 470 | beginning of a stream to be cropped or a live stream to be joined without |
| 471 | rewriting the granule position of all the remaining pages. |
| 472 | This means that the PCM sample position just before the first sample to be |
| 473 | played may be larger than '0'. |
| 474 | Synchronization when multiplexing with other logical streams still uses the PCM |
| 475 | sample position relative to '0' to compute sample times. |
| 476 | This does not affect the behavior of pre-skip: exactly 'pre-skip' samples |
| 477 | should be skipped from the beginning of the decoded output, even if the |
| 478 | initial PCM sample position is greater than zero. |
| 479 | </t> |
| 480 | |
| 481 | <t> |
| 482 | On the other hand, a granule position that is smaller than the number of |
| 483 | decoded samples prevents a demuxer from working backwards to assign each |
| 484 | packet or each individual sample a valid granule position, since granule |
| 485 | positions must be non-negative. |
| 486 | A decoder MUST reject as invalid any stream where the granule position is |
| 487 | smaller than the number of samples contained in packets that complete on the |
| 488 | first audio data page with a completed packet, unless that page has the 'end |
| 489 | of stream' flag set. |
| 490 | It MAY defer this action until it decodes the last packet completed on that |
| 491 | page. |
Timothy B. Terriberry | dd2520c | 2012-11-19 15:01:01 -0800 | [diff] [blame] | 492 | </t> |
| 493 | |
| 494 | <t> |
| 495 | If that page has the 'end of stream' flag set, a demuxer MUST reject as invalid |
| 496 | any stream where its granule position is smaller than the 'pre-skip' amount. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 497 | This would indicate that more samples should be skipped from the initial |
| 498 | decoded output than exist in the stream. |
Timothy B. Terriberry | dd2520c | 2012-11-19 15:01:01 -0800 | [diff] [blame] | 499 | If the granule position is smaller than the number of decoded samples produced |
| 500 | by the packets that complete on that page, then a demuxer MUST use an initial |
| 501 | granule position of '0', and can work forwards from '0' to timestamp |
| 502 | individual packets. |
| 503 | If the granule position is larger than the number of decoded samples available, |
| 504 | then the demuxer MUST still work backwards as described above, even if the |
| 505 | 'end of stream' flag is set, to determine the initial granule position, and |
| 506 | thus the initial PCM sample position. |
| 507 | Both of these will be greater than '0' in this case. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 508 | </t> |
| 509 | </section> |
| 510 | |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 511 | <section anchor="seeking_and_preroll" title="Seeking and Pre-roll"> |
| 512 | <t> |
| 513 | Seeking in Ogg files is best performed using a bisection search for a page |
| 514 | whose granule position corresponds to a PCM position at or before the seek |
| 515 | target. |
| 516 | With appropriately weighted bisection, accurate seeking can be performed with |
| 517 | just three or four bisections even in multi-gigabyte files. |
| 518 | See <xref target="seeking"/> for general implementation guidance. |
| 519 | </t> |
| 520 | |
| 521 | <t> |
| 522 | When seeking within an Ogg Opus stream, the decoder SHOULD start decoding (and |
| 523 | discarding the output) at least 3840 samples (80 ms) prior to the |
| 524 | seek target in order to ensure that the output audio is correct by the time it |
| 525 | reaches the seek target. |
| 526 | This 'pre-roll' is separate from, and unrelated to, the 'pre-skip' used at the |
| 527 | beginning of the stream. |
| 528 | If the point 80 ms prior to the seek target comes before the initial PCM |
| 529 | sample position, the decoder SHOULD start decoding from the beginning of the |
| 530 | stream, applying pre-skip as normal, regardless of whether the pre-skip is |
Timothy B. Terriberry | dd2520c | 2012-11-19 15:01:01 -0800 | [diff] [blame] | 531 | larger or smaller than 80 ms, and then continue to discard the samples |
| 532 | required to reach the seek target (if any). |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 533 | </t> |
| 534 | </section> |
| 535 | |
| 536 | </section> |
| 537 | |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 538 | <section anchor="headers" title="Header Packets"> |
| 539 | <t> |
Ralph Giles | 05bf400 | 2012-12-19 12:21:06 -0800 | [diff] [blame] | 540 | An Opus stream contains exactly two mandatory header packets: |
| 541 | an identification header and a comment header. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 542 | </t> |
| 543 | |
| 544 | <section anchor="id_header" title="Identification Header"> |
| 545 | |
| 546 | <figure anchor="id_header_packet" title="ID Header Packet" align="center"> |
| 547 | <artwork align="center"><![CDATA[ |
| 548 | 0 1 2 3 |
| 549 | 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 |
| 550 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 551 | | 'O' | 'p' | 'u' | 's' | |
| 552 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 553 | | 'H' | 'e' | 'a' | 'd' | |
| 554 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 555 | | Version = 1 | Channel Count | Pre-skip | |
| 556 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 557 | | Input Sample Rate (Hz) | |
| 558 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 559 | | Output Gain (Q7.8 in dB) | Mapping Family| | |
| 560 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : |
| 561 | | | |
| 562 | : Optional Channel Mapping Table... : |
| 563 | | | |
| 564 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 565 | ]]></artwork> |
| 566 | </figure> |
| 567 | |
| 568 | <t> |
| 569 | The fields in the identification (ID) header have the following meaning: |
| 570 | <list style="numbers"> |
| 571 | <t><spanx style="strong">Magic Signature</spanx>: |
| 572 | <vspace blankLines="1"/> |
| 573 | This is an 8-octet (64-bit) field that allows codec identification and is |
| 574 | human-readable. |
| 575 | It contains, in order, the magic numbers: |
| 576 | <list style="empty"> |
| 577 | <t>0x4F 'O'</t> |
| 578 | <t>0x70 'p'</t> |
| 579 | <t>0x75 'u'</t> |
| 580 | <t>0x73 's'</t> |
| 581 | <t>0x48 'H'</t> |
| 582 | <t>0x65 'e'</t> |
| 583 | <t>0x61 'a'</t> |
| 584 | <t>0x64 'd'</t> |
| 585 | </list> |
| 586 | Starting with "Op" helps distinguish it from audio data packets, as this is an |
| 587 | invalid TOC sequence. |
| 588 | <vspace blankLines="1"/> |
| 589 | </t> |
| 590 | <t><spanx style="strong">Version</spanx> (8 bits, unsigned): |
| 591 | <vspace blankLines="1"/> |
| 592 | The version number MUST always be '1' for this version of the encapsulation |
| 593 | specification. |
| 594 | Implementations SHOULD treat streams where the upper four bits of the version |
| 595 | number match that of a recognized specification as backwards-compatible with |
| 596 | that specification. |
| 597 | That is, the version number can be split into "major" and "minor" version |
| 598 | sub-fields, with changes to the "minor" sub-field (in the lower four bits) |
| 599 | signaling compatible changes. |
| 600 | For example, a decoder implementing this specification SHOULD accept any stream |
| 601 | with a version number of '15' or less, and SHOULD assume any stream with a |
| 602 | version number '16' or greater is incompatible. |
| 603 | The initial version '1' was chosen to keep implementations from relying on this |
| 604 | octet as a null terminator for the "OpusHead" string. |
| 605 | <vspace blankLines="1"/> |
| 606 | </t> |
| 607 | <t><spanx style="strong">Output Channel Count</spanx> 'C' (8 bits, unsigned): |
| 608 | <vspace blankLines="1"/> |
| 609 | This is the number of output channels. |
| 610 | This might be different than the number of encoded channels, which can change |
| 611 | on a packet-by-packet basis. |
| 612 | This value MUST NOT be zero. |
| 613 | The maximum allowable value depends on the channel mapping family, and might be |
| 614 | as large as 255. |
| 615 | See <xref target="channel_mapping"/> for details. |
| 616 | <vspace blankLines="1"/> |
| 617 | </t> |
| 618 | <t><spanx style="strong">Pre-skip</spanx> (16 bits, unsigned, little |
| 619 | endian): |
| 620 | <vspace blankLines="1"/> |
| 621 | This is the number of samples (at 48 kHz) to discard from the decoder |
| 622 | output when starting playback, and also the number to subtract from a page's |
| 623 | granule position to calculate its PCM sample position. |
Ralph Giles | 05bf400 | 2012-12-19 12:21:06 -0800 | [diff] [blame] | 624 | When cropping the beginning of existing Ogg Opus streams, a pre-skip of at |
| 625 | least 3,840 samples (80 ms) is RECOMMENDED to ensure complete |
| 626 | convergence in the decoder. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 627 | <vspace blankLines="1"/> |
| 628 | </t> |
| 629 | <t><spanx style="strong">Input Sample Rate</spanx> (32 bits, unsigned, little |
| 630 | endian): |
| 631 | <vspace blankLines="1"/> |
| 632 | This field is <spanx style="emph">not</spanx> the sample rate to use for |
| 633 | playback of the encoded data. |
| 634 | <vspace blankLines="1"/> |
Ron | e37262c | 2014-01-19 15:20:05 +1030 | [diff] [blame] | 635 | Opus can switch between internal audio bandwidths of 4, 6, 8, 12, and |
| 636 | 20 kHz. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 637 | Each packet in the stream may have a different audio bandwidth. |
| 638 | Regardless of the audio bandwidth, the reference decoder supports decoding any |
| 639 | stream at a sample rate of 8, 12, 16, 24, or 48 kHz. |
| 640 | The original sample rate of the encoder input is not preserved by the lossy |
| 641 | compression. |
| 642 | <vspace blankLines="1"/> |
| 643 | An Ogg Opus player SHOULD select the playback sample rate according to the |
| 644 | following procedure: |
| 645 | <list style="numbers"> |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 646 | <t>If the hardware supports 48 kHz playback, decode at 48 kHz.</t> |
| 647 | <t>Otherwise, if the hardware's highest available sample rate is a supported |
| 648 | rate, decode at this sample rate.</t> |
| 649 | <t>Otherwise, if the hardware's highest available sample rate is less than |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 650 | 48 kHz, decode at the next highest supported rate above this and |
| 651 | resample.</t> |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 652 | <t>Otherwise, decode at 48 kHz and resample.</t> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 653 | </list> |
| 654 | However, the 'Input Sample Rate' field allows the encoder to pass the sample |
| 655 | rate of the original input stream as metadata. |
| 656 | This may be useful when the user requires the output sample rate to match the |
| 657 | input sample rate. |
| 658 | For example, a non-player decoder writing PCM format samples to disk might |
| 659 | choose to resample the output audio back to the original input sample rate to |
| 660 | reduce surprise to the user, who might reasonably expect to get back a file |
| 661 | with the same sample rate as the one they fed to the encoder. |
| 662 | <vspace blankLines="1"/> |
| 663 | A value of zero indicates 'unspecified'. |
| 664 | Encoders SHOULD write the actual input sample rate or zero, but decoder |
| 665 | implementations which do something with this field SHOULD take care to behave |
| 666 | sanely if given crazy values (e.g., do not actually upsample the output to |
| 667 | 10 MHz if requested). |
| 668 | <vspace blankLines="1"/> |
| 669 | </t> |
| 670 | <t><spanx style="strong">Output Gain</spanx> (16 bits, signed, little |
| 671 | endian): |
| 672 | <vspace blankLines="1"/> |
| 673 | This is a gain to be applied by the decoder. |
| 674 | It is 20*log10 of the factor to scale the decoder output by to achieve the |
| 675 | desired playback volume, stored in a 16-bit, signed, two's complement |
| 676 | fixed-point value with 8 fractional bits (i.e., Q7.8). |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 677 | <figure align="center"> |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 678 | <preamble> |
| 679 | To apply the gain, a decoder could use |
| 680 | </preamble> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 681 | <artwork align="center"><![CDATA[ |
| 682 | sample *= pow(10, output_gain/(20.0*256)) , |
| 683 | ]]></artwork> |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 684 | <postamble> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 685 | where output_gain is the raw 16-bit value from the header. |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 686 | </postamble> |
| 687 | </figure> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 688 | <vspace blankLines="1"/> |
| 689 | Virtually all players and media frameworks should apply it by default. |
| 690 | If a player chooses to apply any volume adjustment or gain modification, such |
Ralph Giles | 64881ec | 2014-08-08 14:16:50 -0700 | [diff] [blame^] | 691 | as the R128_TRACK_GAIN, R128_ALBUM_GAIN (see <xref target="comment_header"/>) |
| 692 | or a user-facing volume knob, the adjustment MUST be applied in addition |
| 693 | to this output gain in order to achieve playback at the desired volume. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 694 | <vspace blankLines="1"/> |
| 695 | An encoder SHOULD set this field to zero, and instead apply any gain prior to |
| 696 | encoding, when this is possible and does not conflict with the user's wishes. |
| 697 | The output gain should only be nonzero when the gain is adjusted after |
| 698 | encoding, or when the user wishes to adjust the gain for playback while |
| 699 | preserving the ability to recover the original signal amplitude. |
| 700 | <vspace blankLines="1"/> |
| 701 | Although the output gain has enormous range (+/- 128 dB, enough to amplify |
| 702 | inaudible sounds to the threshold of physical pain), most applications can |
| 703 | only reasonably use a small portion of this range around zero. |
| 704 | The large range serves in part to ensure that gain can always be losslessly |
| 705 | transferred between OpusHead and R128_TRACK_GAIN (see below) without |
| 706 | saturating. |
| 707 | <vspace blankLines="1"/> |
| 708 | </t> |
| 709 | <t><spanx style="strong">Channel Mapping Family</spanx> (8 bits, |
| 710 | unsigned): |
| 711 | <vspace blankLines="1"/> |
Ralph Giles | bb68e11 | 2014-08-08 13:22:18 -0700 | [diff] [blame] | 712 | This octet indicates the order and semantic meaning of the output channels. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 713 | <vspace blankLines="1"/> |
| 714 | Each possible value of this octet indicates a mapping family, which defines a |
| 715 | set of allowed channel counts, and the ordered set of channel names for each |
| 716 | allowed channel count. |
| 717 | The details are described in <xref target="channel_mapping"/>. |
| 718 | </t> |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 719 | <t><spanx style="strong">Channel Mapping Table</spanx>: |
| 720 | This table defines the mapping from encoded streams to output channels. |
| 721 | It is omitted when the channel mapping family is 0, but REQUIRED otherwise. |
| 722 | Its contents are specified in <xref target="channel_mapping"/>. |
| 723 | </t> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 724 | </list> |
| 725 | </t> |
| 726 | |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 727 | <t> |
| 728 | All fields in the ID headers are REQUIRED, except for the channel mapping |
| 729 | table, which is omitted when the channel mapping family is 0. |
| 730 | Implementations SHOULD reject ID headers which do not contain enough data for |
| 731 | these fields, even if they contain a valid Magic Signature. |
| 732 | Future versions of this specification, even backwards-compatible versions, |
| 733 | might include additional fields in the ID header. |
| 734 | If an ID header has a compatible major version, but a larger minor version, |
| 735 | an implementation MUST NOT reject it for containing additional data not |
| 736 | specified here. |
| 737 | However, implementations MAY reject streams in which the ID header does not |
| 738 | complete on the first page. |
| 739 | </t> |
| 740 | |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 741 | <section anchor="channel_mapping" title="Channel Mapping"> |
| 742 | <t> |
| 743 | An Ogg Opus stream allows mapping one number of Opus streams (N) to a possibly |
| 744 | larger number of decoded channels (M+N) to yet another number of output |
| 745 | channels (C), which might be larger or smaller than the number of decoded |
| 746 | channels. |
Ralph Giles | 9621e71 | 2012-07-17 17:35:12 -0400 | [diff] [blame] | 747 | The order and meaning of these channels are defined by a channel mapping, |
| 748 | which consists of the 'channel mapping family' octet and, for channel mapping |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 749 | families other than family 0, a channel mapping table, as illustrated in |
| 750 | <xref target="channel_mapping_table"/>. |
| 751 | </t> |
| 752 | |
| 753 | <figure anchor="channel_mapping_table" title="Channel Mapping Table" |
| 754 | align="center"> |
| 755 | <artwork align="center"><![CDATA[ |
| 756 | 0 1 2 3 |
| 757 | 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 |
| 758 | +-+-+-+-+-+-+-+-+ |
| 759 | | Stream Count | |
| 760 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 761 | | Coupled Count | Channel Mapping... : |
| 762 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 763 | ]]></artwork> |
| 764 | </figure> |
| 765 | |
| 766 | <t> |
| 767 | The fields in the channel mapping table have the following meaning: |
| 768 | <list style="numbers" counter="8"> |
| 769 | <t><spanx style="strong">Stream Count</spanx> 'N' (8 bits, unsigned): |
| 770 | <vspace blankLines="1"/> |
| 771 | This is the total number of streams encoded in each Ogg packet. |
| 772 | This value is required to correctly parse the packed Opus packets inside an |
| 773 | Ogg packet, as described in <xref target="packet_organization"/>. |
| 774 | This value MUST NOT be zero, as without at least one Opus packet with a valid |
| 775 | TOC sequence, a demuxer cannot recover the duration of an Ogg packet. |
| 776 | <vspace blankLines="1"/> |
| 777 | For channel mapping family 0, this value defaults to 1, and is not coded. |
| 778 | <vspace blankLines="1"/> |
| 779 | </t> |
| 780 | <t><spanx style="strong">Coupled Stream Count</spanx> 'M' (8 bits, unsigned): |
| 781 | This is the number of streams whose decoders should be configured to produce |
| 782 | two channels. |
| 783 | This MUST be no larger than the total number of streams, N. |
| 784 | <vspace blankLines="1"/> |
| 785 | Each packet in an Opus stream has an internal channel count of 1 or 2, which |
| 786 | can change from packet to packet. |
Ralph Giles | e7aa6cb | 2013-01-11 17:11:07 -0800 | [diff] [blame] | 787 | This is selected by the encoder depending on the bitrate and the audio being |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 788 | encoded. |
| 789 | The original channel count of the encoder input is not preserved by the lossy |
| 790 | compression. |
| 791 | <vspace blankLines="1"/> |
| 792 | Regardless of the internal channel count, any Opus stream can be decoded as |
| 793 | mono (a single channel) or stereo (two channels) by appropriate initialization |
| 794 | of the decoder. |
| 795 | The 'coupled stream count' field indicates that the first M Opus decoders are |
Ron | e37262c | 2014-01-19 15:20:05 +1030 | [diff] [blame] | 796 | to be initialized for stereo output, and the remaining N-M decoders are to be |
| 797 | initialized for mono only. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 798 | The total number of decoded channels, (M+N), MUST be no larger than 255, as |
| 799 | there is no way to index more channels than that in the channel mapping. |
| 800 | <vspace blankLines="1"/> |
| 801 | For channel mapping family 0, this value defaults to C-1 (i.e., 0 for mono |
| 802 | and 1 for stereo), and is not coded. |
| 803 | <vspace blankLines="1"/> |
| 804 | </t> |
| 805 | <t><spanx style="strong">Channel Mapping</spanx> (8*C bits): |
| 806 | This contains one octet per output channel, indicating which decoded channel |
| 807 | should be used for each one. |
| 808 | Let 'index' be the value of this octet for a particular output channel. |
| 809 | This value MUST either be smaller than (M+N), or be the special value 255. |
| 810 | If 'index' is less than 2*M, the output MUST be taken from decoding stream |
| 811 | ('index'/2) as stereo and selecting the left channel if 'index' is even, and |
| 812 | the right channel if 'index' is odd. |
Ralph Giles | bb68e11 | 2014-08-08 13:22:18 -0700 | [diff] [blame] | 813 | If 'index' is 2*M or larger, but less than 255, the output MUST be taken from |
| 814 | decoding stream ('index'-M) as mono. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 815 | If 'index' is 255, the corresponding output channel MUST contain pure silence. |
| 816 | <vspace blankLines="1"/> |
| 817 | The number of output channels, C, is not constrained to match the number of |
| 818 | decoded channels (M+N). |
| 819 | A single index value MAY appear multiple times, i.e., the same decoded channel |
| 820 | might be mapped to multiple output channels. |
| 821 | Some decoded channels might not be assigned to any output channel, as well. |
| 822 | <vspace blankLines="1"/> |
| 823 | For channel mapping family 0, the first index defaults to 0, and if C==2, |
| 824 | the second index defaults to 1. |
| 825 | Neither index is coded. |
| 826 | </t> |
| 827 | </list> |
| 828 | </t> |
| 829 | |
| 830 | <t> |
| 831 | After producing the output channels, the channel mapping family determines the |
| 832 | semantic meaning of each one. |
Ralph Giles | 2fd3d0a | 2013-01-16 16:30:55 -0800 | [diff] [blame] | 833 | Currently there are three defined mapping families, although more may be added. |
| 834 | </t> |
| 835 | |
| 836 | <section anchor="channel_mapping_0" title="Channel Mapping Family 0"> |
| 837 | <t> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 838 | Allowed numbers of channels: 1 or 2. |
Ralph Giles | 2fd3d0a | 2013-01-16 16:30:55 -0800 | [diff] [blame] | 839 | RTP mapping. |
| 840 | </t> |
| 841 | <t> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 842 | <list style="symbols"> |
| 843 | <t>1 channel: monophonic (mono).</t> |
| 844 | <t>2 channels: stereo (left, right).</t> |
| 845 | </list> |
| 846 | <spanx style="strong">Special mapping</spanx>: This channel mapping value also |
| 847 | indicates that the contents consists of a single Opus stream that is stereo if |
Ralph Giles | e7aa6cb | 2013-01-11 17:11:07 -0800 | [diff] [blame] | 848 | and only if C==2, with stream index 0 mapped to output channel 0 (mono, or |
| 849 | left channel) and stream index 1 mapped to output channel 1 (right channel) |
| 850 | if stereo. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 851 | When the 'channel mapping family' octet has this value, the channel mapping |
| 852 | table MUST be omitted from the ID header packet. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 853 | </t> |
Ralph Giles | 2fd3d0a | 2013-01-16 16:30:55 -0800 | [diff] [blame] | 854 | </section> |
| 855 | |
| 856 | <section anchor="channel_mapping_1" title="Channel Mapping Family 1"> |
| 857 | <t> |
Ralph Giles | 05bf400 | 2012-12-19 12:21:06 -0800 | [diff] [blame] | 858 | Allowed numbers of channels: 1...8. |
Ralph Giles | 2fd3d0a | 2013-01-16 16:30:55 -0800 | [diff] [blame] | 859 | Vorbis channel order. |
| 860 | </t> |
| 861 | <t> |
Ralph Giles | 05bf400 | 2012-12-19 12:21:06 -0800 | [diff] [blame] | 862 | Each channel is assigned to a speaker location in a conventional surround |
Ron | e37262c | 2014-01-19 15:20:05 +1030 | [diff] [blame] | 863 | arrangement. |
Ralph Giles | 05bf400 | 2012-12-19 12:21:06 -0800 | [diff] [blame] | 864 | Specific locations depend on the number of channels, and are given below |
| 865 | in order of the corresponding channel indicies. |
| 866 | <list style="symbols"> |
| 867 | <t>1 channel: monophonic (mono).</t> |
| 868 | <t>2 channels: stereo (left, right).</t> |
| 869 | <t>3 channels: linear surround (left, center, right)</t> |
| 870 | <t>4 channels: quadraphonic (front left, front right, rear left, rear right).</t> |
Ralph Giles | fc113b7 | 2013-01-11 17:01:38 -0800 | [diff] [blame] | 871 | <t>5 channels: 5.0 surround (front left, front center, front right, rear left, rear right).</t> |
| 872 | <t>6 channels: 5.1 surround (front left, front center, front right, rear left, rear right, LFE).</t> |
| 873 | <t>7 channels: 6.1 surround (front left, front center, front right, side left, side right, rear center, LFE).</t> |
| 874 | <t>8 channels: 7.1 surround (front left, front center, front right, side left, side right, rear left, rear right, LFE)</t> |
Ralph Giles | 05bf400 | 2012-12-19 12:21:06 -0800 | [diff] [blame] | 875 | </list> |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 876 | </t> |
| 877 | <t> |
Ron | e37262c | 2014-01-19 15:20:05 +1030 | [diff] [blame] | 878 | This set of surround options and speaker location orderings is the same |
| 879 | as those used by the Vorbis codec <xref target="vorbis-mapping"/>. |
Ralph Giles | 05bf400 | 2012-12-19 12:21:06 -0800 | [diff] [blame] | 880 | The ordering is different from the one used by the |
| 881 | WAVE <xref target="wave-multichannel"/> and |
| 882 | FLAC <xref target="flac"/> formats, |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 883 | so correct ordering requires permutation of the output channels when decoding |
| 884 | to or encoding from those formats. |
Ralph Giles | e7aa6cb | 2013-01-11 17:11:07 -0800 | [diff] [blame] | 885 | 'LFE' here refers to a Low Frequency Effects, often mapped to a subwoofer |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 886 | with no particular spatial position. |
Ralph Giles | 05bf400 | 2012-12-19 12:21:06 -0800 | [diff] [blame] | 887 | Implementations SHOULD identify 'side' or 'rear' speaker locations with |
Ralph Giles | e7aa6cb | 2013-01-11 17:11:07 -0800 | [diff] [blame] | 888 | 'surround' and 'back' as appropriate when interfacing with audio formats |
| 889 | or systems which prefer that terminology. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 890 | </t> |
Ralph Giles | 2fd3d0a | 2013-01-16 16:30:55 -0800 | [diff] [blame] | 891 | </section> |
| 892 | |
| 893 | <section anchor="channel_mapping_255" |
| 894 | title="Channel Mapping Family 255"> |
| 895 | <t> |
| 896 | Allowed numbers of channels: 1...255. |
| 897 | No defined channel meaning. |
| 898 | </t> |
| 899 | <t> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 900 | Channels are unidentified. |
| 901 | General-purpose players SHOULD NOT attempt to play these streams, and offline |
| 902 | decoders MAY deinterleave the output into separate PCM files, one per channel. |
| 903 | Decoders SHOULD NOT produce output for channels mapped to stream index 255 |
| 904 | (pure silence) unless they have no other way to indicate the index of |
| 905 | non-silent channels. |
| 906 | </t> |
Ralph Giles | 2fd3d0a | 2013-01-16 16:30:55 -0800 | [diff] [blame] | 907 | </section> |
| 908 | |
| 909 | <section anchor="channel_mapping_undefined" |
| 910 | title="Undefined Channel Mappings"> |
| 911 | <t> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 912 | The remaining channel mapping families (2...254) are reserved. |
Ralph Giles | 360a411 | 2012-07-16 13:53:29 -0400 | [diff] [blame] | 913 | A decoder encountering a reserved channel mapping family value SHOULD act as |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 914 | though the value is 255. |
Ralph Giles | 2fd3d0a | 2013-01-16 16:30:55 -0800 | [diff] [blame] | 915 | </t> |
| 916 | </section> |
| 917 | |
| 918 | <section anchor="downmix" title="Downmixing"> |
| 919 | <t> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 920 | An Ogg Opus player MUST play any Ogg Opus stream with a channel mapping family |
| 921 | of 0 or 1, even if the number of channels does not match the physically |
| 922 | connected audio hardware. |
| 923 | Players SHOULD perform channel mixing to increase or reduce the number of |
| 924 | channels as needed. |
| 925 | </t> |
| 926 | |
Ralph Giles | 2fd3d0a | 2013-01-16 16:30:55 -0800 | [diff] [blame] | 927 | <t> |
| 928 | Implementations MAY use the following matricies to implement downmixing from |
| 929 | multichannel files using <xref target="channel_mapping_1">Channel Mapping |
| 930 | Family 1</xref>, which are known to give acceptable results for stereo. |
| 931 | Matricies for 3 and 4 channels are normalized so each coefficent row sums |
| 932 | to 1 to avoid clipping. |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 933 | For 5 or more channels they are normalized to 2 as a compromise between |
Ralph Giles | 2fd3d0a | 2013-01-16 16:30:55 -0800 | [diff] [blame] | 934 | clipping and dynamic range reduction. |
| 935 | </t> |
| 936 | <t> |
| 937 | In these matricies the front left and front right channels are generally |
| 938 | passed through directly. |
| 939 | When a surround channel is split between both the left and right stereo |
| 940 | channels, coefficients are chosen so their squares sum to 1, which |
| 941 | helps preserve the perceived intensity. |
| 942 | Rear channels are mixed more diffusely or attenuated to maintain focus |
| 943 | on the front channels. |
| 944 | </t> |
| 945 | |
| 946 | <figure anchor="downmix-matrix-3" |
| 947 | title="Stereo downmix matrix for the linear surround channel mapping" |
| 948 | align="center"> |
| 949 | <artwork align="center"><![CDATA[ |
Ralph Giles | 593680a | 2014-01-20 12:52:38 -0800 | [diff] [blame] | 950 | L output = ( 0.585786 * left + 0.414214 * center ) |
| 951 | R output = ( 0.414214 * center + 0.585786 * right ) |
Ralph Giles | 2fd3d0a | 2013-01-16 16:30:55 -0800 | [diff] [blame] | 952 | ]]></artwork> |
| 953 | <postamble> |
| 954 | Exact coefficient values are 1 and 1/sqrt(2), multiplied by |
| 955 | 1/(1 + 1/sqrt(2)) for normalization. |
| 956 | </postamble> |
| 957 | </figure> |
| 958 | |
| 959 | <figure anchor="downmix-matrix-4" |
| 960 | title="Stereo downmix matrix for the quadraphonic channel mapping" |
| 961 | align="center"> |
| 962 | <artwork align="center"><![CDATA[ |
| 963 | / \ / \ / FL \ |
| 964 | | L output | | 0.422650 0.000000 0.366025 0.211325 | | FR | |
| 965 | | R output | = | 0.000000 0.422650 0.211325 0.366025 | | RL | |
| 966 | \ / \ / \ RR / |
| 967 | ]]></artwork> |
| 968 | <postamble> |
| 969 | Exact coefficient values are 1, sqrt(3)/2 and 1/2, multiplied by |
| 970 | 1/(1 + sqrt(3)/2 + 1/2) for normalization. |
| 971 | </postamble> |
| 972 | </figure> |
| 973 | |
| 974 | <figure anchor="downmix-matrix-5" |
| 975 | title="Stereo downmix matrix for the 5.0 surround mapping" |
| 976 | align="center"> |
| 977 | <artwork align="center"><![CDATA[ |
| 978 | / FL \ |
| 979 | / \ / \ | FC | |
| 980 | | L | | 0.650802 0.460186 0.000000 0.563611 0.325401 | | FR | |
| 981 | | R | = | 0.000000 0.460186 0.650802 0.325401 0.563611 | | RL | |
| 982 | \ / \ / | RR | |
| 983 | \ / |
| 984 | ]]></artwork> |
| 985 | <postamble> |
| 986 | Exact coefficient values are 1, 1/sqrt(2), sqrt(3)/2 and 1/2, multiplied by |
| 987 | 2/(1 + 1/sqrt(2) + sqrt(3)/2 + 1/2) |
| 988 | for normalization. |
| 989 | </postamble> |
| 990 | </figure> |
| 991 | |
| 992 | <figure anchor="downmix-matrix-6" |
| 993 | title="Stereo downmix matrix for the 5.1 surround mapping" |
| 994 | align="center"> |
| 995 | <artwork align="center"><![CDATA[ |
| 996 | /FL \ |
| 997 | / \ / \ |FC | |
| 998 | |L| | 0.529067 0.374107 0.000000 0.458186 0.264534 0.374107 | |FR | |
| 999 | |R| = | 0.000000 0.374107 0.529067 0.264534 0.458186 0.374107 | |RL | |
| 1000 | \ / \ / |RR | |
| 1001 | \LFE/ |
| 1002 | ]]></artwork> |
| 1003 | <postamble> |
| 1004 | Exact coefficient values are 1, 1/sqrt(2), sqrt(3)/2 and 1/2, multiplied by |
| 1005 | 2/(1 + 1/sqrt(2) + sqrt(3)/2 + 1/2 + 1/sqrt(2)) |
| 1006 | for normalization. |
| 1007 | </postamble> |
| 1008 | </figure> |
| 1009 | |
| 1010 | <figure anchor="downmix-matrix-7" |
| 1011 | title="Stereo downmix matrix for the 6.1 surround mapping" |
| 1012 | align="center"> |
| 1013 | <artwork align="center"><![CDATA[ |
| 1014 | / \ |
| 1015 | | 0.455310 0.321953 0.000000 0.394310 0.227655 0.278819 0.321953 | |
| 1016 | | 0.000000 0.321953 0.455310 0.227655 0.394310 0.278819 0.321953 | |
| 1017 | \ / |
| 1018 | ]]></artwork> |
| 1019 | <postamble> |
| 1020 | Exact coefficient values are 1, 1/sqrt(2), sqrt(3)/2, 1/2 and |
| 1021 | sqrt(3)/2/sqrt(2), multiplied by |
| 1022 | 2/(1 + 1/sqrt(2) + sqrt(3)/2 + 1/2 + |
| 1023 | sqrt(3)/2/sqrt(2) + 1/sqrt(2)) for normalization. |
| 1024 | The coeffients are in the same order as in <xref target="channel_mapping_1" />, |
| 1025 | and the matricies above. |
| 1026 | </postamble> |
| 1027 | </figure> |
| 1028 | |
| 1029 | <figure anchor="downmix-matrix-8" |
| 1030 | title="Stereo downmix matrix for the 7.1 surround mapping" |
| 1031 | align="center"> |
| 1032 | <artwork align="center"><![CDATA[ |
| 1033 | / \ |
| 1034 | | .388631 .274804 .000000 .336565 .194316 .336565 .194316 .274804 | |
| 1035 | | .000000 .274804 .388631 .194316 .336565 .194316 .336565 .274804 | |
| 1036 | \ / |
| 1037 | ]]></artwork> |
| 1038 | <postamble> |
| 1039 | Exact coefficient values are 1, 1/sqrt(2), sqrt(3)/2 and 1/2, multiplied by |
| 1040 | 2/(2 + 2/sqrt(2) + sqrt(3)) for normalization. |
| 1041 | The coeffients are in the same order as in <xref target="channel_mapping_1" />, |
| 1042 | and the matricies above. |
| 1043 | </postamble> |
| 1044 | </figure> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1045 | |
| 1046 | </section> |
| 1047 | |
Ralph Giles | 2fd3d0a | 2013-01-16 16:30:55 -0800 | [diff] [blame] | 1048 | </section> <!-- end channel_mapping_table --> |
| 1049 | |
| 1050 | </section> <!-- end id_header --> |
| 1051 | |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1052 | <section anchor="comment_header" title="Comment Header"> |
| 1053 | |
| 1054 | <figure anchor="comment_header_packet" title="Comment Header Packet" |
| 1055 | align="center"> |
| 1056 | <artwork align="center"><![CDATA[ |
| 1057 | 0 1 2 3 |
| 1058 | 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 |
| 1059 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 1060 | | 'O' | 'p' | 'u' | 's' | |
| 1061 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 1062 | | 'T' | 'a' | 'g' | 's' | |
| 1063 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 1064 | | Vendor String Length | |
| 1065 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 1066 | | | |
| 1067 | : Vendor String... : |
| 1068 | | | |
| 1069 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 1070 | | User Comment List Length | |
| 1071 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 1072 | | User Comment #0 String Length | |
| 1073 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 1074 | | | |
| 1075 | : User Comment #0 String... : |
| 1076 | | | |
| 1077 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 1078 | | User Comment #1 String Length | |
| 1079 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 1080 | : : |
| 1081 | ]]></artwork> |
| 1082 | </figure> |
| 1083 | |
| 1084 | <t> |
| 1085 | The comment header consists of a 64-bit magic signature, followed by data in |
| 1086 | the same format as the <xref target="vorbis-comment"/> header used in Ogg |
Ralph Giles | bfcc1dd | 2014-01-15 09:02:01 -0800 | [diff] [blame] | 1087 | Vorbis, except (like Ogg Theora and Speex) the final "framing bit" specified |
| 1088 | in the Vorbis spec is not present. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1089 | <list style="numbers"> |
| 1090 | <t><spanx style="strong">Magic Signature</spanx>: |
| 1091 | <vspace blankLines="1"/> |
| 1092 | This is an 8-octet (64-bit) field that allows codec identification and is |
| 1093 | human-readable. |
| 1094 | It contains, in order, the magic numbers: |
| 1095 | <list style="empty"> |
| 1096 | <t>0x4F 'O'</t> |
| 1097 | <t>0x70 'p'</t> |
| 1098 | <t>0x75 'u'</t> |
| 1099 | <t>0x73 's'</t> |
| 1100 | <t>0x54 'T'</t> |
| 1101 | <t>0x61 'a'</t> |
| 1102 | <t>0x67 'g'</t> |
| 1103 | <t>0x73 's'</t> |
| 1104 | </list> |
| 1105 | Starting with "Op" helps distinguish it from audio data packets, as this is an |
| 1106 | invalid TOC sequence. |
| 1107 | <vspace blankLines="1"/> |
| 1108 | </t> |
| 1109 | <t><spanx style="strong">Vendor String Length</spanx> (32 bits, unsigned, |
| 1110 | little endian): |
| 1111 | <vspace blankLines="1"/> |
| 1112 | This field gives the length of the following vendor string, in octets. |
| 1113 | It MUST NOT indicate that the vendor string is longer than the rest of the |
| 1114 | packet. |
| 1115 | <vspace blankLines="1"/> |
| 1116 | </t> |
| 1117 | <t><spanx style="strong">Vendor String</spanx> (variable length, UTF-8 vector): |
| 1118 | <vspace blankLines="1"/> |
| 1119 | This is a simple human-readable tag for vendor information, encoded as a UTF-8 |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 1120 | string <xref target="RFC3629"/>. |
Ralph Giles | 05bf400 | 2012-12-19 12:21:06 -0800 | [diff] [blame] | 1121 | No terminating null octet is required. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1122 | <vspace blankLines="1"/> |
Ralph Giles | 360a411 | 2012-07-16 13:53:29 -0400 | [diff] [blame] | 1123 | This tag is intended to identify the codec encoder and encapsulation |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 1124 | implementations, for tracing differences in technical behavior. |
Ralph Giles | aff527e | 2012-07-16 17:36:52 -0400 | [diff] [blame] | 1125 | User-facing encoding applications can use the 'ENCODER' user comment tag |
| 1126 | to identify themselves. |
Ralph Giles | 360a411 | 2012-07-16 13:53:29 -0400 | [diff] [blame] | 1127 | <vspace blankLines="1"/> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1128 | </t> |
| 1129 | <t><spanx style="strong">User Comment List Length</spanx> (32 bits, unsigned, |
| 1130 | little endian): |
| 1131 | <vspace blankLines="1"/> |
| 1132 | This field indicates the number of user-supplied comments. |
| 1133 | It MAY indicate there are zero user-supplied comments, in which case there are |
| 1134 | no additional fields in the packet. |
| 1135 | It MUST NOT indicate that there are so many comments that the comment string |
| 1136 | lengths would require more data than is available in the rest of the packet. |
| 1137 | <vspace blankLines="1"/> |
| 1138 | </t> |
| 1139 | <t><spanx style="strong">User Comment #i String Length</spanx> (32 bits, |
| 1140 | unsigned, little endian): |
| 1141 | <vspace blankLines="1"/> |
| 1142 | This field gives the length of the following user comment string, in octets. |
| 1143 | There is one for each user comment indicated by the 'user comment list length' |
| 1144 | field. |
| 1145 | It MUST NOT indicate that the string is longer than the rest of the packet. |
| 1146 | <vspace blankLines="1"/> |
| 1147 | </t> |
| 1148 | <t><spanx style="strong">User Comment #i String</spanx> (variable length, UTF-8 |
| 1149 | vector): |
| 1150 | <vspace blankLines="1"/> |
| 1151 | This field contains a single user comment string. |
| 1152 | There is one for each user comment indicated by the 'user comment list length' |
| 1153 | field. |
| 1154 | </t> |
| 1155 | </list> |
| 1156 | </t> |
| 1157 | |
| 1158 | <t> |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 1159 | The vendor string length and user comment list length are REQUIRED, and |
| 1160 | implementations SHOULD reject comment headers that do not contain enough data |
| 1161 | for these fields, or that do not contain enough data for the corresponding |
| 1162 | vendor string or user comments they describe. |
| 1163 | Making this check before allocating the associated memory to contain the data |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 1164 | helps prevent a possible Denial-of-Service (DoS) attack from small comment |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 1165 | headers that claim to contain strings longer than the entire packet or more |
| 1166 | user comments than than could possibly fit in the packet. |
| 1167 | </t> |
| 1168 | |
Ralph Giles | 64881ec | 2014-08-08 14:16:50 -0700 | [diff] [blame^] | 1169 | <section anchor="comment_format" title="Tag Definitions"> |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 1170 | <t> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1171 | The user comment strings follow the NAME=value format described by |
Ralph Giles | 64881ec | 2014-08-08 14:16:50 -0700 | [diff] [blame^] | 1172 | <xref target="vorbis-comment"/> with the same recommended tag names: |
| 1173 | ARTIST, TITLE, DATE, ALBUM, and so on. |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 1174 | </t> |
Ralph Giles | 64881ec | 2014-08-08 14:16:50 -0700 | [diff] [blame^] | 1175 | <t> |
| 1176 | Two new comment tags are introduced for Ogg Opus: |
| 1177 | </t> |
| 1178 | |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1179 | <figure align="center"> |
Ralph Giles | 64881ec | 2014-08-08 14:16:50 -0700 | [diff] [blame^] | 1180 | <preamble>An optional gain for track nomalization</preamble> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1181 | <artwork align="left"><![CDATA[ |
| 1182 | R128_TRACK_GAIN=-573 |
| 1183 | ]]></artwork> |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 1184 | <postamble> |
Ralph Giles | 64881ec | 2014-08-08 14:16:50 -0700 | [diff] [blame^] | 1185 | representing the volume shift needed to normalize the track's volume |
| 1186 | during isolated playback, in random shuffle, and so on. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1187 | The gain is a Q7.8 fixed point number in dB, as in the ID header's 'output |
| 1188 | gain' field. |
Ralph Giles | 4e8acd5 | 2014-02-07 15:41:55 -0800 | [diff] [blame] | 1189 | </postamble> |
| 1190 | </figure> |
| 1191 | <t> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1192 | This tag is similar to the REPLAYGAIN_TRACK_GAIN tag in |
| 1193 | Vorbis <xref target="replay-gain"/>, except that the normal volume |
| 1194 | reference is the <xref target="EBU-R128"/> standard. |
| 1195 | </t> |
Ralph Giles | 64881ec | 2014-08-08 14:16:50 -0700 | [diff] [blame^] | 1196 | <figure align="center"> |
| 1197 | <preamble>An optional gain for album nomalization</preamble> |
Ralph Giles | 2e1b043 | 2014-08-08 13:41:25 -0700 | [diff] [blame] | 1198 | <artwork align="left"><![CDATA[ |
| 1199 | R128_ALBUM_GAIN=111 |
| 1200 | ]]></artwork> |
| 1201 | <postamble> |
Ralph Giles | 64881ec | 2014-08-08 14:16:50 -0700 | [diff] [blame^] | 1202 | representing the volume shift needed to normalize the overall volume when |
| 1203 | played as part of a collection of tracks. |
| 1204 | The gain is also a Q7.8 fixed point number in dB, as in the ID header's |
| 1205 | 'output gain' field. |
Ralph Giles | 2e1b043 | 2014-08-08 13:41:25 -0700 | [diff] [blame] | 1206 | </postamble> |
| 1207 | </figure> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1208 | <t> |
Ralph Giles | 64881ec | 2014-08-08 14:16:50 -0700 | [diff] [blame^] | 1209 | An Ogg Opus file MUST NOT have more than one of each tag, and if present |
| 1210 | their values MUST be an integer from -32768 to 32767, inclusive, |
| 1211 | represented in ASCII with no whitespace. |
| 1212 | If present, R128_TRACK_GAIN and R128_ALBUM_GAIN MUST correctly represent |
| 1213 | the R128 normalization gain relative to the 'output gain' field specified |
| 1214 | in the ID header. |
Ralph Giles | 2e1b043 | 2014-08-08 13:41:25 -0700 | [diff] [blame] | 1215 | If a player chooses to make use of the R128_TRACK_GAIN tag or the |
Ralph Giles | 64881ec | 2014-08-08 14:16:50 -0700 | [diff] [blame^] | 1216 | R128_ALBUM_GAIN tag, it MUST apply those gains |
| 1217 | <spanx style="emph">in addition</spanx> to the 'output gain' value. |
| 1218 | </t> |
| 1219 | <t> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1220 | If an encoder wishes to use R128 normalization, and the output gain is not |
| 1221 | otherwise constrained or specified, the encoder SHOULD write the R128 gain |
| 1222 | into the 'output gain' field and store a tag containing "R128_TRACK_GAIN=0". |
| 1223 | That is, it should assume that by default tools will respect the 'output gain' |
| 1224 | field, and not the comment tag. |
| 1225 | If a tool modifies the ID header's 'output gain' field, it MUST also update or |
Ralph Giles | 64881ec | 2014-08-08 14:16:50 -0700 | [diff] [blame^] | 1226 | remove the R128_TRACK_GAIN and R128_ALBUM_GAIN comment tags if present. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1227 | </t> |
| 1228 | <t> |
| 1229 | To avoid confusion with multiple normalization schemes, an Opus comment header |
| 1230 | SHOULD NOT contain any of the REPLAYGAIN_TRACK_GAIN, REPLAYGAIN_TRACK_PEAK, |
| 1231 | REPLAYGAIN_ALBUM_GAIN, or REPLAYGAIN_ALBUM_PEAK tags. |
Ralph Giles | 64881ec | 2014-08-08 14:16:50 -0700 | [diff] [blame^] | 1232 | The <xref target="EBU-R128"/> normalization is preferred to the earlier |
| 1233 | REPLAYGAIN schemes because of its clear definition and adoption by industry. |
| 1234 | PEAK normalizations are difficult to calculate reliably because of variation |
| 1235 | in excursion heights due to decoder differences. |
| 1236 | In the authors' investigations they were not applied consistently or broadly |
| 1237 | enough to merit inclusion here. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1238 | </t> |
Ralph Giles | 64881ec | 2014-08-08 14:16:50 -0700 | [diff] [blame^] | 1239 | </section> <!-- end comment_format --> |
| 1240 | </section> <!-- end comment_header --> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1241 | |
Ralph Giles | 64881ec | 2014-08-08 14:16:50 -0700 | [diff] [blame^] | 1242 | </section> <!-- end headers --> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1243 | |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 1244 | <section anchor="packet_size_limits" title="Packet Size Limits"> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1245 | <t> |
| 1246 | Technically valid Opus packets can be arbitrarily large due to the padding |
| 1247 | format, although the amount of non-padding data they can contain is bounded. |
| 1248 | These packets might be spread over a similarly enormous number of Ogg pages. |
| 1249 | Encoders SHOULD use no more padding than required to make a variable bitrate |
| 1250 | (VBR) stream constant bitrate (CBR). |
| 1251 | Decoders SHOULD avoid attempting to allocate excessive amounts of memory when |
| 1252 | presented with a very large packet. |
| 1253 | The presence of an extremely large packet in the stream could indicate a |
Ralph Giles | 360a411 | 2012-07-16 13:53:29 -0400 | [diff] [blame] | 1254 | memory exhaustion attack or stream corruption. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1255 | Decoders SHOULD reject a packet that is too large to process, and display a |
| 1256 | warning message. |
| 1257 | </t> |
| 1258 | <t> |
| 1259 | In an Ogg Opus stream, the largest possible valid packet that does not use |
| 1260 | padding has a size of (61,298*N - 2) octets, or about 60 kB per |
| 1261 | Opus stream. |
| 1262 | With 255 streams, this is 15,630,988 octets (14.9 MB) and can |
| 1263 | span up to 61,298 Ogg pages, all but one of which will have a granule |
| 1264 | position of -1. |
| 1265 | This is of course a very extreme packet, consisting of 255 streams, each |
| 1266 | containing 120 ms of audio encoded as 2.5 ms frames, each frame |
| 1267 | using the maximum possible number of octets (1275) and stored in the least |
| 1268 | efficient manner allowed (a VBR code 3 Opus packet). |
Ralph Giles | 7ad2f43 | 2013-01-10 14:15:41 -0800 | [diff] [blame] | 1269 | Even in such a packet, most of the data will be zeros as 2.5 ms frames |
| 1270 | cannot actually use all 1275 octets. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1271 | The largest packet consisting of entirely useful data is |
| 1272 | (15,326*N - 2) octets, or about 15 kB per stream. |
| 1273 | This corresponds to 120 ms of audio encoded as 10 ms frames in either |
Ralph Giles | e26ed59 | 2014-01-17 14:33:54 -0800 | [diff] [blame] | 1274 | SILK or Hybrid mode, but at a data rate of over 1 Mbps, which makes little |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1275 | sense for the quality achieved. |
| 1276 | A more reasonable limit is (7,664*N - 2) octets, or about 7.5 kB |
| 1277 | per stream. |
Ralph Giles | e26ed59 | 2014-01-17 14:33:54 -0800 | [diff] [blame] | 1278 | This corresponds to 120 ms of audio encoded as 20 ms stereo CELT mode |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1279 | frames, with a total bitrate just under 511 kbps (not counting the Ogg |
| 1280 | encapsulation overhead). |
Timothy B. Terriberry | 396c4e5 | 2012-07-16 13:43:10 -0700 | [diff] [blame] | 1281 | With N=8, the maximum number of channels currently defined by mapping |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1282 | family 1, this gives a maximum packet size of 61,310 octets, or just |
| 1283 | under 60 kB. |
| 1284 | This is still quite conservative, as it assumes each output channel is taken |
| 1285 | from one decoded channel of a stereo packet. |
| 1286 | An implementation could reasonably choose any of these numbers for its internal |
| 1287 | limits. |
| 1288 | </t> |
| 1289 | </section> |
| 1290 | |
Ralph Giles | 2ad6eaf | 2013-05-24 18:28:58 +0800 | [diff] [blame] | 1291 | <section anchor="encoder" title="Encoder Guidelines"> |
| 1292 | <t> |
| 1293 | When encoding Opus files, Ogg encoders should take into account the |
| 1294 | algorithmic delay of the Opus encoder. |
Ralph Giles | b243dca | 2013-05-25 01:23:41 +0800 | [diff] [blame] | 1295 | </t> |
| 1296 | <figure align="center"> |
| 1297 | <preamble> |
Ralph Giles | 2ad6eaf | 2013-05-24 18:28:58 +0800 | [diff] [blame] | 1298 | In encoders derived from the reference implementation, the number of |
| 1299 | samples can be queried with: |
Ralph Giles | b243dca | 2013-05-25 01:23:41 +0800 | [diff] [blame] | 1300 | </preamble> |
| 1301 | <artwork align="center"><![CDATA[ |
Ralph Giles | c42c6db | 2014-01-17 15:36:03 -0800 | [diff] [blame] | 1302 | opus_encoder_ctl(encoder_state, OPUS_GET_LOOKAHEAD, &delay_samples); |
Ralph Giles | b243dca | 2013-05-25 01:23:41 +0800 | [diff] [blame] | 1303 | ]]></artwork> |
| 1304 | </figure> |
| 1305 | <t> |
Ralph Giles | 2ad6eaf | 2013-05-24 18:28:58 +0800 | [diff] [blame] | 1306 | To achieve good quality in the very first samples of a stream, the Ogg encoder |
Ralph Giles | c42c6db | 2014-01-17 15:36:03 -0800 | [diff] [blame] | 1307 | MAY use linear predictive coding (LPC) extrapolation |
| 1308 | <xref target="linear-prediction"/> to generate at least 120 extra samples at |
| 1309 | the beginning to avoid the Opus encoder having to encode a discontinuous |
| 1310 | signal. |
| 1311 | For an input file containing 'length' samples, the Ogg encoder SHOULD set the |
Ralph Giles | cf33d32 | 2014-01-17 16:16:46 -0800 | [diff] [blame] | 1312 | pre-skip header value to delay_samples+extra_samples, encode at least |
Ralph Giles | c42c6db | 2014-01-17 15:36:03 -0800 | [diff] [blame] | 1313 | length+delay_samples+extra_samples samples, and set the granulepos of the last |
| 1314 | page to length+delay_samples+extra_samples. |
Ralph Giles | 2ad6eaf | 2013-05-24 18:28:58 +0800 | [diff] [blame] | 1315 | This ensures that the encoded file has the same duration as the original, with |
| 1316 | no time offset. The best way to pad the end of the stream is to also use LPC |
| 1317 | extrapolation, but zero-padding is also acceptable. |
| 1318 | </t> |
| 1319 | |
| 1320 | <section anchor="lpc" title="LPC Extrapolation"> |
| 1321 | <t> |
| 1322 | The first step in LPC extrapolation is to compute linear prediction |
Ralph Giles | 078775b | 2014-01-17 15:44:08 -0800 | [diff] [blame] | 1323 | coefficients. <xref target="lpc-sample"/> |
Ralph Giles | 2ad6eaf | 2013-05-24 18:28:58 +0800 | [diff] [blame] | 1324 | When extending the end of the signal, order-N (typically with N ranging from 8 |
| 1325 | to 40) LPC analysis is performed on a window near the end of the signal. |
| 1326 | The last N samples are used as memory to an infinite impulse response (IIR) |
| 1327 | filter. |
Ralph Giles | 7918ac1 | 2013-05-25 01:16:23 +0800 | [diff] [blame] | 1328 | </t> |
| 1329 | <figure align="center"> |
| 1330 | <preamble> |
Ralph Giles | 2ad6eaf | 2013-05-24 18:28:58 +0800 | [diff] [blame] | 1331 | The filter is then applied on a zero input to extrapolate the end of the signal. |
| 1332 | Let a(k) be the kth LPC coefficient and x(n) be the nth sample of the signal, |
| 1333 | each new sample past the end of the signal is computed as: |
Ralph Giles | 7918ac1 | 2013-05-25 01:16:23 +0800 | [diff] [blame] | 1334 | </preamble> |
Ralph Giles | 2ad6eaf | 2013-05-24 18:28:58 +0800 | [diff] [blame] | 1335 | <artwork align="center"><![CDATA[ |
| 1336 | N |
| 1337 | --- |
| 1338 | x(n) = \ a(k)*x(n-k) |
| 1339 | / |
| 1340 | --- |
| 1341 | k=1 |
| 1342 | ]]></artwork> |
Ralph Giles | 7918ac1 | 2013-05-25 01:16:23 +0800 | [diff] [blame] | 1343 | </figure> |
| 1344 | <t> |
Ralph Giles | 2ad6eaf | 2013-05-24 18:28:58 +0800 | [diff] [blame] | 1345 | The process is repeated independently for each channel. |
| 1346 | It is possible to extend the beginning of the signal by applying the same |
| 1347 | process backward in time. |
| 1348 | When extending the beginning of the signal, it is best to apply a "fade in" to |
Ralph Giles | bd5cfda | 2013-05-25 01:37:46 +0800 | [diff] [blame] | 1349 | the extrapolated signal, e.g. by multiplying it by a half-Hanning window |
| 1350 | <xref target="hanning"/>. |
Ralph Giles | 2ad6eaf | 2013-05-24 18:28:58 +0800 | [diff] [blame] | 1351 | </t> |
| 1352 | |
| 1353 | </section> |
| 1354 | |
| 1355 | <section anchor="continuous_chaining" title="Continuous Chaining"> |
| 1356 | <t> |
| 1357 | In some applications, such as Internet radio, it is desirable to cut a long |
Ron | 3f3cd99 | 2014-01-19 13:48:21 +1030 | [diff] [blame] | 1358 | stream into smaller chains, e.g. so the comment header can be updated. |
Ralph Giles | 2ad6eaf | 2013-05-24 18:28:58 +0800 | [diff] [blame] | 1359 | This can be done simply by separating the input streams into segments and |
| 1360 | encoding each segment independently. |
| 1361 | The drawback of this approach is that it creates a small discontinuity |
| 1362 | at the boundary due to the lossy nature of Opus. |
| 1363 | An encoder MAY avoid this discontinuity by using the following procedure: |
| 1364 | <list style="numbers"> |
| 1365 | <t>Encode the last frame of the first segment as an independent frame by |
Ralph Giles | 785a21f | 2014-01-17 16:02:52 -0800 | [diff] [blame] | 1366 | turning off all forms of inter-frame prediction. |
| 1367 | De-emphasis is allowed.</t> |
Ralph Giles | 2ad6eaf | 2013-05-24 18:28:58 +0800 | [diff] [blame] | 1368 | <t>Set the granulepos of the last page to a point near the end of the last |
| 1369 | frame.</t> |
| 1370 | <t>Begin the second segment with a copy of the last frame of the first |
| 1371 | segment.</t> |
Ralph Giles | cf33d32 | 2014-01-17 16:16:46 -0800 | [diff] [blame] | 1372 | <t>Set the pre-skip value of the second stream in such a way as to properly |
Ralph Giles | 2ad6eaf | 2013-05-24 18:28:58 +0800 | [diff] [blame] | 1373 | join the two streams.</t> |
| 1374 | <t>Continue the encoding process normally from there, without any reset to |
| 1375 | the encoder.</t> |
| 1376 | </list> |
| 1377 | </t> |
Ralph Giles | 785a21f | 2014-01-17 16:02:52 -0800 | [diff] [blame] | 1378 | <figure align="center"> |
| 1379 | <preamble> |
| 1380 | In encoders derived from the reference implementation, inter-frame prediction |
| 1381 | can be turned off by calling: |
| 1382 | </preamble> |
| 1383 | <artwork align="center"><![CDATA[ |
| 1384 | opus_encoder_ctl(encoder_state, OPUS_SET_PREDICTION_DISABLED, 1); |
| 1385 | ]]></artwork> |
| 1386 | <postamble> |
| 1387 | Prediction should be enabled again before resuming normal encoding, even |
| 1388 | after a reset. |
| 1389 | </postamble> |
| 1390 | </figure> |
| 1391 | |
Ralph Giles | 2ad6eaf | 2013-05-24 18:28:58 +0800 | [diff] [blame] | 1392 | </section> |
| 1393 | |
Ralph Giles | 7918ac1 | 2013-05-25 01:16:23 +0800 | [diff] [blame] | 1394 | </section> |
| 1395 | |
Ralph Giles | 0c1487a | 2013-01-10 16:38:31 -0800 | [diff] [blame] | 1396 | <section anchor="implementation" title="Implementation Status"> |
| 1397 | <t> |
Ralph Giles | dfda81e | 2013-05-24 17:44:43 +0800 | [diff] [blame] | 1398 | A brief summary of major implementations of this draft is available |
| 1399 | at <eref target="https://wiki.xiph.org/OggOpusImplementation"/>, |
| 1400 | along with their status. |
Ralph Giles | 0c1487a | 2013-01-10 16:38:31 -0800 | [diff] [blame] | 1401 | </t> |
Ralph Giles | 0c1487a | 2013-01-10 16:38:31 -0800 | [diff] [blame] | 1402 | <t> |
Ralph Giles | dfda81e | 2013-05-24 17:44:43 +0800 | [diff] [blame] | 1403 | [Note to RFC Editor: please remove this entire section before |
Ralph Giles | 5742f10 | 2014-01-20 13:40:36 -0800 | [diff] [blame] | 1404 | final publication per <xref target="RFC6982"/>.] |
Ralph Giles | 0c1487a | 2013-01-10 16:38:31 -0800 | [diff] [blame] | 1405 | </t> |
Ralph Giles | 0c1487a | 2013-01-10 16:38:31 -0800 | [diff] [blame] | 1406 | </section> |
| 1407 | |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1408 | <section anchor="security" title="Security Considerations"> |
| 1409 | <t> |
| 1410 | Implementations of the Opus codec need to take appropriate security |
| 1411 | considerations into account, as outlined in <xref target="RFC4732"/>. |
| 1412 | This is just as much a problem for the container as it is for the codec itself. |
| 1413 | It is extremely important for the decoder to be robust against malicious |
| 1414 | payloads. |
| 1415 | Malicious payloads must not cause the decoder to overrun its allocated memory |
| 1416 | or to take an excessive amount of resources to decode. |
| 1417 | Although problems in encoders are typically rarer, the same applies to the |
| 1418 | encoder. |
| 1419 | Malicious audio streams must not cause the encoder to misbehave because this |
| 1420 | would allow an attacker to attack transcoding gateways. |
| 1421 | </t> |
| 1422 | |
| 1423 | <t> |
| 1424 | Like most other container formats, Ogg Opus files should not be used with |
| 1425 | insecure ciphers or cipher modes that are vulnerable to known-plaintext |
| 1426 | attacks. |
| 1427 | Elements such as the Ogg page capture pattern and the magic signatures in the |
| 1428 | ID header and the comment header all have easily predictable values, in |
| 1429 | addition to various elements of the codec data itself. |
| 1430 | </t> |
| 1431 | </section> |
| 1432 | |
| 1433 | <section anchor="content_type" title="Content Type"> |
| 1434 | <t> |
| 1435 | An "Ogg Opus file" consists of one or more sequentially multiplexed segments, |
| 1436 | each containing exactly one Ogg Opus stream. |
| 1437 | The RECOMMENDED mime-type for Ogg Opus files is "audio/ogg". |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1438 | </t> |
| 1439 | |
Ralph Giles | 0431f93 | 2013-01-16 14:14:32 -0800 | [diff] [blame] | 1440 | <figure> |
| 1441 | <preamble> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1442 | If more specificity is desired, one MAY indicate the presence of Opus streams |
| 1443 | using the codecs parameter defined in <xref target="RFC6381"/>, e.g., |
Ralph Giles | 0431f93 | 2013-01-16 14:14:32 -0800 | [diff] [blame] | 1444 | </preamble> |
| 1445 | <artwork align="center"><![CDATA[ |
| 1446 | audio/ogg; codecs=opus |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1447 | ]]></artwork> |
Ralph Giles | 0431f93 | 2013-01-16 14:14:32 -0800 | [diff] [blame] | 1448 | <postamble> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1449 | for an Ogg Opus file. |
Ralph Giles | 0431f93 | 2013-01-16 14:14:32 -0800 | [diff] [blame] | 1450 | </postamble> |
| 1451 | </figure> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1452 | |
| 1453 | <t> |
| 1454 | The RECOMMENDED filename extension for Ogg Opus files is '.opus'. |
| 1455 | </t> |
| 1456 | |
Ralph Giles | a1b913f | 2013-01-10 17:00:18 -0800 | [diff] [blame] | 1457 | <t> |
| 1458 | When Opus is concurrently multiplexed with other streams in an Ogg container, |
| 1459 | one SHOULD use one of the "audio/ogg", "video/ogg", or "application/ogg" |
| 1460 | mime-types, as defined in <xref target="RFC5334"/>. |
| 1461 | Such streams are not strictly "Ogg Opus files" as described above, |
| 1462 | since they contain more than a single Opus stream per sequentially |
| 1463 | multiplexed segment, e.g. video or multiple audio tracks. |
| 1464 | In such cases the the '.opus' filename extension is NOT RECOMMENDED. |
| 1465 | </t> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1466 | </section> |
| 1467 | |
| 1468 | <section title="IANA Considerations"> |
| 1469 | <t> |
| 1470 | This document has no actions for IANA. |
| 1471 | </t> |
| 1472 | </section> |
| 1473 | |
| 1474 | <section anchor="Acknowledgments" title="Acknowledgments"> |
| 1475 | <t> |
Timothy B. Terriberry | b7985f3 | 2012-07-17 12:07:36 -0700 | [diff] [blame] | 1476 | Thanks to Greg Maxwell, Christopher "Monty" Montgomery, and Jean-Marc Valin for |
| 1477 | their valuable contributions to this document. |
| 1478 | Additional thanks to Andrew D'Addesio, Greg Maxwell, and Vincent Penqeurc'h for |
| 1479 | their feedback based on early implementations. |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1480 | </t> |
| 1481 | </section> |
| 1482 | |
| 1483 | <section title="Copying Conditions"> |
| 1484 | <t> |
| 1485 | The authors agree to grant third parties the irrevocable right to copy, use, |
| 1486 | and distribute the work, with or without modification, in any medium, without |
| 1487 | royalty, provided that, unless separate permission is granted, redistributed |
| 1488 | modified works do not contain misleading author, version, name of work, or |
| 1489 | endorsement information. |
| 1490 | </t> |
| 1491 | </section> |
| 1492 | |
| 1493 | </middle> |
| 1494 | <back> |
| 1495 | <references title="Normative References"> |
Timothy B. Terriberry | 50f214c | 2012-11-03 13:01:25 -0700 | [diff] [blame] | 1496 | &rfc2119; |
| 1497 | &rfc3533; |
Timothy B. Terriberry | 50f214c | 2012-11-03 13:01:25 -0700 | [diff] [blame] | 1498 | &rfc3629; |
Ralph Giles | a1b913f | 2013-01-10 17:00:18 -0800 | [diff] [blame] | 1499 | &rfc5334; |
Timothy B. Terriberry | 50f214c | 2012-11-03 13:01:25 -0700 | [diff] [blame] | 1500 | &rfc6381; |
| 1501 | &rfc6716; |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1502 | |
Ralph Giles | cbb75cc | 2014-01-20 14:38:05 -0800 | [diff] [blame] | 1503 | <reference anchor="EBU-R128" target="https://tech.ebu.ch/loudness"> |
Ralph Giles | 360a411 | 2012-07-16 13:53:29 -0400 | [diff] [blame] | 1504 | <front> |
Ralph Giles | 864196b | 2014-01-20 12:32:11 -0800 | [diff] [blame] | 1505 | <title>Loudness Recommendation EBU R128</title> |
| 1506 | <author> |
| 1507 | <organization>EBU Technical Committee</organization> |
| 1508 | </author> |
| 1509 | <date month="August" year="2011"/> |
Timothy B. Terriberry | 396c4e5 | 2012-07-16 13:43:10 -0700 | [diff] [blame] | 1510 | </front> |
| 1511 | </reference> |
| 1512 | |
| 1513 | <reference anchor="vorbis-comment" |
Ralph Giles | cbb75cc | 2014-01-20 14:38:05 -0800 | [diff] [blame] | 1514 | target="https://www.xiph.org/vorbis/doc/v-comment.html"> |
Timothy B. Terriberry | 396c4e5 | 2012-07-16 13:43:10 -0700 | [diff] [blame] | 1515 | <front> |
| 1516 | <title>Ogg Vorbis I Format Specification: Comment Field and Header |
| 1517 | Specification</title> |
Ralph Giles | 360a411 | 2012-07-16 13:53:29 -0400 | [diff] [blame] | 1518 | <author initials="C." surname="Montgomery" |
| 1519 | fullname="Christopher "Monty" Montgomery"/> |
Timothy B. Terriberry | 50f214c | 2012-11-03 13:01:25 -0700 | [diff] [blame] | 1520 | <date month="July" year="2002"/> |
Ralph Giles | 360a411 | 2012-07-16 13:53:29 -0400 | [diff] [blame] | 1521 | </front> |
| 1522 | </reference> |
| 1523 | |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1524 | </references> |
| 1525 | |
| 1526 | <references title="Informative References"> |
| 1527 | |
| 1528 | <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml"?--> |
Timothy B. Terriberry | 50f214c | 2012-11-03 13:01:25 -0700 | [diff] [blame] | 1529 | &rfc4732; |
Ralph Giles | 5742f10 | 2014-01-20 13:40:36 -0800 | [diff] [blame] | 1530 | &rfc6982; |
Ralph Giles | 0c1487a | 2013-01-10 16:38:31 -0800 | [diff] [blame] | 1531 | |
Ralph Giles | 05bf400 | 2012-12-19 12:21:06 -0800 | [diff] [blame] | 1532 | <reference anchor="flac" |
| 1533 | target="https://xiph.org/flac/format.html"> |
| 1534 | <front> |
| 1535 | <title>FLAC - Free Lossless Audio Codec Format Description</title> |
| 1536 | <author initials="J." surname="Coalson" fullname="Josh Coalson"/> |
| 1537 | <date month="January" year="2008"/> |
| 1538 | </front> |
| 1539 | </reference> |
| 1540 | |
Ralph Giles | 9e85220 | 2013-05-25 01:20:00 +0800 | [diff] [blame] | 1541 | <reference anchor="hanning" |
Ralph Giles | c42c6db | 2014-01-17 15:36:03 -0800 | [diff] [blame] | 1542 | target="https://en.wikipedia.org/wiki/Hamming_function#Hann_.28Hanning.29_window"> |
Ralph Giles | 9e85220 | 2013-05-25 01:20:00 +0800 | [diff] [blame] | 1543 | <front> |
Ralph Giles | 74f6a01 | 2014-01-17 15:47:08 -0800 | [diff] [blame] | 1544 | <title>Hann window</title> |
Ralph Giles | 864196b | 2014-01-20 12:32:11 -0800 | [diff] [blame] | 1545 | <author> |
| 1546 | <organization>Wikipedia</organization> |
| 1547 | </author> |
Ralph Giles | 9e85220 | 2013-05-25 01:20:00 +0800 | [diff] [blame] | 1548 | <date month="May" year="2013"/> |
| 1549 | </front> |
| 1550 | </reference> |
| 1551 | |
Ralph Giles | c42c6db | 2014-01-17 15:36:03 -0800 | [diff] [blame] | 1552 | <reference anchor="linear-prediction" |
| 1553 | target="https://en.wikipedia.org/wiki/Linear_predictive_coding"> |
| 1554 | <front> |
Ralph Giles | 74f6a01 | 2014-01-17 15:47:08 -0800 | [diff] [blame] | 1555 | <title>Linear Predictive Coding</title> |
Ralph Giles | 864196b | 2014-01-20 12:32:11 -0800 | [diff] [blame] | 1556 | <author> |
| 1557 | <organization>Wikipedia</organization> |
| 1558 | </author> |
Ralph Giles | c42c6db | 2014-01-17 15:36:03 -0800 | [diff] [blame] | 1559 | <date month="January" year="2014"/> |
| 1560 | </front> |
| 1561 | </reference> |
| 1562 | |
Ralph Giles | 078775b | 2014-01-17 15:44:08 -0800 | [diff] [blame] | 1563 | <reference anchor="lpc-sample" |
| 1564 | target="https://svn.xiph.org/trunk/vorbis/lib/lpc.c"> |
| 1565 | <front> |
| 1566 | <title>Autocorrelation LPC coeff generation algorithm |
Ralph Giles | 26e31c0 | 2014-01-20 12:33:22 -0800 | [diff] [blame] | 1567 | (Vorbis source code)</title> |
Ralph Giles | 078775b | 2014-01-17 15:44:08 -0800 | [diff] [blame] | 1568 | <author initials="J." surname="Degener" fullname="Jutta Degener"/> |
| 1569 | <author initials="C." surname="Bormann" fullname="Carsten Bormann"/> |
| 1570 | <date month="November" year="1994"/> |
| 1571 | </front> |
| 1572 | </reference> |
| 1573 | |
| 1574 | |
Timothy B. Terriberry | 396c4e5 | 2012-07-16 13:43:10 -0700 | [diff] [blame] | 1575 | <reference anchor="replay-gain" |
Ralph Giles | cbb75cc | 2014-01-20 14:38:05 -0800 | [diff] [blame] | 1576 | target="https://wiki.xiph.org/VorbisComment#Replay_Gain"> |
Timothy B. Terriberry | 396c4e5 | 2012-07-16 13:43:10 -0700 | [diff] [blame] | 1577 | <front> |
| 1578 | <title>VorbisComment: Replay Gain</title> |
| 1579 | <author initials="C." surname="Parker" fullname="Conrad Parker"/> |
| 1580 | <author initials="M." surname="Leese" fullname="Martin Leese"/> |
Timothy B. Terriberry | 50f214c | 2012-11-03 13:01:25 -0700 | [diff] [blame] | 1581 | <date month="June" year="2009"/> |
Timothy B. Terriberry | 396c4e5 | 2012-07-16 13:43:10 -0700 | [diff] [blame] | 1582 | </front> |
| 1583 | </reference> |
| 1584 | |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 1585 | <reference anchor="seeking" |
Ralph Giles | cbb75cc | 2014-01-20 14:38:05 -0800 | [diff] [blame] | 1586 | target="https://wiki.xiph.org/Seeking"> |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 1587 | <front> |
| 1588 | <title>Granulepos Encoding and How Seeking Really Works</title> |
| 1589 | <author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer"/> |
| 1590 | <author initials="C." surname="Parker" fullname="Conrad Parker"/> |
| 1591 | <author initials="G." surname="Maxwell" fullname="Greg Maxwell"/> |
Timothy B. Terriberry | 50f214c | 2012-11-03 13:01:25 -0700 | [diff] [blame] | 1592 | <date month="May" year="2012"/> |
Timothy B. Terriberry | b374461 | 2012-07-16 13:17:27 -0700 | [diff] [blame] | 1593 | </front> |
| 1594 | </reference> |
| 1595 | |
Ralph Giles | 6bdbd26 | 2013-05-25 01:18:25 +0800 | [diff] [blame] | 1596 | <reference anchor="vorbis-mapping" |
Ralph Giles | cbb75cc | 2014-01-20 14:38:05 -0800 | [diff] [blame] | 1597 | target="https://www.xiph.org/vorbis/doc/Vorbis_I_spec.html#x1-800004.3.9"> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1598 | <front> |
Ralph Giles | 6bdbd26 | 2013-05-25 01:18:25 +0800 | [diff] [blame] | 1599 | <title>The Vorbis I Specification, Section 4.3.9 Output Channel Order</title> |
Timothy B. Terriberry | 396c4e5 | 2012-07-16 13:43:10 -0700 | [diff] [blame] | 1600 | <author initials="C." surname="Montgomery" |
| 1601 | fullname="Christopher "Monty" Montgomery"/> |
Ralph Giles | 6bdbd26 | 2013-05-25 01:18:25 +0800 | [diff] [blame] | 1602 | <date month="January" year="2010"/> |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1603 | </front> |
| 1604 | </reference> |
| 1605 | |
Ralph Giles | 6bdbd26 | 2013-05-25 01:18:25 +0800 | [diff] [blame] | 1606 | <reference anchor="vorbis-trim" |
Ralph Giles | cbb75cc | 2014-01-20 14:38:05 -0800 | [diff] [blame] | 1607 | target="https://xiph.org/vorbis/doc/Vorbis_I_spec.html#x1-130000A.2"> |
Ralph Giles | 6bdbd26 | 2013-05-25 01:18:25 +0800 | [diff] [blame] | 1608 | <front> |
| 1609 | <title>The Vorbis I Specification, Appendix A: Embedding Vorbis |
| 1610 | into an Ogg stream</title> |
| 1611 | <author initials="C." surname="Montgomery" |
| 1612 | fullname="Christopher "Monty" Montgomery"/> |
| 1613 | <date month="November" year="2008"/> |
| 1614 | </front> |
| 1615 | </reference> |
| 1616 | |
Ralph Giles | 05bf400 | 2012-12-19 12:21:06 -0800 | [diff] [blame] | 1617 | <reference anchor="wave-multichannel" |
| 1618 | target="http://msdn.microsoft.com/en-us/windows/hardware/gg463006.aspx"> |
| 1619 | <front> |
| 1620 | <title>Multiple Channel Audio Data and WAVE Files</title> |
Ralph Giles | 864196b | 2014-01-20 12:32:11 -0800 | [diff] [blame] | 1621 | <author> |
| 1622 | <organization>Microsoft Corporation</organization> |
| 1623 | </author> |
Ralph Giles | 05bf400 | 2012-12-19 12:21:06 -0800 | [diff] [blame] | 1624 | <date month="March" year="2007"/> |
| 1625 | </front> |
| 1626 | </reference> |
| 1627 | |
Timothy B. Terriberry | a2b2e0b | 2012-07-05 08:34:15 -0700 | [diff] [blame] | 1628 | </references> |
| 1629 | |
| 1630 | </back> |
| 1631 | </rfc> |