doc/draft-ietf-payload-rtp-opus.xml - Issue 28553003: Updating Opus to a pre-release of 1.1

Unified Diff: doc/draft-ietf-payload-rtp-opus.xml

Issue 28553003: Updating Opus to a pre-release of 1.1 (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/deps/third_party/opus

Patch Set: Removing failing file Created 7 years, 2 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View side-by-side diff with in-line comments

Download patch

Index: doc/draft-ietf-payload-rtp-opus.xml

diff --git a/doc/draft-ietf-payload-rtp-opus.xml b/doc/draft-ietf-payload-rtp-opus.xml

new file mode 100644

index 0000000000000000000000000000000000000000..02440d94ff3aab41846e2b26611eff7aa83cba43

--- /dev/null

+++ b/doc/draft-ietf-payload-rtp-opus.xml

@@ -0,0 +1,932 @@

+<?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'>

+<!ENTITY rfc5576 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5576.xml'>

+<!ENTITY rfc6562 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6562.xml'>

+<!ENTITY rfc6716 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6716.xml'>

+<!ENTITY nbsp " ">

+ ]>

+ <rfc category="std" ipr="trust200902" docName="draft-ietf-payload-rtp-opus-01">

+<?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 for Opus Speech and Audio Codec

+ </title>

+ <author fullname="Julian Spittka" initials="J." surname="Spittka">

+ <address>

+ <email>jspittka@gmail.com</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>koenvos74@gmail.com</email>

+ </address>

+ </author>

+ <author initials="JM" surname="Valin" fullname="Jean-Marc Valin">

+ <organization>Mozilla</organization>

+ <address>

+ <postal>

+ <street>650 Castro Street</street>

+ <city>Mountain View</city>

+ <region>CA</region>

+ <code>94041</code>

+ <country>USA</country>

+ </postal>

+ <email>jmvalin@jmvalin.ca</email>

+ </address>

+ </author>

+ <date day='2' month='August' year='2013' />

+ <abstract>

+ <t>

+ This document defines the Real-time Transport Protocol (RTP) payload

+ 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.

+ </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 it

+ is highly scalable in terms of audio bandwidth, bitrate, 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 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. More information on the Opus

+ codec can be obtained from <xref target="RFC6716"/>.

+ </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="CBR:"> Constant bitrate</t>

+ <t hangText="CPU:"> Central Processing Unit</t>

+ <t hangText="DTX:"> Discontinuous transmission</t>

+ <t hangText="FEC:"> Forward error correction</t>

+ <t hangText="IP:"> Internet Protocol</t>

+ <t hangText="samples:"> Speech or audio samples (usually per channel)</t>

+ <t hangText="SDP:"> Session Description Protocol</t>

+ <t hangText="VBR:"> Variable bitrate</t>

+ </list>

+ </t>

+ <section title='Audio Bandwidth'>

+ <t>

+ Throughout this document, we refer to the following definitions:

+ </t>

+ <texttable anchor='bandwidth_definitions'>

+ <ttcol align='center'>Abbreviation</ttcol>

+ <ttcol align='center'>Name</ttcol>

+ <ttcol align='center'>Bandwidth</ttcol>

+ <ttcol align='center'>Sampling</ttcol>

+ <c>nb</c>

+ <c>Narrowband</c>

+ <c>0 - 4000</c>

+ <c>8000</c>

+ <c>mb</c>

+ <c>Mediumband</c>

+ <c>0 - 6000</c>

+ <c>12000</c>

+ <c>wb</c>

+ <c>Wideband</c>

+ <c>0 - 8000</c>

+ <c>16000</c>

+ <c>swb</c>

+ <c>Super-wideband</c>

+ <c>0 - 12000</c>

+ <c>24000</c>

+ <c>fb</c>

+ <c>Fullband</c>

+ <c>0 - 20000</c>

+ <c>48000</c>

+ <postamble>

+ Audio bandwidth naming

+ </postamble>

+ </texttable>

+ </section>

+ <section title='Opus Codec'>

+ <t>

+ The Opus <xref target="RFC6716"/> 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 efficient encoding of voice signals at lower bit

+ rates while the audio mode is optimized for audio signals at medium and

+ higher bitrates.

+ </t>

+ <t>

+ The Opus speech and audio codec is highly scalable in terms of audio

+ bandwidth, bitrate, and complexity. Further, Opus allows

+ transmitting stereo signals.

+ </t>

+ <section title='Network Bandwidth'>

+ <t>

+ Opus supports all bitrates from 6 kb/s to 510 kb/s.

+ The bitrate can be changed dynamically within that range.

+ All

+ other parameters being

+ equal, higher bitrate results in higher quality.

+ </t>

+ <section title='Recommended Bitrate' anchor='bitrate_by_bandwidth'>

+ <t>

+ For a frame size of

+ 20 ms, these

+ are the bitrate "sweet spots" for Opus in various configurations:

+ <list style="symbols">

+ <t>8-12 kb/s for NB speech,</t>

+ <t>16-20 kb/s for WB speech,</t>

+ <t>28-40 kb/s for FB speech,</t>

+ <t>48-64 kb/s for FB mono music, and</t>

+ <t>64-128 kb/s for FB stereo music.</t>

+ </list>

+ </t>

+ </section>

+ <section title='Variable versus Constant Bit Rate' anchor='variable-vs-constant-bitrate'>

+ <t>

+ For the same average bitrate, variable bitrate (VBR) can achieve higher quality

+ than constant bitrate (CBR). For the majority of voice transmission application, VBR

+ is the best choice. One potential reason for choosing CBR is the potential

+ information leak that <spanx style='emph'>may</spanx> occur when encrypting the

+ compressed stream. See <xref target="RFC6562"/> for guidelines on when VBR is

+ appropriate for encrypted audio communications. In the case where an existing

+ VBR stream needs to be converted to CBR for security reasons, then the Opus padding

+ mechanism described in <xref target="RFC6716"/> is the RECOMMENDED way to achieve padding

+ because the RTP padding bit is unencrypted.</t>

+ <t>

+ The bitrate can be adjusted at any point in time. To avoid congestion,

+ the average bitrate SHOULD be adjusted to the available

+ network capacity. If no target bitrate is specified, the bitrates specified in

+ <xref target='bitrate_by_bandwidth'/> are RECOMMENDED.

+ </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 bitrate. In that case, the bitrate

+ will automatically be reduced for certain input signals like periods

+ of silence. During continuous transmission the bitrate 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 bitrate of Opus needs to be reduced even

+ further or in cases where only constant bitrate 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

+ capacity are severe. The DTX mode can be engaged for operation

+ in both adaptive or constant bitrate.

+ </t>

+ </section>

+ <section title='Complexity'>

+ <t>

+ Complexity can be scaled to optimize for CPU resources in real-time, mostly as

+ a trade-off between audio quality and bitrate. 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 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

+ resources. 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

+ is signaled in-band in the Opus payload and no special arrangement

+ is required in the payload format. Any implementation of the Opus

+ decoder MUST be capable of receiving stereo signals, although it MAY

+ decode those signals as mono.

+ </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 the network.

+ </t>

+ </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 is used in accordance with

+ Section 4.1 of <xref target="RFC3551"/>.</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 audio bandwidths 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 per single (mono) channel. 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' title="Timestamp multiplier">

+ <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>

+ </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 in

+ milliseconds of encoded speech or audio data for speech and audio mode

+ (Mode) and sampling rates (fs) of Opus and how the timestamp needs to

+ be incremented for packetization (ts incr). If the Opus encoder

+ outputs multiple encoded frames into a single packet the timestamps

+ have to be added up according to the combined frames.

+ </t>

+ <texttable anchor='opus-packetization' title="Supported Opus frame

+ sizes and timestamp increments">

+ <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>nb/mb/wb/swb/fb</c>

+ <c></c>

+ <c>x</c>

+ <c>audio</c>

+ <c>nb/wb/swb/fb</c>

+ <c>x</c>

+ <c></c>

+ </texttable>

+ </section>

+ <section title='Congestion Control'>

+ <t>The adaptive nature of the Opus codec allows for an efficient

+ congestion control.</t>

+ <t>The target bitrate of Opus can be adjusted at any point in time and

+ thus allowing for an efficient congestion control. 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="maxplaybackrate:">

+ a hint about the maximum output sampling rate that the receiver is

+ capable of rendering in Hz.

+ The decoder MUST be capable of decoding

+ any audio bandwidth but due to hardware limitations only signals

+ up to the specified sampling rate can be played back. Sending signals

+ with higher audio bandwidth results in higher than necessary network

+ usage and encoding complexity, so an encoder SHOULD NOT encode

+ frequencies above the audio bandwidth specified by maxplaybackrate.

+ This parameter can take any value between 8000 and 48000, although

+ commonly the value will match one of the Opus bandwidths

+ (<xref target="bandwidth_definitions"/>).

+ By default, the receiver is assumed to have no limitations, i.e. 48000.

+ <vspace blankLines='1'/>

+ </t>

+ <t hangText="sprop-maxcapturerate:">

+ a hint about the maximum input sampling rate that the sender is likely to produce.

+ This is not a guarantee that the sender will never send any higher bandwidth

+ (e.g. it could send a pre-recorded prompt that uses a higher bandwidth), but it

+ indicates to the receiver that frequencies above this maximum can safely be discarded.

+ This parameter is useful to avoid wasting receiver resources by operating the audio

+ processing pipeline (e.g. echo cancellation) at a higher rate than necessary.

+ This parameter can take any value between 8000 and 48000, although

+ commonly the value will match one of the Opus bandwidths

+ (<xref target="bandwidth_definitions"/>).

+ By default, the sender is assumed to have no limitations, i.e. 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'/>. 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 of accepting 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'/>. 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 of accepting 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'/>. 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 bitrate of a session in bits per second (b/s). The actual

+ value of the bitrate may vary as it is dependent on the

+ characteristics of the media in a packet. Note that the maximum

+ average bitrate 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 maxplaybackrate:

+ will be the default.<vspace blankLines='1'/></t>

+ <t hangText="stereo:">

+ specifies whether the decoder prefers receiving stereo or 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

+ utilisation and encoding complexity. If no value is specified, mono

+ is assumed (stereo=0).<vspace blankLines='1'/>

+ </t>

+ <t hangText="sprop-stereo:">

+ specifies whether the sender is likely to produce stereo audio.

+ Possible values are 1 and 0 where 1 specifies that stereo signals are likely to

+ be sent, and 0 speficies that the sender will likely only send mono.

+ This is not a guarantee that the sender will never send stereo audio

+ (e.g. it could send a pre-recorded prompt that uses stereo), but it

+ indicates to the receiver that the received signal can be safely downmixed to mono.

+ This parameter is useful to avoid wasting receiver resources by operating the audio

+ processing pipeline (e.g. echo cancellation) in stereo when not necessary.

+ If no value is specified, mono

+ is assumed (sprop-stereo=0).<vspace blankLines='1'/>

+ </t>

+ <t hangText="cbr:">

+ specifies if the decoder prefers the use of a constant bitrate versus

+ variable bitrate. Possible values are 1 and 0 where 1 specifies constant

+ bitrate and 0 specifies variable bitrate. If no value is specified, cbr

+ is assumed to be 0. Note that the maximum average bitrate may still be

+ changed, e.g. to adapt to changing network conditions.<vspace blankLines='1'/>

+ </t>

+ <t hangText="useinbandfec:"> specifies that the decoder has the capability to

+ take advantage of the Opus in-band FEC. Possible values are 1 and 0. It is RECOMMENDED to provide

+ 0 in case FEC cannot be utilized on the receiving side. If no

+ value is specified, useinbandfec is assumed to be 0.

+ This parameter is only a preference and the receiver MUST be able to process

+ packets that include FEC information, even if it means the FEC part is discarded.

+ <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 of

+ speech or audio data may use this media type. Some examples are,

+ but not limited to, audio and video conferencing, Voice over IP,

+ media streaming.</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 jmvalin@jmvalin.ca</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.</t>

+ </list></t>

+ <t>Author:</t>

+ <t><list style="hanging">

+ <t>Julian Spittka jspittka@gmail.com<vspace blankLines='1'/></t>

+ <t>Koen Vos koenvos74@gmail.com<vspace blankLines='1'/></t>

+ <t>Jean-Marc Valin jmvalin@jmvalin.ca<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 48000 and the number of

+ channels MUST be 2.</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>The OPTIONAL media type parameters "maxaveragebitrate",

+ "maxplaybackrate", "minptime", "stereo", "cbr", "useinbandfec", and

+ "usedtx", when present, MUST be included in the "a=fmtp" attribute

+ in the SDP, expressed as a media type string in the form of a

+ semicolon-separated list of parameter=value pairs (e.g.,

+ maxaveragebitrate=20000). They MUST NOT be specified in an

+ SSRC-specific "fmtp" source-level attribute (as defined in

+ Section 6.3 of <xref target="RFC5576"/>).</t>

+ <t>The OPTIONAL media type parameters "sprop-maxcapturerate",

+ and "sprop-stereo" MAY be mapped to the "a=fmtp" SDP attribute by

+ copying them directly from the media type parameter string as part

+ of the semicolon-separated list of parameter=value pairs (e.g.,

+ sprop-stereo=1). These same OPTIONAL media type parameters MAY also

+ be specified using an SSRC-specific "fmtp" source-level attribute

+ as described in Section 6.3 of <xref target="RFC5576"/>.

+ They MAY be specified in both places, in which case the parameter

+ in the source-level attribute overrides the one found on the

+ "a=fmtp" line. The value of any parameter which is not specified in

+ a source-level source attribute MUST be taken from the "a=fmtp"

+ line, if it is present there.</t>

+ </list>

+ </t>

+ <t>Below are some examples of SDP session descriptions for Opus:</t>

+ <t>Example 1: Standard mono session with 48000 Hz clock rate</t>

+ <figure>

+ <artwork>

+ <![CDATA[

+ m=audio 54312 RTP/AVP 101

+ a=rtpmap:101 opus/48000/2

+ ]]>

+ </artwork>

+ </figure>

+ <t>Example 2: 16000 Hz clock rate, maximum packet size of 40 ms,

+ recommended packet size of 40 ms, maximum average bitrate of 20000 bps,

+ prefers to receive stereo but only plans to send mono, FEC is allowed,

+ DTX is not allowed</t>

+ <figure>

+ <artwork>

+ <![CDATA[

+ m=audio 54312 RTP/AVP 101

+ a=rtpmap:101 opus/48000/2

+ a=fmtp:101 maxplaybackrate=16000; sprop-maxcapturerate=16000;

+ maxaveragebitrate=20000; stereo=1; useinbandfec=1; usedtx=0

+ a=ptime:40

+ a=maxptime:40

+ ]]>

+ </artwork>

+ </figure>

+ <t>Example 3: Two-way full-band stereo preferred</t>

+ <figure>

+ <artwork>

+ <![CDATA[

+ m=audio 54312 RTP/AVP 101

+ a=rtpmap:101 opus/48000/2

+ a=fmtp:101 stereo=1; sprop-stereo=1

+ ]]>

+ </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/2

+ ]]>

+ </artwork>

+ </figure>

+ </t>

+ <t>The "ptime" and "maxptime" parameters 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 "minptime" parameter 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 "maxplaybackrate" parameter is a unidirectional receive-only

+ parameter that reflects limitations of the local receiver. The sender

+ of the other side SHOULD NOT send with an audio bandwidth higher than

+ "maxplaybackrate" as this would lead to inefficient use of network resources.

+ The "maxplaybackrate" parameter does not

+ affect interoperability. Also, this parameter SHOULD NOT be used

+ to adjust the audio bandwidth as a function of the bitrates, as this

+ is the responsibility of the Opus encoder implementation.

+ </t>

+ <t>The "maxaveragebitrate" parameter 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 bitrate higher than

+ "maxaveragebitrate" as it might overload the network and/or

+ receiver. The "maxaveragebitrate" parameter 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 "sprop-maxcapturerate" and "sprop-stereo" parameters are

+ unidirectional sender-only parameters that reflect limitations of

+ the sender side.

+ They allow the receiver to set up a reduced-complexity audio

+ processing pipeline if the sender is not planning to use the full

+ range of Opus's capabilities.

+ Neither "sprop-maxcapturerate" nor "sprop-stereo" affect

+ interoperability and the receiver MUST be capable of receiving any signal.

+ </t>

+ <t>

+ The "stereo" parameter is a unidirectional receive-only

+ parameter.

+ </t>

+ <t>

+ The "cbr" parameter is a unidirectional receive-only

+ parameter.

+ </t>

+ <t>The "useinbandfec" parameter is a unidirectional receive-only

+ parameter.</t>

+ <t>The "usedtx" parameter 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", "maxplaybackrate", 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 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;

+ &rfc5576;

+ &rfc6562;

+ &rfc6716;

+ </references>

+ </back>

+</rfc>

« no previous file with comments | « doc/draft-ietf-codec-opus.xml ('k') | doc/draft-valin-codec-opus-update.xml » ('j') | no next file with comments »