diff options
author | Timothy B. Terriberry <tterribe@xiph.org> | 2014-07-25 22:33:55 -0700 |
---|---|---|
committer | Jean-Marc Valin <jmvalin@jmvalin.ca> | 2014-07-28 15:09:51 -0400 |
commit | 1e87fea32698ac3070ebf092d2ca08feae57373f (patch) | |
tree | 4efb73480c7acd70c92b5ef8329077a1f62b1109 | |
parent | f7faa90b49b8482e2847486e55ed8152cd8b753b (diff) | |
download | opus-1e87fea32698ac3070ebf092d2ca08feae57373f.tar.gz |
RTP draft edits (normative changes).
Here are my proposals to resolve a few issues with the current
draft.
See the corresponding message to the list for details.
-rw-r--r-- | doc/draft-ietf-payload-rtp-opus.xml | 34 |
1 files changed, 23 insertions, 11 deletions
diff --git a/doc/draft-ietf-payload-rtp-opus.xml b/doc/draft-ietf-payload-rtp-opus.xml index afa7284a..412ce0fc 100644 --- a/doc/draft-ietf-payload-rtp-opus.xml +++ b/doc/draft-ietf-payload-rtp-opus.xml @@ -220,7 +220,7 @@ <t> The bitrate can be adjusted at any point in time. To avoid congestion, - the average bitrate SHOULD be adjusted to the available + the average bitrate SHOULD NOT exceed the available network capacity. If no target bitrate is specified, the bitrates specified in <xref target='bitrate_by_bandwidth'/> are RECOMMENDED. </t> @@ -299,9 +299,10 @@ On the receiving side, the decoder can take advantage of this additional information when it loses a packet and 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 + to provide access to payloads with the FEC data. The receiver can + then configure its decoder to decode the FEC data from the packet + rather than the regular audio data. + If no FEC data is available for the current frame, the decoder will consider the frame lost and invoke frame loss concealment. </t> @@ -388,9 +389,10 @@ The Opus encoder can 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, up to a maximum packet duration representing - 120 ms of speech or audio data. The packetization of encoded data - is purely done by the Opus encoder, and therefore an RTP payload MUST - contain exactly one packet output from the Opus encoder. + 120 ms of speech or audio data. The grouping of one or more Opus + frames into a single Opus packet is defined in Section 3 of + <xref target="RFC6716"/>. An RTP payload MUST contain exactly one + Opus packet as defined by that document. </t> <t><xref target='payload-structure'/> shows the structure combined with the RTP header.</t> @@ -807,9 +809,14 @@ <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. + parameter that reflects limitations of the local receiver. When + sending to a single destination, a sender MUST NOT use an audio + bandwidth higher than necessary to represent audio sampled at + a sampling rate of "maxplaybackrate". Gateways or senders that + are sending the same encoded audio to multiple destinations + SHOULD NOT use an audio bandwidth higher than necessary to + represent audio sampled at "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 bitrate, as this @@ -837,7 +844,12 @@ <t> The "stereo" parameter is a unidirectional receive-only - parameter. + parameter. When sending to a single destination, a sender MUST + NOT use stereo when "stereo" is 0. Gateways or senders that are + sending the same encoded audio to multiple destinations SHOULD + NOT use stereo when "stereo" is 0, as this would lead to + inefficient use of network resources. The "stereo" parameter does + not affect interoperability. </t> <t> |