[xiph-commits] r10626 - trunk/vorbis/doc
giles at svn.xiph.org
giles at svn.xiph.org
Sat Dec 17 12:18:41 PST 2005
Author: giles
Date: 2005-12-17 12:18:41 -0800 (Sat, 17 Dec 2005)
New Revision: 10626
Modified:
trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-00.txt
trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-00.xml
Log:
Minor clarifications and typo fixes.
Modified: trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-00.txt
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-00.txt 2005-12-17 20:10:12 UTC (rev 10625)
+++ trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-00.txt 2005-12-17 20:18:41 UTC (rev 10626)
@@ -1,7 +1,6 @@
-
AVT Working Group L. Barbato
Internet-Draft Xiph.Org
Expires: April 24, 2006 October 21, 2005
@@ -80,7 +79,7 @@
3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 10
3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 12
4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 13
- 5. Frame Packetizing . . . . . . . . . . . . . . . . . . . . . . 13
+ 5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 13
5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 14
5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
@@ -237,7 +236,7 @@
A timestamp representing the sampling time of the first sample of the
first Vorbis packet in the RTP packet. The clock frequency MUST be
set to the sample rate of the encoded audio data and is conveyed out-
- of-band as a SDP attribute.
+ of-band as a SDP parameter.
SSRC/CSRC identifiers:
@@ -282,8 +281,8 @@
Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
- This field sets the packet payload type for the Vorbis data. There
- are currently three type of Vorbis payloads.
+ This field sets the payload type for the Vorbis data in this RTP
+ packet. There are currently three type of Vorbis payloads.
0 = Raw Vorbis payload
1 = Vorbis Packed Configuration payload
@@ -298,13 +297,14 @@
2.3. Payload Data
Raw Vorbis packets are unbounded in length currently, although at
- some future point there will likely be a practical limit placed on
- them. Typical Vorbis packet sizes are from very small (2-3 bytes) to
- quite large (8-12 kilobytes). The reference implementation [14]
+ some future point application profiles will likely define a practical
+ limit. Typical Vorbis packet sizes are from very small (2-3 bytes)
+ to quite large (8-12 kilobytes). The reference implementation [14]
typically produces packets less than ~800 bytes, except for the setup
- header packets which are ~4-12 kilobytes. Within an RTP context the
- maximum packet size, including the RTP and payload headers, SHOULD be
- kept below the path MTU to avoid packet fragmentation.
+ header packets which are ~4-12 kilobytes. Within an RTP context, to
+ avoid fragmentation, the Vorbis data packet size SHOULD be kept
+ sufficiently small so that after adding the the RTP and payload
+ headers, the complete RTP packet is smaller than the path MTU.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
@@ -327,17 +327,17 @@
The payload packing of the Vorbis data packets MUST follow the
guidelines set-out in [4] where the oldest packet occurs immediately
- after the RTP packet header.
+ after the RTP packet header. Subsequence packets, if any, MUST
+ follow in temporal order.
- Channel mapping of the audio is in accordance with the Vorbis I
-
Barbato Expires April 24, 2006 [Page 6]
Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
+ Channel mapping of the audio is in accordance with the Vorbis I
Specification [15].
2.4. Example RTP Packet
@@ -388,7 +388,6 @@
-
Barbato Expires April 24, 2006 [Page 7]
Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
@@ -400,25 +399,25 @@
configured probability model. Instead, it packs all entropy decoding
configuration, VQ and Huffman models into a data block that must be
transmitted to the decoder along with the compressed data. A decoder
- also requires identification information detailing the number of
- audio channels, bitrates and other information to configure itself
- for a particular compressed data stream. These two blocks of
- information are often referred to collectively as the "codebooks" for
- a Vorbis stream, and are nominally included as special "header"
- packets at the start of the compressed data.
+ also requires information detailing the number of audio channels,
+ bitrates and similar information to configure itself for a particular
+ compressed data stream. These two blocks of information are often
+ referred to collectively as the "codebooks" for a Vorbis stream, and
+ are nominally included as special "header" packets at the start of
+ the compressed data. In addition, the Vorbis I specification [15]
+ requires the presence of a comment header packet which gives simple
+ metadata about the stream, but this information is not required for
+ decoding the frame sequence.
Thus these two codebook header packets must be received by the
- decoder before any audio data can be interpreted. In addition, the
- Vorbis I specification [15] requires the presense of a comment header
- packet which gives simple metadata about the stream. This
- requirement poses problems in RTP, which is often used over
- unreliable transports.
+ decoder before any audio data can be interpreted. These requirements
+ pose problems in RTP, which is often used over unreliable transports.
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 used to setup an initial state for the client application. The
+ is 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 stream.
@@ -428,12 +427,13 @@
delivery methods MAY be advertised for the same session. The in-band
Configuration delivery SHOULD be considered as baseline, out-of-band
delivery methods that don't use RTP will not be described in this
- document. For non chained streams, the Configuration delivery method
- RECOMMENDED is inline the Packed Configuration (Section 3.1.1) in the
- SDP as explained in the IANA considerations (Section 6.1) section.
+ document. For non chained streams, the Configuration recommended
+ delivery method is inline the Packed Configuration (Section 3.1.1) in
+ the SDP as explained in the IANA considerations (Section 6.1)
+ section.
The 24 bit Ident field is used to map which Configuration will be
- used to decodea packet. When the Ident field changes, it indicates
+ 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
@@ -444,7 +444,6 @@
-
Barbato Expires April 24, 2006 [Page 8]
Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
@@ -513,9 +512,9 @@
3.2. Out of Band Transmission
- This section, as stated before, won't cover all the possible out-of-
- band delivery methods since they rely to different protocols and be
- linked to a specific application. The following packet definition
+ This section, as stated above, does not cover all the possible out-
+ of-band delivery methods since they rely to different protocols and
+ are linked to specific applications. The following packet definition
SHOULD be used in out-of-band delivery and MUST be used when
Configuration is inlined in the SDP.
@@ -711,25 +710,26 @@
fragmented.
-5. Frame Packetizing
+5. Frame Packetization
Each RTP packet contains either one Vorbis packet fragment, or an
- integer number of complete Vorbis packets (up to a max of 15 packets,
- since the number of packets is defined by a 4 bit value).
+ integer number of complete Vorbis packets (up to a maximum of 15
+ packets, since the number of packets is defined by a 4 bit value).
Any Vorbis data packet that is less than path MTU SHOULD be bundled
in the RTP packet with as many Vorbis packets as will fit, up to a
- maximum of 15. Path MTU is detailed in [6] and [7].
+ maximum of 15, except when such bundling would exceed an
+ application's desired transmission latency. Path MTU is detailed in
+ [6] and [7].
- If a Vorbis packet, not only data but also Configuration and Comment,
-
Barbato Expires April 24, 2006 [Page 13]
Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
+ If a Vorbis packet, not only data but also Configuration and Comment,
is larger than 65535 octets it MUST be fragmented. 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
@@ -780,7 +780,6 @@
-
Barbato Expires April 24, 2006 [Page 14]
Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
@@ -1101,7 +1100,7 @@
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 in a short time
+ listening to the content in a short time.
On join the client will receive the current Configuration necessary
to decode the current stream inlined in the SDP. And can start
@@ -1343,4 +1342,3 @@
Barbato Expires April 24, 2006 [Page 24]
-
Modified: trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-00.xml
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-00.xml 2005-12-17 20:10:12 UTC (rev 10625)
+++ trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-00.xml 2005-12-17 20:18:41 UTC (rev 10626)
@@ -163,7 +163,7 @@
Timestamp: 32 bits</t>
<t>
A timestamp representing the sampling time of the first sample of the first Vorbis packet in the RTP packet. The clock frequency
-MUST be set to the sample rate of the encoded audio data and is conveyed out-of-band as a SDP attribute.
+MUST be set to the sample rate of the encoded audio data and is conveyed out-of-band as a SDP parameter.
</t>
<t>
@@ -213,7 +213,7 @@
<t>
Vorbis Data Type (VDT): 2 bits</t>
<t>
-This field sets the packet payload type for the Vorbis data. There are currently three type of Vorbis payloads.
+This field sets the payload type for the Vorbis data in this RTP packet. There are currently three type of Vorbis payloads.
</t>
<vspace blankLines="1" />
@@ -233,7 +233,7 @@
<section anchor="Payload Data" title="Payload Data">
<t>
-Raw Vorbis packets are unbounded in length currently, although at some future point there will likely be a practical limit placed on them. Typical Vorbis packet sizes are from very small (2-3 bytes) to quite large (8-12 kilobytes). The reference implementation <xref target="libvorbis"></xref> typically produces packets less than ~800 bytes, except for the setup header packets which are ~4-12 kilobytes. Within an RTP context the maximum packet size, including the RTP and payload headers, SHOULD be kept below the path MTU to avoid packet fragmentation.
+Raw Vorbis packets are unbounded in length currently, although at some future point application profiles will likely define a practical limit. Typical Vorbis packet sizes are from very small (2-3 bytes) to quite large (8-12 kilobytes). The reference implementation <xref target="libvorbis"></xref> typically produces packets less than ~800 bytes, except for the setup header packets which are ~4-12 kilobytes. Within an RTP context, to avoid fragmentation, the Vorbis data packet size SHOULD be kept sufficiently small so that after adding the the RTP and payload headers, the complete RTP packet is smaller than the path MTU.
</t>
<figure anchor="Payload Data Figure" title="Payload Data Header">
@@ -259,7 +259,7 @@
</t>
<t>
-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.
+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. Subsequence packets, if any, MUST follow in temporal order.
</t>
<t>
@@ -333,20 +333,22 @@
configured probability model. Instead, it packs all entropy decoding
configuration, VQ and Huffman models into a data block that must be
transmitted to the decoder along with the compressed data. A decoder
-also requires identification information detailing the number of audio
-channels, bitrates and other information to configure itself for a
+also requires information detailing the number of audio
+channels, bitrates and similar information to configure itself for a
particular compressed data stream. These two blocks of information are
often referred to collectively as the "codebooks" for a Vorbis stream,
and are nominally included as special "header" packets at the start
-of the compressed data.
+of the compressed data. In addition,
+the <xref target="vorbis-spec-ref">Vorbis I specification</xref>
+requires the presence of a comment header packet which gives simple
+metadata about the stream, but this information is not required for
+decoding the frame sequence.
</t>
<t>
Thus these two codebook header packets must be received by the decoder
-before any audio data can be interpreted. In addition,
-the <xref target="vorbis-spec-ref">Vorbis I specification</xref>
-requires the presense of a comment header packet which gives simple
-metadata about the stream. This requirement poses problems in RTP,
+before any audio data can be interpreted.
+ These requirements pose problems in RTP,
which is often used over unreliable transports.
</t>
@@ -355,17 +357,17 @@
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 used to setup an initial state for the client application.
+delivery is 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 stream.
</t>
<t>
-The delivery vectors in use are 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. Different delivery methods MAY be advertised for the same session. The in-band Configuration delivery SHOULD be considered as baseline, out-of-band delivery methods that don't use RTP will not be described in this document. For non chained streams, the Configuration delivery method RECOMMENDED is inline the <xref target="Packed Configuration">Packed Configuration</xref> in the SDP as explained in the <xref target="Mapping MIME Parameters into SDP"> IANA considerations</xref> section.
+The delivery vectors in use are 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. Different delivery methods MAY be advertised for the same session. The in-band Configuration delivery SHOULD be considered as baseline, out-of-band delivery methods that don't use RTP will not be described in this document. For non chained streams, the Configuration recommended delivery method is inline the <xref target="Packed Configuration">Packed Configuration</xref> in the SDP as explained in the <xref target="Mapping MIME Parameters into SDP"> IANA considerations</xref> section.
</t>
<t>
-The 24 bit Ident field is used to map which Configuration will be used to decodea 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.
+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.
</t>
<section anchor="In-band Header Transmission" title="In-band Header Transmission">
@@ -422,7 +424,7 @@
<t>
-This section, as stated before, won't cover all the possible out-of-band delivery methods since they rely to different protocols and be linked to a specific application. The following packet definition SHOULD be used in out-of-band delivery and MUST be used when Configuration is inlined in the SDP.
+This section, as stated above, does not cover all the possible out-of-band delivery methods since they rely to different protocols and are linked to specific applications. The following packet definition SHOULD be used in out-of-band delivery and MUST be used when Configuration is inlined in the SDP.
</t>
<section anchor="Packed Headers" title="Packed Headers">
@@ -660,14 +662,14 @@
<t>The 2 bytes length field is necessary since this packet could be fragmented.</t>
</section>
-<section anchor="Frame Packetizing" title="Frame Packetizing">
+<section anchor="Frame Packetization" title="Frame Packetization">
<t>
-Each RTP packet contains either one Vorbis packet fragment, or an integer number of complete Vorbis packets (up to a max of 15 packets, since the number of packets is defined by a 4 bit value).
+Each RTP packet contains either one Vorbis packet fragment, or an integer number of complete Vorbis packets (up to a maximum of 15 packets, since the number of packets is defined by a 4 bit value).
</t>
<t>
-Any Vorbis data packet that is less than path MTU SHOULD be bundled in the RTP packet with as many Vorbis packets as will fit, up to a maximum of 15. Path MTU is detailed in <xref target="rfc1063"></xref> and <xref target="rfc1981"></xref>.
+Any Vorbis data packet that is less than path MTU SHOULD be bundled in the RTP packet with as many Vorbis packets as will fit, up to a maximum of 15, except when such bundling would exceed an application's desired transmission latency. Path MTU is detailed in <xref target="rfc1063"></xref> and <xref target="rfc1981"></xref>.
</t>
<t>
@@ -995,7 +997,7 @@
<t>That 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 dj'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 in a short time</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 in a short time.</t>
<t>On join the client will receive the current Configuration necessary to decode the current stream inlined in the SDP. And can start decoding the current stream as soon it joins the session.</t>
More information about the commits
mailing list