[xiph-commits] r10173 - trunk/vorbis/doc
lu_zero at svn.xiph.org
lu_zero at svn.xiph.org
Mon Oct 17 13:32:40 PDT 2005
Author: lu_zero
Date: 2005-10-17 13:32:37 -0700 (Mon, 17 Oct 2005)
New Revision: 10173
Modified:
trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-01.xml
Log:
24 bit tag instead of 32bit hash, other changes propagated by that
Modified: trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-01.xml
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-01.xml 2005-10-17 18:14:48 UTC (rev 10172)
+++ trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-01.xml 2005-10-17 20:32:37 UTC (rev 10173)
@@ -6,7 +6,7 @@
<rfc ipr="full3667" docName="RTP Payload Format for Vorbis Encoded Audio">
<front>
-<title>draft-ietf-avt-vorbis-rtp-01</title>
+<title>draft-ietf-avt-vorbis-rtp-00</title>
<author initials="L" surname="Barbato" fullname="Luca Barbato">
<organization>Xiph.Org</organization>
@@ -77,16 +77,13 @@
<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 4 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">
<t>
-The format of the RTP header is specified in <xref target="rfc3550"></xref> and shown in Figure 1. This payload format uses the fields of the header in a manner consistent with that specification.
+The format of the RTP header is specified in <xref target="rfc3550"></xref> and shown in Figure <xref target="RTP Header Figure"/>. This payload format uses the fields of the header in a manner consistent with that specification.
</t>
<t>
@@ -176,8 +173,7 @@
<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 4 octets are the Payload Header. This header is split into a number of bitfields detailing the format of the following payload data packets.
</t>
<figure anchor="Payload Header Figure" title="Payload Header">
@@ -185,17 +181,15 @@
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident |
+ | Ident | F |VDT|# pkts.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | F |VDT|# pkts.|
- +-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
-Ident: 32 bits</t>
+Ident: 24 bits</t>
<t>
-This 32 bit field is used to associate the Vorbis data to a decoding Configuration. It is created by making a CRC32 checksum of the <xref target="Packed Configuration">Packed Configuration</xref> required to decode the particular Vorbis audio stream.
+This 24 bit field is used to associate the Vorbis data to a decoding Configuration.
</t>
<t>
@@ -214,14 +208,14 @@
<t>
Vorbis Data Type (VDT): 2 bits</t>
<t>
-This field sets the packet payload type for the Vorbis data. There are currently two type of Vorbis payloads.
+This field sets the packet payload type for the Vorbis data. There are currently three type of Vorbis payloads.
</t>
<vspace blankLines="1" />
<list style="empty">
<t> 0 = Raw Vorbis payload</t>
<t> 1 = Vorbis Packed Configuration payload</t>
-<t> 2 = Reserved</t>
+<t> 2 = Legacy Vorbis Comment payload</t>
<t> 3 = Reserved</t>
</list>
@@ -306,9 +300,9 @@
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident |
+ | Ident | 0 | 0 | 2 pks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 0 | 0 | 2 pks | length | vorbis data ..
+ | length | vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -320,146 +314,18 @@
</figure>
<t>
-The payload data section of the RTP packet starts with the 32 bit Ident field followed by the one octet bitfield header, which has the number of Vorbis frames set to 2. Each of the Vorbis data frames is prefixed by the two
-octet length field.
+The payload data section of the RTP packet starts with the 24 bit Ident field followed by the one octet bitfield header, which has the number of Vorbis frames set to 2. Each of the Vorbis data frames is prefixed by the two octet length field. The Packet Type and Fragment Type are set to 0. The decode Configuration that will be used to decode the packets is the one indexed by the ident value.
</t>
</section>
</section>
-<section anchor="Frame Packetizing" title="Frame Packetizing">
-<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).
-</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>.
-</t>
-
-<t>
-If a Vorbis packet 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 the first will set the Fragment type to 2 in the payload header. The RTP packet 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 packets.
-</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. Each packet contains the standard RTP headers as
-well as the 5 octet Vorbis headers.
-</t>
-
-<figure anchor="Example Fragmented Packet (Packet 1)" title="Example Fragmented Packet (Packet 1)">
-<artwork><![CDATA[
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |V=2|P|X| CC |M| PT | 1000 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | xxxxx |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | synchronization source (SSRC) identifier |
- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
- | contributing source (CSRC) identifiers |
- | ... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 1 | 0 | 0| length | vorbis data ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. vorbis data |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-]]></artwork>
-</figure>
-
-<t>
-In this packet the initial sequence number is 1000 and the timestamp is xxxxx. The Fragment type is set to 1, the number of packets field is set to 0, and as the payload is raw Vorbis data the VDT field is set to 0.
-</t>
-
-<figure anchor="Example Fragmented Packet (Packet 2)" title="Example Fragmented Packet (Packet 2)">
-<artwork><![CDATA[
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |V=2|P|X| CC |M| PT | 1001 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | xxxxx |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | synchronization source (SSRC) identifier |
- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
- | contributing source (CSRC) identifiers |
- | ... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 2 | 0 | 0| length | vorbis data ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. vorbis data |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-]]></artwork>
-</figure>
-
-<t>
-The Fragment type field is set to 2 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>
-
-<figure anchor="Example Fragmented Packet (Packet 3)" title="Example Fragmented Packet (Packet 3)">
-<artwork><![CDATA[
- Packet 3:
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |V=2|P|X| CC |M| PT | 1002 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | xxxxx |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | synchronization source (SSRC) identifier |
- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
- | contributing source (CSRC) identifiers |
- | ... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 3 | 0 | 0| length | vorbis data ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. vorbis data |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-]]></artwork>
-</figure>
-
-<t>
-This is the last Vorbis fragment packet. The Fragment type is set to 3 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 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.
-</t>
-
-<t>
-If a particular multicast session has a large number of participants care must be taken to prevent an RTCP feedback implosion, <xref target="rtcp-feedback"></xref>, in the event of packet loss from a large number of participants.
-</t>
-
-<t>
-Loss of any of the configuration headers, detailed below, is dealt with in the Loss of Configuration Headers Section later.
-</t>
-
-</section>
-</section>
-
<section anchor="Configuration Headers" title="Configuration Headers">
<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, bitrates and other information used to initialise the Vorbis stream.
+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>
@@ -467,32 +333,30 @@
</t>
<t>
-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 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.
+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 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 methodsMAY 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 streams that do not change, 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>
+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.
</t>
<t>
-The 32 bit 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 if the client detects a change in the Ident value and does not have this information it MUST NOT decode the raw Vorbis data.
+The 24 bit 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 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">
<t>
-The <xref target="Packed Configuration">Packed Configuration</xref> Payload is sent in-band with the packet type bits set to match the payload type. Clients MUST be capable of dealing with periodic re-transmission of the configuration headers.
+The <xref target="Packed Configuration">Packed Configuration</xref> Payload is sent in-band with the packet type bits set to match the payload type. Clients MUST be capable of dealing with fragmentation and periodic re-transmission of the configuration headers.
</t>
<section anchor="Packed Configuration" title="Packed Configuration">
<t>
A Vorbis Packed Configuration is indicated with the payload type field set to 1. Of the three headers, defined in the <xref target="vorbis-spec-ref">Vorbis I specification</xref>, the identification and the setup will be packed together, the comment header is completely suppressed. Is up to the client provide a minimal size comment header to the decoder if required by the implementation.
-The 4 byte Ident field is produced by making a CRC32 checksum of the Packed Configuration.
-
</t>
-<figure anchor="Setup Header Figure" title="Setup Header">
+<figure anchor="Packed Configuration Figure" title="Packed Configuration Figure">
<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
@@ -507,17 +371,17 @@
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident |
+ | Ident | 0 | 1 | 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |0|1| 1 | 1| Identification ..
+ | Setup length | Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Identification |
+ .. Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Setup length | Setup ..
+ .. | Setup ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Setup ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -525,46 +389,13 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
+
+<t>The Ident field is set with the value that will be used by the Raw Payload Packets to address this Configuration. The Fragment type is set to 0 since the packet bears the full Packed configuration, the number of packet is set to 1</t>
</section>
-<section anchor="Configuration CRC32 Generation" title="Configuration CRC32 Generation">
-<t>
-In order for different implementations of Vorbis RTP clients and servers to interoperate with each other a common format for the production of the CRC32 hash is required. The polynomial is X^32+X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8+X^7+X^5+X^4+X^2+X^1+X^0. (See also <xref target="ISO 3309">ISO 3309</xref> or <xref target="ITU-T V42">ITU-T V42</xref> for a formal specification.)
-</t>
-
-<t>
-The following C code function gives a straightforward, but inefficient implementation of CRC32. It MAY be used by implementations, if not then the code responsible for generating the CRC32 value MUST use the polynomial function above.
-</t>
-
-<artwork><![CDATA[
-unsigned int crc32 (int length, unsigned char *crcdata)
-{
- int index, loop;
- unsigned int byte, crc, mask;
-
- index = 0;
- crc = 0xFFFFFFFF;
-
- while (index < length) {
- byte = crcdata [index];
- crc = crc ^ byte;
-
- for (loop = 7; loop >= 0; loop--) {
- mask = -(crc & 1);
- crc = (crc >> 1) ^ (0xEDB88320 & mask);
- }
- index++;
- }
- return ~crc;
-}
-]]></artwork>
-
-
</section>
-</section>
-
<section anchor="Packed Headers Delivery" title="Packed Headers Delivery">
<t>
@@ -586,7 +417,7 @@
</figure>
<t>
-Since the Configuration Ident and the Identification Header are fixed lenght there is only a 2 byte Setup Lenght tag to define the lenght of the Setup header.
+Since the Configuration Ident and the Identification Header are fixed length there is only a 2 byte Setup Length tag to define the length of the Setup header.
</t>
<figure anchor="Packed Headers Detail Figure" title="Packed Headers Detail">
@@ -594,18 +425,20 @@
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Identification Header ..
+ | Ident | ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Identification Header | Lenght ..
+ .. Length | Identification Header ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Lenght | Setup Header ..
+ .. Identification Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Setup Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
-The key difference between the in-band format is there is no need for the payload header octet and Configuration Ident field.
+The key difference between the in-band format is there is no need for the payload header octet.
</t>
<section anchor="Packed Headers IANA Considerations" title="Packed Headers IANA Considerations">
@@ -678,7 +511,7 @@
<section anchor="Configuration Caching" title="Configuration Caching">
<t>
-Configuration caching allows clients that have previously connected to a stream to re-use the associated configuration data. When a client receives a Packed Configuration packet 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.
+Configuration caching allows clients that have previously connected to a stream to re-use the associated configuration data. When a client receives a Packed Configuration packet it may store it locally and can compare the Ident key with that of the new stream and begin decoding before it has received any of the headers.
</t>
</section>
@@ -694,8 +527,180 @@
</t>
</section>
+
+<!-- <section anchor="Mapping between Configuration and Stream" title="Mapping between Configuration and Stream">
+
+<t>
+The mapping between the stream and the the configuration is explicit.
+</t>
+
+</section> -->
+
+
</section>
+<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. During a session 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[
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | xxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 0 | 2 | 1|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | Comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>The 2 bytes length field is necessary since this packet could be fragmented.</t>
+
+</section>
+<section anchor="Frame Packetizing" title="Frame Packetizing">
+
+<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).
+</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>.
+</t>
+
+<t>
+If a Vorbis packet 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 the first will set the Fragment type to 2 in the payload header. The RTP packet 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 packets.
+</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. Each packet contains the standard RTP headers as
+well as the 4 octet Vorbis headers.
+</t>
+
+<figure anchor="Example Fragmented Packet (Packet 1)" title="Example Fragmented Packet (Packet 1)">
+<artwork><![CDATA[
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1000 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 1 | 0 | 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+In this packet the initial sequence number is 1000 and the timestamp is xxxxx. The Fragment type is set to 1, the number of packets field is set to 0, and as the payload is raw Vorbis data the VDT field is set to 0.
+</t>
+
+<figure anchor="Example Fragmented Packet (Packet 2)" title="Example Fragmented Packet (Packet 2)">
+<artwork><![CDATA[
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1001 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 2 | 0 | 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+The Fragment type field is set to 2 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>
+
+<figure anchor="Example Fragmented Packet (Packet 3)" title="Example Fragmented Packet (Packet 3)">
+<artwork><![CDATA[
+ Packet 3:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1002 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 3 | 0 | 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+</figure>
+
+<t>
+This is the last Vorbis fragment packet. The Fragment type is set to 3 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 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.
+</t>
+
+<t>
+If a particular multicast session has a large number of participants care must be taken to prevent an RTCP feedback implosion, <xref target="rtcp-feedback"></xref>, in the event of packet loss from a large number of participants.
+</t>
+
+<t>
+Loss of any of the configuration headers, detailed below, is dealt with in the Loss of Configuration Headers Section later.
+</t>
+
+</section>
+</section>
<section anchor="IANA Considerations" title="IANA Considerations">
<t>
@@ -717,7 +722,7 @@
<t>
Optional Parameters: </t><t>
-configuration-uri: the URI of the configuration headers in case of out of band transmission.
+configuration-uri: the URI of the configuration headers in case of out of band transmission. In the form of proto://path/to/resource/Ident
</t>
<t>
@@ -807,7 +812,7 @@
<t>m=audio RTP/AVP 98</t>
<t>a=rtpmap:98 VORBIS/44100/2</t>
<t>a=delivery:out_band/http</t>
-<t>a=fmtp:98 delivery-method:inline,out_band/http; configuration=base16string1; configuration-uri=http://path/to/the/headers</t>
+<t>a=fmtp:98 delivery-method:inline,out_band/http; configuration=base16string1; configuration-uri=http://path/to/the/resource/159</t>
</list>
<t>
@@ -857,7 +862,7 @@
</t>
<t>
-Thanks to the AVT, Ogg Vorbis Communities / Xiph.org including Steve Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, Pascal Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John Lazzaro, Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry Short, Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, David Barrett, Politecnico di Torino (LS)³/IMG Group in particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini, Juan Carlos De Martin.
+Thanks to the AVT, Ogg Vorbis Communities / Xiph.org including Steve Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, Pascal Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John Lazzaro, Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry Short, Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, David Barrett, Politecnico di Torino (LS)³/IMG Group in particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini, Juan Carlos De Martin.
</t>
</section>
@@ -990,21 +995,6 @@
</front>
</reference>
-<reference anchor="ITU-T V42">
-<front>
-<title>
-ITU-T Recommendation V.42, 1994, Rev. 1. Error-correcting Procedures for DCEs Using Asynchronous-to-Synchronous Conversion. International Telecommunications Union. Available from the ITU website, http://www.itu.int
-</title>
-</front>
-</reference>
-
-<reference anchor="ISO 3309">
-<front>
-<title>ISO 3309, October 1984, 3rd Edition. Information Processing Systems--Data Communication High-Level Data Link Control Procedure--Frame Structure. International Organization for Standardization.
-</title>
-</front>
-</reference>
-
</references>
</back>
</rfc>
More information about the commits
mailing list