[xiph-commits] r14171 - trunk/vorbis/doc

lu_zero at svn.xiph.org lu_zero at svn.xiph.org
Sat Nov 17 09:14:57 PST 2007


Author: lu_zero
Date: 2007-11-17 09:14:57 -0800 (Sat, 17 Nov 2007)
New Revision: 14171

Modified:
   trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-08.xml
Log:
Partially addressing issues pointed in comment 73639 by Magnus Westerlund

Modified: trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-08.xml
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-08.xml	2007-11-17 15:27:52 UTC (rev 14170)
+++ trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-08.xml	2007-11-17 17:14:57 UTC (rev 14171)
@@ -426,6 +426,7 @@
 sent in-band with the packet type bits set to match the Vorbis Data Type.
 Clients MUST be capable of dealing with fragmentation and periodic
 <xref target="rfc4588">re-transmission of</xref> the configuration headers.
+The RTP timestamp value MUST reflect the transmission time of the next data packet.
 </t>
 
 <section anchor="Packed Configuration" title="Packed Configuration">
@@ -640,12 +641,14 @@
 <t>
 A fragmented packet has a zero in the last four bits of the payload header.
 The first fragment will set the Fragment type to 1. Each fragment after the
-first will set the Fragment type to 2 in the payload header.  The RTP payload
-containing the last fragment of the Vorbis packet will have the Fragment type
-set to 3.  To maintain the correct sequence for fragmented packet reception
-the timestamp field of fragmented packets MUST be the same as the first packet
-sent, with the sequence number incremented as normal for the subsequent RTP
-payloads. The length field shows the fragment length.
+first will set the Fragment type to 2 in the payload header. The consecutive
+fragments MUST be sent without any other payloads being sent between the first
+and the last fragment. The RTP payload containing the last fragment of the
+Vorbis packet will have the Fragment type set to 3. To maintain the correct
+sequence for fragmented packet reception the timestamp field of fragmented
+packets MUST be the same as the first packet sent, with the sequence number
+incremented as normal for the subsequent RTP payloads, this will affect the RTCP jitter measurement. The length field shows
+the fragment length.
 </t>
 
 <section anchor="Example Fragmented Vorbis Packet" title="Example Fragmented Vorbis Packet">
@@ -909,7 +912,7 @@
 <section anchor="Packed Headers IANA Considerations" title="Packed Headers IANA Considerations"> 
 
 <t>
-The following IANA considerations MUST only be applied to the packed headers.
+The following IANA considerations MUST only be applied to the <xref target="Packed Headers">Packed Headers</xref>.
 </t>
 
 <vspace blankLines="1" />
@@ -1118,18 +1121,6 @@
 
 </section>
 
-<section anchor="Congestion Control" title="Congestion Control"> 
-
-<t>
-Vorbis clients SHOULD send regular receiver reports detailing congestion. A
-mechanism for dynamically downgrading the stream, known as bitrate peeling,
-will allow for a graceful backing off of the stream bitrate. This feature is
-not available at present so an alternative would be to redirect the client to
-a lower bitrate stream if one is available.
-</t>
-
-</section> 
-
 <section anchor="Examples" title="Examples">
 
 <t>
@@ -1142,8 +1133,8 @@
 
 <t>This is one of the most common situation: one single server streaming
 content in multicast, the clients may start a session at random time. The
-content itself could be a mix of live stream, as the webjockey's voice, and stored
-streams as the music she plays.</t>
+content itself could be a mix of live stream, as the webjockey's voice,
+and stored streams as the music she plays.</t>
 
 <t>In this situation we don't know in advance how many codebooks we will use.
 The clients can join anytime and users expect to start listening to the content



More information about the commits mailing list