Commit 3def62c3 authored by lu_zero's avatar lu_zero

address comment 73637 from Magnus Westerlund

svn path=/trunk/vorbis/; revision=14104
parent 91c8c88c
......@@ -145,8 +145,8 @@ Internet-Draft draft-ietf-avt-rtp-vorbis-08 Oct 2007
its associated decoding codebooks as well as indicating if the
following packet contains fragmented Vorbis data and/or the number of
whole Vorbis data frames. The payload data contains the raw Vorbis
bitstream information. There are 3 types of Vorbis payload data, an
RTP packet MUST contain just one of them at a time.
bitstream information. There are 3 types of Vorbis data, an RTP
payload MUST contain just one of them at a time.
2.1. RTP Header
......@@ -234,7 +234,7 @@ Internet-Draft draft-ietf-avt-rtp-vorbis-08 Oct 2007
Timestamp: 32 bits
A timestamp representing the sampling time of the first sample of the
first Vorbis packet in the RTP packet. The clock frequency MUST be
first Vorbis packet in the RTP payload. The clock frequency MUST be
set to the sample rate of the encoded audio data and is conveyed out-
of-band (e.g. as an SDP parameter).
......@@ -284,8 +284,8 @@ Internet-Draft draft-ietf-avt-rtp-vorbis-08 Oct 2007
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 (e.g. you must not aggregate configuration and comment
payload in the same packet)
packet (e.g. you must not aggregate configuration and comment packets
in the same RTP payload)
0 = Raw Vorbis payload
1 = Vorbis Packed Configuration payload
......@@ -296,7 +296,7 @@ Internet-Draft draft-ietf-avt-rtp-vorbis-08 Oct 2007
The last 4 bits represent 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
the payload. If the payload contains fragmented data the number of
packets MUST be set to 0.
2.3. Payload Data
......@@ -350,7 +350,7 @@ Internet-Draft draft-ietf-avt-rtp-vorbis-08 Oct 2007
2.4. Example RTP Packet
Here is an example RTP packet containing two Vorbis packets.
Here is an example RTP payload containing two Vorbis packets.
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
......@@ -703,12 +703,12 @@ Internet-Draft draft-ietf-avt-rtp-vorbis-08 Oct 2007
5. Frame Packetization
Each RTP packet contains either one Vorbis packet fragment, or an
Each RTP payload contains either one Vorbis packet fragment, or an
integer number of complete Vorbis packets (up to a maximum of 15
packets, since the number of packets is defined by a 4 bit value).
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
in the RTP payload with as many Vorbis packets as will fit, up to a
maximum of 15, except when such bundling would exceed an
application's desired transmission latency. Path MTU is detailed in
[6] and [7].
......@@ -716,7 +716,7 @@ Internet-Draft draft-ietf-avt-rtp-vorbis-08 Oct 2007
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
payload header. The RTP payload 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
......@@ -729,12 +729,12 @@ Barbato Expires April 30, 2008 [Page 13]
Internet-Draft draft-ietf-avt-rtp-vorbis-08 Oct 2007
packets. The length field shows the fragment length.
payloads. The length field shows the fragment length.
5.1. Example Fragmented Vorbis Packet
Here is an example fragmented Vorbis packet split over three RTP
packets. Each packet contains the standard RTP headers as well as
payloads. Each of them contains the standard RTP headers as well as
the 4 octets Vorbis headers.
Packet 1:
......@@ -761,7 +761,7 @@ Internet-Draft draft-ietf-avt-rtp-vorbis-08 Oct 2007
Figure 9: Example Fragmented Packet (Packet 1)
In this packet the initial sequence number is 1000 and the timestamp
In this payload 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.
......@@ -811,10 +811,10 @@ Internet-Draft draft-ietf-avt-rtp-vorbis-08 Oct 2007
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 this
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.
type of payloads. 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 payload.
......@@ -865,10 +865,10 @@ Internet-Draft draft-ietf-avt-rtp-vorbis-08 Oct 2007
Figure 11: Example Fragmented Packet (Packet 3)
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.
This is the last Vorbis fragment payload. The Fragment type is set
to 3 and the packet count remains set to 0. As in the previous
payloads the timestamp remains set to the first payload timestamp in
the sequence and the sequence number has been incremented.
5.2. Packet Loss
......@@ -878,11 +878,11 @@ Internet-Draft draft-ietf-avt-rtp-vorbis-08 Oct 2007
handling of the Fragment Type. In case of loss of fragments the
client MUST discard all the remaining Vorbis fragments and decode the
incomplete packet. If we use the fragmented Vorbis packet example
above and the first RTP packet is lost the client MUST detect that
the next RTP packet has the packet count field set to 0 and the
Fragment type 2 and MUST drop it. The next RTP packet, which is the
above and the first RTP payload is lost the client MUST detect that
the next RTP payload has the packet count field set to 0 and the
Fragment type 2 and MUST drop it. The next RTP payload, which is the
final fragmented packet, MUST be dropped in the same manner. If the
missing RTP packet is the last, the received two fragments will be
missing RTP payload is the last, the received two fragments will be
kept and the incomplete Vorbis packet decoded.
Loss of any of the Configuration fragment will result in the loss of
......@@ -1233,7 +1233,7 @@ Barbato Expires April 30, 2008 [Page 22]
Internet-Draft draft-ietf-avt-rtp-vorbis-08 Oct 2007
that the confidentiality of the media stream is achieved by using
that the confidentiality of the media stream is archieved 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. Additional care MAY be needed for delivery methods
......
......@@ -93,7 +93,7 @@ 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 number of whole Vorbis data frames. The payload data
contains the raw Vorbis bitstream information. There are 3 types of Vorbis
payload data, an RTP packet MUST contain just one of them at a time.
data, an RTP payload MUST contain just one of them at a time.
</t>
<section anchor="RTP Header" title="RTP Header">
......@@ -183,7 +183,7 @@ field is detailed further in <xref target="rfc3550"></xref>.
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
Vorbis packet in the RTP payload. The clock frequency MUST be set to the sample
rate of the encoded audio data and is conveyed out-of-band (e.g. as an SDP parameter).
</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 (e.g. you must not aggregate configuration and comment payload in the same packet)
are currently three different types of Vorbis payloads. Each packet MUST contain only a single type of Vorbis packet (e.g. you must not aggregate configuration and comment packets in the same RTP payload)
</t>
<vspace blankLines="1" />
......@@ -255,7 +255,7 @@ are currently three different types of Vorbis payloads. Each packet MUST contain
<t>
The last 4 bits represent 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.
payload contains fragmented data the number of packets MUST be set to 0.
</t>
</section>
......@@ -318,7 +318,7 @@ Channel mapping of the audio is in accordance with the
<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 payload containing two Vorbis packets.
</t>
<figure anchor="Example Raw Vorbis Packet" title="Example Raw Vorbis Packet">
......@@ -625,14 +625,14 @@ The 2 bytes length field is necessary since this packet could be fragmented.
<section anchor="Frame Packetization" title="Frame Packetization">
<t>
Each RTP packet contains either one Vorbis packet fragment, or an integer
Each RTP payload contains either one Vorbis packet fragment, or an integer
number of complete Vorbis packets (up to a maximum of 15 packets, since the
number of packets is defined by a 4 bit value).
</t>
<t>
Any Vorbis data packet that is less than path MTU SHOULD be bundled in the RTP
packet with as many Vorbis packets as will fit, up to a maximum of 15, except
payload with as many Vorbis packets as will fit, up to a maximum of 15, except
when such bundling would exceed an application's desired transmission latency.
Path MTU is detailed in <xref target="rfc1191"></xref> and <xref target="rfc1981"></xref>.
</t>
......@@ -640,19 +640,19 @@ Path MTU is detailed in <xref target="rfc1191"></xref> and <xref target="rfc1981
<t>
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
first will set the Fragment type to 2 in the payload header. The RTP payload
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. The length field shows the fragment length.
payloads. The length field shows the fragment length.
</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 octets Vorbis
Here is an example fragmented Vorbis packet split over three RTP payloads.
Each of them contains the standard RTP headers as well as the 4 octets Vorbis
headers.
</t>
......@@ -683,7 +683,7 @@ headers.
</figure>
<t>
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
In this payload 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>
......@@ -715,10 +715,10 @@ the payload is raw Vorbis data the VDT field is set to 0.
<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 this type of payload
packets. The maximum packet size SHOULD be no greater than the path MTU,
For large Vorbis fragments there can be several of this type of payloads.
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.
by one but the timestamp field remains the same as the initial payload.
</t>
<figure anchor="Example Fragmented Packet (Packet 3)" title="Example Fragmented Packet (Packet 3)">
......@@ -748,10 +748,10 @@ by one but the timestamp field remains the same as the initial packet.
</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.
This is the last Vorbis fragment payload. The Fragment type is set to 3 and the
packet count remains set to 0. As in the previous payloads the timestamp remains
set to the first payload timestamp in the sequence and the sequence number has
been incremented.
</t>
</section>
......@@ -763,12 +763,12 @@ 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 the
remaining Vorbis fragments and decode the incomplete packet. If we use the
fragmented Vorbis packet example above and the first RTP packet is lost the
client MUST detect that the next RTP packet has the packet count field set
fragmented Vorbis packet example above and the first RTP payload is lost the
client MUST detect that the next RTP payload has the packet count field set
to 0 and the Fragment type 2 and MUST drop it.
The next RTP packet, which is the final fragmented packet, MUST be dropped in
The next RTP payload, which is the final fragmented packet, MUST be dropped in
the same manner.
If the missing RTP packet is the last, the received two fragments will be kept
If the missing RTP payload is the last, the received two fragments will be kept
and the incomplete Vorbis packet decoded.
</t>
......@@ -1178,7 +1178,7 @@ per session and don't process configuration packets already known.</t>
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
media stream is archieved 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. Additional care MAY be needed for delivery methods that
point to external resources, using secure protocols to fetch the configuration
......
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