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

[lu_zero at svn.xiph.org]

Author: lu_zero
Date: 2005-10-19 15:52:18 -0700 (Wed, 19 Oct 2005)
New Revision: 10195

Modified:
   trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-01.xml
Log:
Byte boundary explictly noted

Payload packing definition clarified

Comments just optional, not discouraged

Fragment loss behaviour changed slightly.

Vorbis present in lowercase in the SDP/MIME sections.



Modified: trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-01.xml
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-01.xml	2005-10-19 19:21:08 UTC (rev 10194)
+++ trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-01.xml	2005-10-19 22:52:18 UTC (rev 10195)
@@ -247,7 +247,7 @@
 </figure>
 
 <t>
-Each Vorbis payload packet starts with a two octet length header, which is used to represent the size of the following data payload, followed by the raw Vorbis data.
+Each Vorbis payload packet starts with a two octet length header, which is used to represent the size of the following data payload, followed by the raw Vorbis data padded to the nearest byte boundary.
 </t>
 
 <t>
@@ -259,7 +259,7 @@
 </t>
 
 <t>
-The payload packing of the Vorbis data packets SHOULD follow the guidelines set-out in <xref target="rfc3551"></xref> where the oldest packet occurs immediately after the RTP packet header.
+The payload packing of the Vorbis data packets MUST follow the guidelines set-out in <xref target="rfc3551"></xref> where the oldest packet occurs immediately after the RTP packet header.
 </t>
 
 <t>
@@ -559,7 +559,7 @@
 <section anchor="Comment Headers" title="Comment Headers">
 
 <t>
-With the payload type flag set to 2, this indicates that the packet contain the comment metadata, such as artist name, track title and so on. These metadata messages are not intended to be fully descriptive but to offer basic track/song information. This packet SHOULD NOT be sent and clients MAY ignore it completely. The details on the format of the comments can be found in the <xref target="vorbis-spec-ref">Vorbis documentation</xref>.
+With the payload type flag set to 2, this indicates that the packet contain the comment metadata, such as artist name, track title and so on. These metadata messages are not intended to be fully descriptive but to offer basic track/song information. Clients MAY ignore it completely. The details on the format of the comments can be found in the <xref target="vorbis-spec-ref">Vorbis documentation</xref>.
 </t>
 <figure anchor="Comment Packet Figure" title="Comment Packet">
 <artwork><![CDATA[
@@ -704,7 +704,7 @@
 <section anchor="Packet Loss" title="Packet Loss">
 
 <t>
-As there is no error correction within the Vorbis stream, packet loss will result in a loss of signal. Packet loss is more of an issue for fragmented Vorbis packets as the client will have to cope with the handling of the Fragment Type. In case of loss of fragments the client MUST discard all of them. If we use the fragmented Vorbis packet example above and the first packet is lost the client MUST detect that the next packet has the packet count field set to 0 and the Fragment type 2 and MUST drop it. The next packet, which is the final fragmented packet, MUST be dropped in the same manner. Feedback reports on lost and dropped packets MUST be sent back via RTCP.
+As there is no error correction within the Vorbis stream, packet loss will result in a loss of signal. Packet loss is more of an issue for fragmented Vorbis packets as the client will have to cope with the handling of the Fragment Type. In case of loss of fragments the client MUST discard all the remaining fragments and decode the incomplete packet. If we use the fragmented Vorbis packet example above and the first packet is lost the client MUST detect that the next packet has the packet count field set to 0 and the Fragment type 2 and MUST drop it. The next packet, which is the final fragmented packet, MUST be dropped in the same manner. If the missing packet is the last, the received two fragments will be kept and the incomplete vorbis packet decoded. Feedback reports on lost and dropped packets MUST be sent back via RTCP.
 </t>
 
 <t>
@@ -794,7 +794,7 @@
 <t>The MIME type ("audio") goes in SDP "m=" as the media name.</t>
 <vspace blankLines="1" />
 
-<t>The MIME subtype ("VORBIS") goes in SDP "a=rtpmap" as the encoding name.</t>
+<t>The MIME subtype ("vorbis") goes in SDP "a=rtpmap" as the encoding name.</t>
 <vspace blankLines="1" />
 
 <t>The parameter "rate" also goes in "a=rtpmap" as clock rate.</t>