doc/draft-moffitt-vorbis-rtp-00.txt

   1 Network Working Group                           Jack Moffitt
   2 Internet-Draft                                  Xiph.org Foundation
   3 Expire in six months                            February 2001
   4
   5
   6             RTP Payload Format for Vorbis Encoded Audio
   7
   8                    <draft-moffitt-vorbis-rtp-00.txt>
   9
  10 Status of this Memo
  11
  12    This document is an Internet-Draft and is in full conformance
  13    with all provisions of Section 10 of RFC2026.
  14
  15    Internet-Drafts are working documents of the Internet Engineering
  16    Task Force (IETF), its areas, and its working groups.  Note that
  17    other groups may also distribute working documents as
  18    Internet-Drafts.
  19
  20    Internet-Drafts are draft documents valid for a maximum of six
  21    months and may be updated, replaced, or obsoleted by other
  22    documents at any time.  It is inappropriate to use Internet-
  23    Drafts as reference material or to cite them other than as
  24    "work in progress".
  25
  26    The list of current Internet-Drafts can be accessed at
  27    http://www.ietf.org/ietf/1id-abstracts.txt
  28
  29    The list of Internet-Draft Shadow Directories can be accessed at
  30    http://www.ietf.org/shadow.html.
  31
  32 Abstract
  33
  34    This document describes a RTP payload format for transporting Vorbis
  35    encoded audio.
  36
  37 1 Introduction
  38
  39    This document describes how Vorbis encoded audio may be formatted for
  40    use as an RTP payload type.
  41
  42    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  43    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  44    document are to be interpreted as described in RFC 2119 [1].
  45
  46 2 Background
  47
  48    The Xiph.org Foundation creates and defines codecs for use in
  49    multimedia that are not encumbered by patents and thus may be freely
  50    implemented by any individual or organization.
  51
  52    Vorbis is the general purpose multi-channel audio codec created by
  53    the Xiph.org Foundation.
  54
  55    Vorbis encoded audio is generally found within an Ogg format
  56    bitstream, which provides framing and synchronization.  For the
  57    purposes of RTP transport, this layer is unnecessary, and so raw
  58    Vorbis packets are used in the payload.
  59
  60    Vorbis packets are unbounded in length currently.  At some future
  61    point there will likely be a practical limit placed on packet
  62    length.
  63
  64    Typical Vorbis packet sizes are from very small (2-3 bytes) to
  65    quite large (8-12 kilobytes).  The reference implementation seems to
  66    make every packet less than ~800 bytes, except for the codebooks
  67    packet which is ~8-12 kilobytes.
  68
  69 3 Payload Format
  70
  71    The standard RTP header is followed by an 8 bit payload header, and
  72    the payload data.
  73
  74 3.1 RTP Header
  75
  76    The following fields of the RTP header are used for Vorbis payloads:
  77
  78    Payload Type (PT): 7 bits
  79       An RTP profile for a class of applications is expected to assign a
  80       payload type for this format, or a dynamically allocated payload
  81       type should be chosen which designates the payload as Vorbis.
  82
  83    Timestamp: 32 bits
  84       A timestamp representing the sampling time of the first sample of
  85       the first Vorbis packet in the RTP packet.  The clock frequency
  86       MUST be set to the sample rate of the encoded audio data and is
  87       conveyed out-of-band.
  88
  89    Marker (M): 1 bit
  90       Set to one if the payload contains complete packets or if it
  91       contains the last fragment of a fragmented packet.
  92
  93 3.2 Payload Header
  94
  95    The first byte of the payload data is the payload header:
  96
  97            +---+---+---+---+---+---+---+---+
  98            | C | R | R |  # of packets     |
  99            +---+---+---+---+---+---+---+---+
 100
 101    C: 1 bit
 102       Set to one if this is a continuation of a fragmented packet.
 103
 104    R: 1 bit x 2
 105       Reserved, must be set to zero by senders, and ignored by
 106       receivers.
 107
 108    The last 5 bits are the number of complete packets in this payload.
 109    If C is set to one, this number should be 0.
 110
 111 3.3 Payload Data
 112
 113    If the payload contains a single Vorbis packet or a Vorbis packet
 114    fragment, the Vorbis packet data follows the payload header.
 115
 116    For payloads which consist of multiple Vorbis packets, payload data
 117    consists of one byte representing the packet length followed by the
 118    packet data for each of the Vorbis packets in the payload.
 119
 120    The Vorbis packet length byte is the length minus one.  A value of
 121    0 means a length of 1.
 122
 123 3.4 Example RTP Packet
 124
 125    Here is an example RTP packet containing two Vorbis packets.
 126
 127    RTP Packet Header:
 128
 129     0                   1                   2                   3
 130     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 8 0 1
 131    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 132    |V=2|P|X|  CC   |M|      PT     |      sequence number          |
 133    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 134    |                 timestamp (in sample rate units)              |
 135    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 136    |         sychronization source (SSRC) identifier               |
 137    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 138    |         contributing source (CSRC) identifiers                |
 139    |                      ...                                      |
 140    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 141
 142    Payload Data:
 143
 144     0                   1                   2                   3
 145     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
 146    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 147    |0|0|0| # pks: 2|      len      |  vorbis data ...              |
 148    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 149    |                  ...vorbis data...                            |
 150    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 151    |     ...       |      len      | next vorbis packet data...    |
 152    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 153
 154 4 Frame Packetizing
 155
 156    Each RTP packet contains either one complete Vorbis packet, one
 157    Vorbis packet fragment, or an integer number of complete Vorbis
 158    packets (a max of 32 packets, since the number of packets is
 159    defined by a 5 bit value).
 160
 161    Any Vorbis packet that is larger than 256 bytes and less than the
 162    path-MTU should be placed in a RTP packet by itself.
 163
 164    Any Vorbis packet that is 256 bytes or less should be bundled in the
 165    RTP packet with as many Vorbis packets as will fit, up to a maximum
 166    of 32.
 167
 168    If a packet will not fit into the RTP packet, it must be fragmented.
 169    A fragmented packet has a zero in the last five bits of the payload
 170    header.  Each fragment after the first will also set the Continued
 171    (C) bit to one in the payload header.  The RTP packet containing the
 172    last fragment of the Vorbis packet will have the Marker (M) bit set
 173    to one.
 174
 175 5 Open Issues
 176
 177    To decode a Vorbis stream, a set of codebooks is required.  These
 178    codebooks are allowed to change for each logical bitstream (for
 179    example, for each song encoded in a radio stream).
 180
 181    The codebooks must be completely intact and a client can not decode
 182    a stream with an incomplete or corrupted set.
 183
 184    A client connecting to a multicast RTP Vorbis session needs to get the
 185    first set of codebooks in some manner.  These codebooks are typically
 186    between 4 kilobytes and 8 kilobytes in size.
 187
 188    A final solution to how best to deliver the codebooks has not yet been
 189    realized.  Here are the current proposals:
 190
 191    - Including the first set of codebooks in the SDP description
 192
 193    - Broadcasting a codebook only stream as a second multicast Vorbis
 194      stream
 195
 196    - Create some method of requesting the codebooks via RTCP
 197
 198    - Periodically retransmit the headers inline
 199
 200 6 Security Considerations
 201
 202    RTP packets using this payload format are subject to the security
 203    considerations discussed in the RTP specification [1].  This implies
 204    that the confidentiality of the media stream is achieved by using
 205    encryption.  Becase the data compression used with this payload
 206    format is applied end-to-end, encryption may be performed on the
 207    compressed data.
 208
 209 7 Acknowledgements
 210
 211    Thanks to the rest of the Xiph.org team, especially Monty
 212    <monty@xiph.org>. Thanks also to Rob Lanphier <robla@real.com> for
 213    his guidance.
 214
 215 8 References
 216
 217    1. RTP: A Transport Protocol for Real-Time Applications (RFC 1889)
 218
 219    2. Xiph.org's Ogg Vorbis pages http://www.xiph.org/ogg/vorbis/
 220       Vorbis documentation only currently exists as API documenation,
 221       or as source code.  The source can be obtained at
 222       http://www.xiph.org/ogg/vorbis/download.html
 223
 224 9 Author's Address
 225
 226    Jack Moffitt
 227    Executive Director
 228    Xiph.org Foundation
 229    email: jack@xiph.org
 230    WWW: http://www.xiph.org/