One document matched: draft-spittka-payload-rtp-opus-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3550 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml'>
<!ENTITY rfc3711 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml'>
<!ENTITY rfc3551 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml'>
<!ENTITY rfc4288 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml'>
<!ENTITY rfc4855 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4855.xml'>
<!ENTITY rfc4566 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml'>
<!ENTITY rfc3264 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml'>
<!ENTITY rfc2974 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2974.xml'>
<!ENTITY rfc2326 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2326.xml'>
<!ENTITY rfc3555 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3555.xml'>
]>
<rfc category="info" ipr="trust200902" docName="draft-spittka-payload-rtp-opus-00.xml">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="3" ?>
<?rfc tocappendix='no' ?>
<?rfc tocindent='yes' ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="no" ?>
<?rfc subcompact="yes" ?>
<?rfc iprnotified="yes" ?>
<front>
<title abbrev="RTP Payload Format for Opus Codec">
RTP Payload Format and File Storage Format for Opus Speech and Audio Codec
</title>
<author fullname="Julian Spittka" initials="J." surname="Spittka">
<organization>Skype Technologies S.A.</organization>
<address>
<postal>
<street>3210 Porter Drive</street>
<code>94304</code>
<city>Palo Alto</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>julian.spittka@skype.net</email>
</address>
</author>
<author initials='K.' surname='Vos' fullname='Koen Vos'>
<organization>Skype Technologies S.A.</organization>
<address>
<postal>
<street>3210 Porter Drive</street>
<code>94304</code>
<city>Palo Alto</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>koen.vos@skype.net</email>
</address>
</author>
<author initials='JM.' surname='Valin' fullname='Jean-Marc Valin'>
<organization>Octasic Inc.</organization>
<address>
<postal>
<street>4101 Molson Street</street>
<code></code>
<city>Montreal</city>
<region>Quebec</region>
<country>Canada</country>
</postal>
<email>jean-marc.valin@octasic.com</email>
</address>
</author>
<date month='July' year='2011' />
<abstract>
<t>
This document defines the Real-time Transport Protocol (RTP) payload
format and file storage format for packetization of Opus encoded
speech and audio data that is essential to integrate the codec in the
most compatible way. Further, media type registrations
are described for the RTP payload format and the file storage format.
</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>
The Opus codec is a speech and audio codec developed within the
IETF Internet Wideband Audio Codec working group [codec]. The codec
has a very low algorithmic delay and is
is highly scalable in terms of audio bandwidth, network bit rate, and
complexity. Further, it provides different modes to efficiently encode speech signals
as well as music signals, thus, making it the codec of choice for
various applications using the Internet or similar networks.
</t>
<t>
This document defines the Real-time Transport Protocol (RTP)
<xref target="RFC3550"/> payload format and file storage format for packetization
of Opus encoded speech and audio data that is essential to
integrate the Opus codec in the
most compatible way. Further, media type registrations are described for
the RTP payload format and the file storage format. More information on the Opus
codec can be obtained from the following IETF draft
[Opus].
</t>
</section>
<section title='Conventions, Definitions and Acronyms used in this document'>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.</t>
<t>
<list style='hanging'>
<t hangText="CPU:"> Central Processing Unit</t>
<t hangText="IP:"> Internet Protocol</t>
<t hangText="PSTN:"> Public Switched Telephone Network</t>
<t hangText="samples:"> Speech or audio samples</t>
<t hangText="SDP:"> Session Description Protocol</t>
</list>
</t>
</section>
<section title='Opus Codec'>
<t>
The Opus speech and audio codec has been developed to encode speech
signals as well as audio signals. Two different modes, a voice mode
or an audio mode, may be chosen to allow the most efficient coding
dependent on the type of input signal, the sampling frequency of the
input signal, and the specific application.
</t>
<t>
The voice mode allows to efficiently encode voice signals at lower bit
rates while the audio mode is optimized for audio signals at medium and
higher bit rates.
</t>
<t>
The Opus speech and audio codec is highly scalable in terms of audio
bandwidth, network bit rate, and complexity. Further, Opus allows to
transmit stereo signals.
</t>
<t>
The Opus speech and audio codec is based on the SILK codec [SILK]
and the CELT codec [CELT]. For more detailed information on how Opus
operates, also refer to [Opus].
</t>
<section title='Modes'>
<t>
Opus supports five different audio bandwidths, 8000, 12000, 16000,
24000, and 48000 Hz sampling frequency, for the voice mode and four
different audio bandwidths, 8000, 16000, 24000, and 48000 Hz
sampling frequency, for the audio mode.
</t>
<section title='Audio Mode'>
<t>
For low bit rate applications transmitting mostly speech signals
the voice mode of Opus SHOULD be used. The voice mode allows to
encode voice signals at 8000, 12000, 16000, 24000, and 48000 Hz
sampling frequency.
</t>
<t>
A sampling rate of 8000 Hz SHOULD only
be used to interface to PSTN networks or on low end devices that do
not support greater than 8000 Hz sampling frequency. A sampling rate
of 12000 Hz SHOULD be used for lower end devices that do not support
greater than 12000 Hz sampling frequency or are under severe network
bandwidth constrains (e.g. wireless devices). A sampling rate of
16000 Hz SHOULD be used for all-IP platforms that do not support
greater than 16000 Hz sampling frequency. Higher sampling rates are
recommended for all devices that support those high sampling rates
and desire full-bandwidth speech at medium bit rates.
</t>
</section>
<section title='Audio Mode'>
<t>
For applications desiring very low delay speech transmission as well
as music transmission in trade off to a higher bit rate, the
audio mode SHOULD be used. This mode supports audio sampling
rates of 8000, 16000, 24000, and 48000 Hz.
</t>
</section>
</section>
<section title='Network Bandwidth'>
<t>
The network bit rate is adaptive within the
range specified in <xref target='bitrate_by_bandwidth'/> for corresponding
modes and audio sampling rates. The average target network bit rate can be
defined and modified in real-time while the actual bit rate will be dependent
on the settings of Opus and the input signal and may change over time.
</t>
<texttable anchor='bitrate_by_bandwidth'>
<ttcol align='center'>Mode</ttcol>
<ttcol align='center'>fs (Hz)</ttcol>
<ttcol align='center'>BR (kbps)</ttcol>
<c>voice</c>
<c>8000</c>
<c>6 - 20</c>
<c>voice</c>
<c>12000</c>
<c>7 - 25</c>
<c>voice</c>
<c>16000</c>
<c>8 - 30</c>
<c>voice</c>
<c>24000</c>
<c>18 - 28</c>
<c>voice</c>
<c>48000</c>
<c>24 - 32</c>
<c>audio</c>
<c>8000</c>
<c>20 - 28</c>
<c>audio</c>
<c>16000</c>
<c>24 - 32</c>
<c>audio</c>
<c>24000</c>
<c>28 - 40</c>
<c>audio</c>
<c>48000</c>
<c>32 - 128</c>
<postamble>
Mode specifies the Opus mode of operation; fs specifies the audio
sampling frequency in Hertz (Hz); BR specifies
the network bit rate range in kilobits per second (kbps).
</postamble>
</texttable>
<section title='Variable versus Constant Bit Rate' anchor='variable-vs-constant-bitrate'>
<t>
The voice mode will always use a variable bit rate at audio sampling rates
of 8000, 12000, and 16000 Hz. The average target
bit rate can be adjusted at any point in time. To avoid congestion of the
connection the average target bit rate SHOULD be adjusted to the available
network bandwidth. If no target bit rate is specified the average bit rate
may go up to the highest bit rate specified in
<xref target='bitrate_by_bandwidth'/>.
</t>
<t>
In voice mode at audio sampling rates higher than 16000 Hz, i.e. 24000,
and 48000 Hz, and audio mode Opus can be operated in both variable and
constant bit rate. The target bit rate can be adjusted at any point in time.
</t>
</section>
<section title='Discontinuous Transmission (DTX)'>
<t>
The Opus codec may, as described in <xref target='variable-vs-constant-bitrate'/>,
be operated with an adaptive bit rate. In that case, the bit rate
will automatically be reduced for certain input signals like periods
of silence. During continuous transmission the bit rate will be
reduced, when the input signal allows to do so, but the transmission
to the receiver itself will never be interrupted. Therefore, the
received signal will maintain the same high level of quality over the
full duration of a transmission while minimizing the average bit
rate over time.
</t>
<t>
In cases where the bit rate of Opus needs to be reduced even
further or in cases where only constant bit rate is available,
the Opus encoder may be set to use discontinuous
transmission (DTX), where parts of the encoded signal that
correspond to periods of silence in the input speech or audio signal
are not transmitted to the receiver.
</t>
<t>
On the receiving side, the non-transmitted parts will be handled by a
frame loss concealment unit in the Opus decoder which generates a
comfort noise signal to replace the non transmitted parts of the
speech or audio signal.
</t>
<t>
The DTX mode of Opus will have a slightly lower speech or audio
quality than the continuous mode. Therefore, it is RECOMMENDED to
use Opus in the continuous mode unless restraints on network
bandwidth are severe. The DTX mode can be engaged for operation
in both adaptive or constant bit rate.
</t>
</section>
</section>
<section title='Complexity'>
<t>
Complexity can be scaled to optimize for CPU resources in real-time, mostly in
trade-off to network bit rate. Also, different modes of Opus have different complexity.
</t>
</section>
<section title="Forward Error Correction (FEC)">
<t>
The voice mode of Opus allows for "in-band" forward error correction (FEC)
data to be embedded into the bit stream of Opus. This FEC scheme adds
redundant information about the previous packet (n-1) to the current
output packet n. For
each frame, the encoder decides whether to use FEC based on (1) an
externally-provided estimate of the channel's packet loss rate; (2) an
externally-provided estimate of the channel's capacity; (3) the
sensitivity of the audio or speech signal to packet loss; (4) whether
the receiving decoder has indicated it can take advantage of "in-band"
FEC information. The decision to send "in-band" FEC information is
entirely controlled by the encoder and therefore no special precautions
for the payload or storage format have to be taken.
</t>
<t>
On the receiving side, the decoder can take advantage of this
additional information when, in case of a packet loss, the next packet
is available. In order to use the FEC data, the jitter buffer needs
to provide access to payloads with the FEC data. The decoder API function
has a flag to indicate that a FEC frame rather than a regular frame should
be decoded. If no FEC data is available for the current frame, the decoder
will consider the frame lost and invokes the frame loss concealment.
</t>
<t>
If the FEC scheme is not implemented on the receiving side, FEC
SHOULD NOT be used, as it leads to an inefficient usage of network
bandwidth. Decoder support for FEC SHOULD be indicated at the time a
session is set up.
</t>
</section>
<section title='Stereo Operation'>
<t>
Opus allows for transmission of stereo audio signals. This operation
will be signaled in the Opus payload and no special arrangements
have to be made in the payload format. Any implementation of the Opus
decoder MUST be capable to receive stereo signals.
</t>
<t>
If a decoder can not take advantage of the benefits of a stereo signal
this SHOULD be indicated at the time a session is set up. In that case
the sending side SHOULD NOT send stereo signals as it leads to an
inefficient usage of network bandwidth.
</t>
</section>
</section>
<section title='Opus RTP Payload Format' anchor='opus-rtp-payload-format'>
<t>The payload format for Opus consists of the RTP header and Opus payload
data.</t>
<section title='RTP Header Usage'>
<t>The format of the RTP header is specified in <xref target="RFC3550"/>. The Opus
payload format uses the fields of the RTP header consistent with this
specification.</t>
<t>The payload length of Opus is a multiple number of octets and
therefore no padding is required. The payload MAY be padded by an
integer number of octets according to <xref target="RFC3550"/>.</t>
<t>The marker bit (M) of the RTP header has no function in combination
with Opus and MAY be ignored.</t>
<t>The RTP payload type for Opus has not been assigned statically and is
expected to be assigned dynamically.</t>
<t>The receiving side MUST be prepared to receive duplicates of RTP
packets. Only one of those payloads MUST be provided to the Opus decoder
for decoding and others MUST be discarded.</t>
<t>Opus supports 5 different sampling rates which may be adjusted during
the duration of a call. The RTP timestamp clock frequency is defined as
the highest supported sampling frequency of Opus, i.e. 48000 Hz, for all
modes and sampling rates of Opus. The unit
for the timestamp is samples. The RTP timestamp corresponds to the
sample time of the first encoded sample in the encoded frame. For sampling
rates lower than 48000 Hz the number of samples has to be multiplied with
a multiplier according to <xref target="fs-upsample-factors"/> to determine
the RTP timestamp.</t>
<texttable anchor='fs-upsample-factors'>
<ttcol align='center'>fs (Hz)</ttcol>
<ttcol align='center'>Multiplier</ttcol>
<c>8000</c>
<c>6</c>
<c>12000</c>
<c>4</c>
<c>16000</c>
<c>3</c>
<c>24000</c>
<c>2</c>
<c>48000</c>
<c>1</c>
<postamble>
fs specifies the audio sampling frequency in Hertz (Hz); Multiplier is the
value that the number of samples have to be multiplied with to calculate
the RTP timestamp.
</postamble>
</texttable>
</section>
<section title='Payload Structure'>
<t>
The Opus encoder can be set to output encoded frames representing 2.5, 5, 10, 20,
40, or 60 ms of speech or audio data. Further, an arbitrary number of frames can be
combined into a packet. The maximum packet length is limited to the amount of encoded
data representing 120 ms of speech or audio data. The packetization of encoded data
is purely done by the Opus encoder and therefore only one packet output from the Opus
encoder MUST be used as a payload.
</t>
<t><xref target='payload-structure'/> shows the structure combined with the RTP header.</t>
<figure anchor="payload-structure"
title="Payload Structure with RTP header">
<artwork>
<![CDATA[
+----------+--------------+
|RTP Header| Opus Payload |
+----------+--------------+
]]>
</artwork>
</figure>
<t>
<xref target='opus-packetization'/> shows supported frame sizes for different modes
and sampling rates of Opus and how the timestamp needs to be incremented for
packetization.
</t>
<texttable anchor='opus-packetization'>
<ttcol align='center'>Mode</ttcol>
<ttcol align='center'>fs</ttcol>
<ttcol align='center'>2.5</ttcol>
<ttcol align='center'>5</ttcol>
<ttcol align='center'>10</ttcol>
<ttcol align='center'>20</ttcol>
<ttcol align='center'>40</ttcol>
<ttcol align='center'>60</ttcol>
<c>ts incr</c>
<c>all</c>
<c>120</c>
<c>240</c>
<c>480</c>
<c>960</c>
<c>1920</c>
<c>2880</c>
<c>voice</c>
<c>8000/12000/16000/24000/48000</c>
<c></c>
<c></c>
<c>x</c>
<c>x</c>
<c>x</c>
<c>x</c>
<c>audio</c>
<c>8000/16000/24000/48000</c>
<c>x</c>
<c>x</c>
<c>x</c>
<c>x</c>
<c></c>
<c></c>
<postamble>
Mode specifies the Opus mode of operation; fs specifies the audio sampling
frequency in Hertz (Hz); 2.5, 5, 10, 20, 40, and 60 represent the duration of
encoded speech or audio data in a packet; ts incr specifies the
value the timestamp needs to be incremented for the representing packet size.
For multiple frames in a packet these values have to be multiplied with the
respective number of frames.
</postamble>
</texttable>
</section>
</section>
<section title='Opus Storage Format' anchor='opus-storage-format'>
<t>The Opus storage format allows to store Opus encoded data into e.g. a
file or an email attachment. The storage format consists of a header and a
series of blocks containing encoded speech or audio frames. The storage
format closely mimics the real-time payload format and allows to easily
convert packets, e.g. received by a voicemail system, into a storage format
and vice versa and therefore allowing maximum flexibility and low overhead.
Please note that this storage format is not meant to be a robust storage format,
nor the most efficient storage format. For a robust storage format that
allows advanced functionality like e.g. seeking, a more advanced container
format should be used.</t>
<t><xref target='opus-storage-format-figure'/> shows an example of an Opus
encoded file. Note that due to the potentially adaptive bit rate the packet length
may be variable and no fixed block size can be defined for
blocks containing encoded data.</t>
<figure anchor="opus-storage-format-figure"
title="Example of Opus file storage format showing different block
lengths due to potentially adaptive bit rate of Opus">
<artwork><![CDATA[
+------------------+
| Header |
+-----------+------+
| block 1 |
+-----------+--+
| block 2 |
+--------------+--+
: ... :
+--------------+--+
| block n |
+-----------------+
]]></artwork>
</figure>
<section title='Storage Header Structure'>
<t>An Opus storage header contains the following ASCII character string
as a magic number:</t>
<t>"#!opus\n" (hexadecimal: 0x23 0x21 0x6f 0x70 0x75
0x73 0x0A)</t>
</section>
<section title='Storage Block Structure'>
<t>Following the storage header, blocks of encoded data are stored in
consecutive order in time according to <xref
target='opus-storage-format-figure'/>. Each block contains a block
header followed by a payload according to <xref
target='storage-block-header'/>.</t>
<t>The block header contains information that, for an RTP-based session,
can be derived from the IP and RTP headers: The number
of octets contained in the subsequent payload and the RTP timestamp.</t>
<t>The number of octets in the payload is represented by 16
bits and the timestamp is specified by 32 bits. For the first block, the
timestamp MAY be a random number. For the following blocks, the
timestamp MUST be incremented according to the way timestamps are
incremented when Opus payloads are transmitted over RTP.</t>
<figure anchor="storage-block-header"
title="Storage block header structure">
<artwork><![CDATA[
0 16 48
+-------------------+----------------------------+-----------------
| # of octets | Timestamp | Payload
+-------------------+----------------------------+-----------------
]]></artwork>
</figure>
<t>The payload of each block in <xref target='opus-storage-format-figure'/> represents
one packet of Opus encoded data the way as originally encoded by the Opus encoder.
Information about frame size representing the duration of encoded speech or audio data,
number of encoded frames, stereo information, and DTX is embedded into the payload of
Opus and not subject to the storage format. It can be extracted from the payload during
decoding of the encoded data.</t>
<t>During the usage of DTX no blocks are stored when the channel is
inactive. Timestamps MUST be used to reassemble the decoded signal in a
time-aligned way.</t>
</section>
</section>
<section title='Congestion Control'>
<t>The adaptive nature of the Opus codec allows for an efficient
congestion control.</t>
<t>
The voice mode of Opus at audio sampling rates of 8000, 12000, and 16000
always runs with a variable bit rate. The average bit
rate in that mode is dependent on the input signal and will especially
decrease during silent periods. The voice mode at audio sampling rates of
24000 and 48000 Hz and the audio mode may run
at a variable or constant bit rate. In either way, the target bit rate
of Opus can be adjusted at any point in time and thus allowing for an
efficient congestion control.</t>
<t>Furthermore, the amount of encoded speech or audio data encoded in a
single packet can be used for congestion control since the transmission
rate is inversely proportional to these frame sizes. A lower packet
transmission rate reduces the amount of header overhead but at the same
time increases latency and error sensitivity and should be done with care.</t>
<t>It is RECOMMENDED that congestion control is applied during the
transmission of Opus encoded data.</t>
</section>
<section title='IANA Considerations'>
<t>One media subtype (audio/opus) has been defined and registered as
described in the following section.</t>
<section title='Opus Media Type Registration'>
<t>Media type registration is done according to <xref
target="RFC4288"/> and <xref target="RFC4855"/>.<vspace
blankLines='1'/></t>
<t>Type name: audio<vspace blankLines='1'/></t>
<t>Subtype name: opus<vspace blankLines='1'/></t>
<t>Required parameters:</t>
<t><list style="hanging">
<t hangText="rate:"> RTP timestamp clock rate is incremented with
48000 Hz clock rate for all modes of Opus and all sampling
frequencies. For audio sampling rates other than 48000 Hz the rate
has to be adjusted to 48000 Hz according to <xref target="fs-upsample-factors"/>.
</t>
</list></t>
<t>Optional parameters:</t>
<t><list style="hanging">
<t hangText="maxcodedaudiobandwidth:">
the decoder's maximum sampling frequency specified in Hertz (Hz) that the
application can take advantage of. The decoder MUST be capable to receive
any allowed sampling frequency but due to hardware limitations only signals
up to the specified sampling frequency can be processed. Sending signals
with higher sampling frequency may result in higher than necessary network
bandwidth and encoding complexity. Possible values are 8000, 12000, 16000,
24000, 48000.
<vspace blankLines='1'/>
</t>
<t hangText="maxptime:"> the decoder's maximum length of time in
milliseconds rounded up to the next full integer value represented
by the media in a packet that can be
encapsulated in a received packet according to Section 6 of
<xref target="RFC4566"/>. Possible values are 3, 5, 10, 20, 40,
and 60 or an arbitrary multiple of Opus frame sizes rounded up to
the next full integer value up to a maximum value of 120 as
defined in <xref target='opus-rtp-payload-format'/> and <xref
target='opus-storage-format'/> of this document. If no value is
specified, 120 is assumed as default. This value is a recommendation
by the decoding side to ensure the best
performance for the decoder. The decoder MUST be
capable to accept any allowed packet sizes to
ensure maximum compatibility.
<vspace blankLines='1'/></t>
<t hangText="ptime:"> the decoder's recommended length of time in
milliseconds rounded up to the next full integer value represented
by the media in a packet according to
Section 6 of <xref target="RFC4566"/>. Possible values are
3, 5, 10, 20, 40, or 60 or an arbitrary multiple of Opus frame sizes
rounded up to the next full integer value up to a maximum
value of 120 as defined in <xref
target='opus-rtp-payload-format'/> and <xref
target='opus-storage-format'/> of this document. If no value is
specified, 20 is assumed as default. If ptime is greater than
maxptime, ptime MUST be ignored. This parameter MAY be changed
during a session. This value is a recommendation by the decoding
side to ensure the best
performance for the decoder. The decoder MUST be
capable to accept any allowed packet sizes to
ensure maximum compatibility.
<vspace blankLines='1'/></t>
<t hangText="minptime:"> the decoder's minimum length of time in
milliseconds rounded up to the next full integer value represented
by the media in a packet that SHOULD
be encapsulated in a received packet according to Section 6 of <xref
target="RFC4566"/>. Possible values are 3, 5, 10, 20, 40, and 60
or an arbitrary multiple of Opus frame sizes rounded up to the next
full integer value up to a maximum value of 120
as defined in <xref target='opus-rtp-payload-format'/> and <xref
target='opus-storage-format'/> of this document. If no value is
specified, 3 is assumed as default. This value is a recommendation
by the decoding side to ensure the best
performance for the decoder. The decoder MUST be
capable to accept any allowed packet sizes to
ensure maximum compatibility.
<vspace blankLines='1'/></t>
<t hangText="maxaveragebitrate:"> specifies the maximum average
receive bit rate of a session in bits per second (bps). The actual
value of the bit rate may vary as it is dependent on the
characteristics of the media in a packet. Note that the maximum
average bit rate MAY be modified dynamically during a session. Any
positive integer is allowed but values outside the range between
6000 and 510000 SHOULD be ignored. If no value is specified, the
maximum value specified in <xref target='bitrate_by_bandwidth'/>
for the corresponding mode of Opus and corresponding clock rate
will be the default.<vspace blankLines='1'/></t>
<t hangText="stereo:">
specifies if the decoder prefers to receive stereo signals versus mono signals.
Possible values are 1 and 0 where 1 specifies that stereo signals are preferred
and 0 specifies that only mono signals are preferred.
Independent of the stereo parameter every receiver MUST be able to receive and
decode stereo signals but sending stereo signals to a receiver that signaled a
preference for mono signals may result in higher than necessary network
bandwidth and encoding complexity. If no value is specified, stereo
is assumed to be 0.<vspace blankLines='1'/>
</t>
<t hangText="cbr:">
specifies if the decoder prefers the use of a constant bit rate versus
variable bit rate. Possible values are 1 and 0 where 1 specifies constant
bit rate and 0 specifies variable bit rate. If no value is specified, cbr
is assumed to be 0. Note that the maximum average bit rate may still be
changed, e.g. to adapt to changing network conditions.<vspace blankLines='1'/>
</t>
<t hangText="useinbandfec:"> specifies that Opus in-band FEC is
supported by the decoder and MAY be used during a
session. Possible values are 1 and 0. It is RECOMMENDED to provide
0 in case FEC is not implemented on the receiving side. If no
value is specified, useinbandfec is assumed to be 1.<vspace blankLines='1'/></t>
<t hangText="usedtx:"> specifies if the decoder prefers the use of
DTX. Possible values are 1 and 0. If no value is specified, usedtx
is assumed to be 0.<vspace blankLines='1'/></t>
</list></t>
<t>Encoding considerations:<vspace blankLines='1'/></t>
<t><list style="hanging">
<t>Opus media type is framed and consists of binary data according
to Section 4.8 in <xref target="RFC4288"/>.</t>
</list></t>
<t>Security considerations: </t>
<t><list style="hanging">
<t>See <xref target='security-considerations'/> of this document.</t>
</list></t>
<t>Interoperability considerations: none<vspace blankLines='1'/></t>
<t>Published specification: none<vspace blankLines='1'/></t>
<t>Applications that use this media type: </t>
<t><list style="hanging">
<t>Any application that requires the transport or storage of
speech or audio data may use this media type. Some examples are,
but not limited to, audio and video conferencing, Voice over IP,
voice recording, media streaming, voice messaging.</t>
</list></t>
<t>Additional information:</t>
<t><list style="hanging">
<t>For storage transfer methods the following applies:<vspace blankLines='1'/></t>
<t>Magic number:"#!opus\n" (hexadecimal: 0x23 0x21 0x6f 0x70 0x75 0x73 0x0A)<vspace blankLines='1'/></t>
<t>File extension(s): ops, OPS<vspace blankLines='1'/></t>
<t>Macintosh file type code(s): "opus"</t>
</list></t>
<t>Person & email address to contact for further information:</t>
<t><list style="hanging">
<t>SILK Support silksupport@skype.net</t>
<t>Jean-Marc Valin jean-marc.valin@octasic.com</t>
</list></t>
<t>Intended usage: COMMON<vspace blankLines='1'/></t>
<t>Restrictions on usage:<vspace blankLines='1'/></t>
<t><list style="hanging">
<t>For transfer over RTP, the RTP payload format (<xref
target='opus-rtp-payload-format'/> of this document) SHALL be
used. For storage usage, the storage format (<xref target='opus-storage-format'/>
of this document) SHALL be used.</t>
</list></t>
<t>Author:</t>
<t><list style="hanging">
<t>Julian Spittka julian.spittka@skype.net<vspace blankLines='1'/></t>
<t>Koen Vos koen.vos@skype.net<vspace blankLines='1'/></t>
<t>Jean-Marc Valin jean-marc.valin@octasic.com<vspace blankLines='1'/></t>
</list></t>
<t> Change controller: TBD</t>
</section>
<section title='Mapping to SDP Parameters'>
<t>The information described in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
<xref target="RFC4566"/>, which is commonly used to describe RTP
sessions. When SDP is used to specify sessions employing the Opus codec,
the mapping is as follows:</t>
<t>
<list style="symbols">
<t>The media type ("audio") goes in SDP "m=" as the media name.</t>
<t>The media subtype ("opus") goes in SDP "a=rtpmap" as the encoding
name. The RTP clock rate in "a=rtpmap" MUST be mapped to the required
media type parameter "rate".</t>
<t>The optional media type parameters "ptime" and "maxptime" are
mapped to "a=ptime" and "a=maxptime" attributes, respectively, in the
SDP.</t>
<t>All remaining media type parameters are mapped to the "a=fmtp"
attribute in the SDP by copying them directly from the media type
parameter string as a semicolon-separated list of parameter=value
pairs (e.g. maxaveragebitrate=20000).</t>
</list>
</t>
<t>Below are some examples of SDP session descriptions for Opus:</t>
<t>Example 1: Standard session with 48000 Hz clock rate</t>
<figure>
<artwork>
<![CDATA[
m=audio 54312 RTP/AVP 101
a=rtpmap:101 opus/48000
]]>
</artwork>
</figure>
<t>Example 2: 16000 Hz clock rate, maximum packet size of 40 ms,
recommended packet size of 40 ms, maximum average bit rate of 20000 bps,
stereo signals are preferred, FEC is allowed, DTX is not allowed</t>
<figure>
<artwork>
<![CDATA[
m=audio 54312 RTP/AVP 101
a=rtpmap:101 opus/48000
a=fmtp:101 maxcodedaudiobandwidth=16000; maxaveragebitrate=20000;
stereo=1; useinbandfec=1; usedtx=0
a=ptime:40
a=maxptime:40
]]>
</artwork>
</figure>
<section title='Offer-Answer Model Considerations for Opus'>
<t>When using the offer-answer procedure described in <xref
target="RFC3264"/> to negotiate the use of Opus, the following
considerations apply:</t>
<t><list style="symbols">
<t>Opus supports several clock rates. For signaling purposes only
the highest, i.e. 48000, is used. The actual clock rate of the
corresponding media is signaled inside the payload and is not
subject to this payload format description. The decoder MUST be
capable to decode every received clock rate. An example
is shown below:
<figure>
<artwork>
<![CDATA[
m=audio 54312 RTP/AVP 100
a=rtpmap:100 opus/48000
]]>
</artwork>
</figure>
</t>
<t>The parameters "ptime" and "maxptime" are unidirectional
receive-only parameters and typically will not compromise
interoperability; however, dependent on the set values of the
parameters the performance of the application may suffer. <xref
target="RFC3264"/> defines the SDP offer-answer handling of the
"ptime" parameter. The "maxptime" parameter MUST be handled in the
same way.</t>
<t>
The parameter "minptime" is a unidirectional
receive-only parameters and typically will not compromise
interoperability; however, dependent on the set values of the
parameter the performance of the application may suffer and should be
set with care.
</t>
<t>
The parameter "maxcodedaudiobandwidth" is a unidirectional receive-only
parameter that reflects limitations of the local receiver. The sender
of the other side SHOULD NOT send with a sampling rate higher than
"maxcodedaudiobandwidth" as it represents an inefficient use of network bandwidth
resources and CPU cycles on the encoding side. The parameter
"maxcodedaudiobandwidth" typically will not compromise interoperability; however,
dependent on the set value of the parameter the performance of the
application may suffer and should be set with care.
</t>
<t>The parameter "maxaveragebitrate" is a unidirectional receive-only
parameter that reflects limitations of the local receiver. The sender
of the other side MUST NOT send with an average bit rate higher than
"maxaveragebitrate" as it might overload the network and/or
receiver. The parameter "maxaveragebitrate" typically will not
compromise interoperability; however, dependent on the set value of
the parameter the performance of the application may suffer and should
be set with care.</t>
<t>If the parameter "maxaveragebitrate" is below the range specified
in <xref target='bitrate_by_bandwidth'/> the session MUST be rejected.</t>
<t>
The parameter "stereo" is a unidirectional receive-only
parameter.
</t>
<t>
The parameter "cbr" is a unidirectional receive-only
parameter.
</t>
<t>The parameter "useinbandfec" is a unidirectional receive-only
parameter.</t>
<t>The parameter "usedtx" is a unidirectional receive-only
parameter.</t>
<t>Any unknown parameter in an offer MUST be ignored by the receiver
and MUST be removed from the answer.</t>
</list></t>
</section>
<section title='Declarative SDP Considerations for Opus'>
<t>For declarative use of SDP such as in Session Announcement Protocol
(SAP), <xref target="RFC2974"/>, and RTSP, <xref target="RFC2326"/>, for
Opus, the following needs to be considered:</t>
<t><list style="symbols">
<t>The values for "maxptime", "ptime", "minptime", "maxcodedaudiobandwidth", and
"maxaveragebitrate" should be selected carefully to ensure that a
reasonable performance can be achieved for the participants of a session.</t>
<t>
The values for "maxptime", "ptime", and "minptime" of the payload
format configuration are recommendations by the decoding side to ensure
the best performance for the decoder. The decoder MUST be
capable to accept any allowed packet sizes to
ensure maximum compatibility.
</t>
<t>All other parameters of the payload format configuration are declarative
and a participant MUST use the configurations that are provided for
the session. More than one configuration may be provided if necessary
by declaring multiple RTP payload types; however, the number of types
should be kept small.</t>
</list></t>
</section>
</section>
</section>
<section title='Security Considerations' anchor='security-considerations'>
<t>All RTP packets using the payload format defined in this specification
are subject to the general security considerations discussed in the RTP
specification <xref target="RFC3550"/> and any profile from
e.g. <xref target="RFC3711"/> or <xref target="RFC3551"/>.</t>
<t>This payload format transports Opus encoded speech or audio data,
hence, security issues include confidentiality, integrity protection, and
authentication of the speech or audio itself. The Opus payload format does
not have any built-in security mechanisms. Any suitable external
mechanisms, such as SRTP <xref target="RFC3711"/>, MAY be used.</t>
<t>This payload format and the Opus encoding do not exhibit any
significant non-uniformity in the receiver-end computational load and thus
are unlikely to pose a denial-of-service threat due to the receipt of
pathological datagrams.</t>
</section>
<section title='Acknowledgements'>
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3550;
&rfc3711;
&rfc3551;
&rfc4288;
&rfc4855;
&rfc4566;
&rfc3264;
&rfc2974;
&rfc2326;
</references>
<section title='Informational References'>
<t><list style="hanging">
<t>[codec] http://datatracker.ietf.org/wg/codec/</t>
<t>[SILK] https://developer.skype.com/silk</t>
<t>[CELT] http://www.celt-codec.org/</t>
<t>[Opus] http://datatracker.ietf.org/doc/draft-ietf-codec-opus/</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:21:37 |