[xiph-commits] r10835 - trunk/theora/doc
lu_zero at svn.xiph.org
lu_zero at svn.xiph.org
Sun Feb 19 16:12:36 PST 2006
Author: lu_zero
Date: 2006-02-19 16:12:33 -0800 (Sun, 19 Feb 2006)
New Revision: 10835
Modified:
trunk/theora/doc/draft-barbato-avt-rtp-theora-00.xml
Log:
rephrasing and typo hunt
Modified: trunk/theora/doc/draft-barbato-avt-rtp-theora-00.xml
===================================================================
--- trunk/theora/doc/draft-barbato-avt-rtp-theora-00.xml 2006-02-19 22:35:10 UTC (rev 10834)
+++ trunk/theora/doc/draft-barbato-avt-rtp-theora-00.xml 2006-02-20 00:12:33 UTC (rev 10835)
@@ -82,7 +82,7 @@
<section anchor="Payload Format" title="Payload Format">
<t>
-Each frame of digital video is encoded as a single Theora data packet and sent over one of more RTP packets. If the data for a complete frame exceeds the network MTU, it SHOULD be fragmented into multiple RTP packets, each smaller than the MTU. Conversely, a single RTP packet MAY contain data for more than one Theora frame.
+For RTP based transportation of Theora encoded video the standard RTP header is followed by a 4 octet payload header, then the payload data. The payload headers are used to associate the Theora data with its associated decoding codebooks as well as indicating if the following packet contains fragmented Theora data and/or the number of whole Theora data frames. The payload data contains the raw Theora bitstream information.
</t>
<t>
@@ -290,7 +290,7 @@
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Configuration Ident | 0 | 0 | 2 pks |
+ | Configuration Ident | 0 | 0 | 2 pks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -330,7 +330,7 @@
</t>
<t>
-The 24 bit Ident field is used to map which Configuration will be used to decodea packet. When the Ident field changes, it indicates that 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 data associated until it fetches the correct Configuration.
+The 24 bit Ident field is used to map which Configuration will be used to decode a packet. When the Ident field changes, it indicates that 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 data associated until it fetches the correct Configuration.
</t>
@@ -343,7 +343,7 @@
<section anchor="Packed Configuration" title="Packed Configuration">
<t>
-A Theora Packed Configuration is indicated with the payload type field set to 1. Of the three headers, defined in the <xref target="theora-spec-ref">Theora 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.
+A Theora Packed Configuration is indicated with the payload type field set to 1. Of the three headers, defined in the <xref target="theora-spec-ref">Theora I specification</xref>, the identification and the setup will be packed together, the comment header is completely suppressed. It 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">
@@ -379,7 +379,7 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></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. In practice, Packed Headers usually need to be fragmented to stay below the path MTU.
+<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. In practice, Packed Headers usually need to be fragmented to fit the path MTU.
</t>
@@ -391,13 +391,13 @@
<section anchor="Out of Band Transmission" title="Out of Band Transmission">
<t>
-This section, as stated above, does not cover all the possible out-of-band delivery methods since they rely to different protocols and be linked to specific applications. The following packet definition SHOULD be used in out-of-band delivery and MUST be used when Configuration is inlined in the SDP.
+This section, as stated above, does not cover all the possible out-of-band delivery methods since they rely on different protocols and be linked to specific applications. The following packet definition SHOULD be used in out-of-band delivery and MUST be used when Configuration is inlined in the SDP.
</t>
<section anchor="Packed Headers" title="Packed Headers">
<t>
-As mentioned above the recommended delivery vector for Theora 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 setup id.
+As mentioned above, the recommended delivery vector for Theora 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 setup id.
</t>
<figure anchor="Packed Headers Overview Figure" title="Packed Headers Overview">
@@ -415,7 +415,7 @@
</figure>
<t>
-Since the Configuration Ident and the Identification Header are fixed length there is only a 2 byte Length tag to define the length of the packed headers.
+Since the Configuration Ident and the Identification Header are fixed length there is only a 16bit Length tag to define the length of the packed headers.
</t>
<figure anchor="Packed Headers Detail Figure" title="Packed Headers Detail">
@@ -435,7 +435,7 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
-<t>The key difference between the in-band format is there is no need for the payload header octet.
+<t>The key difference from the in-band format is that there is no need for the payload header octet.
</t>
<section anchor="Packed Headers IANA Considerations" title="Packed Headers IANA Considerations">
@@ -529,7 +529,7 @@
<t hangText="Restriction on usage:">
<vspace blankLines="1" />
-This media type doesn't depend on the transport.
+This media type does not depend on the transport.
</t>
<vspace blankLines="1" />
@@ -573,11 +573,11 @@
<section anchor="Loss of Configuration Headers" title="Loss of Configuration Headers">
<t>
-Unlike the loss of raw Theora payload data, loss of a configuration header can lead to a situation where it will not be possible to successfully decode the stream.
+Unlike the loss of raw Theora payload data, the loss of a configuration header can lead to a situation where it will not be possible to successfully decode the stream.
</t>
<t>
-Loss of Configuration Packet results in the halting of stream decoding and SHOULD be reported to the client as well as a loss report sent via RTCP.
+A loss of a Configuration Packet results in the halting of stream decoding and SHOULD be reported to the client as well as a loss report sent via RTCP.
</t>
</section>
@@ -588,7 +588,7 @@
<section anchor="Comment Headers" title="Comment Headers">
<t>
-When the payload type is set to 2, the packet contains the so-called "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 title information. Clients MAY ignore it completely. The details on the format of the comments can be found in the <xref target="theora-spec-ref">Theora documentation</xref>.
+When the payload type is set to 2, the packet contains 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 title information. Clients MAY ignore them completely. The details on the format of the comments can be found in the <xref target="theora-spec-ref">Theora documentation</xref>.
</t>
<figure anchor="Comment Packet Figure" title="Comment Packet">
<artwork><![CDATA[
@@ -631,7 +631,7 @@
</t>
<t>
-If a Theora 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 RTP packet containing the first fragment will set the Fragment type to 1. Each RTP packet after the first will set the Fragment type to 2 in the payload header. The RTP packet containing the last fragment of the Theora packet will have the Fragment type set to 3. If the fragmented Theora packet spans only two RTP packets, the first will set the Fragement type field to 1 and the second will set it to 2. 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>
+A fragmented packet has a zero in the last four bits of the payload header. The RTP packet containing the first fragment will set the Fragment type to 1. Each RTP packet after the first will set the Fragment type to 2 in the payload header. The RTP packet containing the last fragment of the Theora packet will have the Fragment type set to 3. If the fragmented Theora packet spans only two RTP packets, the first will set the Fragment type field to 1 and the second will set it to 2. 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 Theora Packet" title="Example Fragmented Theora Packet">
@@ -734,12 +734,11 @@
<section anchor="Packet Loss" title="Packet Loss">
<t>
-As there is no error correction within the Theora stream, packet loss will result in a loss of signal. Packet loss is more of an issue for fragmented Theora packets as the client will have to cope with the handling of the Fragment type field. If we use the fragmented Theora 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 is set to 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.
+As there is no error correction within the Theora stream, packet loss will result in a loss of signal. Packet loss is more of an issue for fragmented Theora packets as the client will have to cope with the handling of the Fragment type field. If we use the fragmented Theora 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 is set to 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.[note: reordering]
</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.
+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>
@@ -932,7 +931,6 @@
<section anchor="Usage with the SDP Offer/Answer Mode" title="Usage with the SDP Offer/Answer Model">
-
<t>
The offer, as described in <xref target="rfc3264">An Offer/Answer Model Session Description Protocol</xref>, may contain a large number of delivery methods per single fmtp attribute, the answerer MUST remove every delivery-method and configuration-uri not supported. All the parameters MUST not be altered on answer otherwise.
</t>
@@ -962,7 +960,7 @@
-->
<section anchor="Stream Video" title="Stream Video">
-<t>That is one of the most common situation: one single server streaming content in multicast, the clients may start a session at random time. The content itself could be a mix of live stream, as the wj's voice or studio scenes, and stored streams, as the music she plays.</t>
+<t>This is one of the most common situation: one single server streaming content in multicast, the clients may start a session at random time. The content itself could be a mix of live stream, as the wj's voice or studio scenes, and stored streams, as the music she plays.</t>
<t>In this situation we don't know in advance how many codebooks we will use. The clients can join anytime and users expect to start the fruition of the content in a short time.</t>
@@ -970,7 +968,7 @@
<t>When the streamed content changes the new Configuration is sent in-band before the actual stream, and the Configuration that has to be sent inline in the SDP updated. Since the inline method is unreliable, an out of band fallback is provided.</t>
-<t>The client could choose to fetch the Configuration from the alternate source as soon it discovers a Configuration packet got lost inline or use <xref target="rfc3611">selective retransmission</xref>, if the server supports that feature.</t>
+<t>The client could choose to fetch the Configuration from the alternate source as soon it discovers a Configuration packet got lost inline or use <xref target="rfc3611">selective retransmission</xref>, if the server supports the feature.</t>
<t>A serverside optimization would be to keep an hash list of the Configurations per session to avoid packing all of them and send the same Configuration with different Ident tags</t>
@@ -982,10 +980,7 @@
<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="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.
+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>
@@ -995,7 +990,7 @@
<t>This document is a continuation of draft-kerr-avt-theora-rtp-00.txt</t>
<t>
-Thanks to the AVT, Ogg Theora Communities / Xiph.org, Fluendo, Ralph Giles, Mike Smith, Phil Kerr, Timothy Terriberry, Stefan Ehmann, Politecnico di Torino (LS)³/IMG Group in particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini, Juan Carlos De Martin.
+Thanks to the AVT, Ogg Theora Communities / Xiph.org, Fluendo, Ralph Giles, Mike Smith, Phil Kerr, Timothy Terriberry, Stefan Ehmann, Alessandro Salvatori, Politecnico di Torino (LS)³/IMG Group in particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini, Juan Carlos De Martin.
</t>
</section>
More information about the commits
mailing list