[xiph-commits] r14402 - trunk/vorbis/doc
lu_zero at svn.xiph.org
lu_zero at svn.xiph.org
Tue Jan 15 04:18:54 PST 2008
Author: lu_zero
Date: 2008-01-15 04:18:53 -0800 (Tue, 15 Jan 2008)
New Revision: 14402
Modified:
trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-09.txt
trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-09.xml
Log:
Update congestion control section and detail the configuration section addressing late Colin comments
Modified: trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-09.txt
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-09.txt 2008-01-15 02:47:16 UTC (rev 14401)
+++ trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-09.txt 2008-01-15 12:18:53 UTC (rev 14402)
@@ -93,8 +93,8 @@
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 22
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
- 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
- 13.1. Normative References . . . . . . . . . . . . . . . . . . . 22
+ 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . . 23
@@ -425,10 +425,14 @@
Since this information must be transmitted reliably and, as the RTP
stream may change certain configuration data mid-session, there are
different methods for delivering this configuration data to a client,
- both in-band and out-of-band which is detailed below. SDP delivery
- is typically used to set up an initial state for the client
- application. The changes may be due to different codebooks as well
- as different bitrates of the RTP stream.
+ both in-band and out-of-band which is detailed below. In order to
+ set up an initial state for the client application the configuration
+ MUST be inlined in the session setup informations. Changes to the
+ configuration MAY be communicated via a re-invite, conveying new SDP,
+ or sent in-band in the RTP channel. Implementations MUST support in-
+ band delivery of updated codebooks, and SHOULD support out-of-band
+ codebook update using a new SDP file. The changes may be due to
+ different codebooks as well as different bitrates of the RTP stream.
For non chained streams, the recommended Configuration delivery
method is inline the Packed Configuration (Section 3.1.1) in the SDP
@@ -437,10 +441,6 @@
The 24 bit Ident field is used to map which Configuration will be
used to decode a packet. When the Ident field changes, it indicates
that a change in the stream has taken place. The client application
- MUST have in advance the correct configuration and if the client
- detects a change in the Ident value and does not have this
- information it MUST NOT decode the raw Vorbis data associated until
- it fetches the correct Configuration.
@@ -449,6 +449,11 @@
Internet-Draft Vorbis RTP Payload Format Jan 2008
+ MUST have in advance the correct configuration and if the client
+ detects a change in the Ident value and does not have this
+ information it MUST NOT decode the raw Vorbis data associated until
+ it fetches the correct Configuration.
+
3.1. In-band Header Transmission
The Packed Configuration (Section 3.1.1) Payload is sent in-band with
@@ -495,11 +500,6 @@
-
-
-
-
-
Barbato Expires July 17, 2008 [Page 9]
Internet-Draft Vorbis RTP Payload Format Jan 2008
@@ -1132,9 +1132,13 @@
8. Congestion Control
- Vorbis clients SHOULD send regular receiver reports detailing
- congestion. A way to handle bandwidth changes MAY be redirect the
- client to a lower bitrate stream if one is available.
+ The general congestion control considerations for transporting RTP
+ data apply to vorbis audio over RTP as well. See the RTP
+ specification [2] and any applicable RTP profile (e.g., [3]). Audio
+ data can be encoded using a range of different bit rates, so it is
+ possible to adapt network bandwidth by adjusting the encoder bit rate
+ in real time or by having multiple copies of content encoded at
+ different bit rates.
9. Example
@@ -1165,18 +1169,18 @@
The client may choose to fetch the Configuration from the alternate
source as soon as it discovers a Configuration packet got lost in-
band or use selective retransmission [13], if the server supports the
- feature.
- A serverside optimization would be to keep an hash list of the
- Configurations per session to avoid packing all of them and send the
-
Barbato Expires July 17, 2008 [Page 21]
Internet-Draft Vorbis RTP Payload Format Jan 2008
+ feature.
+
+ A serverside optimization would be to keep an hash list of the
+ Configurations per session to avoid packing all of them and send the
same Configuration with different Ident tags
A clientside optimization would be to keep a tag list of the
@@ -1219,12 +1223,8 @@
13. References
-13.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119.
- [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
@@ -1233,6 +1233,12 @@
Internet-Draft Vorbis RTP Payload Format Jan 2008
+13.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119.
+
+ [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for real-time applications", STD 64,
RFC 3550.
@@ -1278,12 +1284,6 @@
-
-
-
-
-
-
Barbato Expires July 17, 2008 [Page 23]
Internet-Draft Vorbis RTP Payload Format Jan 2008
Modified: trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-09.xml
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-09.xml 2008-01-15 02:47:16 UTC (rev 14401)
+++ trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-09.xml 2008-01-15 12:18:53 UTC (rev 14402)
@@ -393,19 +393,17 @@
Since this information must be transmitted reliably and, as the RTP
stream may change certain configuration data mid-session, there are
different methods for delivering this configuration data to a
-client, both in-band and out-of-band which is detailed below. SDP
-delivery is typically used to set up an initial state for the client
-application. The changes may be due to different codebooks as well as
+client, both in-band and out-of-band which is detailed below.
+In order to set up an initial state for the client application the
+configuration MUST be inlined in the session setup informations.
+Changes to the configuration MAY be communicated via a re-invite,
+conveying new SDP, or sent in-band in the RTP channel.
+Implementations MUST support in-band delivery of updated codebooks,
+and SHOULD support out-of-band codebook update using a new SDP file.
+The changes may be due to different codebooks as well as
different bitrates of the RTP stream.
</t>
-<!--
-<t>
-The delivery vectors in use can be specified by an SDP attribute to indicate the
-method and the optional URI where the Vorbis
-<xref target="Packed Configuration">Packed Configuration</xref> Packets could
-be fetched.
--->
<t>For non chained streams, the recommended Configuration delivery
method is inline the <xref target="Packed Configuration">Packed Configuration</xref> in the SDP as explained in the <xref target="Mapping Media Type Parameters into SDP"> IANA considerations</xref>.
</t>
@@ -1097,9 +1095,13 @@
</section>
<section anchor="Congestion Control" title="Congestion Control">
<t>
- Vorbis clients SHOULD send regular receiver reports detailing
- congestion. A way to handle bandwidth changes MAY be redirect
- the client to a lower bitrate stream if one is available.
+The general congestion control considerations for transporting RTP
+data apply to vorbis audio over RTP as well. See the RTP specification
+<xref target="rfc3550" /> and any applicable RTP profile (e.g., <xref target="rfc3551" />).
+Audio data can be encoded using a range of different bit rates, so
+it is possible to adapt network bandwidth by adjusting the encoder
+bit rate in real time or by having multiple copies of content encoded
+ at different bit rates.
</t>
</section>
<section anchor="Example" title="Example">
More information about the commits
mailing list