[xiph-commits] r10627 - trunk/theora/doc
giles at svn.xiph.org
giles at svn.xiph.org
Sat Dec 17 13:14:10 PST 2005
Author: giles
Date: 2005-12-17 13:14:08 -0800 (Sat, 17 Dec 2005)
New Revision: 10627
Modified:
trunk/theora/doc/draft-barbato-avt-rtp-theora-00.txt
trunk/theora/doc/draft-barbato-avt-rtp-theora-00.xml
Log:
Clarify some sections and correct typos.
Modified: trunk/theora/doc/draft-barbato-avt-rtp-theora-00.txt
===================================================================
--- trunk/theora/doc/draft-barbato-avt-rtp-theora-00.txt 2005-12-17 20:18:41 UTC (rev 10626)
+++ trunk/theora/doc/draft-barbato-avt-rtp-theora-00.txt 2005-12-17 21:14:08 UTC (rev 10627)
@@ -1,7 +1,6 @@
-
AVT Working Group L. Barbato
Internet-Draft Xiph.Org
Expires: April 18, 2006 October 15, 2005
@@ -43,13 +42,13 @@
This document describes a RTP payload format for transporting Theora
encoded video. It details the RTP encapsulation mechanism for raw
- Theora data and configuration headers consisting of the quantization
- matrices and the Huffman codebooks for the DCT coefficients, and a
- table of limit values for the deblocking filter.
+ Theora data and configuration headers necessary to configure the
+ decoder.
Also included within the document are the necessary details for the
use of Theora with MIME and Session Description Protocol (SDP).
+Editors Note
@@ -58,8 +57,6 @@
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
-Editors Note
-
All references to RFC XXXX are to be replaced by references to the
RFC number of this memo, when published.
@@ -77,22 +74,22 @@
3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9
3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 9
3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 10
- 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 10
- 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 12
+ 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 11
+ 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 13
4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 13
- 5. Frame Packetizing . . . . . . . . . . . . . . . . . . . . . . 13
- 5.1. Example Fragmented Theora Packet . . . . . . . . . . . . . 14
- 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 16
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
- 6.1. Mapping MIME Parameters into SDP . . . . . . . . . . . . . 18
- 6.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 19
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
- 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
- Intellectual Property and Copyright Statements . . . . . . . . . . 23
+ 5. Frame Packetizing . . . . . . . . . . . . . . . . . . . . . . 14
+ 5.1. Example Fragmented Theora Packet . . . . . . . . . . . . . 15
+ 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
+ 6.1. Mapping MIME Parameters into SDP . . . . . . . . . . . . . 19
+ 6.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 20
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 22
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ Intellectual Property and Copyright Statements . . . . . . . . . . 24
@@ -109,6 +106,8 @@
+
+
Barbato Expires April 18, 2006 [Page 2]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
@@ -117,8 +116,8 @@
1. Introduction
Theora is a general purpose, lossy video codec. It is based on the
- VP3.1 video codec produced by On2 Technologies and has been donated
- to the Xiph.org Foundation.
+ VP3 video codec produced by On2 Technologies and has been donated to
+ the Xiph.org Foundation.
Theora I is a block-based lossy transform codec that utilizes an 8 x
8 Type-II Discrete Cosine Transform and block-based motion
@@ -129,16 +128,17 @@
frames (I frames in MPEG) and inter frames (P frames in MPEG).
Theora provides none of its own framing, synchronization, or
- protection against transmission errors. Theora is a free-form
- variable bit rate (VBR) codec, and packets have no minimum size,
- maximum size, or fixed/expected size. Theora packets are thus
+ protection against transmission errors. Instead, the codec expects
+ to receive a discrete sequence of data packets. Theora is a free-
+ form variable bit rate (VBR) codec, and these packets have no minimum
+ size, maximum size, or fixed/expected size. Theora packets are thus
intended to be used with a transport mechanism that provides free-
form framing, synchronization, positioning, and error correction in
- accordance with these design assumptions, such as Ogg [1]. or RTP/AVP
+ accordance with these design assumptions, such as Ogg [1] or RTP/AVP
[3].
Theora I currently supports progressive video data of arbitrary
- dimensions at a constant frame rate in one of several YCbCr color
+ dimensions at a constant frame rate in one of several Y'CbCr color
spaces. Three different chroma subsampling formats are supported:
4:2:0, 4:2:2, and 4:4:4. The Theora I format does not support
interlaced material, variable frame rates, bit-depths larger than 8
@@ -147,14 +147,14 @@
efficiently encoded, however, because the uniform chroma planes
compress well.
- Theora is similar to Vorbis audio [10] in that it requires the
- inclusion of the entire probability model for the DCT coefficients
- and all the quantization parameters in the bitstream headers to be
- sent ahead of the video data. It is therefore impossible to decode
- any frame in the stream without having previously fetched the codec
- info and codec setup headers, although Theora can initiate decode at
- an arbitrary intra-frame packet within a bitstream so long as the
- codec has been initialized with the setup headers.
+ Theora is similar to the Vorbis audio [10] in that it the decoder
+ reads the probability model for the entropy coder and all
+ quantization parameters from special "header" packets at the start of
+ the compressed data. It is therefore impossible to decode any video
+ data without having previously fetched the codec info and codec setup
+ headers, although Theora can initiate decode at an arbitrary intra-
+ frame packet so long as the codec has been initialized with the
+ associated headers.
1.1. Terminology
@@ -164,7 +164,6 @@
-
Barbato Expires April 18, 2006 [Page 3]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
@@ -172,13 +171,13 @@
2. Payload Format
- Each frame of digital video is packetized into one or 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. A single RTP packet MAY contain data for more than one
- Theora frame.
+ 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
+ For RTP based transport of Theora encoded video the standard RTP
header is followed by a 4 octet payload header, then the payload
data.
@@ -298,10 +297,12 @@
2 = Continuation Fragment
3 = End Fragment
+ This field must be zero if the number of packets field is non-zero.
+
Theora Data Type (TDT): 2 bits
This field sets the packet payload type for the Theora data. There
- are currently two type of Vorbis payloads.
+ are currently three Theora payload types.
0 = Raw Theora payload
1 = Theora Packed Configuration payload
@@ -317,7 +318,7 @@
Each Theora payload section starts with a two octet length header
that is used to represent the size of the following data payload,
- followed by the raw Theora data.
+ followed by the raw Theora packet data.
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
@@ -328,8 +329,6 @@
Figure 3: Payload Data
The Theora codec uses relatively unstructured raw packets containing
- binary integer fields of arbitrary width that often do not fall on an
- octet boundary. When this happens the bitstream is packed to an
@@ -338,14 +337,17 @@
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
+ binary integer fields of arbitrary width that often do not fall on an
octet boundary. When a Theora encoder produces packets, unused space
in the last byte of a packet is always zeroed during the encoding
process. Thus, should this unused space be read, it will return
binary zeros.
For payloads which consist of multiple Theora packets the payload
- data consists of the payload length field followed by the payload
- data for each of the Theora packets in the payload.
+ data consists of the payload length field followed by the first
+ Theora packet's data, then the payload length followed by the second
+ Theora packet, and so on for each of the Theora packets in the
+ payload.
2.4. Example RTP Packet
@@ -370,6 +372,27 @@
Payload Data:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires April 18, 2006 [Page 7]
+
+Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
+
+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -386,39 +409,31 @@
Figure 5: Example Theora Payload Packet
-
-
-
-Barbato Expires April 18, 2006 [Page 7]
-
-Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
-
-
The payload portion of the packet starts with the 24 bit
- Configuration ident field followed by the 8 bit bitfield. The
- Fragment type field is set to 0, indicating that this packet contains
- whole Theora frame data. The Data type field is set to 0 since it is
- theora raw data. The number of whole Theora data packets is set to
- 2.
+ Configuration ident field followed by 8 bits describing the payload.
+ The Fragment type field is set to 0, indicating that this packet
+ contains whole Theora frame data. The Data type field is set to 0
+ since it is theora raw data. The number of whole Theora data packets
+ is set to 2.
- Each of the payload blocks starts with the two octet length field and
- then follows by the variable length Theora data.
+ Each of the payload blocks starts with the two octet length field
+ followed by the variable length Theora packet data.
3. Configuration Headers
- To decode a Theora stream three configuration header blocks are
- needed. The first header, the Identification Header, indicates the
+ To decode a Theora stream three configuration header packets are
+ needed. The first, called the Identification Header, indicates the
frame dimensions, quality, blocks used and the version of the Theora
- encoder used. The second header, the Comment Header, contains stream
- metadata and the third header, the Setup Header, details which
- contains dequantization and Huffman tables.
+ encoder used. The second, called the Comment Header, contains stream
+ metadata and the third, called the Setup Header, contains details of
+ the dequantization and Huffman tables.
Since this information must be transmitted reliably, and as the RTP
- stream may change certain configuration data mid-session there are
+ 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
+ both in-band and out-of-band which are detailed below. SDP delivery
+ is used to set up an initial state for the client application. The
changes may be due to different dequantization and Huffman tables as
well as different bitrates of the stream.
@@ -426,6 +441,14 @@
indicate the method and the optional URI where the Vorbis Packed
Configuration (Section 3.1.1) Packets could be fetched. Different
delivery methods MAY be advertised for the same session. The in-band
+
+
+
+Barbato Expires April 18, 2006 [Page 8]
+
+Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
+
+
codebook 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
@@ -440,16 +463,6 @@
information it MUST NOT decode the raw data associated until it
fetches the correct Configuration.
-
-
-
-
-
-Barbato Expires April 18, 2006 [Page 8]
-
-Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
-
-
3.1. In-band Header Transmission
The Packed Configuration (Section 3.1.1) Payload is sent in-band with
@@ -466,6 +479,32 @@
client provide a minimal size comment header to the decoder if
required by the implementation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires April 18, 2006 [Page 9]
+
+Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
+
+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -498,37 +537,40 @@
Figure 6: Packed Configuration Figure
-
-
-
-Barbato Expires April 18, 2006 [Page 9]
-
-Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
-
-
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.
+ number of packet is set to 1. In practice, Packed Headers usually
+ need to be fragmented to stay below the path MTU.
3.2. Out of Band Transmission
- This section, as stated before, will not cover all the possible out-
+ 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 a specific application. The following packet definition
+ 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.
+
+
+
+
+
+Barbato Expires April 18, 2006 [Page 10]
+
+Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
+
+
3.2.1. Packed Headers
- As mentioned above the RECOMMENDED delivery vector for Theora
+ 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 chained Theora stream.
+ for each setup id.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of packed headers |
@@ -543,25 +585,9 @@
Figure 7: Packed Headers Overview
Since the Configuration Ident and the Identification Header are fixed
- lenght there is only a 2 byte Lenght tag to define the lenght of the
+ length there is only a 2 byte Length tag to define the length of the
packed headers.
-
-
-
-
-
-
-
-
-
-
-
-Barbato Expires April 18, 2006 [Page 10]
-
-Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
-
-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -581,6 +607,16 @@
The key difference between the in-band format is there is no need for
the payload header octet.
+
+
+
+
+
+Barbato Expires April 18, 2006 [Page 11]
+
+Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
+
+
3.2.1.1. Packed Headers IANA Considerations
The following IANA considerations MUST only be applied to the packed
@@ -606,18 +642,6 @@
See Section 6 of RFC XXXX.
-
-
-
-
-
-
-
-Barbato Expires April 18, 2006 [Page 11]
-
-Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
-
-
Interoperability considerations:
None
@@ -640,6 +664,15 @@
Luca Barbato: <lu_zero at gentoo.org>
IETF Audio/Video Transport Working Group
+
+
+
+
+Barbato Expires April 18, 2006 [Page 12]
+
+Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
+
+
Intended usage: COMMON
Restriction on usage:
@@ -665,24 +698,37 @@
report sent via RTCP.
+4. Comment Headers
+ 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 Theora
+ documentation [16].
-Barbato Expires April 18, 2006 [Page 12]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires April 18, 2006 [Page 13]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
-4. Comment Headers
-
- 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. Clients MAY ignore it
- completely. The details on the format of the comments can be found
- in the Theora documentation [16].
-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -707,39 +753,41 @@
Figure 9: Comment Packet
- The 2 bytes length field is necessary since this packet could be
- fragmented.
+ The 2 byte length field is necessary since this Theora packet could
+ be fragmented.
5. Frame Packetizing
Each RTP packet contains either one complete Theora packet, one
Theora packet fragment, or an integer number of complete Theora
- packets (up to a max of 15 packets, since the number of packets is
- defined by a 4 bit value).
+ packets (up to a maximum of 15 packets, since the number of packets
+ is defined by a 4 bit value).
Any Theora data packet that is less than path MTU SHOULD be bundled
in the RTP packet with as many Theora packets as will fit, up to a
maximum of 15. Path MTU is detailed in [7] and [8].
+ 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
-Barbato Expires April 18, 2006 [Page 13]
+Barbato Expires April 18, 2006 [Page 14]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
- 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 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
- Theora 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.
+ 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.
5.1. Example Fragmented Theora Packet
@@ -781,7 +829,14 @@
-Barbato Expires April 18, 2006 [Page 14]
+
+
+
+
+
+
+
+Barbato Expires April 18, 2006 [Page 15]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
@@ -812,8 +867,8 @@
The Fragment type field is set to 2 and the number of packets field
is set to 0. For large Theora 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.
+ these type of payload packets. The maximum RTP 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.
@@ -837,7 +892,7 @@
-Barbato Expires April 18, 2006 [Page 15]
+Barbato Expires April 18, 2006 [Page 16]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
@@ -889,11 +944,11 @@
event of packet loss from a large number of participants.
Loss of any of the Configuration fragment will result in the loss of
- the full Configuration packet with the result detailed in the Loss of
+ the full Configuration packet as detailed in the Loss of
-Barbato Expires April 18, 2006 [Page 16]
+Barbato Expires April 18, 2006 [Page 17]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
@@ -949,7 +1004,7 @@
-Barbato Expires April 18, 2006 [Page 17]
+Barbato Expires April 18, 2006 [Page 18]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
@@ -1005,7 +1060,7 @@
-Barbato Expires April 18, 2006 [Page 18]
+Barbato Expires April 18, 2006 [Page 19]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
@@ -1026,10 +1081,10 @@
included in the SDP "a=fmpt" attribute and MUST follow the
delivery-method that applies.
- If the stream comprises chained Theora files and all of them are
- known in advance, the Configuration Packet for each file SHOULD be
- packaged together and passed to the client using the configuration
- attribute.
+ If the stream uses multiple decoder setup configurations and all of
+ them are known in advance, the Configuration Packet for each file
+ SHOULD be packaged together and passed to the client using the
+ configuration attribute.
The URI specified in the configuration-uri attribute MUST point to a
location where all of the Configuration Packets needed for the life
@@ -1061,7 +1116,7 @@
-Barbato Expires April 18, 2006 [Page 19]
+Barbato Expires April 18, 2006 [Page 20]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
@@ -1078,9 +1133,9 @@
This document is a continuation of draft-kerr-avt-theora-rtp-00.txt
Thanks to the AVT, Ogg Theora Communities / Xiph.org, Fluendo, Ralph
- Giles, Mike Smith, Phil Kerr, Politecnico di Torino (LS)^3/IMG Group
- in particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini,
- Juan Carlos De Martin.
+ Giles, Mike Smith, Phil Kerr, Timothy Terriberry, Politecnico di
+ Torino (LS)^3/IMG Group in particular Federico Ridolfo, Francesco
+ Varano, Giampaolo Mancini, Juan Carlos De Martin.
9. References
@@ -1117,7 +1172,7 @@
-Barbato Expires April 18, 2006 [Page 20]
+Barbato Expires April 18, 2006 [Page 21]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
@@ -1144,8 +1199,8 @@
[15] "libTheora: Available from the Xiph website,
http://www.xiph.org".
- [16] "Ogg Theora I specification: Codec setup and packet decode.
- http://www.xiph.org/ogg/Theora/doc/Theora-spec-ref.html".
+ [16] "Theora I specification: Codec setup and packet decode.
+ http://www.xiph.org/theora/doc/Theora_I_spec.pdf".
[17] "ITU-T Recommendation V.42, 1994, Rev. 1. Error-correcting
Procedures for DCEs Using Asynchronous-to-Synchronous
@@ -1173,7 +1228,7 @@
-Barbato Expires April 18, 2006 [Page 21]
+Barbato Expires April 18, 2006 [Page 22]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
@@ -1229,7 +1284,7 @@
-Barbato Expires April 18, 2006 [Page 22]
+Barbato Expires April 18, 2006 [Page 23]
Internet-Draft draft-barbato-avt-rtp-theora-00 October 2005
@@ -1285,6 +1340,5 @@
-Barbato Expires April 18, 2006 [Page 23]
+Barbato Expires April 18, 2006 [Page 24]
-
Modified: trunk/theora/doc/draft-barbato-avt-rtp-theora-00.xml
===================================================================
--- trunk/theora/doc/draft-barbato-avt-rtp-theora-00.xml 2005-12-17 20:18:41 UTC (rev 10626)
+++ trunk/theora/doc/draft-barbato-avt-rtp-theora-00.xml 2005-12-17 21:14:08 UTC (rev 10627)
@@ -28,7 +28,7 @@
<abstract>
<t>
-This document describes a RTP payload format for transporting Theora encoded video. It details the RTP encapsulation mechanism for raw Theora data and configuration headers consisting of the quantization matrices and the Huffman codebooks for the DCT coefficients, and a table of limit values for the deblocking filter.
+This document describes a RTP payload format for transporting Theora encoded video. It details the RTP encapsulation mechanism for raw Theora data and configuration headers necessary to configure the decoder.
</t>
<t>
@@ -49,7 +49,7 @@
<section anchor="Introduction" title="Introduction">
<t>
-Theora is a general purpose, lossy video codec. It is based on the VP3.1 video codec produced by On2 Technologies and has been donated to the Xiph.org Foundation.
+Theora is a general purpose, lossy video codec. It is based on the VP3 video codec produced by On2 Technologies and has been donated to the Xiph.org Foundation.
</t>
<t>
@@ -57,16 +57,16 @@
</t>
<t>
-Theora provides none of its own framing, synchronization, or protection against transmission errors. Theora is a free-form variable bit rate (VBR) codec, and packets have no minimum size, maximum size, or fixed/expected size. Theora packets are thus intended to be used with a transport mechanism that provides free-form framing, synchronization, positioning, and error correction in accordance with these design assumptions, such as Ogg <xref target="rfc3533"></xref>. or RTP/AVP <xref target="rfc3550"></xref>.
+Theora provides none of its own framing, synchronization, or protection against transmission errors. Instead, the codec expects to receive a discrete sequence of data packets. Theora is a free-form variable bit rate (VBR) codec, and these packets have no minimum size, maximum size, or fixed/expected size. Theora packets are thus intended to be used with a transport mechanism that provides free-form framing, synchronization, positioning, and error correction in accordance with these design assumptions, such as Ogg <xref target="rfc3533"></xref> or RTP/AVP <xref target="rfc3550"></xref>.
</t>
<t>
-Theora I currently supports progressive video data of arbitrary dimensions at a constant frame rate in one of several YCbCr color spaces.
+Theora I currently supports progressive video data of arbitrary dimensions at a constant frame rate in one of several Y'CbCr color spaces.
Three different chroma subsampling formats are supported: 4:2:0, 4:2:2, and 4:4:4. The Theora I format does not support interlaced material, variable frame rates, bit-depths larger than 8 bits per component, nor alternate color spaces such as RGB or arbitrary multi-channel spaces. Black and white content can be efficiently encoded, however, because the uniform chroma planes compress well.
</t>
<t>
-Theora is similar to Vorbis audio <xref target="vorbisrtp"></xref> in that it requires the inclusion of the entire probability model for the DCT coefficients and all the quantization parameters in the bitstream headers to be sent ahead of the video data. It is therefore impossible to decode any frame in the stream without having previously fetched the codec info and codec setup headers, although Theora can initiate decode at an arbitrary intra-frame packet within a bitstream so long as the codec has been initialized with the setup headers.
+Theora is similar to the Vorbis audio <xref target="vorbisrtp"></xref> in that it the decoder reads the probability model for the entropy coder and all quantization parameters from special "header" packets at the start of the compressed data. It is therefore impossible to decode any video data without having previously fetched the codec info and codec setup headers, although Theora can initiate decode at an arbitrary intra-frame packet so long as the codec has been initialized with the associated headers.
</t>
<section anchor="Terminology" title="Terminology">
@@ -82,11 +82,11 @@
<section anchor="Payload Format" title="Payload Format">
<t>
-Each frame of digital video is packetized into one or 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. A single RTP packet MAY contain data for more than one Theora frame.
+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.
</t>
<t>
-For RTP based transportation of Theora encoded video the standard RTP header is followed by a 4 octet payload header, then the payload data.
+For RTP based transport of Theora encoded video the standard RTP header is followed by a 4 octet payload header, then the payload data.
</t>
<section anchor="RTP Header" title="RTP Header">
@@ -202,11 +202,12 @@
<t> 3 = End Fragment</t>
</list>
+<t>This field must be zero if the number of packets field is non-zero.</t>
<t>
Theora Data Type (TDT): 2 bits</t>
<t>
-This field sets the packet payload type for the Theora data. There are currently two type of Vorbis payloads.
+This field sets the packet payload type for the Theora data. There are currently three Theora payload types.
</t>
<vspace blankLines="1" />
@@ -226,7 +227,7 @@
<section anchor="Payload Data" title="Payload Data">
<t>
-Each Theora payload section starts with a two octet length header that is used to represent the size of the following data payload, followed by the raw Theora data.
+Each Theora payload section starts with a two octet length header that is used to represent the size of the following data payload, followed by the raw Theora packet data.
</t>
<figure anchor="Payload Data Figure" title="Payload Data">
@@ -240,11 +241,11 @@
</figure>
<t>
-The Theora codec uses relatively unstructured raw packets containing binary integer fields of arbitrary width that often do not fall on an octet boundary. When this happens the bitstream is packed to an octet boundary. When a Theora encoder produces packets, unused space in the last byte of a packet is always zeroed during the encoding process. Thus, should this unused space be read, it will return binary zeros.
+The Theora codec uses relatively unstructured raw packets containing binary integer fields of arbitrary width that often do not fall on an octet boundary. When a Theora encoder produces packets, unused space in the last byte of a packet is always zeroed during the encoding process. Thus, should this unused space be read, it will return binary zeros.
</t>
<t>
-For payloads which consist of multiple Theora packets the payload data consists of the payload length field followed by the payload data for each of the Theora packets in the payload.
+For payloads which consist of multiple Theora packets the payload data consists of the payload length field followed by the first Theora packet's data, then the payload length followed by the second Theora packet, and so on for each of the Theora packets in the payload.
</t>
</section>
@@ -299,12 +300,12 @@
</figure>
<t>
-The payload portion of the packet starts with the 24 bit Configuration ident field followed by the 8 bit bitfield. The Fragment type field is set to 0, indicating that this packet contains whole Theora frame data. The Data type field is set to 0 since it is theora raw data. The number of whole Theora data packets is set to 2.
+The payload portion of the packet starts with the 24 bit Configuration ident field followed by 8 bits describing the payload. The Fragment type field is set to 0, indicating that this packet contains whole Theora frame data. The Data type field is set to 0 since it is theora raw data. The number of whole Theora data packets is set to 2.
</t>
<t>
-Each of the payload blocks starts with the two octet length field and then
-follows by the variable length Theora data.
+Each of the payload blocks starts with the two octet length field followed
+by the variable length Theora packet data.
</t>
</section>
@@ -313,11 +314,11 @@
<section anchor="Configuration Headers" title="Configuration Headers">
<t>
-To decode a Theora stream three configuration header blocks are needed. The first header, the Identification Header, indicates the frame dimensions, quality, blocks used and the version of the Theora encoder used. The second header, the Comment Header, contains stream metadata and the third header, the Setup Header, details which contains dequantization and Huffman tables.
+To decode a Theora stream three configuration header packets are needed. The first, called the Identification Header, indicates the frame dimensions, quality, blocks used and the version of the Theora encoder used. The second, called the Comment Header, contains stream metadata and the third, called the Setup Header, contains details of the dequantization and Huffman tables.
</t>
<t>
-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 dequantization and Huffman tables as well as different bitrates of the stream.
+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 are detailed below. SDP delivery is used to set up an initial state for the client application. The changes may be due to different dequantization and Huffman tables as well as different bitrates of the stream.
</t>
<t>
@@ -374,7 +375,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.
+<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>
@@ -386,13 +387,13 @@
<section anchor="Out of Band Transmission" title="Out of Band Transmission">
<t>
-This section, as stated before, will not cover all the possible out-of-band delivery methods since they rely to different protocols and be linked to a specific application. 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 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.
</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 chained Theora stream.
+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">
@@ -410,7 +411,7 @@
</figure>
<t>
-Since the Configuration Ident and the Identification Header are fixed lenght there is only a 2 byte Lenght tag to define the lenght of the packed headers.
+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.
</t>
<figure anchor="Packed Headers Detail Figure" title="Packed Headers Detail">
@@ -583,7 +584,7 @@
<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. 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 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>.
</t>
<figure anchor="Comment Packet Figure" title="Comment Packet">
<artwork><![CDATA[
@@ -611,14 +612,14 @@
]]></artwork>
</figure>
-<t>The 2 bytes length field is necessary since this packet could be fragmented.</t>
+<t>The 2 byte length field is necessary since this Theora packet could be fragmented.</t>
</section>
<section anchor="Frame Packetizing" title="Frame Packetizing">
<t>
-Each RTP packet contains either one complete Theora packet, one Theora packet fragment, or an integer number of complete Theora packets (up to a max of 15 packets, since the number of packets is defined by a 4 bit value).
+Each RTP packet contains either one complete Theora packet, one Theora packet fragment, or an integer number of complete Theora packets (up to a maximum of 15 packets, since the number of packets is defined by a 4 bit value).
</t>
<t>
@@ -626,7 +627,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 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 Theora 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>
+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>
<section anchor="Example Fragmented Theora Packet" title="Example Fragmented Theora Packet">
@@ -691,7 +692,7 @@
</figure>
<t>
-The Fragment type field is set to 2 and the number of packets field is set to 0. For large Theora 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.
+The Fragment type field is set to 2 and the number of packets field is set to 0. For large Theora fragments there can be several of these type of payload packets. The maximum RTP 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)">
@@ -738,7 +739,7 @@
</t>
<t>
-Loss of any of the Configuration fragment will result in the loss of the full Configuration packet with the result detailed in the <xref target="Loss of Configuration Headers">Loss of Configuration Headers</xref> section.
+Loss of any of the Configuration fragment will result in the loss of the full Configuration packet as detailed in the <xref target="Loss of Configuration Headers">Loss of Configuration Headers</xref> section.
</t>
</section>
@@ -907,7 +908,7 @@
<t>
-If the stream comprises chained Theora files and all of them are known in advance, the Configuration Packet for each file SHOULD be packaged together and passed to the client using the configuration attribute.
+If the stream uses multiple decoder setup configurations and all of them are known in advance, the Configuration Packet for each file SHOULD be packaged together and passed to the client using the configuration attribute.
</t>
<t>
@@ -954,7 +955,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, 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, Politecnico di Torino (LS)³/IMG Group in particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini, Juan Carlos De Martin.
</t>
</section>
@@ -1100,7 +1101,7 @@
<reference anchor="theora-spec-ref">
<front>
-<title>Ogg Theora I specification: Codec setup and packet decode. http://www.xiph.org/ogg/Theora/doc/Theora-spec-ref.html</title>
+<title>Theora I specification: Codec setup and packet decode. http://www.xiph.org/theora/doc/Theora_I_spec.pdf</title>
</front>
</reference>
More information about the commits
mailing list