[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