Internet Engineering Task Force Audio-Video Transport WG INTERNET-DRAFT A. Jones, A. Periyannan, D. Singer draft-ietf-avt-qt-rtp-00 Apple Computer, Inc. July 22, 1997 Expires: January 22, 1998 RTP Payload Format for QuickTime Media Streams Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This document specifies the payload format for encapsulating QuickTime media streams in the Realtime Transport Protocol (RTP). This specification is intended for QuickTime media/codec types that are not already handled by other RTP payload specifications. Each QuickTime media track within a movie is sent over a separate RTP session and synchronized using standard RTP techniques. A static QuickTime payload type (if assigned) or a dynamic payload type may be used. A QuickTime header within the RTP payload is defined to carry the media type and other media specific information. A packetization scheme is defined for the media data. This specification is intended for streaming stored QuickTime movies as well as live QuickTime content. 1 Introduction This document specifies the payload format for encapsulating A. Jones, A. Periyannan, D. Singer [Page 1] Internet Draft draft-ietf-avt-qt-rtp-00 July 22 1997 QuickTime media streams in the Realtime Transport Protocol (RTP) [1]. RTP is a generic protocol designed to carry realtime media data along with synchronization information over a datagram protocol (mostly UDP over IP). The protocol itself does not address the encapsulation of specific media types, but instead leaves it to various profile specifications. An accompanying RTP profile document [2] contains various payload specifications to carry audio and video over RTP for conferencing applications and specifies the static payload types for various audio/video compression schemes. Other documents specify the encapsulation format used to carry specific compression schemes such as JPEG, MPEG and H.261 [3,4,5]. The QuickTime file format and architecture support an extensible set of media types and compression schemes. Many of these are not covered by the profile specifications available today. Hence, it is desirable to have an RTP encapsulation scheme that will handle all QuickTime media/codec types that are not covered by specific RTP payload types. This specification proposes a scheme to carry QuickTime media/codec types over RTP. The scheme specified here handles all loss-tolerant media and a few loss-intolerant media such as text. Support for other loss-intolerant media such as MIDI and 3D will be added in future. This specification is intended for streaming stored QuickTime movies as well as live QuickTime content. 2 QuickTime Overview QuickTime consists of a software architecture for multimedia authoring/playback and a movie file format to store multimedia presentations. These two aspects of QuickTime are independent of each other but are often combined when referring to QuickTime. It is possible to playback/author movies in other file formats such as AVI, AIFF, etc. using QuickTime software. Similarly it is possible to use QuickTime files independent of the software, for example, streaming movies over the Internet. The QuickTime movie file format is specified in [6]. More information on the QuickTime software architecture can be obtained from [7,8,9]. For the purpose of this document we will mostly be concerned with streaming QuickTime content using RTP. "QuickTime content" refers to content as specified in the QuickTime movie file format specification [6]. This does not preclude live QuickTime content. We merely use the file format specification as way to specify the format of the content. QuickTime movie files contain the media data and synchronization information for the movie. A movie consists of multiple tracks, each of which contains a specific media type such as video, sound, MIDI, A. Jones, A. Periyannan, D. Singer [Page 2] Internet Draft draft-ietf-avt-qt-rtp-00 July 22 1997 text, etc. Not all media types are loss-tolerant. Table 2.1 lists the common QuickTime media types and whether they are loss-tolerant. The loss tolerant media can be carried over RTP/UDP in classic RTP-style. This will not however work for loss-intolerant data. RTP over TCP or using the Realtime Streaming Protocol (RTSP) [10] are some of the options for loss-intolerant media data. Another option is to achieve semi-reliability through redundant transmission. This specification uses this latter option to handle QuickTime "text" media over RTP. QuickTime Media TypeLoss Tolerant? Sound Yes Video Yes Timecode No Text No Music (MIDI) No MPEG Yes Sprite No Tween No 3D No Table 2.1 QuickTime Media Types QuickTime Timescales QuickTime has a concept of timescales. A timescale defines the number of units of time that pass in every second of real time. Any time value has to be specified with respect to a timescale. A QuickTime movie has a timescale associated with it. Each of the tracks (medias) have a timescale associated with them. All of these timescales could be different. The RTP timestamp will be based on the timescale of the track associated with the RTP session. The timescale of a track never changes during its lifetime. QuickTime Sample Descriptions Every QuickTime media type has a sample description format associated with it. The sample description specifies how the sample is interpreted. For example, the video media sample description specifies the compression scheme, quality, bit depth and other such information. The sample description may change during the life of a track. QuickTime Track Parameters Every QuickTime track has a number of parameters associated with it such as height, width, transformation matrix, etc. These are as important to the presentation as the sample description. A. Jones, A. Periyannan, D. Singer [Page 3] Internet Draft draft-ietf-avt-qt-rtp-00 July 22 1997 3 RTP Encapsulation Format The encapsulation scheme described here requires that each QuickTime media track within a single movie be sent over a separate RTP session and be synchronized using standard RTP techniques. The QuickTime information is carried as payload data within the RTP protocol. There is a variable length QuickTime header immediately following the RTP header. The media data is packetized and placed in the RTP packet following the QuickTime header. The RTP packet is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . RTP Header . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . QuickTime Header... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . QuickTime Media Data... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1 RTP Header The format and general usage of the RTP header fields are described in [1]. The following fields of the RTP header will be used as specified below: - The payload type should specify the static QuickTime payload type (if assigned) or one of the dynamic payload types. (The need for a static payload type for QuickTime is up for discussion at the IETF AVT working group.) If a dynamic payload type is used, it should be agreed upon through some non-RTP means. - The RTP timestamp is based on the timescale specified in the QuickTime header. The timestamp encodes the sampling instant of the first media sample contained in the RTP data packet. Multiple samples may be contained in one RTP packet or a single sample may require multiple RTP packets. The packetization rules are specified in a subsequent section. If a media sample occupies more than one packet, the timestamp will be the same on all of those packets. Packets A. Jones, A. Periyannan, D. Singer [Page 4] Internet Draft draft-ietf-avt-qt-rtp-00 July 22 1997 containing different samples must have different timestamps so that samples may be distinguished by the timestamp. The initial value of the timestamp is random (unpredictable) to make known-plaintext attacks on encryption more difficult, see RTP [1]. - The marker bit (M-bit) of the RTP header is set to one in the last packet of a sample and otherwise, must be zero. If one or more samples are fully contained within an RTP packet the M-bit must be set to one. Thus, it is possible to easily detect that a complete sample has been received and can be decoded and presented. 3.2 QuickTime Header The QuickTime Header is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VER |Q|P|S| RES | QuickTime Payload ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . QuickTime Payload Description ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in the QuickTime Header have the following meanings: VER: 4 bits A version field that must be set to zero by transmitters implementing this specification. Q bit: 1 bit The Q-bit is set to one if there is a payload description as part of this QuickTime header. Otherwise it is set to zero. P bit: 1 bit The P-bit is set to one if there are multiple samples which are of different sizes or durations carried in the payload. Otherwise it is set to zero. When the P-bit is set, two or more samples are placed in the QuickTime media data portion of the RTP packet along with individual timestamp and length information. The format for this packing is explained in a subsequent section. When the P-bit is not set, one or more samples or a partial sample is placed directly in the QuickTime media data portion of the RTP packet. S bit: 1 bit The S-bit is set to one if this packet contains data from a sync A. Jones, A. Periyannan, D. Singer [Page 5] Internet Draft draft-ietf-avt-qt-rtp-00 July 22 1997 sample, i.e. key sample. Otherwise it is set to zero. When the packet contains more than one sample the S-bit is set to one if the first sample is a sync sample. RES: 8 bits Reserved for future use. Transmitter must set these bits to zero. Receivers must ignore these bits. QuickTime Payload ID: 16 bits A payload identifier that identifies the format of the QuickTime media data carried in this RTP session. The payload ID associates the QuickTime payload description (that is transmitted periodically) with the QuickTime media data. This identifier is changed every time the payload format changes. Payload IDs are explained further in a subsequent section. QuickTime Payload Description: variable length This field is present only if the Q-bit is set to one. It contains the QuickTime payload format description such as media type, timescale, sample size, compression information, etc. The header must be padded to a 32-bit boundary. The QuickTime Payload Description is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|C| RES | QuickTime Payload Desc Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QuickTime Media Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timescale | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . QuickTime TLVs ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in the QuickTime Payload Description have the following meanings: A bit: 1 bit The A-bit is set to one if all samples are sync (key) samples for this payload description. Otherwise it is set to zero. RES: 7 bits Reserved for future use. Transmitter must set these bits to zero. A. Jones, A. Periyannan, D. Singer [Page 6] Internet Draft draft-ietf-avt-qt-rtp-00 July 22 1997 Receivers must ignore these bits. QuickTime Payload Description Length: 16 bits Number of bytes in the QuickTime payload description (not including padding of 0 to 3 bytes). The QuickTime Media Data starts at the RTP data offset plus the QuickTime fixed header of 4 bytes plus the payload description length plus padding (of 0 to 3 bytes). QuickTime Media Type: 32 bits A 4 character media type that identifies the QuickTime media [6], example: 'vide' for video, 'soun' for sound, etc. Timescale: 32 bits The number of units of time that pass in 1 second of real time for this QuickTime payload ID. This is the timescale used by the RTP timestamp for this session. QuickTime TLVs: variable length One or more QuickTime parameters that describes this payload. The parameters are expressed as a Type-Length-Value triplet. The TLVs are not padded and can begin at any byte boundary. A QuickTime TLV is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QuickTime TLV Length | QuickTime TLV Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . QuickTime TLV Value ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in a QuickTime TLV have the following meanings: QuickTime TLV Length: 16 bits Number of bytes in the QuickTime TLV. The next QuickTime TLV starts at the offset of the current TLV plus the current TLV length. QuickTime TLV Type: 16 bits A 2 character TLV type that identifies the QuickTime parameter. QuickTime TLV Value: variable length The value of the TLV as specified by the type. Values must be sent in network byte-order (i.e. big-endian format). Note: Section 3.3 lists the set of currently defined TLVs. Some TLVs A. Jones, A. Periyannan, D. Singer [Page 7] Internet Draft draft-ietf-avt-qt-rtp-00 July 22 1997 are mandatory and must be present if the QuickTime Payload Description is being sent. Other TLVs will assume their default values if they are not sent. Any TLV not recognized by a receiver must be ignored and skipped over. 3.3 QuickTime TLVs Sample Description (mandatory) Type: 'sd' Length: variable length Media-specific QuickTime sample description. The format for this TLV for each of the currently defined media types can be found in [6] (starting pg. 59). Default: none QuickTime Atom Type: 'qt' Length: variable Default: none This TLV is used to transparently send a QuickTime Atom as defined in [6] (pg. 3). For example, this can be used to send User Data Atoms, Track Reference Atoms, Track Input Map Atoms, etc. The QuickTime atoms sent depends on the media type associated with the QuickTime payload description. Track ID Type: 'ti' Length: 8 Default: 0 Track ID as defined in [6] (pg. 18). Layer Type: 'ly' Length: 6 Default: 0 Layer as defined in [6] (pg. 18). Volume Type: 'vo' Length: 6 Default: 255 Volume as defined in [6] (pg. 18). Matrix Type: 'mx' Length: 40 Default: identity matrix A. Jones, A. Periyannan, D. Singer [Page 8] Internet Draft draft-ietf-avt-qt-rtp-00 July 22 1997 Matrix as defined in [6] (pg. 18 and 77). Translation Matrix Type: 'tr' Length: 8 Default: identity matrix h, v -- two 16-bit signed numbers indicating translation values (in pixels).This TLV is sent instead of the Matrix TLV when only translation is required. Track Width Type: 'tw' Length: 8 Default: 0 Track Width as defined in [6] (pg. 19). Track Height Type: 'th' Length: 8 Default: 0 Track Height as defined in [6] (pg. 19) Language Type: 'la' Length: 6 Default: 0 Language as defined in [6] (pg. 32 and 75). 3.4 Media Data Packetization The RTP packetization for QuickTime is designed to take into account the needs of a varied set of media types and compression schemes. Hence, 3 different packetization schemes are defined. The following pieces of information are required at the transmission end to make packetization decisions: - Maximum QuickTime Media Data size (MQD) that can be accommodated in a single RTP packet. - Whether all samples for this media type are of constant size? (CQS) - Whether all samples for this media type are of constant duration? (CQD) - Sample size of all samples (when they are constant) (CSS). - Sample size of a specific sample (SS). Based on the above pieces of information, one of the following packetization schemes is adopted: A. Jones, A. Periyannan, D. Singer [Page 9] Internet Draft draft-ietf-avt-qt-rtp-00 July 22 1997 Scheme I : (CQS=true) AND (CQD=true) AND (CSS <= 0.5*MQD) Multiple samples are packed into one RTP packet. The RTP header M-bit is set to one on all packets. The QuickTime header P-bit is set to zero on all packets. Scheme II: ( (CQS=false) OR (CQD=false) ) AND (SS <= 0.5*MQD) Multiple samples are packed into the QuickTime Media Data portion of an RTP packet. The RTP header M-bit is set to one in this packet. The QuickTime header P-bit is set to one. The samples are packed using the format illustrated below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sample Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sample Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Sample Data ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sample Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sample Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Sample Data ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . ...... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in the QuickTime Media Data have the following meanings: Sample Length: 32 bits Number of bytes in the sample data (not including the length field, timestamp field and padding). Sample Timestamp: 32 bits This field contains the timestamp for this sample in the timescale associated with this QuickTime payload ID. The first timestamp must be the same as the timestamp in the RTP header. Sample Data: variable length This field contains the sample data. The data must be padded to a A. Jones, A. Periyannan, D. Singer [Page 10] Internet Draft draft-ietf-avt-qt-rtp-00 July 22 1997 32-bit boundary. All receivers are required to handle this scheme. A transmitter may choose to not implement this scheme in which case it will default to scheme III. Note: This scheme leads to more efficient packing than scheme III for certain media/codec types. However, there is a trade-off between efficiency and losing multiple samples when a packet is lost. Scheme III: Cases not covered by schemes I and II A single sample is placed in one or more RTP packets. The RTP header M-bit is set to one in the last packet and is otherwise set to zero. The QuickTime header P-bit is set to zero in every packet. The packetization boundaries may be chosen intelligently to respect the compression/decompression algorithm requirements. However, this is not a requirement. When intelligent boundaries are not chosen, a single packet loss will lead to the entire sample being lost in the case of multi-packet samples. 3.5 Payload Information Payload ID The QuickTime payload ID identifies the format of the QuickTime media data carried in an RTP session. It associates the QuickTime payload description (that is transmitted periodically) with the QuickTime media data. This identifier is an arbitrary 16-bit number that is changed every time the payload format changes. When streaming QuickTime movie tracks, the payload format changes usually when the sample description changes during the life of the track. The following restrictions apply when picking payload IDs, - The payload ID must be unique among all QuickTime RTP sessions originating from a given source canonical name. This is to ensure efficient mapping of payload IDs to payload descriptions using a single receiver-side table per canonical name. - A payload ID must not be reused for a different payload description during the lifetime of the session. This allows receivers to cache the payload descriptions for the duration of the session. Payload Description The QuickTime payload descriptions are transmitted as part of the A. Jones, A. Periyannan, D. Singer [Page 11] Internet Draft draft-ietf-avt-qt-rtp-00 July 22 1997 QuickTime header. The payload descriptions specify the format of the QuickTime media data. The information for the specific fields in a payload description can be found in [6]. These fields do not include all of the information associated with a QuickTime track. For example, information on transformation matrices, layers, etc. is not included. This information needs to be communicated through non-RTP means. Payload Description Transmission The payload description must be transmitted in the first RTP packet which contains media samples that require the payload description. After the first packet, the payload description must be retransmitted at a periodic interval until the format of the media samples changes. The maximum retransmission interval should be 1 second, unless packets are being transmitted at less than 1 packet/second in which case the payload description must be transmitted with each packet. The retransmission interval may be negotiated to an arbitrary value through non-RTP means. Note: This includes the case in which the payload descriptions are never sent over RTP, i.e. a retransmission interval of infinity. In this case the payload descriptions are communicated through some non-RTP means. A transmitter may send an RTP packet that contains only a payload description and no QuickTime media data. This payload description must be cached by the receiver and used to interpret data that may arrive in the future. 3.6 Loss-intolerant Media Types Loss-intolerant media types can not be easily handled within the standard RTP framework. Hence, we may need to use some non-RTP techniques to transmit these media types. However, some of the media types, notably Text and Tween media can be sent over RTP by the use of redundant transmissions. (Tween media is used to alter the characteristics of other media streams. For example, Tween samples may contain a series of values that change the volume of an audio stream.) The use of this technique is experimental. Redundant Transmissions The redundant transmission technique is one in which the RTP packet is retransmitted multiple times within the duration of the sample. The RTP packet is resent as a whole with the same RTP sequence number, timestamp and other information, i.e. it is an identical packet when seen on the wire. This technique is not bandwidth friendly when used with high bandwidth media types. Hence it will be A. Jones, A. Periyannan, D. Singer [Page 12] Internet Draft draft-ietf-avt-qt-rtp-00 July 22 1997 used only with the low bandwidth media types such as "text" and "tween" media. The rationale for using the same RTP sequence numbers in the retransmitted packets is as follows: If the sequence numbers were incremented for each of the retransmitted packets we would require an additional field to identify the duplicate samples. In the proposed scheme, the receiver can discard duplicates by simply keeping track of the sequence numbers of the packets received. The interval between retransmissions depends on the media type and the current congestion situation in the network. This interval can be a simple fixed interval, say 4 retransmissions equally spaced within the duration of the sample, or it could be more complex, say exponentially increasing intervals within the duration of the sample. This specification does not currently recommend a preferred scheme to use for determining the retransmission interval. 4 Open Issues The following open issues need to be resolved: - How to handle loss-intolerant media with "key" and "update" samples? Loss-intolerant media samples can be retransmitted multiple times with fixed or variable intervals between transmission. The samples can be classified as key samples and update samples and handled appropriately. Update samples need not be periodically retransmitted. For example, in sprite media, key samples will contain the sprite image and update samples will contain the motion vectors. Whereas, in text media, all samples will be key samples. - What is the appropriate interval between redundant transmissions for "text" and "tween" media samples? - Should there be sample size TLV (that specifies bits per sample)? Acknowledgments The authors would like to thank Joe Pallas (of Apple ATG) and all the members of the QuickTime Streaming team, Jay Geagan, Andy Grignon, Sylvain Rouze and Kevin Gong for their valuable input in writing this proposal. A. Jones, A. Periyannan, D. Singer [Page 13] Internet Draft draft-ietf-avt-qt-rtp-00 July 22 1997 References [1] H. Schulzrinne, et. al., "RTP : A Transport Protocol for Real- Time Applications", IETF RFC 1889, January 1996. [2] H. Schulzrinne, et. al., "RTP Profile for Audio and Video Conference with Minimal Control", IETF RFC 1890, January 1996. [3] L. Berc, et. al., "RTP Payload Format for JPEG-compressed Video", IETF RFC 2035, October 1996. [4] D. Hoffman, et. al., "RTP Payload Format for MPEG1/MPEG2 Video", IETF RFC 2038, October 1996. [5] T. Turletti, C. Huitema, "RTP Payload Format for H.261 Video Streams", IETF RFC 2032, October 1996. [6] Apple Computer, Inc., "QuickTime File Format Specification", May 1996. [7] Apple Computer, Inc., "Inside Macintosh: QuickTime", Addison Wesley Press. [8] Apple Computer, Inc., "Inside Macintosh: QuickTime Components", Addison Wesley Press. [9] Apple Computer, Inc., "QuickTime 2.5 Developer Guide", Developer Press. [10] H. Schulzrinne, et. al., "Real Time Streaming Protocol", IETF Draft ietf-mmusic-rtsp-02.txt, March 24 1994, Expires: August 20 1997. Authors' Contact Information Alagu Periyannan Email: alagu@apple.com Tel: (408) 862 5387 Fax: (408) 974 0234 Anne Jones Email: astoria@apple.com Tel: (408) 862 1170 David Singer Email: singer@apple.com Tel: (408) 974 3162 A. Jones, A. Periyannan, D. Singer [Page 14] Internet Draft draft-ietf-avt-qt-rtp-00 July 22 1997 Apple Computer, Inc. One Infinite Loop, MS:302-3MT Cupertino CA 95014 USA A. Jones, A. Periyannan, D. Singer [Page 15]