[xiph-commits] r8816 - trunk/theora/doc
philkerr at motherfish-iii.xiph.org
philkerr at motherfish-iii.xiph.org
Mon Jan 31 19:59:23 PST 2005
Author: philkerr
Date: 2005-01-31 19:59:18 -0800 (Mon, 31 Jan 2005)
New Revision: 8816
Added:
trunk/theora/doc/draft-kerr-avt-theora-rtp-00.txt
Log:
Initial commit.
Added: trunk/theora/doc/draft-kerr-avt-theora-rtp-00.txt
===================================================================
--- trunk/theora/doc/draft-kerr-avt-theora-rtp-00.txt 2005-02-01 03:58:44 UTC (rev 8815)
+++ trunk/theora/doc/draft-kerr-avt-theora-rtp-00.txt 2005-02-01 03:59:18 UTC (rev 8816)
@@ -0,0 +1,1512 @@
+
+
+AVT Working Group P. Kerr
+Internet-Draft Xiph.Org
+Expires: August 1, 2005 January 31, 2005
+
+
+ draft-kerr-avt-theora-rtp-00
+ RTP Payload Format for Theora Encoded Video
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which he or she is aware have been or will be disclosed, and any of
+ which he or she become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on August 1, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ 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.
+
+ Also included within the document are the necessary details for the
+ use of Theora with MIME and Session Description Protocol (SDP).
+
+
+
+Kerr Expires August 1, 2005 [Page 1]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+Editors Note
+
+ All references to RFC XXXX are to be replaced by references to the
+ RFC number of this memo, when published.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1 RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.2 Payload Header . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.3 Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.4 Example RTP Packet . . . . . . . . . . . . . . . . . . . . 7
+ 3. Frame Packetizing . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.1 Example Fragmented Theora Packet . . . . . . . . . . . . . 9
+ 4. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5. Configuration Headers . . . . . . . . . . . . . . . . . . . . 13
+ 5.1 In-band Header Transmission . . . . . . . . . . . . . . . 13
+ 5.1.1 Identification Header . . . . . . . . . . . . . . . . 13
+ 5.1.2 Comment Header . . . . . . . . . . . . . . . . . . . . 15
+ 5.1.3 Setup Header . . . . . . . . . . . . . . . . . . . . . 16
+ 5.2 Packed Headers Delivery . . . . . . . . . . . . . . . . . 18
+ 5.2.1 Packed Headers IANA Considerations . . . . . . . . . . 21
+ 5.3 Setup Header Caching . . . . . . . . . . . . . . . . . . . 22
+ 5.4 Loss of Configuration Headers . . . . . . . . . . . . . . 22
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
+ 6.1 Mapping MIME Parameters into SDP . . . . . . . . . . . . . 24
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 25
+ 9.2 Informative References . . . . . . . . . . . . . . . . . . . 26
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26
+ Intellectual Property and Copyright Statements . . . . . . . . 27
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 2]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+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.
+
+ Theora I is a block-based lossy transform codec that utilizes an 8 x
+ 8 Type-II Discrete Cosine Transform and block-based motion
+ compensation. This places it in the same class of codecs as MPEG-1,
+ MPEG-2, MPEG-4, and H.263. The details of how individual blocks are
+ organized and how DCT coefficients are stored in the bitstream differ
+ substantially from these codecs, however. Theora supports only intra
+ 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
+ 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 [3].
+
+ Theora I currently supports progressive video data of arbitrary
+ dimensions at a constant frame rate in one of several YCbCr 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.
+
+ Theora is similar to Vorbis audio [9] 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.
+
+1.1 Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [2].
+
+
+
+
+Kerr Expires August 1, 2005 [Page 3]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+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.
+
+ For RTP based transportation of Theora encoded video the standard RTP
+ header is followed by a 5 octet payload header, then the payload
+ data.
+
+2.1 RTP Header
+
+ The format of the RTP header is specified in [3] and shown in Figure
+ 1. This payload format uses the fields of the header in a manner
+ consistent with that specification.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | sequence number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | timestamp |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: RTP Header
+
+ The RTP header begins with an octet of fields (V, P, X, and CC) to
+ support specialized RTP uses (see [3] and [4] for details). For
+ Theora RTP, the following values are used.
+
+ Version (V): 2 bits
+
+ This field identifies the version of RTP. The version used by this
+ specification is two (2).
+
+ Padding (P): 1 bit
+
+ Padding MAY be used with this payload format according to section 5.1
+ of [3].
+
+ Extension (X): 1 bit
+
+
+
+Kerr Expires August 1, 2005 [Page 4]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+ The Extension bit is used in accordance with [3].
+
+ CSRC count (CC): 4 bits
+
+ The CSRC count is used in accordance with [3].
+
+ Marker (M): 1 bit
+
+ The Marker bit is used in accordance with [3].
+
+ Payload Type (PT): 7 bits
+
+ An RTP profile for a class of applications is expected to assign a
+ payload type for this format, or a dynamically allocated payload type
+ SHOULD be chosen which designates the payload as Theora.
+
+ Sequence number: 16 bits
+
+ The sequence number increments by one for each RTP data packet sent,
+ and may be used by the receiver to detect packet loss and to restore
+ packet sequence. This field is detailed further in [3].
+
+ Timestamp: 32 bits
+
+ A timestamp representing the sampling time of the first sample of the
+ first Theora packet in the RTP packet. The clock frequency MUST be
+ set to the sample rate of the encoded video data and is conveyed
+ out-of-band as an SDP attribute.
+
+ SSRC/CSRC identifiers:
+
+ These two fields, 32 bits each with one SSRC field and a maximum of
+ 16 CSRC fields, are as defined in [3].
+
+2.2 Payload Header
+
+ After the RTP Header section the following five octets are the
+ Payload Header. This header is split into a number of bitfields
+ detailing the format of the following Payload Data packets.
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 5]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header Ident |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |C|F|0|0|# pkts.|
+ +-+-+-+-+-+-+-+-+
+
+ Figure 2: Payload Header
+
+ Setup Header Ident: 32 bits
+
+ This 32 bit field is used to associate the Theora data to a decoding
+ Setup Header. It is created by making a CRC32 checksum of the Setup
+ Header required to decode the particular Theora video stream.
+
+ Continuation (C): 1 bit
+
+ Set to one if this is a continuation of a fragmented packet.
+
+ Fragmented (F): 1 bit
+
+ Set to one if the payload contains complete packets or if it contains
+ the last fragment of a fragmented packet.
+
+ The next two bits are currently reserved and MUST be set to 0.
+
+ The last 4 bits are the number of complete packets in this payload.
+ This provides for a maximum number of 15 Theora packets in the
+ payload. If the packet contains fragmented data the number of
+ packets MUST be set to 0.
+
+2.3 Payload Data
+
+ Each Theora payload section starts with a three octet header. The
+ first octet is used to denote what kind of Theora data follows. Then
+ a two octet length header is used to represent the size of the
+ following data payload, followed by the raw Theora data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 6]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data type | Payload Length | Theora Data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 3: Payload Data
+
+ The data type octet is used to signify the payload data type. If the
+ first bit is set to 0, this indicates the payload is Theora video
+ data.
+
+ The following values for the Theora payload type are valid:
+
+ 0 = Raw Theora data
+ 0x80 = Theora Identification header
+ 0x81 = Theora Comment header
+ 0x82 = Theora Setup header
+
+
+ The Theora packet length header is the length of the Theora data
+ block only and does not count the length octets and payload data type
+ octet.
+
+ 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.
+
+ For payloads which consist of multiple Theora packets the payload
+ data consists of the data type field, the payload length field
+ followed by the payload data for each of the Theora packets in the
+ payload.
+
+2.4 Example RTP Packet
+
+ Here is an example RTP packet containing two Theora packets.
+
+ RTP Packet Header:
+
+
+
+
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 7]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 2 |0|0| 0 |0| PT | sequence number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | timestamp (in sample rate units) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronisation source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 4: Example RTP Packet
+
+ Payload 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header Ident |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0|1|0|0| 2 pks | 0x80 | Payload Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Theora data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. data | 0 | Payload Length ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Theora data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 5: Example Theora Payload Packet
+
+ The payload portion of the packet starts with the 32 bit Setup Header
+ ident field followed by the 8 bit fragment/count fields. The F bit
+ is set to 1, indicating that this packet contains whole Theora frame
+ data. The number of whole Theora data packets is set to 2.
+
+ Each of the payload blocks starts with a Data type field, for the
+ first payload this is set to 0x80 indicating it is an Identification
+ header and the second payload is set to 0 indicating it is raw Theora
+ data. Then the two octet length field is followed by the variable
+ length Theora data.
+
+3. Frame Packetizing
+
+ Each RTP packet contains either one complete Theora packet, one
+ Theora packet fragment, or an integer number of complete Theora
+
+
+
+Kerr Expires August 1, 2005 [Page 8]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+ packets (up to a max 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 [6] and [7].
+
+ 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. Each fragment after the first will also set the Continued
+ (C) bit to one in the payload header. The RTP packet containing the
+ last fragment of the Theora packet will have the Fragmented (F) bit
+ set to one. 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.
+
+3.1 Example Fragmented Theora Packet
+
+ Here is an example fragmented Theora packet split over three RTP
+ packets. Each packet contains the standard RTP headers as well as
+ the 5 octet Theora headers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 9]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+ Packet 1:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1000 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header Ident |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0|0|0|0| 0| 0 | Payload Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Theora data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 6: Example Fragmented Packet (Packet 1)
+
+ In this packet the initial sequence number is 1000 and the timestamp
+ is xxxxx. The Continuation (C) bit is set to one, indicating it is
+ not the continuation of a fragmented bit, and the Fragmentation (F)
+ is set to 0 indicating it is a fragmented packet. The number of
+ packets field is set to 0, and as the payload is raw Theora data the
+ Theora payload type field is set to 0.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 10]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+ Packet 2:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1001 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header Ident |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |1|0|0|0| 0| 0 | Payload Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Theora data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 7: Example Fragmented Packet (Packet 2)
+
+ The C bit is set to 1 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 11]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+ Packet 3:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1002 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header Ident |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |1|1|0|0| 0| 0 | Payload Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Theora data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 8: Example Fragmented Packet (Packet 3)
+
+ This is the last Theora fragment packet. The C and F bits are set
+ 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.
+
+4. Packet Loss
+
+ 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 C and F flags. If we use the fragmented Theora
+ packet example above and the first packet is lost the client SHOULD
+ detect that the next packet has the packet count field set to 0 and
+ the C bit is set and MUST drop it. The next packet, which is the
+ final fragmented packet, SHOULD be dropped in the same manner, or
+ buffered. Feedback reports on lost and dropped packets MUST be sent
+ back via RTCP.
+
+ If a particular multicast session has a large number of participants
+ care must be taken to prevent an RTCP feedback implosion, [8], in the
+ event of packet loss from a large number of participants.
+
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 12]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+5. Configuration Headers
+
+ 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.
+
+ As the RTP stream may change certain configuration data mid-session
+ there are two different methods for delivering this configuration
+ data to a client, in-band and SDP which is detailed below. SDP
+ delivery is used to set-up an initial state for the client
+ application and in-band is used to change state during the session.
+ The changes may be due to different metadata or Setup Header as well
+ as different bitrates of the stream.
+
+ Out of the two delivery vectors the use of an SDP attribute to
+ indicate an URI where the configuration and Setup Header data can be
+ obtained is preferred as they can be fetched reliably using TCP. The
+ in-band Setup Header delivery SHOULD only be used in situations where
+ the link between the client is unidirectional or if the SDP-based
+ information is not available.
+
+ Synchronizing the configuration and Setup Header to the RTP stream is
+ critical. The 32 bit Setup Header Ident field is used to indicate
+ when a change in the stream has taken place. The client application
+ MUST have in advance the correct configuration and Setup Headers and
+ if the client detects a change in the Ident value and does not have
+ this information it MUST NOT decode the raw Theora data.
+
+5.1 In-band Header Transmission
+
+ The three header data blocks are sent in-band with the packet type
+ bits set to match the payload type. Normally the Setup Header and
+ Identification Header are sent once per session if the stream is an
+ encoding of live video, as typically the encoder state will not
+ change, but the encoder state can change at the boundary of chained
+ Theora video files. Metadata can be sent at the start as well as any
+ time during the life of the session. Clients MUST be capable of
+ dealing with periodic re-transmission of the configuration headers.
+
+5.1.1 Identification Header
+
+ The Identification Header is a short header with only a few fields
+ used to declare the stream definitively as Theora and provide
+ detailed information about the format of the fully decoded video
+ data.
+
+
+
+Kerr Expires August 1, 2005 [Page 13]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | xxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header Ident |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0|1|0|0| 1| 0x80 | Payload Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | VMAJ | VMIN | VREV | FMBW |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | FMBW | FMBH | NSBS |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NSBS | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NBS | NMBS |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NMBS | PICW |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PICW | PICH |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PICH | PICX | PICY | FRN |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | FRN | FRD |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | FRD | PARN |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PARN | PARD |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PARD | CS |PF | NOMBR |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NOMBR | QUAL | KFGSHIFT|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 9: Identification Header
+
+ The fields listed above have the following meanings:
+
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 14]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+ VMAJ = The major version number. 8 bits.
+ VMIN = The minor version number. 8 bits.
+ VREV = The version revision number. 8 bits.
+ FMBW = The width of the frame in macro blocks. 16 bits.
+ FMBH = The height of the frame in macro blocks. 16 bits.
+ NSBS = The total number of super blocks in a frame. 32 bits.
+ NBS = The total number of blocks in a frame. 36 bits.
+ NMBS = The total number of macro blocks in a frame. 32 bits.
+ PICW = The width of the picture region in pixels. 20 bits.
+ PICH = The height of the picture region in pixels. 20 bits.
+ PICX = The X offset of the picture region in pixels. 8 bits.
+ PICY = The Y offset of the picture region in pixels. 8 bits.
+ FRN = The frame-rate numerator. 32 bits.
+ FRD = The frame-rate denominator. 32 bits.
+ PARN = The pixel aspect-ratio numerator. 24 bits.
+ PARD = The pixel aspect-ratio denominator. 24 bits.
+ CS = The color space. 8 bits.
+ PF = The pixel format. 2 bits.
+ NOMBR = The nominal bitrate of the stream, in bits per second.
+ 24 bits.
+ QUAL = The quality hint. 6 bits.
+ KFGSHIFT = The amount to shift the key frame number by in the
+ granule position. 5 bits.
+
+
+5.1.2 Comment Header
+
+ The Theora Comment Header is the second of three header packets that
+ begin a Theora stream. It is meant for short text comments, not
+ arbitrary metadata; arbitrary metadata belongs in a separate logical
+ stream that provides greater structure and machine parseability. The
+ comment field is meant to be used much like someone jotting a quick
+ note on the label of a video. It should be a little information to
+ remember the disc or tape by and explain it to others; a short,
+ to-the-point text note that can be more than a couple words, but
+ isn't going to be more than a short paragraph.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 15]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | xxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header Ident |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0|1|0|0| 1| 0x81 | Payload Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | User comments list length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | User comment length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | User comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. User comment |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Figure 10: Comment Header
+
+ The format for the data takes the form of a 32 bit field denoting the
+ number of user comments. Each of the user comments is prefixed by a
+ 32 bit length field followed by the comment text encoded in UTF-8.
+
+5.1.3 Setup Header
+
+ The Theora setup header contains the limit values used to drive the
+ loop filter, the base matrices and scale values used to build the
+ dequantization tables, and the Huffman tables used to unpack the DCT
+ tokens. Because the contents of this header are specific to Theora,
+ no concessions have been made to keep the fields octet-aligned for
+ easy parsing.
+
+
+
+
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 16]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | xxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header Ident |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0|1|0|0| 1| 0x82 | Payload Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Setup Header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 11: Setup Header
+
+
+5.1.3.1 Setup Header CRC32 Generation
+
+ In order for different implementations of Theora RTP clients and
+ servers to interoperate with each other a common format for the
+ production of the CRC32 hash is required. The polynomial is
+ X^32+X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8+X^7+X^5+X^4+X^2+X^1+X^0.
+
+ The following C code function SHOULD be used by implementations, if
+ not then the code responsible for generating the CRC32 value MUST use
+ the polynomial function above.
+
+ unsigned int crc32 (int length, unsigned char *crcdata)
+ {
+ int index, loop;
+ unsigned int byte, crc, mask;
+
+ index = 0;
+ crc = 0xFFFFFFFF;
+
+ while (index < length) {
+ byte = crcdata [index];
+
+
+
+Kerr Expires August 1, 2005 [Page 17]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+ crc = crc ^ byte;
+
+ for (loop = 7; loop >= 0; loop--) {
+ mask = -(crc & 1);
+ crc = (crc >> 1) ^ (0xEDB88320 & mask);
+ }
+ index++;
+ }
+ return ~crc;
+ }
+
+
+5.2 Packed Headers Delivery
+
+ As mentioned above the RECOMMENDED delivery vector for Theora
+ configuration data is via an SDP attribute as this retrieval method
+ can be performed using a reliable transport protocol.
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Number of packed headers |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packed header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packed header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 12: Packed Headers Overview
+
+ 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 file.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 18]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Header Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header Ident |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identification Header ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Identification Header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Comment Header ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment Header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Setup Header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 13: Packed Headers Detail
+
+ The key difference between the in-band format is there is no need for
+ the payload header octet and Setup Header Ident field. Below are
+ examples of the packed headers format.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 19]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | VMAJ | VMIN | VREV | FMBW |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | FMBW | FMBH | NSBS |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NSBS | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NBS | NMBS |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NMBS | PICW |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PICW | PICH |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PICH | PICX | PICY | FRN |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | FRN | FRD |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | FRD | PARN |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PARN | PARD |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PARD | CS |PF | NOMBR |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NOMBR | QUAL | KFGSHIFT|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 14: Packed Identification Header
+
+ The alignment of the packed Identification Header is slightly
+ different from the RTP payload type as the payload header is not
+ used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 20]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | User comments list length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | User comment length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | User comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. User comment |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 15: Packed Comment Header
+
+ The packed Comment Header also as a slightly different structure to
+ that of the RTP payload type with the payload header not being used.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Setup Header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 16: Packed Setup Header
+
+ The packed Setup Header also has a slightly different structure to
+ that of the RTP payload type. The Setup Header Ident field that is
+ normally part of this structure is moved to the second field of the
+ overall packed structure.
+
+5.2.1 Packed Headers IANA Considerations
+
+ The following IANA considerations MUST only be applied to the packed
+ headers.
+
+ MIME media type name: video
+
+ MIME subtype: theora-config
+
+ Required Parameters:
+
+ None.
+
+
+
+
+Kerr Expires August 1, 2005 [Page 21]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+ Optional Parameters:
+
+ None.
+
+ Encoding considerations:
+
+ This type is only defined for transfer via HTTP as specified in RFC
+ XXXX.
+
+ Security Considerations:
+
+ See Section 6 of RFC 3047.
+
+ Interoperability considerations: none
+
+ Published specification:
+
+ See RFC XXXX for details.
+
+ Applications which use this media type:
+
+ Theora encoded video, configuration data.
+
+ Additional information: none
+
+ Person & email address to contact for further information:
+
+ Phil Kerr: <phil at plus24.com>
+
+ Intended usage: COMMON
+
+ Author/Change controller:
+
+ Author: Phil Kerr
+
+ Change controller: IETF AVT Working Group
+
+5.3 Setup Header Caching
+
+ Setup Header caching allows clients that have previously connected to
+ a stream to re-use the associated Setup Header and configuration
+ data. When a client receives a Setup Header it may store it locally
+ and can compare the CRC32 key with that of the new stream and begin
+ decoding before it has received any of the headers.
+
+5.4 Loss of Configuration Headers
+
+ Unlike the loss of raw Theora payload data, loss of a configuration
+
+
+
+Kerr Expires August 1, 2005 [Page 22]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+ header can lead to a situation where it will not be possible to
+ successfully decode the stream.
+
+ Out of the three headers, loss of either the Setup Header or
+ Identification Headers MUST result in the halting of stream decoding.
+ Loss of the Comment header SHOULD NOT be regarded as fatal for
+ decoding. Loss of any of the headers SHOULD be reported to the
+ client as well as a loss report sent via RTCP.
+
+6. IANA Considerations
+
+ MIME media type name: video
+
+ MIME subtype: theora
+
+ Required Parameters:
+
+ sampling: Determines the chroma subsampling format.
+
+ width: Determines the number of pixels per line. This is an integer
+ between 1 and 1048561 and MUST be in multiples of 16.
+
+ height: Determines the number of lines per frame. This is an integer
+ between 1 and 1048561 and MUST be in multiples of 16.
+
+ header: Indicates the URI of the decoding configuration headers.
+
+ Optional Parameters:
+
+ None.
+
+ Encoding considerations:
+
+ This type is only defined for transfer via RTP as specified in RFC
+ XXXX.
+
+ Security Considerations:
+
+ See Section 6 of RFC 3047.
+
+ Interoperability considerations: none
+
+ Published specification:
+
+ See the Theora documentation [11] for details.
+
+ Applications which use this media type:
+
+
+
+
+Kerr Expires August 1, 2005 [Page 23]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+ Video streaming and conferencing tools
+
+ Additional information: none
+
+ Person & email address to contact for further information:
+
+ Phil Kerr: <phil at plus24.com>
+
+ Intended usage: COMMON
+
+ Author/Change controller:
+
+ Author: Phil Kerr
+
+ Change controller: IETF AVT Working Group
+
+6.1 Mapping MIME Parameters into SDP
+
+ The information carried in the MIME media type specification has a
+ specific mapping to fields in the Session Description Protocol (SDP)
+ [5], which is commonly used to describe RTP sessions. When SDP is
+ used to specify sessions the mapping are as follows:
+
+ o The MIME type ("video") goes in SDP "m=" as the media name.
+
+ o The MIME subtype ("THEORA") goes in SDP "a=rtpmap" as the encoding
+ name.
+
+ o The parameter "rate" also goes in "a=rtpmap" as clock rate.
+
+ o The parameter "channels" also goes in "a=rtpmap" as channel count.
+
+ o The parameter "header" goes in the SDP "a=fmpt" attribute.
+
+ If the stream comprises chained Theora files the configuration and
+ Setup Headers for each file SHOULD be packaged together and passed to
+ the client using the headers attribute if all the files to be played
+ are known in advance.
+
+ Example:
+
+ c=IN IP4/6
+ m=video RTP/AVP 98
+ a=rtpmap:98 theora/90000
+ a=fmtp:98 sampling=YCbCr-4:2:2; width=1280; height=720;
+ header=<URI of configuration header>
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 24]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+7. Security Considerations
+
+ RTP packets using this payload format are subject to the security
+ considerations discussed in the RTP specification [3]. 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.
+
+8. Acknowledgments
+
+ Thanks to the AVT, Ogg Theora Communities / Xiph.org, Fluendo, Ralph
+ Giles.
+
+9. References
+
+9.1 Normative References
+
+ [1] Pfeiffer, S., "The Ogg Encapsulation Format Version 0", RFC
+ 3533.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119.
+
+ [3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
+ "RTP: A Transport Protocol for real-time applications", RFC
+ 3550.
+
+ [4] Schulzrinne, H. and S. Casner, "RTP Profile for video and Video
+ Conferences with Minimal Control.", RFC 3551.
+
+ [5] Handley, M. and V. Jacobson, "SDP: Session Description
+ Protocol", RFC 2327.
+
+ [6] Mogul et al., J., "Path MTU Discovery", RFC 1063.
+
+ [7] McCann et al., J., "Path MTU Discovery for IP version 6", RFC
+ 1981.
+
+ [8] Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey,
+ "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)",
+ Internet Draft (draft-ietf-avt-rtcp-feedback-11: Work in
+ progress).
+
+ [9] Kerr, P., "RTP Payload Format for Vorbis Encoded Audio -
+ draft-ietf-avt-vorbis-rtp-00", Internet Draft (Work in
+ progress).
+
+
+
+Kerr Expires August 1, 2005 [Page 25]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+9.2 Informative References
+
+ [10] "libTheora: Available from the Xiph website,
+ http://www.xiph.org".
+
+ [11] "Ogg Theora I spec: Codec setup and packet decode.
+ http://www.xiph.org/ogg/Theora/doc/Theora-spec-ref.html".
+
+
+Author's Address
+
+ Phil Kerr
+ Xiph.Org
+
+ EMail: phil at plus24.com
+ URI: http://www.xiph.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 26]
+
+Internet-Draft draft-kerr-avt-theora-rtp-00 January 2005
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Kerr Expires August 1, 2005 [Page 27]
+
More information about the commits
mailing list