idnits 2.17.1 draft-ietf-avt-qt-rtp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 48 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 22, 1997) is 9768 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1890 (ref. '2') (Obsoleted by RFC 3551) ** Obsolete normative reference: RFC 2035 (ref. '3') (Obsoleted by RFC 2435) ** Obsolete normative reference: RFC 2038 (ref. '4') (Obsoleted by RFC 2250) ** Obsolete normative reference: RFC 2032 (ref. '5') (Obsoleted by RFC 4587) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 15 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Audio-Video Transport WG 3 INTERNET-DRAFT A. Jones, A. Periyannan, D. Singer 4 draft-ietf-avt-qt-rtp-00 Apple Computer, Inc. 5 July 22, 1997 6 Expires: January 22, 1998 8 RTP Payload Format for QuickTime Media Streams 10 Status of This Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 Abstract 32 This document specifies the payload format for encapsulating 33 QuickTime media streams in the Realtime Transport Protocol (RTP). 34 This specification is intended for QuickTime media/codec types that 35 are not already handled by other RTP payload specifications. Each 36 QuickTime media track within a movie is sent over a separate RTP 37 session and synchronized using standard RTP techniques. A static 38 QuickTime payload type (if assigned) or a dynamic payload type may be 39 used. A QuickTime header within the RTP payload is defined to carry 40 the media type and other media specific information. A packetization 41 scheme is defined for the media data. This specification is intended 42 for streaming stored QuickTime movies as well as live QuickTime 43 content. 45 1 Introduction 47 This document specifies the payload format for encapsulating 48 QuickTime media streams in the Realtime Transport Protocol (RTP) [1]. 49 RTP is a generic protocol designed to carry realtime media data along 50 with synchronization information over a datagram protocol (mostly UDP 51 over IP). The protocol itself does not address the encapsulation of 52 specific media types, but instead leaves it to various profile 53 specifications. An accompanying RTP profile document [2] contains 54 various payload specifications to carry audio and video over RTP for 55 conferencing applications and specifies the static payload types for 56 various audio/video compression schemes. Other documents specify the 57 encapsulation format used to carry specific compression schemes such 58 as JPEG, MPEG and H.261 [3,4,5]. 60 The QuickTime file format and architecture support an extensible set 61 of media types and compression schemes. Many of these are not covered 62 by the profile specifications available today. Hence, it is desirable 63 to have an RTP encapsulation scheme that will handle all QuickTime 64 media/codec types that are not covered by specific RTP payload types. 66 This specification proposes a scheme to carry QuickTime media/codec 67 types over RTP. The scheme specified here handles all loss-tolerant 68 media and a few loss-intolerant media such as text. Support for other 69 loss-intolerant media such as MIDI and 3D will be added in future. 70 This specification is intended for streaming stored QuickTime movies 71 as well as live QuickTime content. 73 2 QuickTime Overview 75 QuickTime consists of a software architecture for multimedia 76 authoring/playback and a movie file format to store multimedia 77 presentations. These two aspects of QuickTime are independent of each 78 other but are often combined when referring to QuickTime. It is 79 possible to playback/author movies in other file formats such as AVI, 80 AIFF, etc. using QuickTime software. Similarly it is possible to use 81 QuickTime files independent of the software, for example, streaming 82 movies over the Internet. The QuickTime movie file format is 83 specified in [6]. More information on the QuickTime software 84 architecture can be obtained from [7,8,9]. 86 For the purpose of this document we will mostly be concerned with 87 streaming QuickTime content using RTP. "QuickTime content" refers to 88 content as specified in the QuickTime movie file format specification 89 [6]. This does not preclude live QuickTime content. We merely use the 90 file format specification as way to specify the format of the 91 content. 93 QuickTime movie files contain the media data and synchronization 94 information for the movie. A movie consists of multiple tracks, each 95 of which contains a specific media type such as video, sound, MIDI, 96 text, etc. Not all media types are loss-tolerant. Table 2.1 lists the 97 common QuickTime media types and whether they are loss-tolerant. The 98 loss tolerant media can be carried over RTP/UDP in classic RTP-style. 99 This will not however work for loss-intolerant data. RTP over TCP or 100 using the Realtime Streaming Protocol (RTSP) [10] are some of the 101 options for loss-intolerant media data. Another option is to achieve 102 semi-reliability through redundant transmission. This specification 103 uses this latter option to handle QuickTime "text" media over RTP. 105 QuickTime Media TypeLoss Tolerant? 106 Sound Yes 107 Video Yes 108 Timecode No 109 Text No 110 Music (MIDI) No 111 MPEG Yes 112 Sprite No 113 Tween No 114 3D No 116 Table 2.1 QuickTime Media Types 118 QuickTime Timescales 120 QuickTime has a concept of timescales. A timescale defines the number 121 of units of time that pass in every second of real time. Any time 122 value has to be specified with respect to a timescale. A QuickTime 123 movie has a timescale associated with it. Each of the tracks (medias) 124 have a timescale associated with them. All of these timescales could 125 be different. The RTP timestamp will be based on the timescale of the 126 track associated with the RTP session. The timescale of a track never 127 changes during its lifetime. 129 QuickTime Sample Descriptions 131 Every QuickTime media type has a sample description format associated 132 with it. The sample description specifies how the sample is 133 interpreted. For example, the video media sample description 134 specifies the compression scheme, quality, bit depth and other such 135 information. The sample description may change during the life of a 136 track. 138 QuickTime Track Parameters 140 Every QuickTime track has a number of parameters associated with it 141 such as height, width, transformation matrix, etc. These are as 142 important to the presentation as the sample description. 144 3 RTP Encapsulation Format 146 The encapsulation scheme described here requires that each QuickTime 147 media track within a single movie be sent over a separate RTP session 148 and be synchronized using standard RTP techniques. 150 The QuickTime information is carried as payload data within the RTP 151 protocol. There is a variable length QuickTime header immediately 152 following the RTP header. The media data is packetized and placed in 153 the RTP packet following the QuickTime header. 155 The RTP packet is formatted as follows: 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 . . 161 . RTP Header . 162 . . 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 . QuickTime Header... . 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 . QuickTime Media Data... . 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 3.1 RTP Header 171 The format and general usage of the RTP header fields are described 172 in [1]. 174 The following fields of the RTP header will be used as specified 175 below: 177 - The payload type should specify the static QuickTime payload type 178 (if assigned) or one of the dynamic payload types. (The need for a 179 static payload type for QuickTime is up for discussion at the IETF 180 AVT working group.) If a dynamic payload type is used, it should be 181 agreed upon through some non-RTP means. 183 - The RTP timestamp is based on the timescale specified in the 184 QuickTime header. The timestamp encodes the sampling instant of the 185 first media sample contained in the RTP data packet. Multiple samples 186 may be contained in one RTP packet or a single sample may require 187 multiple RTP packets. The packetization rules are specified in a 188 subsequent section. If a media sample occupies more than one packet, 189 the timestamp will be the same on all of those packets. Packets 190 containing different samples must have different timestamps so that 191 samples may be distinguished by the timestamp. The initial value of 192 the timestamp is random (unpredictable) to make known-plaintext 193 attacks on encryption more difficult, see RTP [1]. 195 - The marker bit (M-bit) of the RTP header is set to one in the last 196 packet of a sample and otherwise, must be zero. If one or more 197 samples are fully contained within an RTP packet the M-bit must be 198 set to one. Thus, it is possible to easily detect that a complete 199 sample has been received and can be decoded and presented. 201 3.2 QuickTime Header 203 The QuickTime Header is defined as follows: 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | VER |Q|P|S| RES | QuickTime Payload ID | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 . QuickTime Payload Description ... . 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 The fields in the QuickTime Header have the following meanings: 215 VER: 4 bits 216 A version field that must be set to zero by transmitters implementing 217 this specification. 219 Q bit: 1 bit 220 The Q-bit is set to one if there is a payload description as part of 221 this QuickTime header. Otherwise it is set to zero. 223 P bit: 1 bit 224 The P-bit is set to one if there are multiple samples which are of 225 different sizes or durations carried in the payload. Otherwise it is 226 set to zero. When the P-bit is set, two or more samples are placed 227 in the QuickTime media data portion of the RTP packet along with 228 individual timestamp and length information. The format for this 229 packing is explained in a subsequent section. When the P-bit is not 230 set, one or more samples or a partial sample is placed directly in 231 the QuickTime media data portion of the RTP packet. 233 S bit: 1 bit 234 The S-bit is set to one if this packet contains data from a sync 235 sample, i.e. key sample. Otherwise it is set to zero. When the packet 236 contains more than one sample the S-bit is set to one if the first 237 sample is a sync sample. 239 RES: 8 bits 240 Reserved for future use. Transmitter must set these bits to zero. 241 Receivers must ignore these bits. 243 QuickTime Payload ID: 16 bits 244 A payload identifier that identifies the format of the QuickTime 245 media data carried in this RTP session. The payload ID associates the 246 QuickTime payload description (that is transmitted periodically) with 247 the QuickTime media data. This identifier is changed every time the 248 payload format changes. Payload IDs are explained further in a 249 subsequent section. 251 QuickTime Payload Description: variable length 252 This field is present only if the Q-bit is set to one. It contains 253 the QuickTime payload format description such as media type, 254 timescale, sample size, compression information, etc. The header must 255 be padded to a 32-bit boundary. 257 The QuickTime Payload Description is defined as follows: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 |A|C| RES | QuickTime Payload Desc Length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | QuickTime Media Type | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Timescale | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 . QuickTime TLVs ... . 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 The fields in the QuickTime Payload Description have the following 272 meanings: 274 A bit: 1 bit 275 The A-bit is set to one if all samples are sync (key) samples for 276 this payload description. Otherwise it is set to zero. 278 RES: 7 bits 279 Reserved for future use. Transmitter must set these bits to zero. 281 Receivers must ignore these bits. 283 QuickTime Payload Description Length: 16 bits 284 Number of bytes in the QuickTime payload description (not including 285 padding of 0 to 3 bytes). The QuickTime Media Data starts at the RTP 286 data offset plus the QuickTime fixed header of 4 bytes plus the 287 payload description length plus padding (of 0 to 3 bytes). 289 QuickTime Media Type: 32 bits 290 A 4 character media type that identifies the QuickTime media [6], 291 example: 'vide' for video, 'soun' for sound, etc. 293 Timescale: 32 bits 294 The number of units of time that pass in 1 second of real time for 295 this QuickTime payload ID. This is the timescale used by the RTP 296 timestamp for this session. 298 QuickTime TLVs: variable length 299 One or more QuickTime parameters that describes this payload. The 300 parameters are expressed as a Type-Length-Value triplet. The TLVs are 301 not padded and can begin at any byte boundary. 303 A QuickTime TLV is formatted as follows: 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | QuickTime TLV Length | QuickTime TLV Type | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 . QuickTime TLV Value ... . 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 The fields in a QuickTime TLV have the following meanings: 315 QuickTime TLV Length: 16 bits 316 Number of bytes in the QuickTime TLV. The next QuickTime TLV starts 317 at the offset of the current TLV plus the current TLV length. 319 QuickTime TLV Type: 16 bits 320 A 2 character TLV type that identifies the QuickTime parameter. 322 QuickTime TLV Value: variable length 323 The value of the TLV as specified by the type. Values must be sent in 324 network byte-order (i.e. big-endian format). 326 Note: Section 3.3 lists the set of currently defined TLVs. Some TLVs 327 are mandatory and must be present if the QuickTime Payload 328 Description is being sent. Other TLVs will assume their default 329 values if they are not sent. Any TLV not recognized by a receiver 330 must be ignored and skipped over. 332 3.3 QuickTime TLVs 334 Sample Description (mandatory) 335 Type: 'sd' 336 Length: variable length 337 Media-specific QuickTime sample description. The format for this TLV 338 for each of the currently defined media types can be found in [6] 339 (starting pg. 59). 340 Default: none 342 QuickTime Atom 343 Type: 'qt' 344 Length: variable 345 Default: none 346 This TLV is used to transparently send a QuickTime Atom as defined in 347 [6] (pg. 3). For example, this can be used to send User Data Atoms, 348 Track Reference Atoms, Track Input Map Atoms, etc. The QuickTime 349 atoms sent depends on the media type associated with the QuickTime 350 payload description. 352 Track ID 353 Type: 'ti' 354 Length: 8 355 Default: 0 356 Track ID as defined in [6] (pg. 18). 358 Layer 359 Type: 'ly' 360 Length: 6 361 Default: 0 362 Layer as defined in [6] (pg. 18). 364 Volume 365 Type: 'vo' 366 Length: 6 367 Default: 255 368 Volume as defined in [6] (pg. 18). 370 Matrix 371 Type: 'mx' 372 Length: 40 373 Default: identity matrix 374 Matrix as defined in [6] (pg. 18 and 77). 376 Translation Matrix 377 Type: 'tr' 378 Length: 8 379 Default: identity matrix 380 h, v -- two 16-bit signed numbers indicating translation values (in 381 pixels).This TLV is sent instead of the Matrix TLV when only 382 translation is required. 384 Track Width 385 Type: 'tw' 386 Length: 8 387 Default: 0 388 Track Width as defined in [6] (pg. 19). 390 Track Height 391 Type: 'th' 392 Length: 8 393 Default: 0 394 Track Height as defined in [6] (pg. 19) 396 Language 397 Type: 'la' 398 Length: 6 399 Default: 0 400 Language as defined in [6] (pg. 32 and 75). 402 3.4 Media Data Packetization 404 The RTP packetization for QuickTime is designed to take into account 405 the needs of a varied set of media types and compression schemes. 406 Hence, 3 different packetization schemes are defined. 408 The following pieces of information are required at the transmission 409 end to make packetization decisions: 411 - Maximum QuickTime Media Data size (MQD) that can be accommodated 412 in a single RTP packet. 413 - Whether all samples for this media type are of constant size? (CQS) 414 - Whether all samples for this media type are of constant duration? 415 (CQD) 416 - Sample size of all samples (when they are constant) (CSS). 417 - Sample size of a specific sample (SS). 419 Based on the above pieces of information, one of the following 420 packetization schemes is adopted: 422 Scheme I : (CQS=true) AND (CQD=true) AND (CSS <= 0.5*MQD) 424 Multiple samples are packed into one RTP packet. The RTP header M-bit 425 is set to one on all packets. The QuickTime header P-bit is set to 426 zero on all packets. 428 Scheme II: ( (CQS=false) OR (CQD=false) ) AND (SS <= 0.5*MQD) 430 Multiple samples are packed into the QuickTime Media Data portion of 431 an RTP packet. The RTP header M-bit is set to one in this packet. The 432 QuickTime header P-bit is set to one. 434 The samples are packed using the format illustrated below: 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Sample Length | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Sample Timestamp | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 . Sample Data ... . 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Sample Length | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Sample Timestamp | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 . Sample Data ... . 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 . ...... . 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 The fields in the QuickTime Media Data have the following meanings: 456 Sample Length: 32 bits 457 Number of bytes in the sample data (not including the length field, 458 timestamp field and padding). 460 Sample Timestamp: 32 bits 461 This field contains the timestamp for this sample in the timescale 462 associated with this QuickTime payload ID. The first timestamp must 463 be the same as the timestamp in the RTP header. 465 Sample Data: variable length 466 This field contains the sample data. The data must be padded to a 467 32-bit boundary. 469 All receivers are required to handle this scheme. A transmitter may 470 choose to not implement this scheme in which case it will default to 471 scheme III. 473 Note: This scheme leads to more efficient packing than scheme III for 474 certain media/codec types. However, there is a trade-off between 475 efficiency and losing multiple samples when a packet is lost. 477 Scheme III: Cases not covered by schemes I and II 479 A single sample is placed in one or more RTP packets. The RTP header 480 M-bit is set to one in the last packet and is otherwise set to zero. 481 The QuickTime header P-bit is set to zero in every packet. 483 The packetization boundaries may be chosen intelligently to respect 484 the compression/decompression algorithm requirements. However, this 485 is not a requirement. When intelligent boundaries are not chosen, a 486 single packet loss will lead to the entire sample being lost in the 487 case of multi-packet samples. 489 3.5 Payload Information 491 Payload ID 493 The QuickTime payload ID identifies the format of the QuickTime media 494 data carried in an RTP session. It associates the QuickTime payload 495 description (that is transmitted periodically) with the QuickTime 496 media data. This identifier is an arbitrary 16-bit number that is 497 changed every time the payload format changes. When streaming 498 QuickTime movie tracks, the payload format changes usually when the 499 sample description changes during the life of the track. 501 The following restrictions apply when picking payload IDs, 503 - The payload ID must be unique among all QuickTime RTP sessions 504 originating from a given source canonical name. This is to ensure 505 efficient mapping of payload IDs to payload descriptions using a 506 single receiver-side table per canonical name. 508 - A payload ID must not be reused for a different payload description 509 during the lifetime of the session. This allows receivers to cache 510 the payload descriptions for the duration of the session. 512 Payload Description 514 The QuickTime payload descriptions are transmitted as part of the 515 QuickTime header. The payload descriptions specify the format of the 516 QuickTime media data. The information for the specific fields in a 517 payload description can be found in [6]. These fields do not include 518 all of the information associated with a QuickTime track. For 519 example, information on transformation matrices, layers, etc. is not 520 included. This information needs to be communicated through non-RTP 521 means. 523 Payload Description Transmission 525 The payload description must be transmitted in the first RTP packet 526 which contains media samples that require the payload description. 527 After the first packet, the payload description must be retransmitted 528 at a periodic interval until the format of the media samples changes. 529 The maximum retransmission interval should be 1 second, unless 530 packets are being transmitted at less than 1 packet/second in which 531 case the payload description must be transmitted with each packet. 533 The retransmission interval may be negotiated to an arbitrary value 534 through non-RTP means. Note: This includes the case in which the 535 payload descriptions are never sent over RTP, i.e. a retransmission 536 interval of infinity. In this case the payload descriptions are 537 communicated through some non-RTP means. 539 A transmitter may send an RTP packet that contains only a payload 540 description and no QuickTime media data. This payload description 541 must be cached by the receiver and used to interpret data that may 542 arrive in the future. 544 3.6 Loss-intolerant Media Types 546 Loss-intolerant media types can not be easily handled within the 547 standard RTP framework. Hence, we may need to use some non-RTP 548 techniques to transmit these media types. However, some of the media 549 types, notably Text and Tween media can be sent over RTP by the use 550 of redundant transmissions. (Tween media is used to alter the 551 characteristics of other media streams. For example, Tween samples 552 may contain a series of values that change the volume of an audio 553 stream.) The use of this technique is experimental. 555 Redundant Transmissions 557 The redundant transmission technique is one in which the RTP packet 558 is retransmitted multiple times within the duration of the sample. 559 The RTP packet is resent as a whole with the same RTP sequence 560 number, timestamp and other information, i.e. it is an identical 561 packet when seen on the wire. This technique is not bandwidth 562 friendly when used with high bandwidth media types. Hence it will be 563 used only with the low bandwidth media types such as "text" and 564 "tween" media. 566 The rationale for using the same RTP sequence numbers in the 567 retransmitted packets is as follows: If the sequence numbers were 568 incremented for each of the retransmitted packets we would require an 569 additional field to identify the duplicate samples. In the proposed 570 scheme, the receiver can discard duplicates by simply keeping track 571 of the sequence numbers of the packets received. 573 The interval between retransmissions depends on the media type and 574 the current congestion situation in the network. This interval can be 575 a simple fixed interval, say 4 retransmissions equally spaced within 576 the duration of the sample, or it could be more complex, say 577 exponentially increasing intervals within the duration of the sample. 578 This specification does not currently recommend a preferred scheme to 579 use for determining the retransmission interval. 581 4 Open Issues 583 The following open issues need to be resolved: 585 - How to handle loss-intolerant media with "key" and "update" 586 samples? 587 Loss-intolerant media samples can be retransmitted multiple times 588 with fixed or variable intervals between transmission. The samples 589 can be classified as key samples and update samples and handled 590 appropriately. Update samples need not be periodically retransmitted. 591 For example, in sprite media, key samples will contain the sprite 592 image and update samples will contain the motion vectors. Whereas, in 593 text media, all samples will be key samples. 595 - What is the appropriate interval between redundant 596 transmissions for "text" and "tween" media samples? 598 - Should there be sample size TLV (that specifies bits per 599 sample)? 601 Acknowledgments 603 The authors would like to thank Joe Pallas (of Apple ATG) and all the 604 members of the QuickTime Streaming team, Jay Geagan, Andy Grignon, 605 Sylvain Rouze and Kevin Gong for their valuable input in writing this 606 proposal. 608 References 610 [1] H. Schulzrinne, et. al., "RTP : A Transport Protocol for Real- 611 Time Applications", IETF RFC 1889, January 1996. 613 [2] H. Schulzrinne, et. al., "RTP Profile for Audio and Video 614 Conference with Minimal Control", IETF RFC 1890, January 1996. 616 [3] L. Berc, et. al., "RTP Payload Format for JPEG-compressed Video", 617 IETF RFC 2035, October 1996. 619 [4] D. Hoffman, et. al., "RTP Payload Format for MPEG1/MPEG2 Video", 620 IETF RFC 2038, October 1996. 622 [5] T. Turletti, C. Huitema, "RTP Payload Format for H.261 Video 623 Streams", IETF RFC 2032, October 1996. 625 [6] Apple Computer, Inc., "QuickTime File Format Specification", May 626 1996. 628 [7] Apple Computer, Inc., "Inside Macintosh: QuickTime", Addison 629 Wesley Press. 631 [8] Apple Computer, Inc., "Inside Macintosh: QuickTime Components", 632 Addison Wesley Press. 634 [9] Apple Computer, Inc., "QuickTime 2.5 Developer Guide", Developer 635 Press. 637 [10] H. Schulzrinne, et. al., "Real Time Streaming Protocol", IETF 638 Draft ietf-mmusic-rtsp-02.txt, March 24 1994, Expires: August 20 639 1997. 641 Authors' Contact Information 642 Alagu Periyannan 643 Email: alagu@apple.com 644 Tel: (408) 862 5387 645 Fax: (408) 974 0234 647 Anne Jones 648 Email: astoria@apple.com 649 Tel: (408) 862 1170 651 David Singer 652 Email: singer@apple.com 653 Tel: (408) 974 3162 654 Apple Computer, Inc. 655 One Infinite Loop, MS:302-3MT 656 Cupertino CA 95014 657 USA