Commit 2c11be88 authored by lu_zero's avatar lu_zero

Colin Perkins' latest comments

svn path=/trunk/vorbis/; revision=12906
parent d890ee9a
......@@ -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 @@ 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 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 @@ This field is set according to the following list
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 @@ complete RTP packet is smaller than the path MTU.
<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 @@ Here is an example RTP packet containing two Vorbis packets.
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 @@ RTP Packet Header:
| 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 @@ that will be used to decode the packets is the one indexed by the ident value.
<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 @@ 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 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 @@ re-transmission of the configuration headers.
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 @@ As mentioned above the RECOMMENDED delivery vector for Vorbis configuration
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 @@ headers.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | 1000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| xxxxx |
| 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
......@@ -675,7 +666,7 @@ headers.
</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 @@ the payload is raw Vorbis data the VDT field is set to 0.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | 1001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| xxxxx |
| 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
......@@ -722,7 +713,7 @@ by one but the timestamp field remains the same as the initial packet.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | 1002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| xxxxx |
| 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
......@@ -793,12 +784,12 @@ Configuration packet with the result detailed in the <xref target="Loss of Confi
<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 @@ A <xref target="FIPS180">sha1</xref> checksum MAY be provided for aggregates.
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 @@ IETF AVT Working Group delegated from the IESG</t>
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 @@ to specify sessions the mapping are as follows:
<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 @@ reside.
<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 @@ configuration packet is inlined in the sdp, other configurations could be
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 @@ 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.
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>
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment