| OLD | NEW |
|---|
| (Empty) | |
| 1 <?xml version="1.0" encoding="UTF-8"?> |
| 2 <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ |
| 3 <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.2119.xml'> |
| 4 <!ENTITY rfc3550 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.3550.xml'> |
| 5 <!ENTITY rfc3711 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.3711.xml'> |
| 6 <!ENTITY rfc3551 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.3551.xml'> |
| 7 <!ENTITY rfc4288 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4288.xml'> |
| 8 <!ENTITY rfc4855 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4855.xml'> |
| 9 <!ENTITY rfc4566 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4566.xml'> |
| 10 <!ENTITY rfc3264 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.3264.xml'> |
| 11 <!ENTITY rfc2974 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.2974.xml'> |
| 12 <!ENTITY rfc2326 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.2326.xml'> |
| 13 <!ENTITY rfc3555 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.3555.xml'> |
| 14 <!ENTITY rfc5576 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5576.xml'> |
| 15 <!ENTITY rfc6562 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6562.xml'> |
| 16 <!ENTITY rfc6716 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6716.xml'> |
| 17 <!ENTITY nbsp " "> |
| 18 ]> |
| 19 |
| 20 <rfc category="std" ipr="trust200902" docName="draft-ietf-payload-rtp-opus-01"
> |
| 21 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> |
| 22 |
| 23 <?rfc strict="yes" ?> |
| 24 <?rfc toc="yes" ?> |
| 25 <?rfc tocdepth="3" ?> |
| 26 <?rfc tocappendix='no' ?> |
| 27 <?rfc tocindent='yes' ?> |
| 28 <?rfc symrefs="yes" ?> |
| 29 <?rfc sortrefs="yes" ?> |
| 30 <?rfc compact="no" ?> |
| 31 <?rfc subcompact="yes" ?> |
| 32 <?rfc iprnotified="yes" ?> |
| 33 |
| 34 <front> |
| 35 <title abbrev="RTP Payload Format for Opus Codec"> |
| 36 RTP Payload Format for Opus Speech and Audio Codec |
| 37 </title> |
| 38 |
| 39 <author fullname="Julian Spittka" initials="J." surname="Spittka"> |
| 40 <address> |
| 41 <email>jspittka@gmail.com</email> |
| 42 </address> |
| 43 </author> |
| 44 |
| 45 <author initials='K.' surname='Vos' fullname='Koen Vos'> |
| 46 <organization>Skype Technologies S.A.</organization> |
| 47 <address> |
| 48 <postal> |
| 49 <street>3210 Porter Drive</street> |
| 50 <code>94304</code> |
| 51 <city>Palo Alto</city> |
| 52 <region>CA</region> |
| 53 <country>USA</country> |
| 54 </postal> |
| 55 <email>koenvos74@gmail.com</email> |
| 56 </address> |
| 57 </author> |
| 58 |
| 59 <author initials="JM" surname="Valin" fullname="Jean-Marc Valin"> |
| 60 <organization>Mozilla</organization> |
| 61 <address> |
| 62 <postal> |
| 63 <street>650 Castro Street</street> |
| 64 <city>Mountain View</city> |
| 65 <region>CA</region> |
| 66 <code>94041</code> |
| 67 <country>USA</country> |
| 68 </postal> |
| 69 <email>jmvalin@jmvalin.ca</email> |
| 70 </address> |
| 71 </author> |
| 72 |
| 73 <date day='2' month='August' year='2013' /> |
| 74 |
| 75 <abstract> |
| 76 <t> |
| 77 This document defines the Real-time Transport Protocol (RTP) payload |
| 78 format for packetization of Opus encoded |
| 79 speech and audio data that is essential to integrate the codec in the |
| 80 most compatible way. Further, media type registrations |
| 81 are described for the RTP payload format. |
| 82 </t> |
| 83 </abstract> |
| 84 </front> |
| 85 |
| 86 <middle> |
| 87 <section title='Introduction'> |
| 88 <t> |
| 89 The Opus codec is a speech and audio codec developed within the |
| 90 IETF Internet Wideband Audio Codec working group (codec). The codec |
| 91 has a very low algorithmic delay and it |
| 92 is highly scalable in terms of audio bandwidth, bitrate, and |
| 93 complexity. Further, it provides different modes to efficiently encode s
peech signals |
| 94 as well as music signals, thus, making it the codec of choice for |
| 95 various applications using the Internet or similar networks. |
| 96 </t> |
| 97 <t> |
| 98 This document defines the Real-time Transport Protocol (RTP) |
| 99 <xref target="RFC3550"/> payload format for packetization |
| 100 of Opus encoded speech and audio data that is essential to |
| 101 integrate the Opus codec in the |
| 102 most compatible way. Further, media type registrations are described for |
| 103 the RTP payload format. More information on the Opus |
| 104 codec can be obtained from <xref target="RFC6716"/>. |
| 105 </t> |
| 106 </section> |
| 107 |
| 108 <section title='Conventions, Definitions and Acronyms used in this document'
> |
| 109 <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| 111 document are to be interpreted as described in <xref target="RFC2119"/>.</
t> |
| 112 <t> |
| 113 <list style='hanging'> |
| 114 <t hangText="CBR:"> Constant bitrate</t> |
| 115 <t hangText="CPU:"> Central Processing Unit</t> |
| 116 <t hangText="DTX:"> Discontinuous transmission</t> |
| 117 <t hangText="FEC:"> Forward error correction</t> |
| 118 <t hangText="IP:"> Internet Protocol</t> |
| 119 <t hangText="samples:"> Speech or audio samples (usually per chann
el)</t> |
| 120 <t hangText="SDP:"> Session Description Protocol</t> |
| 121 <t hangText="VBR:"> Variable bitrate</t> |
| 122 </list> |
| 123 </t> |
| 124 <section title='Audio Bandwidth'> |
| 125 <t> |
| 126 Throughout this document, we refer to the following definitions: |
| 127 </t> |
| 128 <texttable anchor='bandwidth_definitions'> |
| 129 <ttcol align='center'>Abbreviation</ttcol> |
| 130 <ttcol align='center'>Name</ttcol> |
| 131 <ttcol align='center'>Bandwidth</ttcol> |
| 132 <ttcol align='center'>Sampling</ttcol> |
| 133 <c>nb</c> |
| 134 <c>Narrowband</c> |
| 135 <c>0 - 4000</c> |
| 136 <c>8000</c> |
| 137 |
| 138 <c>mb</c> |
| 139 <c>Mediumband</c> |
| 140 <c>0 - 6000</c> |
| 141 <c>12000</c> |
| 142 |
| 143 <c>wb</c> |
| 144 <c>Wideband</c> |
| 145 <c>0 - 8000</c> |
| 146 <c>16000</c> |
| 147 |
| 148 <c>swb</c> |
| 149 <c>Super-wideband</c> |
| 150 <c>0 - 12000</c> |
| 151 <c>24000</c> |
| 152 |
| 153 <c>fb</c> |
| 154 <c>Fullband</c> |
| 155 <c>0 - 20000</c> |
| 156 <c>48000</c> |
| 157 |
| 158 <postamble> |
| 159 Audio bandwidth naming |
| 160 </postamble> |
| 161 </texttable> |
| 162 </section> |
| 163 </section> |
| 164 |
| 165 <section title='Opus Codec'> |
| 166 <t> |
| 167 The Opus <xref target="RFC6716"/> speech and audio codec has been develo
ped to encode speech |
| 168 signals as well as audio signals. Two different modes, a voice mode |
| 169 or an audio mode, may be chosen to allow the most efficient coding |
| 170 dependent on the type of input signal, the sampling frequency of the |
| 171 input signal, and the specific application. |
| 172 </t> |
| 173 |
| 174 <t> |
| 175 The voice mode allows efficient encoding of voice signals at lower bit |
| 176 rates while the audio mode is optimized for audio signals at medium and |
| 177 higher bitrates. |
| 178 </t> |
| 179 |
| 180 <t> |
| 181 The Opus speech and audio codec is highly scalable in terms of audio |
| 182 bandwidth, bitrate, and complexity. Further, Opus allows |
| 183 transmitting stereo signals. |
| 184 </t> |
| 185 |
| 186 <section title='Network Bandwidth'> |
| 187 <t> |
| 188 Opus supports all bitrates from 6 kb/s to 510 kb/s. |
| 189 The bitrate can be changed dynamically within that range. |
| 190 All |
| 191 other parameters being |
| 192 equal, higher bitrate results in higher quality. |
| 193 </t> |
| 194 <section title='Recommended Bitrate' anchor='bitrate_by_bandwidth'> |
| 195 <t> |
| 196 For a frame size of |
| 197 20 ms, these |
| 198 are the bitrate "sweet spots" for Opus in various configurations: |
| 199 |
| 200 <list style="symbols"> |
| 201 <t>8-12 kb/s for NB speech,</t> |
| 202 <t>16-20 kb/s for WB speech,</t> |
| 203 <t>28-40 kb/s for FB speech,</t> |
| 204 <t>48-64 kb/s for FB mono music, and</t> |
| 205 <t>64-128 kb/s for FB stereo music.</t> |
| 206 </list> |
| 207 </t> |
| 208 </section> |
| 209 <section title='Variable versus Constant Bit Rate' anchor='variable-vs-
constant-bitrate'> |
| 210 <t> |
| 211 For the same average bitrate, variable bitrate (VBR) can achieve hig
her quality |
| 212 than constant bitrate (CBR). For the majority of voice transmission
application, VBR |
| 213 is the best choice. One potential reason for choosing CBR is the pot
ential |
| 214 information leak that <spanx style='emph'>may</spanx> occur when enc
rypting the |
| 215 compressed stream. See <xref target="RFC6562"/> for guidelines on wh
en VBR is |
| 216 appropriate for encrypted audio communications. In the case where an
existing |
| 217 VBR stream needs to be converted to CBR for security reasons, then t
he Opus padding |
| 218 mechanism described in <xref target="RFC6716"/> is the RECOMMENDED w
ay to achieve padding |
| 219 because the RTP padding bit is unencrypted.</t> |
| 220 |
| 221 <t> |
| 222 The bitrate can be adjusted at any point in time. To avoid congestio
n, |
| 223 the average bitrate SHOULD be adjusted to the available |
| 224 network capacity. If no target bitrate is specified, the bitrates sp
ecified in |
| 225 <xref target='bitrate_by_bandwidth'/> are RECOMMENDED. |
| 226 </t> |
| 227 |
| 228 </section> |
| 229 |
| 230 <section title='Discontinuous Transmission (DTX)'> |
| 231 |
| 232 <t> |
| 233 The Opus codec may, as described in <xref target='variable-vs-consta
nt-bitrate'/>, |
| 234 be operated with an adaptive bitrate. In that case, the bitrate |
| 235 will automatically be reduced for certain input signals like periods |
| 236 of silence. During continuous transmission the bitrate will be |
| 237 reduced, when the input signal allows to do so, but the transmission |
| 238 to the receiver itself will never be interrupted. Therefore, the |
| 239 received signal will maintain the same high level of quality over th
e |
| 240 full duration of a transmission while minimizing the average bit |
| 241 rate over time. |
| 242 </t> |
| 243 |
| 244 <t> |
| 245 In cases where the bitrate of Opus needs to be reduced even |
| 246 further or in cases where only constant bitrate is available, |
| 247 the Opus encoder may be set to use discontinuous |
| 248 transmission (DTX), where parts of the encoded signal that |
| 249 correspond to periods of silence in the input speech or audio signal |
| 250 are not transmitted to the receiver. |
| 251 </t> |
| 252 |
| 253 <t> |
| 254 On the receiving side, the non-transmitted parts will be handled by
a |
| 255 frame loss concealment unit in the Opus decoder which generates a |
| 256 comfort noise signal to replace the non transmitted parts of the |
| 257 speech or audio signal. |
| 258 </t> |
| 259 |
| 260 <t> |
| 261 The DTX mode of Opus will have a slightly lower speech or audio |
| 262 quality than the continuous mode. Therefore, it is RECOMMENDED to |
| 263 use Opus in the continuous mode unless restraints on network |
| 264 capacity are severe. The DTX mode can be engaged for operation |
| 265 in both adaptive or constant bitrate. |
| 266 </t> |
| 267 |
| 268 </section> |
| 269 |
| 270 </section> |
| 271 |
| 272 <section title='Complexity'> |
| 273 |
| 274 <t> |
| 275 Complexity can be scaled to optimize for CPU resources in real-time, m
ostly as |
| 276 a trade-off between audio quality and bitrate. Also, different modes o
f Opus have different complexity. |
| 277 </t> |
| 278 |
| 279 </section> |
| 280 |
| 281 <section title="Forward Error Correction (FEC)"> |
| 282 |
| 283 <t> |
| 284 The voice mode of Opus allows for "in-band" forward error correction (
FEC) |
| 285 data to be embedded into the bit stream of Opus. This FEC scheme adds |
| 286 redundant information about the previous packet (n-1) to the current |
| 287 output packet n. For |
| 288 each frame, the encoder decides whether to use FEC based on (1) an |
| 289 externally-provided estimate of the channel's packet loss rate; (2) an |
| 290 externally-provided estimate of the channel's capacity; (3) the |
| 291 sensitivity of the audio or speech signal to packet loss; (4) whether |
| 292 the receiving decoder has indicated it can take advantage of "in-band" |
| 293 FEC information. The decision to send "in-band" FEC information is |
| 294 entirely controlled by the encoder and therefore no special precaution
s |
| 295 for the payload have to be taken. |
| 296 </t> |
| 297 |
| 298 <t> |
| 299 On the receiving side, the decoder can take advantage of this |
| 300 additional information when, in case of a packet loss, the next packet |
| 301 is available. In order to use the FEC data, the jitter buffer needs |
| 302 to provide access to payloads with the FEC data. The decoder API func
tion |
| 303 has a flag to indicate that a FEC frame rather than a regular frame sh
ould |
| 304 be decoded. If no FEC data is available for the current frame, the de
coder |
| 305 will consider the frame lost and invokes the frame loss concealment. |
| 306 </t> |
| 307 |
| 308 <t> |
| 309 If the FEC scheme is not implemented on the receiving side, FEC |
| 310 SHOULD NOT be used, as it leads to an inefficient usage of network |
| 311 resources. Decoder support for FEC SHOULD be indicated at the time a |
| 312 session is set up. |
| 313 </t> |
| 314 |
| 315 </section> |
| 316 |
| 317 <section title='Stereo Operation'> |
| 318 |
| 319 <t> |
| 320 Opus allows for transmission of stereo audio signals. This operation |
| 321 is signaled in-band in the Opus payload and no special arrangement |
| 322 is required in the payload format. Any implementation of the Opus |
| 323 decoder MUST be capable of receiving stereo signals, although it MAY |
| 324 decode those signals as mono. |
| 325 </t> |
| 326 <t> |
| 327 If a decoder can not take advantage of the benefits of a stereo signal |
| 328 this SHOULD be indicated at the time a session is set up. In that case |
| 329 the sending side SHOULD NOT send stereo signals as it leads to an |
| 330 inefficient usage of the network. |
| 331 </t> |
| 332 |
| 333 </section> |
| 334 |
| 335 </section> |
| 336 |
| 337 <section title='Opus RTP Payload Format' anchor='opus-rtp-payload-format'> |
| 338 <t>The payload format for Opus consists of the RTP header and Opus payload |
| 339 data.</t> |
| 340 <section title='RTP Header Usage'> |
| 341 <t>The format of the RTP header is specified in <xref target="RFC3550"/>
. The Opus |
| 342 payload format uses the fields of the RTP header consistent with this |
| 343 specification.</t> |
| 344 |
| 345 <t>The payload length of Opus is a multiple number of octets and |
| 346 therefore no padding is required. The payload MAY be padded by an |
| 347 integer number of octets according to <xref target="RFC3550"/>.</t> |
| 348 |
| 349 <t>The marker bit (M) of the RTP header is used in accordance with |
| 350 Section 4.1 of <xref target="RFC3551"/>.</t> |
| 351 |
| 352 <t>The RTP payload type for Opus has not been assigned statically and is |
| 353 expected to be assigned dynamically.</t> |
| 354 |
| 355 <t>The receiving side MUST be prepared to receive duplicates of RTP |
| 356 packets. Only one of those payloads MUST be provided to the Opus decoder |
| 357 for decoding and others MUST be discarded.</t> |
| 358 |
| 359 <t>Opus supports 5 different audio bandwidths which may be adjusted duri
ng |
| 360 the duration of a call. The RTP timestamp clock frequency is defined as |
| 361 the highest supported sampling frequency of Opus, i.e. 48000 Hz, for all |
| 362 modes and sampling rates of Opus. The unit |
| 363 for the timestamp is samples per single (mono) channel. The RTP timestam
p corresponds to the |
| 364 sample time of the first encoded sample in the encoded frame. For sampli
ng |
| 365 rates lower than 48000 Hz the number of samples has to be multiplied wit
h |
| 366 a multiplier according to <xref target="fs-upsample-factors"/> to determ
ine |
| 367 the RTP timestamp.</t> |
| 368 |
| 369 <texttable anchor='fs-upsample-factors' title="Timestamp multiplier"> |
| 370 <ttcol align='center'>fs (Hz)</ttcol> |
| 371 <ttcol align='center'>Multiplier</ttcol> |
| 372 <c>8000</c> |
| 373 <c>6</c> |
| 374 <c>12000</c> |
| 375 <c>4</c> |
| 376 <c>16000</c> |
| 377 <c>3</c> |
| 378 <c>24000</c> |
| 379 <c>2</c> |
| 380 <c>48000</c> |
| 381 <c>1</c> |
| 382 </texttable> |
| 383 </section> |
| 384 |
| 385 <section title='Payload Structure'> |
| 386 <t> |
| 387 The Opus encoder can be set to output encoded frames representing 2.5,
5, 10, 20, |
| 388 40, or 60 ms of speech or audio data. Further, an arbitrary number of
frames can be |
| 389 combined into a packet. The maximum packet length is limited to the am
ount of encoded |
| 390 data representing 120 ms of speech or audio data. The packetization of
encoded data |
| 391 is purely done by the Opus encoder and therefore only one packet outpu
t from the Opus |
| 392 encoder MUST be used as a payload. |
| 393 </t> |
| 394 |
| 395 <t><xref target='payload-structure'/> shows the structure combined with
the RTP header.</t> |
| 396 |
| 397 <figure anchor="payload-structure" |
| 398 title="Payload Structure with RTP header"> |
| 399 <artwork> |
| 400 <![CDATA[ |
| 401 +----------+--------------+ |
| 402 |RTP Header| Opus Payload | |
| 403 +----------+--------------+ |
| 404 ]]> |
| 405 </artwork> |
| 406 </figure> |
| 407 |
| 408 <t> |
| 409 <xref target='opus-packetization'/> shows supported frame sizes in |
| 410 milliseconds of encoded speech or audio data for speech and audio mode
|
| 411 (Mode) and sampling rates (fs) of Opus and how the timestamp needs to |
| 412 be incremented for packetization (ts incr). If the Opus encoder |
| 413 outputs multiple encoded frames into a single packet the timestamps |
| 414 have to be added up according to the combined frames. |
| 415 </t> |
| 416 |
| 417 <texttable anchor='opus-packetization' title="Supported Opus frame |
| 418 sizes and timestamp increments"> |
| 419 <ttcol align='center'>Mode</ttcol> |
| 420 <ttcol align='center'>fs</ttcol> |
| 421 <ttcol align='center'>2.5</ttcol> |
| 422 <ttcol align='center'>5</ttcol> |
| 423 <ttcol align='center'>10</ttcol> |
| 424 <ttcol align='center'>20</ttcol> |
| 425 <ttcol align='center'>40</ttcol> |
| 426 <ttcol align='center'>60</ttcol> |
| 427 <c>ts incr</c> |
| 428 <c>all</c> |
| 429 <c>120</c> |
| 430 <c>240</c> |
| 431 <c>480</c> |
| 432 <c>960</c> |
| 433 <c>1920</c> |
| 434 <c>2880</c> |
| 435 <c>voice</c> |
| 436 <c>nb/mb/wb/swb/fb</c> |
| 437 <c></c> |
| 438 <c></c> |
| 439 <c>x</c> |
| 440 <c>x</c> |
| 441 <c>x</c> |
| 442 <c>x</c> |
| 443 <c>audio</c> |
| 444 <c>nb/wb/swb/fb</c> |
| 445 <c>x</c> |
| 446 <c>x</c> |
| 447 <c>x</c> |
| 448 <c>x</c> |
| 449 <c></c> |
| 450 <c></c> |
| 451 </texttable> |
| 452 |
| 453 </section> |
| 454 |
| 455 </section> |
| 456 |
| 457 <section title='Congestion Control'> |
| 458 |
| 459 <t>The adaptive nature of the Opus codec allows for an efficient |
| 460 congestion control.</t> |
| 461 |
| 462 <t>The target bitrate of Opus can be adjusted at any point in time and |
| 463 thus allowing for an efficient congestion control. Furthermore, the amount |
| 464 of encoded speech or audio data encoded in a |
| 465 single packet can be used for congestion control since the transmission |
| 466 rate is inversely proportional to these frame sizes. A lower packet |
| 467 transmission rate reduces the amount of header overhead but at the same |
| 468 time increases latency and error sensitivity and should be done with care.
</t> |
| 469 |
| 470 <t>It is RECOMMENDED that congestion control is applied during the |
| 471 transmission of Opus encoded data.</t> |
| 472 </section> |
| 473 |
| 474 <section title='IANA Considerations'> |
| 475 <t>One media subtype (audio/opus) has been defined and registered as |
| 476 described in the following section.</t> |
| 477 |
| 478 <section title='Opus Media Type Registration'> |
| 479 <t>Media type registration is done according to <xref |
| 480 target="RFC4288"/> and <xref target="RFC4855"/>.<vspace |
| 481 blankLines='1'/></t> |
| 482 |
| 483 <t>Type name: audio<vspace blankLines='1'/></t> |
| 484 <t>Subtype name: opus<vspace blankLines='1'/></t> |
| 485 |
| 486 <t>Required parameters:</t> |
| 487 <t><list style="hanging"> |
| 488 <t hangText="rate:"> RTP timestamp clock rate is incremented with |
| 489 48000 Hz clock rate for all modes of Opus and all sampling |
| 490 frequencies. For audio sampling rates other than 48000 Hz the rate |
| 491 has to be adjusted to 48000 Hz according to <xref target="fs-upsampl
e-factors"/>. |
| 492 </t> |
| 493 </list></t> |
| 494 |
| 495 <t>Optional parameters:</t> |
| 496 |
| 497 <t><list style="hanging"> |
| 498 <t hangText="maxplaybackrate:"> |
| 499 a hint about the maximum output sampling rate that the receiver is |
| 500 capable of rendering in Hz. |
| 501 The decoder MUST be capable of decoding |
| 502 any audio bandwidth but due to hardware limitations only signals |
| 503 up to the specified sampling rate can be played back. Sending sign
als |
| 504 with higher audio bandwidth results in higher than necessary netwo
rk |
| 505 usage and encoding complexity, so an encoder SHOULD NOT encode |
| 506 frequencies above the audio bandwidth specified by maxplaybackrate
. |
| 507 This parameter can take any value between 8000 and 48000, although |
| 508 commonly the value will match one of the Opus bandwidths |
| 509 (<xref target="bandwidth_definitions"/>). |
| 510 By default, the receiver is assumed to have no limitations, i.e. 4
8000. |
| 511 <vspace blankLines='1'/> |
| 512 </t> |
| 513 |
| 514 <t hangText="sprop-maxcapturerate:"> |
| 515 a hint about the maximum input sampling rate that the sender is li
kely to produce. |
| 516 This is not a guarantee that the sender will never send any higher
bandwidth |
| 517 (e.g. it could send a pre-recorded prompt that uses a higher bandw
idth), but it |
| 518 indicates to the receiver that frequencies above this maximum can
safely be discarded. |
| 519 This parameter is useful to avoid wasting receiver resources by op
erating the audio |
| 520 processing pipeline (e.g. echo cancellation) at a higher rate than
necessary. |
| 521 This parameter can take any value between 8000 and 48000, although |
| 522 commonly the value will match one of the Opus bandwidths |
| 523 (<xref target="bandwidth_definitions"/>). |
| 524 By default, the sender is assumed to have no limitations, i.e. 480
00. |
| 525 <vspace blankLines='1'/> |
| 526 </t> |
| 527 |
| 528 <t hangText="maxptime:"> the decoder's maximum length of time in |
| 529 milliseconds rounded up to the next full integer value represented |
| 530 by the media in a packet that can be |
| 531 encapsulated in a received packet according to Section 6 of |
| 532 <xref target="RFC4566"/>. Possible values are 3, 5, 10, 20, 40, |
| 533 and 60 or an arbitrary multiple of Opus frame sizes rounded up to |
| 534 the next full integer value up to a maximum value of 120 as |
| 535 defined in <xref target='opus-rtp-payload-format'/>. If no value is |
| 536 specified, 120 is assumed as default. This value is a recommendati
on |
| 537 by the decoding side to ensure the best |
| 538 performance for the decoder. The decoder MUST be |
| 539 capable of accepting any allowed packet sizes to |
| 540 ensure maximum compatibility. |
| 541 <vspace blankLines='1'/></t> |
| 542 |
| 543 <t hangText="ptime:"> the decoder's recommended length of time in |
| 544 milliseconds rounded up to the next full integer value represented |
| 545 by the media in a packet according to |
| 546 Section 6 of <xref target="RFC4566"/>. Possible values are |
| 547 3, 5, 10, 20, 40, or 60 or an arbitrary multiple of Opus frame sizes |
| 548 rounded up to the next full integer value up to a maximum |
| 549 value of 120 as defined in <xref |
| 550 target='opus-rtp-payload-format'/>. If no value is |
| 551 specified, 20 is assumed as default. If ptime is greater than |
| 552 maxptime, ptime MUST be ignored. This parameter MAY be changed |
| 553 during a session. This value is a recommendation by the decoding |
| 554 side to ensure the best |
| 555 performance for the decoder. The decoder MUST be |
| 556 capable of accepting any allowed packet sizes to |
| 557 ensure maximum compatibility. |
| 558 <vspace blankLines='1'/></t> |
| 559 |
| 560 <t hangText="minptime:"> the decoder's minimum length of time in |
| 561 milliseconds rounded up to the next full integer value represented |
| 562 by the media in a packet that SHOULD |
| 563 be encapsulated in a received packet according to Section 6 of <xref |
| 564 target="RFC4566"/>. Possible values are 3, 5, 10, 20, 40, and 60 |
| 565 or an arbitrary multiple of Opus frame sizes rounded up to the next |
| 566 full integer value up to a maximum value of 120 |
| 567 as defined in <xref target='opus-rtp-payload-format'/>. If no value
is |
| 568 specified, 3 is assumed as default. This value is a recommendation |
| 569 by the decoding side to ensure the best |
| 570 performance for the decoder. The decoder MUST be |
| 571 capable to accept any allowed packet sizes to |
| 572 ensure maximum compatibility. |
| 573 <vspace blankLines='1'/></t> |
| 574 |
| 575 <t hangText="maxaveragebitrate:"> specifies the maximum average |
| 576 receive bitrate of a session in bits per second (b/s). The actual |
| 577 value of the bitrate may vary as it is dependent on the |
| 578 characteristics of the media in a packet. Note that the maximum |
| 579 average bitrate MAY be modified dynamically during a session. Any |
| 580 positive integer is allowed but values outside the range between |
| 581 6000 and 510000 SHOULD be ignored. If no value is specified, the |
| 582 maximum value specified in <xref target='bitrate_by_bandwidth'/> |
| 583 for the corresponding mode of Opus and corresponding maxplaybackrate
: |
| 584 will be the default.<vspace blankLines='1'/></t> |
| 585 |
| 586 <t hangText="stereo:"> |
| 587 specifies whether the decoder prefers receiving stereo or mono sig
nals. |
| 588 Possible values are 1 and 0 where 1 specifies that stereo signals
are preferred |
| 589 and 0 specifies that only mono signals are preferred. |
| 590 Independent of the stereo parameter every receiver MUST be able to
receive and |
| 591 decode stereo signals but sending stereo signals to a receiver tha
t signaled a |
| 592 preference for mono signals may result in higher than necessary ne
twork |
| 593 utilisation and encoding complexity. If no value is specified, mon
o |
| 594 is assumed (stereo=0).<vspace blankLines='1'/> |
| 595 </t> |
| 596 |
| 597 <t hangText="sprop-stereo:"> |
| 598 specifies whether the sender is likely to produce stereo audio. |
| 599 Possible values are 1 and 0 where 1 specifies that stereo signals
are likely to |
| 600 be sent, and 0 speficies that the sender will likely only send mon
o. |
| 601 This is not a guarantee that the sender will never send stereo aud
io |
| 602 (e.g. it could send a pre-recorded prompt that uses stereo), but i
t |
| 603 indicates to the receiver that the received signal can be safely d
ownmixed to mono. |
| 604 This parameter is useful to avoid wasting receiver resources by op
erating the audio |
| 605 processing pipeline (e.g. echo cancellation) in stereo when not ne
cessary. |
| 606 If no value is specified, mono |
| 607 is assumed (sprop-stereo=0).<vspace blankLines='1'/> |
| 608 </t> |
| 609 |
| 610 <t hangText="cbr:"> |
| 611 specifies if the decoder prefers the use of a constant bitrate ver
sus |
| 612 variable bitrate. Possible values are 1 and 0 where 1 specifies co
nstant |
| 613 bitrate and 0 specifies variable bitrate. If no value is specified
, cbr |
| 614 is assumed to be 0. Note that the maximum average bitrate may stil
l be |
| 615 changed, e.g. to adapt to changing network conditions.<vspace blan
kLines='1'/> |
| 616 </t> |
| 617 |
| 618 <t hangText="useinbandfec:"> specifies that the decoder has the capa
bility to |
| 619 take advantage of the Opus in-band FEC. Possible values are 1 and 0.
It is RECOMMENDED to provide |
| 620 0 in case FEC cannot be utilized on the receiving side. If no |
| 621 value is specified, useinbandfec is assumed to be 0. |
| 622 This parameter is only a preference and the receiver MUST be able to
process |
| 623 packets that include FEC information, even if it means the FEC part
is discarded. |
| 624 <vspace blankLines='1'/></t> |
| 625 |
| 626 <t hangText="usedtx:"> specifies if the decoder prefers the use of |
| 627 DTX. Possible values are 1 and 0. If no value is specified, usedtx |
| 628 is assumed to be 0.<vspace blankLines='1'/></t> |
| 629 </list></t> |
| 630 |
| 631 <t>Encoding considerations:<vspace blankLines='1'/></t> |
| 632 <t><list style="hanging"> |
| 633 <t>Opus media type is framed and consists of binary data according |
| 634 to Section 4.8 in <xref target="RFC4288"/>.</t> |
| 635 </list></t> |
| 636 |
| 637 <t>Security considerations: </t> |
| 638 <t><list style="hanging"> |
| 639 <t>See <xref target='security-considerations'/> of this document.</t
> |
| 640 </list></t> |
| 641 |
| 642 <t>Interoperability considerations: none<vspace blankLines='1'/></t> |
| 643 <t>Published specification: none<vspace blankLines='1'/></t> |
| 644 |
| 645 <t>Applications that use this media type: </t> |
| 646 <t><list style="hanging"> |
| 647 <t>Any application that requires the transport of |
| 648 speech or audio data may use this media type. Some examples are, |
| 649 but not limited to, audio and video conferencing, Voice over IP, |
| 650 media streaming.</t> |
| 651 </list></t> |
| 652 |
| 653 <t>Person & email address to contact for further information:</t> |
| 654 <t><list style="hanging"> |
| 655 <t>SILK Support silksupport@skype.net</t> |
| 656 <t>Jean-Marc Valin jmvalin@jmvalin.ca</t> |
| 657 </list></t> |
| 658 |
| 659 <t>Intended usage: COMMON<vspace blankLines='1'/></t> |
| 660 |
| 661 <t>Restrictions on usage:<vspace blankLines='1'/></t> |
| 662 |
| 663 <t><list style="hanging"> |
| 664 <t>For transfer over RTP, the RTP payload format (<xref |
| 665 target='opus-rtp-payload-format'/> of this document) SHALL be |
| 666 used.</t> |
| 667 </list></t> |
| 668 |
| 669 <t>Author:</t> |
| 670 <t><list style="hanging"> |
| 671 <t>Julian Spittka jspittka@gmail.com<vspace blankLines='1'/></t> |
| 672 <t>Koen Vos koenvos74@gmail.com<vspace blankLines='1'/></t> |
| 673 <t>Jean-Marc Valin jmvalin@jmvalin.ca<vspace blankLines='1'/></t> |
| 674 </list></t> |
| 675 |
| 676 <t> Change controller: TBD</t> |
| 677 </section> |
| 678 |
| 679 <section title='Mapping to SDP Parameters'> |
| 680 <t>The information described in the media type specification has a |
| 681 specific mapping to fields in the Session Description Protocol (SDP) |
| 682 <xref target="RFC4566"/>, which is commonly used to describe RTP |
| 683 sessions. When SDP is used to specify sessions employing the Opus codec, |
| 684 the mapping is as follows:</t> |
| 685 |
| 686 <t> |
| 687 <list style="symbols"> |
| 688 <t>The media type ("audio") goes in SDP "m=" as the media name.</t> |
| 689 |
| 690 <t>The media subtype ("opus") goes in SDP "a=rtpmap" as the encoding |
| 691 name. The RTP clock rate in "a=rtpmap" MUST be 48000 and the number
of |
| 692 channels MUST be 2.</t> |
| 693 |
| 694 <t>The OPTIONAL media type parameters "ptime" and "maxptime" are |
| 695 mapped to "a=ptime" and "a=maxptime" attributes, respectively, in th
e |
| 696 SDP.</t> |
| 697 |
| 698 <t>The OPTIONAL media type parameters "maxaveragebitrate", |
| 699 "maxplaybackrate", "minptime", "stereo", "cbr", "useinbandfec", and |
| 700 "usedtx", when present, MUST be included in the "a=fmtp" attribute |
| 701 in the SDP, expressed as a media type string in the form of a |
| 702 semicolon-separated list of parameter=value pairs (e.g., |
| 703 maxaveragebitrate=20000). They MUST NOT be specified in an |
| 704 SSRC-specific "fmtp" source-level attribute (as defined in |
| 705 Section 6.3 of <xref target="RFC5576"/>).</t> |
| 706 |
| 707 <t>The OPTIONAL media type parameters "sprop-maxcapturerate", |
| 708 and "sprop-stereo" MAY be mapped to the "a=fmtp" SDP attribute by |
| 709 copying them directly from the media type parameter string as part |
| 710 of the semicolon-separated list of parameter=value pairs (e.g., |
| 711 sprop-stereo=1). These same OPTIONAL media type parameters MAY also |
| 712 be specified using an SSRC-specific "fmtp" source-level attribute |
| 713 as described in Section 6.3 of <xref target="RFC5576"/>. |
| 714 They MAY be specified in both places, in which case the parameter |
| 715 in the source-level attribute overrides the one found on the |
| 716 "a=fmtp" line. The value of any parameter which is not specified in |
| 717 a source-level source attribute MUST be taken from the "a=fmtp" |
| 718 line, if it is present there.</t> |
| 719 |
| 720 </list> |
| 721 </t> |
| 722 |
| 723 <t>Below are some examples of SDP session descriptions for Opus:</t> |
| 724 |
| 725 <t>Example 1: Standard mono session with 48000 Hz clock rate</t> |
| 726 <figure> |
| 727 <artwork> |
| 728 <![CDATA[ |
| 729 m=audio 54312 RTP/AVP 101 |
| 730 a=rtpmap:101 opus/48000/2 |
| 731 ]]> |
| 732 </artwork> |
| 733 </figure> |
| 734 |
| 735 |
| 736 <t>Example 2: 16000 Hz clock rate, maximum packet size of 40 ms, |
| 737 recommended packet size of 40 ms, maximum average bitrate of 20000 bps, |
| 738 prefers to receive stereo but only plans to send mono, FEC is allowed, |
| 739 DTX is not allowed</t> |
| 740 |
| 741 <figure> |
| 742 <artwork> |
| 743 <![CDATA[ |
| 744 m=audio 54312 RTP/AVP 101 |
| 745 a=rtpmap:101 opus/48000/2 |
| 746 a=fmtp:101 maxplaybackrate=16000; sprop-maxcapturerate=16000; |
| 747 maxaveragebitrate=20000; stereo=1; useinbandfec=1; usedtx=0 |
| 748 a=ptime:40 |
| 749 a=maxptime:40 |
| 750 ]]> |
| 751 </artwork> |
| 752 </figure> |
| 753 |
| 754 <t>Example 3: Two-way full-band stereo preferred</t> |
| 755 |
| 756 <figure> |
| 757 <artwork> |
| 758 <![CDATA[ |
| 759 m=audio 54312 RTP/AVP 101 |
| 760 a=rtpmap:101 opus/48000/2 |
| 761 a=fmtp:101 stereo=1; sprop-stereo=1 |
| 762 ]]> |
| 763 </artwork> |
| 764 </figure> |
| 765 |
| 766 |
| 767 <section title='Offer-Answer Model Considerations for Opus'> |
| 768 |
| 769 <t>When using the offer-answer procedure described in <xref |
| 770 target="RFC3264"/> to negotiate the use of Opus, the following |
| 771 considerations apply:</t> |
| 772 |
| 773 <t><list style="symbols"> |
| 774 |
| 775 <t>Opus supports several clock rates. For signaling purposes only |
| 776 the highest, i.e. 48000, is used. The actual clock rate of the |
| 777 corresponding media is signaled inside the payload and is not |
| 778 subject to this payload format description. The decoder MUST be |
| 779 capable to decode every received clock rate. An example |
| 780 is shown below: |
| 781 |
| 782 <figure> |
| 783 <artwork> |
| 784 <![CDATA[ |
| 785 m=audio 54312 RTP/AVP 100 |
| 786 a=rtpmap:100 opus/48000/2 |
| 787 ]]> |
| 788 </artwork> |
| 789 </figure> |
| 790 </t> |
| 791 |
| 792 <t>The "ptime" and "maxptime" parameters are unidirectional |
| 793 receive-only parameters and typically will not compromise |
| 794 interoperability; however, dependent on the set values of the |
| 795 parameters the performance of the application may suffer. <xref |
| 796 target="RFC3264"/> defines the SDP offer-answer handling of the |
| 797 "ptime" parameter. The "maxptime" parameter MUST be handled in the |
| 798 same way.</t> |
| 799 |
| 800 <t> |
| 801 The "minptime" parameter is a unidirectional |
| 802 receive-only parameters and typically will not compromise |
| 803 interoperability; however, dependent on the set values of the |
| 804 parameter the performance of the application may suffer and should
be |
| 805 set with care. |
| 806 </t> |
| 807 |
| 808 <t> |
| 809 The "maxplaybackrate" parameter is a unidirectional receive-only |
| 810 parameter that reflects limitations of the local receiver. The sen
der |
| 811 of the other side SHOULD NOT send with an audio bandwidth higher t
han |
| 812 "maxplaybackrate" as this would lead to inefficient use of network
resources. |
| 813 The "maxplaybackrate" parameter does not |
| 814 affect interoperability. Also, this parameter SHOULD NOT be used |
| 815 to adjust the audio bandwidth as a function of the bitrates, as th
is |
| 816 is the responsibility of the Opus encoder implementation. |
| 817 </t> |
| 818 |
| 819 <t>The "maxaveragebitrate" parameter is a unidirectional receive-onl
y |
| 820 parameter that reflects limitations of the local receiver. The sende
r |
| 821 of the other side MUST NOT send with an average bitrate higher than |
| 822 "maxaveragebitrate" as it might overload the network and/or |
| 823 receiver. The "maxaveragebitrate" parameter typically will not |
| 824 compromise interoperability; however, dependent on the set value of |
| 825 the parameter the performance of the application may suffer and shou
ld |
| 826 be set with care.</t> |
| 827 |
| 828 <t>The "sprop-maxcapturerate" and "sprop-stereo" parameters are |
| 829 unidirectional sender-only parameters that reflect limitations of |
| 830 the sender side. |
| 831 They allow the receiver to set up a reduced-complexity audio |
| 832 processing pipeline if the sender is not planning to use the full |
| 833 range of Opus's capabilities. |
| 834 Neither "sprop-maxcapturerate" nor "sprop-stereo" affect |
| 835 interoperability and the receiver MUST be capable of receiving any s
ignal. |
| 836 </t> |
| 837 |
| 838 <t> |
| 839 The "stereo" parameter is a unidirectional receive-only |
| 840 parameter. |
| 841 </t> |
| 842 |
| 843 <t> |
| 844 The "cbr" parameter is a unidirectional receive-only |
| 845 parameter. |
| 846 </t> |
| 847 |
| 848 <t>The "useinbandfec" parameter is a unidirectional receive-only |
| 849 parameter.</t> |
| 850 |
| 851 <t>The "usedtx" parameter is a unidirectional receive-only |
| 852 parameter.</t> |
| 853 |
| 854 <t>Any unknown parameter in an offer MUST be ignored by the receiver |
| 855 and MUST be removed from the answer.</t> |
| 856 |
| 857 </list></t> |
| 858 </section> |
| 859 |
| 860 <section title='Declarative SDP Considerations for Opus'> |
| 861 |
| 862 <t>For declarative use of SDP such as in Session Announcement Protocol |
| 863 (SAP), <xref target="RFC2974"/>, and RTSP, <xref target="RFC2326"/>, for |
| 864 Opus, the following needs to be considered:</t> |
| 865 |
| 866 <t><list style="symbols"> |
| 867 |
| 868 <t>The values for "maxptime", "ptime", "minptime", "maxplaybackrate",
and |
| 869 "maxaveragebitrate" should be selected carefully to ensure that a |
| 870 reasonable performance can be achieved for the participants of a sessi
on.</t> |
| 871 |
| 872 <t> |
| 873 The values for "maxptime", "ptime", and "minptime" of the payload |
| 874 format configuration are recommendations by the decoding side to ens
ure |
| 875 the best performance for the decoder. The decoder MUST be |
| 876 capable to accept any allowed packet sizes to |
| 877 ensure maximum compatibility. |
| 878 </t> |
| 879 |
| 880 <t>All other parameters of the payload format configuration are declar
ative |
| 881 and a participant MUST use the configurations that are provided for |
| 882 the session. More than one configuration may be provided if necessary |
| 883 by declaring multiple RTP payload types; however, the number of types |
| 884 should be kept small.</t> |
| 885 </list></t> |
| 886 </section> |
| 887 </section> |
| 888 </section> |
| 889 |
| 890 <section title='Security Considerations' anchor='security-considerations'> |
| 891 |
| 892 <t>All RTP packets using the payload format defined in this specification |
| 893 are subject to the general security considerations discussed in the RTP |
| 894 specification <xref target="RFC3550"/> and any profile from |
| 895 e.g. <xref target="RFC3711"/> or <xref target="RFC3551"/>.</t> |
| 896 |
| 897 <t>This payload format transports Opus encoded speech or audio data, |
| 898 hence, security issues include confidentiality, integrity protection, and |
| 899 authentication of the speech or audio itself. The Opus payload format does |
| 900 not have any built-in security mechanisms. Any suitable external |
| 901 mechanisms, such as SRTP <xref target="RFC3711"/>, MAY be used.</t> |
| 902 |
| 903 <t>This payload format and the Opus encoding do not exhibit any |
| 904 significant non-uniformity in the receiver-end computational load and thus |
| 905 are unlikely to pose a denial-of-service threat due to the receipt of |
| 906 pathological datagrams.</t> |
| 907 </section> |
| 908 |
| 909 <section title='Acknowledgements'> |
| 910 <t>TBD</t> |
| 911 </section> |
| 912 </middle> |
| 913 |
| 914 <back> |
| 915 <references title="Normative References"> |
| 916 &rfc2119; |
| 917 &rfc3550; |
| 918 &rfc3711; |
| 919 &rfc3551; |
| 920 &rfc4288; |
| 921 &rfc4855; |
| 922 &rfc4566; |
| 923 &rfc3264; |
| 924 &rfc2974; |
| 925 &rfc2326; |
| 926 &rfc5576; |
| 927 &rfc6562; |
| 928 &rfc6716; |
| 929 </references> |
| 930 |
| 931 </back> |
| 932 </rfc> |
| OLD | NEW |
|---|
Chromium Code Reviews
Issue 28553003:
Updating Opus to a pre-release of 1.1 (Closed)
Base URL: svn://svn.chromium.org/chrome/trunk/deps/third_party/opus