[xiph-commits] r8561 - trunk/vorbis/doc
philkerr at motherfish-iii.xiph.org
philkerr at motherfish-iii.xiph.org
Thu Dec 30 20:39:30 PST 2004
Author: philkerr
Date: 2004-12-30 20:39:29 -0800 (Thu, 30 Dec 2004)
New Revision: 8561
Modified:
trunk/vorbis/doc/draft-kerr-avt-vorbis-rtp-04.xml
Log:
Cleaned up references section and minor text improvements. -PK
Modified: trunk/vorbis/doc/draft-kerr-avt-vorbis-rtp-04.xml
===================================================================
--- trunk/vorbis/doc/draft-kerr-avt-vorbis-rtp-04.xml 2004-12-30 21:29:40 UTC (rev 8560)
+++ trunk/vorbis/doc/draft-kerr-avt-vorbis-rtp-04.xml 2004-12-31 04:39:29 UTC (rev 8561)
@@ -15,7 +15,7 @@
</address>
</author>
-<date day="11" month="December" year="2004" />
+<date day="31" month="December" year="2004" />
<area>General</area>
<workgroup>AVT Working Group</workgroup>
@@ -24,54 +24,51 @@
<keyword>Internet-Draft</keyword>
<keyword>Vorbis</keyword>
<keyword>RTP</keyword>
+
<abstract>
<t>This document describes a RTP payload format for transporting
- Vorbis encoded audio. It details the RTP encapsulation mechanism
- for raw Vorbis data and details the delivery mechanisms for the
- decoder probability model, referred to as a codebook, metadata
- and other setup information.</t>
+Vorbis encoded audio. It details the RTP encapsulation mechanism
+for raw Vorbis data and details the delivery mechanisms for the
+decoder probability model, referred to as a codebook, metadata
+and other setup information.</t>
</abstract>
-<note title="Xiph.Org Note">
+<note title="Editors Note">
<t>
- This is a working copy of the Vorbis I-D, used for discussion on the xiph-rtp discussion list. It will be subject
- to frequent revisions before it is submitted to the IETF at the end of December.
+All references to RFC XXXX are to be replaced by references to the RFC number of this memo, when published.
</t>
</note>
-<note title="Editors Note">
-<t>
- All references to RFC XXXX are to be replaced by references to the RFC number of this memo, when published.
-</t>
-</note>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>
- Vorbis is a general purpose perceptual audio codec intended to allow
- maximum encoder flexibility, thus allowing it to scale competitively
- over an exceptionally wide range of bitrates. At the high
- quality/bitrate end of the scale (CD or DAT rate stereo,
- 16/24 bits), it is in the same league as MPEG-2 and MPC. Similarly,
- the 1.0 encoder can encode high-quality CD and DAT rate stereo at
- below 48k bits/sec without resampling to a lower rate. Vorbis is
- also intended for lower and higher sample rates (from 8kHz
- telephony to 192kHz digital masters) and a range of channel
- representations (monaural, polyphonic, stereo, quadraphonic, 5.1,
- ambisonic, or up to 255 discrete channels).
+Vorbis is a general purpose perceptual audio codec intended to allow
+maximum encoder flexibility, thus allowing it to scale competitively
+over an exceptionally wide range of bitrates. At the high
+quality/bitrate end of the scale (CD or DAT rate stereo,
+16/24 bits), it is in the same league as MPEG-2 and MPC. Similarly,
+the 1.0 encoder can encode high-quality CD and DAT rate stereo at
+below 48k bits/sec without resampling to a lower rate. Vorbis is
+also intended for lower and higher sample rates (from 8kHz
+telephony to 192kHz digital masters) and a range of channel
+representations (monaural, polyphonic, stereo, quadraphonic, 5.1,
+ambisonic, or up to 255 discrete channels).
- Vorbis encoded audio is generally encapsulated within an Ogg format
- bitstream <xref target="rfc3533"></xref>, which provides framing and synchronization. For the
- purposes of RTP transport, this layer is unnecessary, and so raw
- Vorbis packets are used in the payload.
+Vorbis encoded audio is generally encapsulated within an Ogg format
+bitstream <xref target="rfc3533"></xref>, which provides framing and synchronization. For the
+purposes of RTP transport, this layer is unnecessary, and so raw
+Vorbis packets are used in the payload.
</t>
+
<section anchor="Terminology" title="Terminology">
+
<t>
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 <xref target="rfc2119"></xref>.
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in RFC 2119 <xref target="rfc2119"></xref>.
</t>
</section>
@@ -79,14 +76,15 @@
<section anchor="Payload Format" title="Payload Format">
<t>
- For RTP based transportation of Vorbis encoded audio the standard
- RTP header is followed by a 5 octet payload header, then the payload
- data. The payload headers are used to associate the Vorbis data with
- its associated decoding codebooks as well as indicating if the following packet
- contains fragmented Vorbis data and/or the the number of whole Vorbis
- data frames. The payload data contains the raw Vorbis bitstream
- information.
+For RTP based transportation of Vorbis encoded audio the standard
+RTP header is followed by a 5 octet payload header, then the payload
+data. The payload headers are used to associate the Vorbis data with
+its associated decoding codebooks as well as indicating if the following packet
+contains fragmented Vorbis data and/or the the number of whole Vorbis
+data frames. The payload data contains the raw Vorbis bitstream
+information.
</t>
+
<section anchor="RTP Header" title="RTP Header">
<artwork><![CDATA[
@@ -103,68 +101,81 @@
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
+
<t>
- The RTP header begins with an octet of fields (V, P, X, and CC) to
- support specialized RTP uses (see <xref target="avt-rtp-new-11"></xref> and <xref target="avt-profile-new-12"></xref> for details). For Vorbis RTP, the following values are used.
+The RTP header begins with an octet of fields (V, P, X, and CC) to
+support specialized RTP uses (see <xref target="rfc3550"></xref> and <xref target="rfc3551"></xref> for details). For Vorbis RTP, the following values are used.
+</t>
+
<t>
+Version (V): 2 bits</t><t>
+This field identifies the version of RTP. The version
+used by this specification is two (2).
</t>
- Version (V): 2 bits</t><t>
- This field identifies the version of RTP. The version
- used by this specification is two (2).
+
<t>
+Padding (P): 1 bit</t><t>
+Padding MAY be used with this payload format according to
+section 5.1 of <xref target="rfc3550"></xref>.
</t>
- Padding (P): 1 bit</t><t>
- Padding MAY be used with this payload format according to
- section 5.1 of <xref target="avt-rtp-new-11"></xref>.
+
<t>
+Extension (X): 1 bit</t><t>
+Always set to 0, as audio silence suppression is not used by
+the Vorbis codec.
</t>
- Extension (X): 1 bit</t><t>
- Always set to 0, as audio silence suppression is not used by
- the Vorbis codec.
+
<t>
+CSRC count (CC): 4 bits</t><t>
+The CSRC count is used in accordance with <xref target="rfc3550"></xref>.
</t>
- CSRC count (CC): 4 bits</t><t>
- The CSRC count is used in accordance with <xref target="rfc1889"></xref>.
+
<t>
+Marker (M): 1 bit</t><t>
+Set to zero. Audio silence suppression not used. This conforms
+to section 4.1 of <xref target="vorbis-spec-ref"></xref>.
</t>
- Marker (M): 1 bit</t><t>
- Set to zero. Audio silence suppression not used. This conforms
- to section 4.1 of <xref target="vorbis-spec-ref"></xref>.
+
<t>
+Payload Type (PT): 7 bits</t><t>
+An RTP profile for a class of applications is expected to assign
+a payload type for this format, or a dynamically allocated
+payload type SHOULD be chosen which designates the payload as
+Vorbis.
</t>
- Payload Type (PT): 7 bits</t><t>
- An RTP profile for a class of applications is expected to assign
- a payload type for this format, or a dynamically allocated
- payload type SHOULD be chosen which designates the payload as
- Vorbis.
+
<t>
+Sequence number: 16 bits</t><t>
+The sequence number increments by one for each RTP data packet
+sent, and may be used by the receiver to detect packet loss and
+to restore packet sequence. This field is detailed further in
+<xref target="rfc3550"></xref>.
</t>
- Sequence number: 16 bits</t><t>
- The sequence number increments by one for each RTP data packet
- sent, and may be used by the receiver to detect packet loss and
- to restore packet sequence. This field is detailed further in
- <xref target="rfc1889"></xref>.
+
<t>
+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.
</t>
- 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.
+
<t>
+SSRC/CSRC identifiers: </t><t>
+These two fields, 32 bits each with one SSRC field and a maximum
+of 16 CSRC fields, are as defined in <xref target="rfc3550"></xref>.
</t>
- SSRC/CSRC identifiers: </t><t>
- These two fields, 32 bits each with one SSRC field and a maximum
- of 16 CSRC fields, are as defined in <xref target="rfc1889"></xref>.
-</t>
+
</section>
<section anchor="Payload Header" title="Payload Header">
+
<t>
- After the RTP Header section the following five octets are the Payload Header.
- This header is split into a number of bitfields detailing the format
- of the following Payload Data packets.
+After the RTP Header section the following five octets are the Payload Header.
+This header is split into a number of bitfields detailing the format
+of the following Payload Data packets.
</t>
+
<artwork><![CDATA[
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
@@ -176,25 +187,29 @@
]]></artwork>
<t>
- Codebook Ident: 32 bits</t><t>
- This 32 bit field is used to associate the Vorbis data to a decoding Codebook.
- It is created by making a CRC32 checksum of the codebook required to decode the
- particular Vorbis audio stream.
+Codebook Ident: 32 bits</t><t>
+This 32 bit field is used to associate the Vorbis data to a decoding Codebook.
+It is created by making a CRC32 checksum of the codebook required to decode the
+particular Vorbis audio stream.
</t>
+
<t>
- Continuation (C): 1 bit</t><t>
- Set to one if this is a continuation of a fragmented packet.
+Continuation (C): 1 bit</t><t>
+Set to one if this is a continuation of a fragmented packet.
</t>
+
<t>
- Fragmented (F): 1 bit</t><t>
- Set to one if the payload contains complete packets or if it
- contains the last fragment of a fragmented packet.
+Fragmented (F): 1 bit</t><t>
+Set to one if the payload contains complete packets or if it
+contains the last fragment of a fragmented packet.
</t>
+
<t>
- Payload Type (T): 2 bits</t><t>
- This field sets the packet payload type. There are currently four type of packet payloads.
+Payload Type (T): 2 bits</t><t>
+This field sets the packet payload type. There are currently four type of packet payloads.
</t>
-<t></t>
+
+<vspace blankLines="1" />
<list style="empty">
<t> 0 = Raw Vorbis payload</t>
<t> 1 = Configuration payload</t>
@@ -203,58 +218,65 @@
</list>
<t>
- The last 4 bits are the number of complete packets in this payload.
- This provides for a maximum number of 16 Vorbis packets in the
- payload. If the packet contains fragmented data the number of packets MUST be set to 0.
+The last 4 bits are the number of complete packets in this payload.
+This provides for a maximum number of 15 Vorbis packets in the
+payload. If the packet contains fragmented data the number of packets MUST be set to 0.
</t>
+
</section>
<section anchor="Payload Data" title="Payload Data">
+
<t>
- 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
- codebook header packets which are ~4-12 kilobytes.
- Within an RTP context the maximum Vorbis packet size, including the RTP and payload
- headers, MUST be kept below the path MTU to avoid packet fragmentation.
+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
+codebook header packets which are ~4-12 kilobytes.
+Within an RTP context the maximum Vorbis packet size, including the RTP and payload
+headers, SHOULD be kept below the path MTU to avoid packet fragmentation.
</t>
+
<t>
- Each Vorbis payload packet starts with a one 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 one octet length header,
+which is used to represent the size of the following data payload, followed
+by the raw Vorbis data.
</t>
+
<t>
- For payloads which consist of multiple Vorbis packets the payload data
- consists of the packet length followed by the packet data for each of
- the Vorbis packets in the payload.
+For payloads which consist of multiple Vorbis packets the payload data
+consists of the packet length followed by the packet data for each of
+the Vorbis packets in the payload.
</t>
+
<t>
- The Vorbis packet length header is the length of the Vorbis data
- block only and does not count the length octet.
+The Vorbis packet length header is the length of the Vorbis data
+block only and does not count the length octet.
</t>
+
<t>
- The payload packing of the Vorbis data packets SHOULD follow the
- guidelines set-out in section 4.4 of <xref target="avt-profile-new-12"></xref> where the oldest packet
- occurs immediately after the RTP packet header.
+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.
</t>
+
<t>
- Channel mapping of the audio is in accordance with BS. 775-1
- ITU-R.
+Channel mapping of the audio is in accordance with BS. 775-1
+ITU-R.
</t>
+
</section>
+<section anchor="Example RTP Packet" title="Example RTP Packet">
-<section anchor="Example RTP Packet" title="Example RTP Packet">
<t>
- Here is an example RTP packet containing two Vorbis packets.
+Here is an example RTP packet containing two Vorbis packets.
</t>
<t>
- RTP Packet Header:
+RTP Packet Header:
</t>
-<t>
<artwork><![CDATA[
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
@@ -269,11 +291,11 @@
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
-</t>
+
<t>
- Payload Data:
+Payload Data:
</t>
-<t>
+
<artwork><![CDATA[
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
@@ -288,45 +310,48 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
-</t>
</section>
-
</section>
<section anchor="Frame Packetizing" title="Frame Packetizing">
+
<t>
- Each RTP packet contains either one complete Vorbis packet, one
- Vorbis packet fragment, or an integer number of complete Vorbis
- packets (up to a max of 16 packets, since the number of packets
- is defined by a 4 bit value).
+Each RTP packet contains either one complete Vorbis packet, 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).
</t>
+
<t>
- Any Vorbis data packet that is 256 octets or less SHOULD be bundled in the
- RTP packet with as many Vorbis packets as will fit, up to a maximum
- of 16.
+Any Vorbis data packet that is 256 octets or less SHOULD be bundled in the
+RTP packet with as many Vorbis packets as will fit, up to a maximum
+of 15.
</t>
+
<t>
- If a Vorbis packet is larger than 256 octets it MUST be
- fragmented. A fragmented packet has a zero in the last four bits
- of the payload header. Each fragment after the first will also set
- the Continued (C) bit to one in the payload header. The RTP packet
- containing the last fragment of the Vorbis packet will have the
- Fragmented (F) bit set to one. 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 packets. Path
- MTU is detailed in <xref target="rfc1063"></xref> and <xref target="rfc1981"></xref>.
+If a Vorbis packet is larger than 256 octets it MUST be
+fragmented. A fragmented packet has a zero in the last four bits
+of the payload header. Each fragment after the first will also set
+the Continued (C) bit to one in the payload header. The RTP packet
+containing the last fragment of the Vorbis packet will have the
+Fragmented (F) bit set to one. 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 packets. Path
+MTU is detailed in <xref target="rfc1063"></xref> and <xref target="rfc1981"></xref>.
</t>
<section anchor="Example Fragmented Vorbis Packet" title="Example Fragmented Vorbis Packet">
+
<t>
- Here is an example fragmented Vorbis packet split over three RTP
- packets.
+Here is an example fragmented Vorbis packet split over three RTP
+packets.
</t>
+
<artwork><![CDATA[
+ Packet 1:
- Packet 1:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -346,17 +371,16 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..vorbis data.. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
]]></artwork>
<t>
- In this packet the initial sequence number is 1000 and the
- timestamp is xxxxx. The number of packets field is set to 0.
+In this packet the initial sequence number is 1000 and the
+timestamp is xxxxx. The number of packets field is set to 0.
</t>
<artwork><![CDATA[
+ Packet 2:
- Packet 2:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -379,16 +403,15 @@
]]></artwork>
<t>
- The C bit is set to 1 and the number of packets field is set to 0.
- For large Vorbis fragments there can be several of these type of
- payload packets. The maximum packet size SHOULD be no greater
- than the path MTU, including all RTP and payload headers. The
- sequence number has been incremented by one but the timestamp field
- remains the same as the initial packet.
+The C bit is set to 1 and the number of packets field is set to 0.
+For large Vorbis fragments there can be several of these type of
+payload packets. The maximum packet size SHOULD be no greater
+than the path MTU, including all RTP and payload headers. The
+sequence number has been incremented by one but the timestamp field
+remains the same as the initial packet.
</t>
<artwork><![CDATA[
-
Packet 3:
0 1 2 3
@@ -410,94 +433,100 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..vorbis data.. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
]]></artwork>
<t>
- This is the last Vorbis fragment packet. The C and F bits are
- set and the packet count remains set to 0. As in the previous
- packets the timestamp remains set to the first packet in the
- sequence and the sequence number has been incremented.
+This is the last Vorbis fragment packet. The C and F bits are
+set and the packet count remains set to 0. As in the previous
+packets the timestamp remains set to the first packet in the
+sequence and the sequence number has been incremented.
</t>
</section>
<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 C and F flags. If we use the
- fragmented Vorbis packet example above and the first packet is
- lost the client SHOULD detect that the next packet has the packet
- count field set to 0 and the C bit is set and MUST drop it. The
- next packet, which is the final fragmented packet, SHOULD be dropped
- in the same manner, or buffered. 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 C and F flags. If we use the
+fragmented Vorbis packet example above and the first packet is
+lost the client SHOULD detect that the next packet has the packet
+count field set to 0 and the C bit is set and MUST drop it. The
+next packet, which is the final fragmented packet, SHOULD be dropped
+in the same manner, or buffered. Feedback reports on lost and
+dropped packets MUST be sent back via RTCP.
</t>
+
</section>
+
</section>
+<section anchor="Configuration Headers" title="Configuration Headers">
-<section anchor="Configuration Headers" title="Configuration Headers">
<t>
- To decode a Vorbis stream three configuration header blocks are
- needed. The first header indicates the sample and bitrates, the
- number of channels and the version of the Vorbis encoder used.
- The second header contains the decoders probability model, or
- codebook and the third header details stream metadata.
+Unlike other mainstream audio codecs Vorbis has no statically
+configured probability model, instead it packs all entropy decoding
+configuration, VQ and Huffman models into a self-contained codebook.
+This codebook block also requires additional identification
+information detailing the number of audio channels, bitrates and
+other information used to initialise the Vorbis stream.
</t>
+
<t>
- As the RTP stream may change certain configuration data mid-session
- there are two different methods for delivering this configuration
- data to a client, in-band which is detailed below and SDP which is
- detailed in section 4.3. SDP delivery is used to set-up an initial
- state for the client application and in-band is used to change state
- during the session. The changes may be due to different metadata
- or codebooks as well as different bitrates of the stream.
+To decode a Vorbis stream three configuration header blocks are
+needed. The first header indicates the sample and bitrates, the
+number of channels and the version of the Vorbis encoder used.
+The second header contains the decoders probability model, or
+codebook and the third header details stream metadata.
</t>
+
<t>
- Unlike other mainstream audio codecs Vorbis has no statically
- configured probability model, instead it packs all entropy decoding
- configuration, VQ and Huffman models into a self-contained codebook.
- This codebook block also requires additional identification
- information detailing the number of audio channels, bit rates and
- other information used to initialise the Vorbis stream.
+As the RTP stream may change certain configuration data mid-session
+there are two different methods for delivering this configuration
+data to a client, in-band and SDP which is
+detailed below. SDP delivery is used to set-up an initial
+state for the client application and in-band is used to change state
+during the session. The changes may be due to different metadata
+or codebooks as well as different bitrates of the stream.
</t>
+
<t>
- Out of the two delivery vectors the use of an SDP attribute to indicate an URI
- where the configuration and codebook data can be obtained is preferred
- as they can be fetched reliably using TCP. The in-band codebook delivery SHOULD
- only be used in situations where the link between the client is unidirectional or if
- the SDP-based information is not available.
+Out of the two delivery vectors the use of an SDP attribute to indicate an URI
+where the configuration and codebook data can be obtained is preferred
+as they can be fetched reliably using TCP. The in-band codebook delivery SHOULD
+only be used in situations where the link between the client is unidirectional or if
+the SDP-based information is not available.
</t>
<t>
- Synchronizing the configuration and codebook headers to the RTP stream is
- critical. The 32 bit Codebook Ident field is used to indicate when a change in the stream has
- taken place. The client application MUST have in advance the correct configuration and codebook
- headers 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.
+Synchronizing the configuration and codebook headers to the RTP stream is
+critical. The 32 bit Codebook Ident field is used to indicate when a change in the stream has
+taken place. The client application MUST have in advance the correct configuration and codebook
+headers 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.
</t>
+<section anchor="In-band Header Transmission" title="In-band Header Transmission">
-<section anchor="In-band Header Transmission" title="In-band Header Transmission">
<t>
- The three header data blocks are sent in-band with the packet type bits set to
- match the payload type. The transmission sequence for the headers MUST be in
- this order: configuration, codebook, metadata. The codebook and configuration
- headers are sent once per session if the stream is an encoding of live audio, but
- can change at the boundary of chained Vorbis audio files. Metadata can be sent at the
- start as well as any time during the life of the session.
+The three header data blocks are sent in-band with the packet type bits set to
+match the payload type. Normally the codebook and configuration
+headers are sent once per session if the stream is an encoding of live audio, as typically
+the encoder state will not change, but the encoder state can change at the boundary
+of chained Vorbis audio files. Metadata can be sent at the start as well as any time during
+the life of the session. Clients MUST be capable of dealing with periodic re-transmission of the
+configuration headers.
</t>
<t>
- The Vorbis configuration header is indicated with the payload type set to 1.
- The Vorbis version MUST be set to zero to comply with
- this document. The fields Sample Rate, Bitrate Maximum/Nominal/
- Minimum and Num Audio Channels are set in accordance with <xref target="vorbis-spec-ref"></xref> with
- the bsz fields above referring to the blocksize parameters. The
- framing bit is not used for RTP transportation and so applications
- constructing Vorbis files MUST take care to set this if required.
+A Vorbis configuration header is indicated with the payload type field set to 1.
+The Vorbis version MUST be set to zero to comply with
+this document. The fields Sample Rate, Bitrate Maximum/Nominal/
+Minimum and Num Audio Channels are set in accordance with <xref target="vorbis-spec-ref"></xref> with
+the bsz fields above referring to the blocksize parameters. The
+framing bit is not used for RTP transportation and so applications
+constructing Vorbis files MUST take care to set this if required.
</t>
<artwork><![CDATA[
@@ -531,33 +560,33 @@
]]></artwork>
<t>
- If the payload type field is set to 2 this indicates the packet contains codebook data.
+If the payload type field is set to 2, this indicates the packet contains codebook data.
</t>
+
<t>
- The configuration information detailed below MUST be completely
- intact, as a client can not decode a stream with an incomplete
- or corrupted codebook set.
+The configuration information detailed below MUST be completely
+intact, as a client can not decode a stream with an incomplete
+or corrupted codebook set.
</t>
+
<t>
- A 16 bit codebook length field precedes the codebook datablock. The length field
- allows for codebooks to be up to 64K in size. Packet fragmentation,
- as per the Vorbis data, MUST be performed if the codebooks size exceeds
- path MTU. The Codebook Ident field MUST be set to match the associated codebook
- needed to decode the Vorbis stream.
+A 16 bit codebook length field precedes the codebook datablock. The length field
+allows for codebooks to be up to 64K in size. Packet fragmentation,
+as per the Vorbis data, MUST be performed if the codebooks size exceeds
+path MTU. The Codebook Ident field MUST be set to match the associated codebook
+needed to decode the Vorbis stream.
+</t>
-</t>
<t>
- The Codebook Ident is the CRC32 checksum of the codebook and
- is used to detect a corrupted codebook as well as
- associating it with its Vorbis data stream. This Ident value
- MUST NOT be set to the value of the current stream if this header is
- being sent before the boundary of the chained file has been reached.
- If a checksum failure is detected then this is considered to
- be a failure and MUST be reported to the client application.
-
+The Codebook Ident is the CRC32 checksum of the codebook and
+is used to detect a corrupted codebook as well as
+associating it with its Vorbis data stream. This Ident value
+MUST NOT be set to the value of the current stream if this header is
+being sent before the boundary of the chained file has been reached.
+If a checksum failure is detected then this is considered to
+be a failure and MUST be reported to the client application.
</t>
-
<artwork><![CDATA[
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
@@ -580,29 +609,44 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Codebook |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
]]></artwork>
<t>
- With the payload type flag set to 3, 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 message MUST be sent at
- the start of the stream, together with the setup and codebook
- headers, even if it contains no information. During a session the
- metadata associated with the stream may change from that specified
- at the start, e.g. a live concert broadcast changing acts/scenes, so
- clients MUST have the ability to receive header blocks. Details
- on the format of the comments can be found in the Vorbis
- documentation <xref target="v-comment"></xref>.
+With the payload type flag set to 3, 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 message MUST be sent at
+the start of the stream, together with the setup and codebook
+headers, even if it contains no information. During a session the
+metadata associated with the stream may change from that specified
+at the start, e.g. a live concert broadcast changing acts/scenes, so
+clients MUST have the ability to receive header blocks. Details
+on the format of the comments can be found in the Vorbis
+documentation <xref target="v-comment"></xref>.
</t>
+
+
+ 1) [vendor_length] = read an unsigned integer of 32 bits
+ 2) [vendor_string] = read a UTF-8 vector as [vendor_length] octets
+ 3) [user_comment_list_length] = read an unsigned integer of 32 bits
+ 4) iterate [user_comment_list_length] times {
+
+ 5) [length] = read an unsigned integer of 32 bits
+ 6) this iteration's user comment = read a UTF-8 vector as [length] octets
+
+ }
+
+ 7) [framing_bit] = read a single bit as boolean
+ 8) if ( [framing_bit] unset or end of packet ) then ERROR
+ 9) done.
+
+
<t>
- The format for the data takes the form of a 32 bit codec vendors
- name length field followed by the name encoded in UTF-8. The next
- field denotes the number of user comments and then the user comments
- length and text field pairs, up to the number indicated by the user
- comment list length.
+The format for the data takes the form of a 32 bit codec vendors
+name length field followed by the name encoded in UTF-8. The next 32
+bit field denotes the number of user comments. Each of the user comments
+is prefixed by a 32 bit length field followed by the comment text.
</t>
<artwork><![CDATA[
@@ -633,143 +677,168 @@
</section>
-<section anchor="Codebook Caching" title="Codebook Caching">
-<t>
- Codebook caching allows clients that have previously connected to a
- stream to re-use the associated codebooks. When a client receives a codebook it may store
- it locally and can compare the CRC32 key with that of the new stream.
-</t>
-</section>
-
<section anchor="Session Description for Vorbis RTP Streams" title="Session Description for Vorbis RTP Streams">
<t>
- Session description information concerning the Vorbis stream
- SHOULD be provided if possible and MUST be in accordance with <xref target="rfc2327"></xref>.
+Session description information concerning the Vorbis stream
+SHOULD be provided if possible and MUST be in accordance with <xref target="rfc2327"></xref>.
</t>
<t>
- If the stream comprises chained Vorbis files the configuration and codebook headers for each
- file SHOULD be packaged together and passed to the client using the headers attribute.
+If the stream comprises chained Vorbis files the configuration and codebook headers for each
+file SHOULD be packaged together and passed to the client using the headers attribute.
</t>
<t>
- Below is an outline of the mandatory SDP attributes.
+Below is an outline of the mandatory SDP attributes.
</t>
+
+<vspace blankLines="1" />
<list style="empty">
-<t></t>
-<t> c=IN IP4/6 </t>
-<t> m=audio RTP/AVP 98</t>
-<t> a=rtpmap:98 VORBIS/44100/2</t>
-<t> a=fmtp:98 header=<URI of configuration header> </t>
+<t>c=IN IP4/6 </t>
+<t>m=audio RTP/AVP 98</t>
+<t>a=rtpmap:98 VORBIS/44100/2</t>
+<t>a=fmtp:98 header=<URI of configuration header> </t>
</list>
+
<t>
- The Vorbis configuraton specified in the header attribute MUST contain
- all of the configuration data and codebooks needed for the life of the session.
+The Vorbis configuration specified in the header attribute MUST contain
+all of the configuration data and codebooks needed for the life of the session.
</t>
+
<t>
- The port value is specified by the server application bound to
- the address specified in the c attribute. The bitrate value
- and channels specified in the m attribute MUST match the Vorbis
- sample rate value.
+The port value is specified by the server application bound to
+the address specified in the c attribute. The bitrate value
+and channels specified in the m attribute MUST match the Vorbis
+sample rate value.
</t>
+
</section>
+<section anchor="Codebook Caching" title="Codebook Caching">
+
+<t>
+Codebook caching allows clients that have previously connected to a
+stream to re-use the associated codebooks and configuration data.
+When a client receives a codebook it may store it locally and can
+compare the CRC32 key with that of the new stream and begin decoding
+before it has received any of the headers.
+</t>
+
</section>
+</section>
+
<section anchor="IANA Considerations" title="IANA Considerations">
+
<t>
- MIME media type name: audio
+MIME media type name: audio
</t>
<t>
- MIME subtype: vorbis
+MIME subtype: vorbis
</t>
+
<t>
- Required Parameters:</t><t>
- header indicates the URI of the decoding codebook.
+Required Parameters:</t><t>
+header indicates the URI of the decoding configuration headers.
</t>
+
<t>
- Optional Parameters: </t><t>
- None.
+Optional Parameters: </t><t>
+None.
</t>
+
<t>
- Encoding considerations:</t><t>
- This type is only defined for transfer via RTP as specified
- in RFC XXXX.
+Encoding considerations:</t><t>
+This type is only defined for transfer via RTP as specified
+in RFC XXXX.
</t>
+
<t>
- Security Considerations:</t><t>
- See Section 6 of RFC 3047.
+Security Considerations:</t><t>
+See Section 6 of RFC 3047.
</t>
+
<t>
- Interoperability considerations: none
+Interoperability considerations: none
</t>
+
<t>
+Published specification:</t>
+<t>See the Vorbis documentation <xref target="vorbis-spec-ref"></xref> for details.</t>
- Published specification:
- See the Vorbis documentation <xref target="vorbis-spec-ref"></xref> for details.
-</t>
<t>
- Applications which use this media type:
- Audio streaming and conferencing tools
+Applications which use this media type:</t><t>
+Audio streaming and conferencing tools
</t>
+
<t>
- Additional information: none
+Additional information: none
</t>
+
<t>
- Person & email address to contact for further information:</t><t>
- Phil Kerr
- phil at plus24.com
+Person & email address to contact for further information:</t><t>
+Phil Kerr: <phil at plus24.com>
</t>
+
<t>
- Intended usage: COMMON
+Intended usage: COMMON
</t>
+
<t>
- Author/Change controller:</t><t>
- Author: Phil Kerr
- Change controller: IETF AVT Working Group
+Author/Change controller:</t><t>
+Author: Phil Kerr
+Change controller: IETF AVT Working Group
</t>
+
</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.
+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="Security Considerations" title="Security Considerations">
<t>
- RTP packets using this payload format are subject to the security
- considerations discussed in the RTP specification <xref target="rfc1889"></xref>. This implies
- that the confidentiality of the media stream is achieved by using
- encryption. Because the data compression used with this payload
- format is applied end-to-end, encryption may be performed on the
- compressed data. Where the size of a data block is set care MUST
- be taken to prevent buffer overflows in the client applications.
+RTP packets using this payload format are subject to the security
+considerations discussed in the RTP specification <xref target="rfc3550"></xref>. This implies
+that the confidentiality of the media stream is achieved by using
+encryption. Because the data compression used with this payload
+format is applied end-to-end, encryption may be performed on the
+compressed data. Where the size of a data block is set care MUST
+be taken to prevent buffer overflows in the client applications.
</t>
+
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
+
<t>
- This document is a continuation of draft-moffitt-vorbis-rtp-00.txt.
- The MIME type section is a continuation of draft-short-avt-rtp-
- vorbis-mime-00.txt
+This document is a continuation of draft-moffitt-vorbis-rtp-00.txt.
+The MIME type section is a continuation of draft-short-avt-rtp-
+vorbis-mime-00.txt
</t>
+
<t>
- Thanks to the AVT, Ogg Vorbis Communities / Xiph.org including
- Steve Casner, Aaron Colwell, Ross Finlayson, Ramon Garcia, Pascal Hennequin, Ralph Giles,
- Tor-Einar Jarnbjo, Colin Law, John Lazzaro, Jack Moffitt, Christopher Montgomery,
- Colin Perkins, Barry Short, Mike Smith, Magnus Westerlund.
+Thanks to the AVT, Ogg Vorbis Communities / Xiph.org including
+Steve Casner, Aaron Colwell, Ross Finlayson, Ramon Garcia, Pascal Hennequin, Ralph Giles,
+Tor-Einar Jarnbjo, Colin Law, John Lazzaro, Jack Moffitt, Christopher Montgomery,
+Colin Perkins, Barry Short, Mike Smith, Magnus Westerlund.
</t>
+
</section>
</middle>
<back>
+
<references title="Normative References">
<reference anchor="rfc3533">
@@ -788,38 +857,27 @@
<seriesInfo name="RFC" value="2119" />
</reference>
-<reference anchor="rfc1889">
+<reference anchor="rfc3550">
<front>
-<title>RTP: A Transport Protocol for Real-Time Applications</title>
-<author initials="H." surname="Schulzrinne, et al." fullname="Henning Schulzrinne, et al."></author>
+<title>RTP: A Transport Protocol for real-time applications</title>
+<author initials="H." surname="Schulzrinne" fullname=""></author>
+<author initials="S." surname="Casner" fullname=""></author>
+<author initials="R." surname="Frederick" fullname=""></author>
+<author initials="V." surname="Jacobson" fullname=""></author>
</front>
-<seriesInfo name="RFC" value="1889" />
-</reference>
+<seriesInfo name="RFC" value="3550" />
+</reference>
-<reference anchor="avt-rtp-new-11">
+<reference anchor="rfc3551">
<front>
-<title>RTP: A transport protocol for real-time applications. Work in progress, draft-ietf-avt-rtp-new-11.txt</title>
+<title>RTP Profile for Audio and Video Conferences with Minimal Control.</title>
+<author initials="H." surname="Schulzrinne" fullname=""></author>
+<author initials="S." surname="Casner" fullname=""></author>
</front>
-</reference>
+<date month="July" year="2003" />
+<seriesInfo name="RFC" value="3551" />
+</reference>
-<reference anchor="avt-profile-new-12">
-<front>
-<title>RTP Profile for Audio and Video Conferences with Minimal Control. Work in progress, draft-ietf-avt-profile-new-12.txt</title>
-</front>
-</reference>
-
-<reference anchor="vorbis-spec-ref">
-<front>
-<title>Ogg Vorbis I spec: Codec setup and packet decode. http://www.xiph.org/ogg/vorbis/doc/vorbis-spec-ref.html</title>
-</front>
-</reference>
-
-<reference anchor="v-comment">
-<front>
-<title>Ogg Vorbis I spec: Comment field and header specification. http://www.xiph.org/ogg/vorbis/doc/v-comment.html</title>
-</front>
-</reference>
-
<reference anchor="rfc2327">
<front>
<title>SDP: Session Description Protocol</title>
@@ -853,6 +911,18 @@
</front>
</reference>
+<reference anchor="vorbis-spec-ref">
+<front>
+<title>Ogg Vorbis I spec: Codec setup and packet decode. http://www.xiph.org/ogg/vorbis/doc/vorbis-spec-ref.html</title>
+</front>
+</reference>
+
+<reference anchor="v-comment">
+<front>
+<title>Ogg Vorbis I spec: Comment field and header specification. http://www.xiph.org/ogg/vorbis/doc/v-comment.html</title>
+</front>
+</reference>
+
</references>
</back>
</rfc>
More information about the commits
mailing list