draft-barbato-avt-rtp-theora-01.txt

mediastreamer2是开源的网络传输媒体流的库

AVT Working Group                                             L. Barbato
Internet-Draft                                                  Xiph.Org
Expires: December 18, 2006                                 June 16, 2006


                    draft-barbato-avt-rtp-theora-01
              RTP Payload Format for Theora Encoded Video

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 December 18, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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 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



Barbato                 Expires December 18, 2006               [Page 1]

Internet-Draft       draft-barbato-avt-rtp-theora-01           June 2006


   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  . . . . . . . . . . . . . . . . . . . . . . .  4
   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.  Configuration Headers  . . . . . . . . . . . . . . . . . . . .  8
     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 . . . . . . . . . . . . . . . . . . . . 11
     3.3.  Loss of Configuration Headers  . . . . . . . . . . . . . . 13
   4.  Comment Headers  . . . . . . . . . . . . . . . . . . . . . . . 13
   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.1.1.  SDP Example  . . . . . . . . . . . . . . . . . . . . . 20
     6.2.  Usage with the SDP Offer/Answer Model  . . . . . . . . . . 20
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     7.1.  Stream Video . . . . . . . . . . . . . . . . . . . . . . . 21
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     10.2. Informative References . . . . . . . . . . . . . . . . . . 23
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
   Intellectual Property and Copyright Statements . . . . . . . . . . 25















Barbato                 Expires December 18, 2006               [Page 2]

Internet-Draft       draft-barbato-avt-rtp-theora-01           June 2006


1.  Introduction

   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.

   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.  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
   [3].

   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.  Arbitrary frame size will be encoded rounding to the
   upper multiple of 16 both dimension for performance reason.  The
   original width and height will be encoded in the header and the
   decoder will use this information to clip the decoded frame to the
   right dimensions.

   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.





Barbato                 Expires December 18, 2006               [Page 3]

Internet-Draft       draft-barbato-avt-rtp-theora-01           June 2006


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].


2.  Payload Format

   For RTP based transportation of Theora encoded video the standard RTP
   header is followed by a 4 octets 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.

   For RTP based transport of Theora encoded video the standard RTP
   header is followed by a 4 octets 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




Barbato                 Expires December 18, 2006               [Page 4]

Internet-Draft       draft-barbato-avt-rtp-theora-01           June 2006


   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

   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 presentation time of the first sample of
   the first Theora packet in the RTP packet.  The clock frequency MUST
   be set to 90kHz.

   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

   The 4 octets following the RTP Header section are the Payload Header.
   This header is split into a number of bitfields detailing the format
   of the following Payload Data packets.



Barbato                 Expires December 18, 2006               [Page 5]

Internet-Draft       draft-barbato-avt-rtp-theora-01           June 2006


       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             | F |TDT|# pkts.|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+

   Figure 2: Payload Header

   Configuration Ident: 24 bits

   This 24 bit field is used to associate the Theora data to a decoding
   Packed Configuration.

   Fragment type (F): 2 bit

   This field is set according to the following list

      0 = Not Fragmented
      1 = Start Fragment
      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 three Theora payload types.

      0 = Raw Theora payload
      1 = Theora Packed Configuration payload
      2 = Legacy Theora Comment payload
      3 = Reserved

   The packets with a TDT of value 3 MUST be ignored

   The last 4 bits represent 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 two octets length header
   that is used to represent the size of the following data payload,
   followed by the raw Theora packet data.



Barbato                 Expires December 18, 2006               [Page 6]

Internet-Draft       draft-barbato-avt-rtp-theora-01           June 2006


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Payload Length         |          Theora Data         ..
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 a Theora encoder produces packets, unused space