[xiph-commits] r12906 - trunk/vorbis/doc
lu_zero at svn.xiph.org
lu_zero at svn.xiph.org
Wed May 2 13:16:33 PDT 2007
Author: lu_zero
Date: 2007-05-02 13:16:32 -0700 (Wed, 02 May 2007)
New Revision: 12906
Modified:
trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-03.xml
Log:
Colin Perkins' latest comments
Modified: trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-03.xml
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-03.xml 2007-05-01 05:06:04 UTC (rev 12905)
+++ trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-03.xml 2007-05-02 20:16:32 UTC (rev 12906)
@@ -6,7 +6,7 @@
<rfc ipr="full3978" docName="RTP Payload Format for Vorbis Encoded Audio">
<front>
-<title>draft-ietf-avt-rtp-vorbis-03</title>
+<title>draft-ietf-avt-rtp-vorbis-04</title>
<author initials="L" surname="Barbato" fullname="Luca Barbato">
<organization>Xiph.Org</organization>
@@ -184,7 +184,7 @@
<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 parameter.
+rate of the encoded audio data and is conveyed out-of-band (e.g. as a SDP parameter).
</t>
<t>
@@ -239,7 +239,7 @@
Vorbis Data Type (VDT): 2 bits</t>
<t>
This field specifies the kind of Vorbis data stored in this RTP packet. There
-are currently three different types of Vorbis payloads. Each packet MUST contain only a single type of Vorbis payload.
+are currently three different types of Vorbis payloads. Each packet MUST contain only a single type of Vorbis payload (e.g. you MUST not aggregate configuration and comment payload in the same packet)
</t>
<vspace blankLines="1" />
@@ -286,7 +286,7 @@
<t>
Each Vorbis payload packet starts with a two octet length header, which is used
to represent the size in bytes of the following data payload, followed by the
-raw Vorbis data padded to the nearest byte boundary. The length value is stored
+raw Vorbis data padded to the nearest byte boundary, as explained by the <xref target="vorbis-spec-ref">vorbis specification</xref>. The length value is stored
as network byte order integer.
</t>
@@ -325,7 +325,7 @@
RTP Packet Header:
</t>
-<figure anchor="Example Header Packet (RTP Headers)" title="Example Packet (RTP Headers)">
+<figure anchor="Example Raw Vorbis Packet" title="Example Raw Vorbis 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
@@ -339,28 +339,19 @@
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-]]></artwork>
-</figure>
-
-<t>
-Payload Data:
-</t>
-
-<figure anchor="Example Packet (Payload Data)" title="Example Packet (Payload Data)">
-<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 0 | 0 | 2 pks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | length | vorbis data ..
+ | length | vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | next vorbis packet data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. vorbis data |
+ .. vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
@@ -382,9 +373,9 @@
<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 data block that must be
-transmitted to the decoder along with the compressed data. A decoder
-also requires information detailing the number of audio
+configuration, Vector Quantization and Huffman models into a data block
+that must be transmitted to the decoder along with the compressed data.
+A decoder 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,
@@ -407,20 +398,20 @@
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.
+delivery is typically 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
+The delivery vectors in use can be 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.
+method is inline the <xref target="Packed Configuration">Packed Configuration</xref> in the SDP as explained in the <xref target="Mapping Media Type Parameters into SDP"> IANA considerations</xref>.
</t>
<t>
@@ -447,9 +438,9 @@
A Vorbis Packed Configuration is indicated with the Vorbis Data 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 to provide a minimal size comment
-header to the decoder if required by the implementation.
+identification and the setup MUST be packed together, while the comment header
+MUST be completely suppressed. Is up to the client to provide a minimal size
+comment header to the decoder if required by the implementation.
</t>
<figure anchor="Packed Configuration Figure" title="Packed Configuration Figure">
@@ -509,9 +500,9 @@
data is via a retrieval method that can be performed using a reliable transport
protocol. As the RTP headers are not required for this method of delivery the
structure of the configuration data is slightly different. The packed header
-starts with a 32 bit count field which details the number of packed headers
-that are contained in the bundle. Next is the Packed header payload for each
-chained Vorbis stream.
+starts with a 32 bit (network ordered) count field which details the number of
+packed headers that are contained in the bundle. Next is the Packed header
+payload for each chained Vorbis stream.
</t>
<figure anchor="Packed Headers Overview Figure" title="Packed Headers Overview">
@@ -657,7 +648,7 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | 1000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | xxxxx |
+ | 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
@@ -675,7 +666,7 @@
</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
+In this packet the initial sequence number is 1000 and the timestamp is 12345. 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>
@@ -688,7 +679,7 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | 1001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | xxxxx |
+ | 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
@@ -722,7 +713,7 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | 1002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | xxxxx |
+ | 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
@@ -793,12 +784,12 @@
<vspace blankLines="1" />
-<t hangText="delivery-method:"> indicates the delivery methods in use, the possible values are: inline, in_band, out_band
+<t hangText="delivery-method:"> indicates the delivery methods in use, the possible values are: inline, in_band, out_band, MAY be included multiple times
</t>
<vspace blankLines="1" />
-<t hangText="configuration:"> the <xref target="rfc3548">base64</xref> representation of the <xref target="Packed Headers">Packed Headers</xref>.
+<t hangText="configuration:"> the <xref target="rfc3548">base64</xref> representation of the <xref target="Packed Headers">Packed Headers</xref>. It MUST follow the associated delivery-method parameter ("inline").
</t>
</list>
</t>
@@ -820,7 +811,9 @@
In this latter case the URI will end with the aggregate name, followed by its
compressed extension if applies, a "!" and the <xref target="rfc3548">base64</xref> representation of the sha1hash of the above mentioned compressed aggregated
as in: "protocol://path/to/resource/aggregated.bz2!sha1hash".
-The trailing '/' discriminates which of two methods are in use.</t>
+The trailing '/' discriminates which of two methods are in use.
+It MUST follow the associated delivery method parameter (either "in_band" or "out_band").
+</t>
</list>
</t>
@@ -1015,21 +1008,22 @@
The following paragraphs defines the mapping of the parameters described in the IANA considerations section and their usage in the <xref target="rfc3264">Offer/Answer Model</xref>.
</t>
-<section anchor="Mapping MIME Parameters into SDP" title="Mapping MIME Parameters into SDP">
+<section anchor="Mapping Media Type Parameters into SDP" title="Mapping MIME Parameters into SDP">
<t>
-The information carried in the MIME media type specification has a specific
-mapping to fields in the <xref target="rfc4566">Session Description Protocol (SDP)</xref>, which is commonly used to describe RTP sessions. When SDP is used
-to specify sessions the mapping are as follows:
+The information carried in the Media Type media type specification has a
+specific mapping to fields in the <xref target="rfc4566">Session Description
+Protocol (SDP)</xref>, which is commonly used to describe RTP sessions.
+When SDP is used to specify sessions the mapping are as follows:
</t>
<vspace blankLines="1" />
<list style="symbols">
-<t>The MIME type ("audio") goes in SDP "m=" as the media name.</t>
+<t>The type name ("audio") goes in SDP "m=" as the media name.</t>
<vspace blankLines="1" />
-<t>The MIME subtype ("vorbis") goes in SDP "a=rtpmap" as the encoding name.</t>
+<t>The subtype name ("vorbis") goes in SDP "a=rtpmap" as the encoding name.</t>
<vspace blankLines="1" />
<t>The parameter "rate" also goes in "a=rtpmap" as clock rate.</t>
@@ -1039,11 +1033,11 @@
<vspace blankLines="1" />
<t>The mandated parameters "delivery-method" and "configuration" MUST be
-included in the SDP "a=fmpt" attribute.</t>
+included in the SDP "a=fmtp" attribute.</t>
<vspace blankLines="1" />
<t>The optional parameter "configuration-uri", when present, MUST be included
-in the SDP "a=fmpt" attribute and MUST follow the delivery-method that applies.</t>
+in the SDP "a=fmtp" attribute and MUST follow the delivery-method that applies.</t>
</list>
@@ -1061,7 +1055,7 @@
<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
+specified in the c= line. The bitrate value and channels specified in the
rtpmap attribute MUST match the Vorbis sample rate value. An example is found
below.
</t>
@@ -1072,7 +1066,7 @@
fetched at any time from the first provided uri using or all the known
configuration could be downloaded using the second uri. The inline
<xref target="rfc3548">base64</xref> configuration string is omitted because of
-the lenght.</t>
+the length.</t>
<list style="empty">
<t>c=IN IP4 192.0.2.1</t>
@@ -1172,8 +1166,10 @@
<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.
+the compressed data. Additional care MAY be needed for delivery methods that
+point to external resources, using secure protocols to fetch the configuration
+payloads. Where the size of a data block is set, care MUST be taken to prevent
+buffer overflows in the client applications.
</t>
</section>
More information about the commits
mailing list