Clean up old automake options.
[theora.git] / doc / draft-ietf-avt-rtp-theora-00.txt
1
2
3
4 AVT Working Group                                             L. Barbato
5 Internet-Draft                                                  Xiph.Org
6 Expires: January 22, 2007                                  July 21, 2006
7
8
9                       draft-ietf-avt-rtp-theora-00
10               RTP Payload Format for Theora Encoded Video
11
12 Status of this Memo
13
14    By submitting this Internet-Draft, each author represents that any
15    applicable patent or other IPR claims of which he or she is aware
16    have been or will be disclosed, and any of which he or she becomes
17    aware will be disclosed, in accordance with Section 6 of BCP 79.
18
19    Internet-Drafts are working documents of the Internet Engineering
20    Task Force (IETF), its areas, and its working groups.  Note that
21    other groups may also distribute working documents as Internet-
22    Drafts.
23
24    Internet-Drafts are draft documents valid for a maximum of six months
25    and may be updated, replaced, or obsoleted by other documents at any
26    time.  It is inappropriate to use Internet-Drafts as reference
27    material or to cite them other than as "work in progress."
28
29    The list of current Internet-Drafts can be accessed at
30    http://www.ietf.org/ietf/1id-abstracts.txt.
31
32    The list of Internet-Draft Shadow Directories can be accessed at
33    http://www.ietf.org/shadow.html.
34
35    This Internet-Draft will expire on January 22, 2007.
36
37 Copyright Notice
38
39    Copyright (C) The Internet Society (2006).
40
41 Abstract
42
43    This document describes a RTP payload format for transporting Theora
44    encoded video.  It details the RTP encapsulation mechanism for raw
45    Theora data and configuration headers necessary to configure the
46    decoder.
47
48    Also included within the document are the necessary details for the
49    use of Theora with MIME and Session Description Protocol (SDP).
50
51 Editors Note
52
53
54
55 Barbato                 Expires January 22, 2007                [Page 1]
56 \f
57 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
58
59
60    All references to RFC XXXX are to be replaced by references to the
61    RFC number of this memo, when published.
62
63
64 Table of Contents
65
66    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
67      1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
68    2.  Payload Format . . . . . . . . . . . . . . . . . . . . . . . .  4
69      2.1.  RTP Header . . . . . . . . . . . . . . . . . . . . . . . .  4
70      2.2.  Payload Header . . . . . . . . . . . . . . . . . . . . . .  5
71      2.3.  Payload Data . . . . . . . . . . . . . . . . . . . . . . .  6
72      2.4.  Example RTP Packet . . . . . . . . . . . . . . . . . . . .  7
73    3.  Configuration Headers  . . . . . . . . . . . . . . . . . . . .  8
74      3.1.  In-band Header Transmission  . . . . . . . . . . . . . . .  9
75        3.1.1.  Packed Configuration . . . . . . . . . . . . . . . . .  9
76      3.2.  Out of Band Transmission . . . . . . . . . . . . . . . . . 10
77        3.2.1.  Packed Headers . . . . . . . . . . . . . . . . . . . . 11
78      3.3.  Loss of Configuration Headers  . . . . . . . . . . . . . . 13
79    4.  Comment Headers  . . . . . . . . . . . . . . . . . . . . . . . 13
80    5.  Frame Packetizing  . . . . . . . . . . . . . . . . . . . . . . 14
81      5.1.  Example Fragmented Theora Packet . . . . . . . . . . . . . 15
82      5.2.  Packet Loss  . . . . . . . . . . . . . . . . . . . . . . . 17
83    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
84      6.1.  Mapping MIME Parameters into SDP . . . . . . . . . . . . . 19
85        6.1.1.  SDP Example  . . . . . . . . . . . . . . . . . . . . . 20
86      6.2.  Usage with the SDP Offer/Answer Model  . . . . . . . . . . 20
87    7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
88      7.1.  Stream Video . . . . . . . . . . . . . . . . . . . . . . . 21
89    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
90    9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
91    10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
92      10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
93      10.2. Informative References . . . . . . . . . . . . . . . . . . 23
94    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
95    Intellectual Property and Copyright Statements . . . . . . . . . . 25
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111 Barbato                 Expires January 22, 2007                [Page 2]
112 \f
113 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
114
115
116 1.  Introduction
117
118    Theora is a general purpose, lossy video codec.  It is based on the
119    VP3 video codec produced by On2 Technologies and has been donated to
120    the Xiph.org Foundation.
121
122    Theora I is a block-based lossy transform codec that utilizes an 8 x
123    8 Type-II Discrete Cosine Transform and block-based motion
124    compensation.  This places it in the same class of codecs as MPEG-1,
125    MPEG-2, MPEG-4, and H.263.  The details of how individual blocks are
126    organized and how DCT coefficients are stored in the bitstream differ
127    substantially from these codecs, however.  Theora supports only intra
128    frames (I frames in MPEG) and inter frames (P frames in MPEG).
129
130    Theora provides none of its own framing, synchronization, or
131    protection against transmission errors.  Instead, the codec expects
132    to receive a discrete sequence of data packets.  Theora is a free-
133    form variable bit rate (VBR) codec, and these packets have no minimum
134    size, maximum size, or fixed/expected size.  Theora packets are thus
135    intended to be used with a transport mechanism that provides free-
136    form framing, synchronization, positioning, and error correction in
137    accordance with these design assumptions, such as Ogg [1] or RTP/AVP
138    [3].
139
140    Theora I currently supports progressive video data of arbitrary
141    dimensions at a constant frame rate in one of several Y'CbCr color
142    spaces.  Three different chroma subsampling formats are supported:
143    4:2:0, 4:2:2, and 4:4:4.  The Theora I format does not support
144    interlaced material, variable frame rates, bit-depths larger than 8
145    bits per component, nor alternate color spaces such as RGB or
146    arbitrary multi-channel spaces.  Black and white content can be
147    efficiently encoded, however, because the uniform chroma planes
148    compress well.  For performance reason, arbitrary frame sizes will be
149    encoded rounding both dimensions to the upper multiple of 16.  The
150    original width and height will be encoded in the header and the
151    decoder will use this information to clip the decoded frame to the
152    right dimensions.
153
154    Theora is similar to the Vorbis audio [10] in that the decoder reads
155    the probability model for the entropy coder and all quantization
156    parameters from special "header" packets at the start of the
157    compressed data.  It is therefore impossible to decode any video data
158    without having previously fetched the codec info and codec setup
159    headers, although Theora can begin to decode at an arbitrary intra-
160    frame packet so long as the codec has been initialized with the
161    associated headers.
162
163
164
165
166
167 Barbato                 Expires January 22, 2007                [Page 3]
168 \f
169 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
170
171
172 1.1.  Terminology
173
174    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
175    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
176    document are to be interpreted as described in RFC 2119 [2].
177
178
179 2.  Payload Format
180
181    For RTP based transportation of Theora encoded video the standard RTP
182    header is followed by a 4 octets payload header, then the payload
183    data.  The payload headers are used to associate the Theora data with
184    its associated decoding codebooks as well as indicating if the
185    following packet contains fragmented Theora data and/or the number of
186    whole Theora data frames.  The payload data contains the raw Theora
187    bitstream information.
188
189    For RTP based transport of Theora encoded video the standard RTP
190    header is followed by a 4 octets payload header, then the payload
191    data.
192
193 2.1.  RTP Header
194
195    The format of the RTP header is specified in [3] and shown in Figure
196    1.  This payload format uses the fields of the header in a manner
197    consistent with that specification.
198
199        0                   1                   2                   3
200        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
201       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
202       |V=2|P|X|  CC   |M|     PT      |       sequence number         |
203       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
204       |                           timestamp                           |
205       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
206       |           synchronization source (SSRC) identifier            |
207       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
208       |            contributing source (CSRC) identifiers             |
209       |                              ...                              |
210       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
211
212    Figure 1: RTP Header
213
214    The RTP header begins with an octet of fields (V, P, X, and CC) to
215    support specialized RTP uses (see [3] and [4] for details).  For
216    Theora RTP, the following values are used.
217
218    Version (V): 2 bits
219
220
221
222
223 Barbato                 Expires January 22, 2007                [Page 4]
224 \f
225 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
226
227
228    This field identifies the version of RTP.  The version used by this
229    specification is two (2).
230
231    Padding (P): 1 bit
232
233    Padding MAY be used with this payload format according to section 5.1
234    of [3].
235
236    Extension (X): 1 bit
237
238    The Extension bit is used in accordance with [3].
239
240    CSRC count (CC): 4 bits
241
242    The CSRC count is used in accordance with [3].
243
244    Marker (M): 1 bit
245
246    The Marker bit is used in accordance with [3].
247
248    Payload Type (PT): 7 bits
249
250    An RTP profile for a class of applications is expected to assign a
251    payload type for this format, or a dynamically allocated payload type
252    SHOULD be chosen which designates the payload as Theora.
253
254    Sequence number: 16 bits
255
256    The sequence number increments by one for each RTP data packet sent,
257    and may be used by the receiver to detect packet loss and to restore
258    packet sequence.  This field is detailed further in [3].
259
260    Timestamp: 32 bits
261
262    A timestamp representing the presentation time of the first sample of
263    the first Theora packet in the RTP packet.  The clock frequency MUST
264    be set to 90kHz.
265
266    SSRC/CSRC identifiers:
267
268    These two fields, 32 bits each with one SSRC field and a maximum of
269    16 CSRC fields, are as defined in [3].
270
271 2.2.  Payload Header
272
273    The 4 octets following the RTP Header section represent the Payload
274    Header.  This header is split into a number of bitfields detailing
275    the format of the following Payload Datagrams.
276
277
278
279 Barbato                 Expires January 22, 2007                [Page 5]
280 \f
281 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
282
283
284        0                   1                   2                   3
285        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
286       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
287       |               Configuration Ident             | F |TDT|# pkts.|
288       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
289
290       +-+-+-+-+-+-+-+-+
291
292    Figure 2: Payload Header
293
294    Configuration Ident: 24 bits
295
296    This 24 bit field is used to associate the Theora data to a decoding
297    Packed Configuration.
298
299    Fragment type (F): 2 bit
300
301    This field is set according to the following list
302
303       0 = Not Fragmented
304       1 = Start Fragment
305       2 = Continuation Fragment
306       3 = End Fragment
307
308    This field must be zero if the number of packets field is non-zero.
309
310    Theora Data Type (TDT): 2 bits
311
312    This field sets the packet payload type for the Theora data.  There
313    are currently three Theora payload types currently used and one
314    reserved for future use.
315
316       0 = Raw Theora payload
317       1 = Theora Packed Configuration payload
318       2 = Legacy Theora Comment payload
319       3 = Reserved
320
321    The packets with a TDT of value 3 MUST be ignored
322
323    The last 4 bits represent the number of complete packets in this
324    payload.  This provides a maximum number of 15 Theora packets in the
325    payload.  If the packet contains fragmented data the number of
326    packets MUST be set to 0.
327
328 2.3.  Payload Data
329
330    Each Theora payload section starts with a two octets length header
331    that is used to represent the size of the following data payload,
332
333
334
335 Barbato                 Expires January 22, 2007                [Page 6]
336 \f
337 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
338
339
340    followed by the raw Theora packet data.
341
342        0                   1                   2                   3
343        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
344       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
345       |        Payload Length         |          Theora Data         ..
346       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
347
348    Figure 3: Payload Data
349
350    The Theora codec uses relatively unstructured raw packets containing
351    binary integer fields of arbitrary width that often do not fall on an
352    octet boundary.  When a Theora encoder produces packets, unused space
353    in the last byte of a packet is always zeroed during the encoding
354    process.  Thus, should this unused space be read, it will return
355    binary zeros.
356
357    For payloads which consist of multiple Theora packets the payload
358    data consists of the payload length field followed by the first
359    Theora packet's data, then the payload length followed by the second
360    Theora packet, and so on for each of the Theora packets in the
361    payload.
362
363 2.4.  Example RTP Packet
364
365    Here is an example RTP packet containing two Theora packets.
366
367    RTP Packet Header:
368
369        0                   1                   2                   3
370        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
371       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
372       | 2 |0|0|  0    |0|      PT     |       sequence number         |
373       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
374       |                           timestamp                           |
375       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
376       |          synchronisation source (SSRC) identifier             |
377       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
378       |            contributing source (CSRC) identifiers             |
379       |                              ...                              |
380       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
381
382    Figure 4: Example RTP Packet
383
384    Payload Data:
385
386
387
388
389
390
391 Barbato                 Expires January 22, 2007                [Page 7]
392 \f
393 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
394
395
396        0                   1                   2                   3
397        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
398       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
399       |               Configuration Ident             | 0 | 0 | 2 pks |
400       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
401       |        Payload Length         |                              ..
402       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
403       ..                        Theora data                          ..
404       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
405       ..           data               |        Payload Length         |
406       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
407       ..                        Theora data                           |
408       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
409
410    Figure 5: Example Theora Payload Packet
411
412    The payload portion of the packet begins with the 24 bit
413    Configuration ident field followed by 8 bits describing the payload.
414    The Fragment type field is set to 0, indicating that this packet
415    contains whole Theora frame data.  The Data type field is set to 0
416    (theora raw data).  The number of whole Theora data packets is set to
417    2.
418
419    Each of the payload blocks starts with the two octets length field
420    followed by the variable length Theora packet data.
421
422
423 3.  Configuration Headers
424
425    To decode a Theora stream three configuration header packets are
426    needed.  The first (Identification Header) indicates frame
427    dimensions, quality, blocks used and Theora encoder version.  The
428    second (Comment Header) contains stream metadata and the third (Setup
429    Header) contains details of the dequantization and Huffman tables.
430
431    Since this information must be transmitted reliably, and as the RTP
432    stream may change certain configuration data mid-session, there are
433    different methods for delivering this configuration data to a client,
434    both in-band and out-of-band, which are detailed below.  SDP delivery
435    is used to set up an initial state for the client application.  The
436    changes may be due to different dequantization and Huffman tables as
437    well as different bitrates of the stream.
438
439    The delivery vectors in use are specified by an SDP attribute that
440    indicates the method and the optional URI where the Theora Packed
441    Configuration (Section 3.1.1) Packets could be fetched.  Different
442    delivery methods MAY be advertised for the same session.  The in-band
443    codebook delivery SHOULD be considered as baseline, out-of-band
444
445
446
447 Barbato                 Expires January 22, 2007                [Page 8]
448 \f
449 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
450
451
452    delivery methods that don't use RTP will not be described in this
453    document.  For non chained streams, the RECOMMENDED Configuration
454    delivery method is inline the Packed Configuration (Section 3.1.1) in
455    the SDP as explained in the IANA considerations (Section 6.1)
456
457    The 24 bit Ident field is used to map which Configuration will be
458    used to decode a packet.  When the Ident field changes, it indicates
459    that a change in the stream has taken place.  The client application
460    MUST have in advance the correct configuration and if the client
461    detects a change in the Ident value and does not have this
462    information it MUST NOT decode the raw data associated until it has
463    fetched the correct Configuration.
464
465 3.1.  In-band Header Transmission
466
467    The Packed Configuration (Section 3.1.1) Payload is sent in-band with
468    the packet type bits set to match the payload type.  Clients MUST be
469    capable of dealing with periodic re-transmission of the configuration
470    headers.
471
472 3.1.1.  Packed Configuration
473
474    A Theora Packed Configuration is identified by a payload type field
475    of 1.  Of the three headers, defined in the Theora I specification
476    [16], the identification and the setup will be packed together, while
477    the comment header will be completely suppressed.  It is up to the
478    client to provide a minimal size comment header to the decoder if
479    required by the implementation.
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503 Barbato                 Expires January 22, 2007                [Page 9]
504 \f
505 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
506
507
508        0                   1                   2                   3
509        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
510       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
511       |V=2|P|X|  CC   |M|     PT      |             xxxx              |
512       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
513       |                             xxxxx                             |
514       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
515       |           synchronization source (SSRC) identifier            |
516       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
517       |            contributing source (CSRC) identifiers             |
518       |                              ...                              |
519       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
520       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
521       |               Configuration Ident             | 0 | 1 |      1|
522       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
523       |             length            |          Identification      ..
524       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
525       ..                        Identification                       ..
526       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
527       ..                        Identification                       ..
528       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
529       ..                        Identification                        |
530       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
531       ..              |                      Setup                   ..
532       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
533       ..                            Setup                            ..
534       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
535       ..                            Setup                             |
536       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
537
538    Figure 6: Packed Configuration Figure
539
540    The Ident field is set with the value that will be used by the Raw
541    Payload Packets to address this Configuration.  The Fragment type is
542    set to 0 since the packet bears full Packed configuration, the number
543    of packet is set to 1.  In practice, Packed Headers usually need to
544    be fragmented to fit the path MTU.
545
546 3.2.  Out of Band Transmission
547
548    This section, as stated above, does not cover all the possible out-
549    of-band delivery methods since they rely on different protocols and
550    are linked to specific applications.  The following packet definition
551    SHOULD be used in out-of-band delivery and MUST be used when
552    Configuration is inlined in the SDP.
553
554
555
556
557
558
559 Barbato                 Expires January 22, 2007               [Page 10]
560 \f
561 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
562
563
564 3.2.1.  Packed Headers
565
566    As mentioned above, the recommended delivery vector for Theora
567    configuration data is via a retrieval method that can be performed
568    using a reliable transport protocol.  As the RTP headers are not
569    required for this method of delivery the structure of the
570    configuration data is slightly different.  The packed header starts
571    with a 32 bit count field which details the number of packed headers
572    that are contained in the bundle.  Next is the Packed header payload
573    for each setup id.
574
575       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
576       |                     Number of packed headers                  |
577       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
578       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
579       |                          Packed header                        |
580       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
581       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
582       |                          Packed header                        |
583       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
584
585    Figure 7: Packed Headers Overview
586
587    Since the Configuration Ident and the Identification Header are fixed
588    length there is only a 16bit Length tag to define the length of the
589    packed headers.
590
591        0                   1                   2                   3
592        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
593       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
594       |              Configuration Ident              |              ..
595       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
596       ..   Length     |              Identification Header           ..
597       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
598       ..                    Identification Header                     |
599       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
600       |                         Setup Header                         ..
601       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
602       ..                        Setup Header                          |
603       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
604
605    Figure 8: Packed Headers Detail
606
607    The key difference from the in-band format is that there is no need
608    for the payload header octet.
609
610
611
612
613
614
615 Barbato                 Expires January 22, 2007               [Page 11]
616 \f
617 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
618
619
620 3.2.1.1.  Packed Headers IANA Considerations
621
622    The following IANA considerations MUST only be applied to the packed
623    headers.
624
625    MIME media type name: audio
626
627    MIME subtype: theora-config
628
629    Required Parameters:
630
631       None
632
633    Optional Parameters:
634
635       None
636
637    Encoding considerations:
638
639       This media type contains binary data.
640
641    Security Considerations:
642
643       See Section 6 of RFC XXXX.
644
645    Interoperability considerations:
646
647       None
648
649    Published specification:
650
651       RFC XXXX [RFC Editor: please replace by the RFC number of this
652       memo, when published]
653
654    Applications which use this media type:
655
656       Theora encoded video, configuration data.
657
658    Additional information:
659
660       None
661
662    Person & email address to contact for further information:
663
664       Luca Barbato: <lu_zero@gentoo.org>
665       IETF Audio/Video Transport Working Group
666
667
668
669
670
671 Barbato                 Expires January 22, 2007               [Page 12]
672 \f
673 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
674
675
676    Intended usage: COMMON
677
678    Restriction on usage:
679
680       This media type does not depend on the transport.
681
682    Author:
683
684       Luca Barbato
685
686    Change controller:
687
688       IETF AVT Working Group
689
690 3.3.  Loss of Configuration Headers
691
692    Unlike the loss of raw Theora payload data, the loss of a
693    configuration header can lead to a situation where it will not be
694    possible to successfully decode the stream.
695
696    A loss of a Configuration Packet causes the stream decoder to halt
697    and SHOULD be reported to the client as well as a loss report sent
698    via RTCP.
699
700
701 4.  Comment Headers
702
703    When the payload type is set to 2, the packet contains comment
704    metadata such as artist name, track title and so on.  These metadata
705    messages are not intended to be fully descriptive but to offer basic
706    title information.  Clients MAY choose to completely ignore them.
707    The details on the comments format can be found in the Theora
708    documentation [16].
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727 Barbato                 Expires January 22, 2007               [Page 13]
728 \f
729 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
730
731
732        0                   1                   2                   3
733        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
734       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
735       |V=2|P|X|  CC   |M|     PT      |             xxxx              |
736       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
737       |                             xxxxx                             |
738       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
739       |           synchronization source (SSRC) identifier            |
740       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
741       |            contributing source (CSRC) identifiers             |
742       |                              ...                              |
743       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
744       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
745       |              Configuration Ident              | 0 | 2 |      1|
746       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
747       |            length             |            Comment           ..
748       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
749       ..                           Comment                           ..
750       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
751       ..                           Comment                            |
752       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
753
754    Figure 9: Comment Packet
755
756    The 2 byte length field is necessary since this Theora packet could
757    be fragmented.
758
759
760 5.  Frame Packetizing
761
762    Each RTP packet contains either one complete Theora packet, one
763    Theora packet fragment, or an integer number of complete Theora
764    packets (up to a maximum of 15 packets, since the number of packets
765    is defined by a 4 bit value).
766
767    Any Theora data packet that is less than path MTU SHOULD be bundled
768    in the RTP packet with as many Theora packets as will fit, up to a
769    maximum of 15.  Path MTU is detailed in [7] and [8].
770
771    A fragmented packet has a zero in the last four bits of the payload
772    header.  The RTP packet containing the first fragment will set the
773    Fragment type to 1.  Each RTP packet after the first will set the
774    Fragment type to 2 in the payload header.  The RTP packet containing
775    the last fragment of the Theora packet will have the Fragment type
776    set to 3.  If the fragmented Theora packet spans only two RTP
777    packets, the first will set the Fragment type field to 1 and the
778    second will set it to 2.  To maintain the correct sequence for
779    fragmented packet reception the timestamp field of fragmented packets
780
781
782
783 Barbato                 Expires January 22, 2007               [Page 14]
784 \f
785 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
786
787
788    MUST be the same as the first packet sent, with the sequence number
789    incremented as normal for the subsequent RTP packets.
790
791 5.1.  Example Fragmented Theora Packet
792
793    Here is an example fragmented Theora packet split over three RTP
794    packets.  Each packet contains the standard RTP headers as well as
795    the 4 octets Theora headers.
796
797       Packet 1:
798
799        0                   1                   2                   3
800        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
801       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
802       |V=2|P|X|  CC   |M|     PT      |           1000                |
803       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
804       |                             xxxxx                             |
805       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
806       |           synchronization source (SSRC) identifier            |
807       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
808       |            contributing source (CSRC) identifiers             |
809       |                              ...                              |
810       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
811       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
812       |              Configuration Ident              | 1 | 0 |      0|
813       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
814       |        Payload Length         |           Theora data        ..
815       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
816       ..                        Theora data                          ..
817       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
818
819    Figure 10: Example Fragmented Packet (Packet 1)
820
821    In this packet the initial sequence number is 1000 and the timestamp
822    is xxxxx.  The Fragment type field is set to one, indicating it is
823    the start packet of a serie of fragments.  The number of packets
824    field is set to 0, and as the payload is raw Theora data the Theora
825    payload type field is set to 0.
826
827
828
829
830
831
832
833
834
835
836
837
838
839 Barbato                 Expires January 22, 2007               [Page 15]
840 \f
841 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
842
843
844       Packet 2:
845
846        0                   1                   2                   3
847        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
848       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
849       |V=2|P|X|  CC   |M|     PT      |           1001                |
850       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
851       |                             xxxxx                             |
852       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
853       |           synchronization source (SSRC) identifier            |
854       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
855       |            contributing source (CSRC) identifiers             |
856       |                              ...                              |
857       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
858       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
859       |              Configuration Ident              | 2 | 0 |      0|
860       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
861       |        Payload Length         |              ..
862       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
863       ..                        Theora data                          ..
864       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
865
866    Figure 11: Example Fragmented Packet (Packet 2)
867
868    The Fragment type field is set to 2 and the number of packets field
869    is set to 0.  For large Theora fragments there can be several of
870    these type of payload packets.  The maximum RTP packet size SHOULD be
871    no greater than the path MTU, including all RTP and payload headers.
872    The sequence number has been incremented by one but the timestamp
873    field remains the same as the initial packet.
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895 Barbato                 Expires January 22, 2007               [Page 16]
896 \f
897 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
898
899
900       Packet 3:
901
902        0                   1                   2                   3
903        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
904       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
905       |V=2|P|X|  CC   |M|     PT      |           1002                |
906       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
907       |                             xxxxx                             |
908       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
909       |           synchronization source (SSRC) identifier            |
910       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
911       |            contributing source (CSRC) identifiers             |
912       |                              ...                              |
913       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
914       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
915       |              Configuration Ident              | 3 | 0 |      0|
916       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
917       |        Payload Length         |                              ..
918       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
919       ..                         Theora data                         ..
920       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
921
922    Figure 12: Example Fragmented Packet (Packet 3)
923
924    This is the last Theora fragment packet.  The Fragment type filed is
925    set to 3 and the packet count remains set to 0.  As in the previous
926    packets the timestamp remains set to the first packet in the sequence
927    and the sequence number has been incremented.
928
929 5.2.  Packet Loss
930
931    As there is no error correction within the Theora stream, packet loss
932    will result in a loss of signal.  Packet loss is more of an issue for
933    fragmented Theora packets as the client will have to cope with the
934    handling of the Fragment type field.  If we use the fragmented Theora
935    packet example above and the first packet is lost the client MUST
936    detect that the next packet has the packet count field set to 0 and
937    the Fragment type is set to 2 and MUST drop it.  The next packet,
938    which is the final fragmented packet, MUST be dropped in the same
939    manner.  Feedback reports on lost and dropped packets MUST be sent
940    back via RTCP.[note: reordering]
941
942    If a particular multicast session has a large number of participants
943    care must be taken to prevent an RTCP feedback implosion, [9], in the
944    event of packet loss from a large number of participants.
945
946    Loss of any of the Configuration fragment will result in the loss of
947    the full Configuration packet as detailed in the Loss of
948
949
950
951 Barbato                 Expires January 22, 2007               [Page 17]
952 \f
953 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
954
955
956    Configuration Headers (Section 3.3) section.
957
958
959 6.  IANA Considerations
960
961    MIME media type name: video
962
963    MIME subtype: theora
964
965    Required Parameters:
966
967       sampling: Determines the chroma subsampling format.
968
969       width: Determines the number of pixels per line.  This is an
970          integer between 1 and 1048561 and MUST be in multiples of 16.
971
972       height: Determines the number of lines per frame encoded.  This is
973          an integer between 1 and 1048561 and MUST be in multiples of
974          16.
975
976       delivery-method: indicates the delivery methods in use, the
977          possible values are: inline, in_band, out_band/specific_name
978          Where "specific_name" is the name of the out of band delivery
979          method.
980
981       configuration: the base16 [11] (hexadecimal) representation of the
982          Packed Headers (Section 3.2.1).
983
984    Optional Parameters:
985
986       configuration-uri: the URI of the configuration headers in case of
987          out of band transmission.  In the form of
988          "protocol://path/to/resource/".  Depending on the specific
989          method the single ident packets could be retrived by their
990          number or aggregated in a single stream, aggregates MAY be
991          compressed using gzip [12] or bzip2 [14] and an sha1 [13]
992          checksum MAY be provided in the form of
993          "protocol://path/to/resource/aggregated.bz2!sha1hash"
994
995    Encoding considerations:
996
997       This media type is framed and contains binary data.
998
999    Security Considerations:
1000
1001       See Section 6 of RFC XXXX.
1002
1003
1004
1005
1006
1007 Barbato                 Expires January 22, 2007               [Page 18]
1008 \f
1009 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
1010
1011
1012    Interoperability considerations:
1013
1014       None
1015
1016    Published specification:
1017
1018       RFC XXXX [RFC Editor: please replace by the RFC number of this
1019       memo, when published]
1020
1021       Ogg Theora I specification: Codec setup and packet decode.
1022       Available from the Xiph website, http://www.xiph.org
1023
1024    Applications which use this media type:
1025
1026       Audio streaming and conferencing tools
1027
1028    Additional information:
1029
1030       None
1031
1032    Person & email address to contact for further information:
1033
1034       Luca Barbato: <lu_zero@gentoo.org>
1035       IETF Audio/Video Transport Working Group
1036
1037    Intended usage:
1038
1039       COMMON
1040
1041    Restriction on usage:
1042
1043       This media type depends on RTP framing, and hence is only defined
1044       for transfer via RTP [3]
1045
1046    Author:
1047
1048       Luca Barbato
1049
1050    Change controller:
1051
1052       IETF AVT Working Group
1053
1054
1055 6.1.  Mapping MIME Parameters into SDP
1056
1057    The information carried in the MIME media type specification has a
1058    specific mapping to fields in the Session Description Protocol (SDP)
1059    [6], which is commonly used to describe RTP sessions.  When SDP is
1060
1061
1062
1063 Barbato                 Expires January 22, 2007               [Page 19]
1064 \f
1065 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
1066
1067
1068    used to specify sessions the mapping are as follows:
1069
1070    o  The MIME type ("video") goes in SDP "m=" as the media name.
1071
1072    o  The MIME subtype ("theora") goes in SDP "a=rtpmap" as the encoding
1073       name.
1074
1075    o  The clock rate in the "a=rtpmap" line MUST be 90000
1076
1077    o  The mandated parameters "delivery-method" and "configuration" MUST
1078       be included in the SDP "a=fmpt" attribute.
1079
1080    o  The optional parameter "configuration-uri", when present, MUST be
1081       included in the SDP "a=fmpt" attribute and MUST follow the
1082       delivery-method that applies.
1083
1084    If the stream uses multiple decoder setup configurations and all of
1085    them are known in advance, the Configuration Packet for each file
1086    SHOULD be packaged together and passed to the client using the
1087    configuration attribute.
1088
1089    The URI specified in the configuration-uri attribute MUST point to a
1090    location where all of the Configuration Packets needed for the life
1091    of the session reside.
1092
1093 6.1.1.  SDP Example
1094
1095    The following example shows a basic SDP for a single stream.  The
1096    first configuration packet is inlined in the sdp, other
1097    configurations could be fetched at any time from the first provided
1098    uri using or all the known configuration could be downloaded using
1099    the second uri.  The inline base16 [11] configuration string is
1100    omitted because of the lenght.
1101       c=IN IP4 192.0.0.1
1102       m=video RTP/AVP 98
1103       a=rtpmap:98 theora/90000
1104       a=fmtp:98 sampling=YCbCr-4:2:2; width=1280; height=720; delivery-
1105       method=inline; configuration=base16string1; delivery-
1106       method=out_band/rtsp; delivery-method=out_band/rtsp;
1107       configuration-uri=rtsp://path/to/resource/; delivery-
1108       method=out_band/http; configuration-uri=http://another/path/to/
1109       resource/aggregate.bz2!sha1hash;
1110
1111 6.2.  Usage with the SDP Offer/Answer Model
1112
1113    The offer, as described in An Offer/Answer Model Session Description
1114    Protocol [5], may contain a large number of delivery methods per
1115    single fmtp attribute, the answerer MUST remove every delivery-method
1116
1117
1118
1119 Barbato                 Expires January 22, 2007               [Page 20]
1120 \f
1121 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
1122
1123
1124    and configuration-uri not supported.  All the parameters MUST not be
1125    altered on answer otherwise.
1126
1127
1128 7.  Examples
1129
1130    The following examples are common usage patterns that MAY be applied
1131    in such situations, the main scope of this section is to explain
1132    better usage of the transmission vectors.
1133
1134 7.1.  Stream Video
1135
1136    This is one of the most common situation: one single server streaming
1137    content in multicast, the clients may start a session at random time.
1138    The content itself could be a mix of live stream, as the wj's voice
1139    or studio scenes, and stored streams, as the music she plays.
1140
1141    In this situation we don't know in advance how many codebooks we will
1142    use.  The clients can join anytime and users expect to start the
1143    fruition of the content in a short time.
1144
1145    On join the client will receive the current Configuration necessary
1146    to decode the current streams inlined in the SDP so that the decoding
1147    will start immediately after.
1148
1149    When the streamed content changes the new Configuration is sent in-
1150    band before the actual stream, and the Configuration that has to be
1151    sent inline in the SDP updated.  Since the inline method is
1152    unreliable, an out of band fallback is provided.
1153
1154    The client could choose to fetch the Configuration from the alternate
1155    source as soon it discovers a Configuration packet got lost inline or
1156    use selective retransmission [17], if the server supports the
1157    feature.
1158
1159    A serverside optimization would be to keep an hash list of the
1160    Configurations per session to avoid packing all of them and send the
1161    same Configuration with different Ident tags
1162
1163    A clientside optimization would be to keep a tag list of the
1164    Configurations per session and don't process configuration packets
1165    already known.
1166
1167
1168 8.  Security Considerations
1169
1170    RTP packets using this payload format are subject to the security
1171    considerations discussed in the RTP specification [3].  This implies
1172
1173
1174
1175 Barbato                 Expires January 22, 2007               [Page 21]
1176 \f
1177 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
1178
1179
1180    that the confidentiality of the media stream is achieved by using
1181    encryption.  Because the data compression used with this payload
1182    format is applied end-to-end, encryption may be performed on the
1183    compressed data.  Where the size of a data block is set care MUST be
1184    taken to prevent buffer overflows in the client applications.
1185
1186
1187 9.  Acknowledgments
1188
1189    This document is a continuation of draft-kerr-avt-theora-rtp-00.txt
1190
1191    Thanks to the AVT, Ogg Theora Communities / Xiph.org, Fluendo, Ralph
1192    Giles, Mike Smith, Phil Kerr, Timothy Terriberry, Stefan Ehmann,
1193    Alessandro Salvatori, Politecnico di Torino (LS)^3/IMG Group in
1194    particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini,
1195    Juan Carlos De Martin.
1196
1197
1198 10.  References
1199
1200 10.1.  Normative References
1201
1202    [1]   Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
1203          RFC 3533.
1204
1205    [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
1206          Levels", RFC 2119.
1207
1208    [3]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
1209          "RTP: A Transport Protocol for real-time applications",
1210          RFC 3550.
1211
1212    [4]   Schulzrinne, H. and S. Casner, "RTP Profile for video and Video
1213          Conferences with Minimal Control.", RFC 3551.
1214
1215    [5]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
1216          Session Description Protocol (SDP)", RFC 3264.
1217
1218    [6]   Handley, M. and V. Jacobson, "SDP: Session Description
1219          Protocol", RFC 2327.
1220
1221    [7]   Mogul et al., J., "Path MTU Discovery", RFC 1063.
1222
1223    [8]   McCann et al., J., "Path MTU Discovery for IP version 6",
1224          RFC 1981.
1225
1226    [9]   Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
1227          "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)",
1228
1229
1230
1231 Barbato                 Expires January 22, 2007               [Page 22]
1232 \f
1233 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
1234
1235
1236          Internet Draft (draft-ietf-avt-rtcp-feedback-11: Work in
1237          progress).
1238
1239    [10]  Barbato, L., "RTP Payload Format for Vorbis Encoded Audio -
1240          draft-ietf-avt-vorbis-rtp-00", Internet Draft (Work in
1241          progress).
1242
1243    [11]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
1244          RFC 3548.
1245
1246    [12]  Deutsch, P., "GZIP file format specification version 4.3",
1247          RFC 1952.
1248
1249    [13]  National Institute of Standards and Technology, "Secure Hash
1250          Standard", May 1993.
1251
1252    [14]  Seward, J., "libbz2 and bzip2".
1253
1254 10.2.  Informative References
1255
1256    [15]  "libTheora: Available from the Xiph website,
1257          http://www.xiph.org".
1258
1259    [16]  "Theora I specification:  Codec setup and packet decode.
1260          http://www.xiph.org/theora/doc/Theora_I_spec.pdf".
1261
1262    [17]  Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
1263          Extended Reports (RTCP XR)", RFC 3611, November 2003.
1264
1265    [18]  "ITU-T Recommendation V.42, 1994, Rev. 1. Error-correcting
1266          Procedures for DCEs Using Asynchronous-to-Synchronous
1267          Conversion. International Telecommunications Union. Available
1268          from the ITU website, http://www.itu.int".
1269
1270    [19]  "ISO 3309, October 1984, 3rd Edition. Information Processing
1271          Systems--Data Communication High-Level Data Link Control
1272          Procedure--Frame Structure. International Organization for
1273          Standardization.".
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287 Barbato                 Expires January 22, 2007               [Page 23]
1288 \f
1289 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
1290
1291
1292 Author's Address
1293
1294    Luca Barbato
1295    Xiph.Org
1296
1297    Email: lu_zero@gentoo.org
1298    URI:   http://www.xiph.org/
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343 Barbato                 Expires January 22, 2007               [Page 24]
1344 \f
1345 Internet-Draft        draft-ietf-avt-rtp-theora-00             July 2006
1346
1347
1348 Intellectual Property Statement
1349
1350    The IETF takes no position regarding the validity or scope of any
1351    Intellectual Property Rights or other rights that might be claimed to
1352    pertain to the implementation or use of the technology described in
1353    this document or the extent to which any license under such rights
1354    might or might not be available; nor does it represent that it has
1355    made any independent effort to identify any such rights.  Information
1356    on the procedures with respect to rights in RFC documents can be
1357    found in BCP 78 and BCP 79.
1358
1359    Copies of IPR disclosures made to the IETF Secretariat and any
1360    assurances of licenses to be made available, or the result of an
1361    attempt made to obtain a general license or permission for the use of
1362    such proprietary rights by implementers or users of this
1363    specification can be obtained from the IETF on-line IPR repository at
1364    http://www.ietf.org/ipr.
1365
1366    The IETF invites any interested party to bring to its attention any
1367    copyrights, patents or patent applications, or other proprietary
1368    rights that may cover technology that may be required to implement
1369    this standard.  Please address the information to the IETF at
1370    ietf-ipr@ietf.org.
1371
1372
1373 Disclaimer of Validity
1374
1375    This document and the information contained herein are provided on an
1376    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1377    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1378    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1379    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1380    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1381    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1382
1383
1384 Copyright Statement
1385
1386    Copyright (C) The Internet Society (2006).  This document is subject
1387    to the rights, licenses and restrictions contained in BCP 78, and
1388    except as set forth therein, the authors retain all their rights.
1389
1390
1391 Acknowledgment
1392
1393    Funding for the RFC Editor function is currently provided by the
1394    Internet Society.
1395
1396
1397
1398
1399 Barbato                 Expires January 22, 2007               [Page 25]
1400 \f