Internet Engineering Task Force Internet Draft Herpel-Thomson/Balabanian-Nortel ietf-avt-rtp-mpeg4-00.txt Basso-AT&T/Civanlar-AT&T/Hoffman-Sun March 09, 1998 Speer-Sun/Schulzrinne-Columbia U. Expires: September 09, 1998 RTP payload format for MPEG-4 Elementary 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 made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them otherthan 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 memorandum describes a scheme to encapsulate MPEG-4 Elementary Streams into RTP packets. Two approaches are described. The first allows to map one MPEG-4 Elementary Stream to one RTP session, for maximum compatibility to the design principles of RTP. The second responds to the observation that MPEG-4 applications may well consist of such a large number of streams that the encapsulation of a bundle of Elementary Streams in one RTP session is required. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. 1 Introduction MPEG-4 is a recent standard from ISO/IEC for the coding of natural and synthetic audio-visual data in the form of audiovisual objects that are arranged into an audiovisual scene by means of a scene description [1][2][3][4]. This memorandum specifies how MPEG-4 encoded data streams are mapped into the real-time transport protocol (RTP)[5]. ietf-avt-rtp-mpeg4-00.txt [Page 1] INTERNET-DRAFT - 2 - March 13th, 1998 This would allow the use of RTP tools to monitor MPEG-4 delivery performance, the use of RTP mixers to combine MPEG-4 streams received from multiple end-systems into a set of consolidated streams for multicasting and the use of RTP translators. 1.1 Overview of MPEG-4 End-System Architecture Figure 1 below shows the general architecture of MPEG-4 terminals. The Compression Layer processes individual audio-visual media streams without regard to delivery technologies. The compression schemes in MPEG-4 achieve efficient encoding over a wide range from Kbps to multiple Mbps. The MPEG-4 compression schemes are defined in the ISO/IEC specifications 14496-2 and 14496-3 [2][3]. The media content at this layer is organized in Elementary Streams. The MPEG-4 Systems specification, ISO/IEC 14496-1 [1], defines the concepts needed to describe the relations between Elementary Streams in a way that allows to create distributed, yet integrated, content presentations and to synchronize the streams. This part of the specification is both media unaware and delivery technology unaware. The hierarchical relations, location and properties of Elementary Streams of a presentation are described by a dynamic set of Object Descriptors (ODs). Each Object Descriptor groups one or more Elementary Stream Descriptors that all refer to a single content item (media object). Hence, multiple alternative or hierarchical representations of each content item can be indicated. Object Descriptors are themselves conveyed through one or more Elementary Streams. A complete set of ODs can be seen as an MPEG-4 resource or session description at a stream level. The resource description may itself be hierarchical, accomplished by creating more than one Elementary Stream conveying Object Descriptors. The session description is accompanied by a dynamic scene description (Binary Format for Scene, BIFS), again conveyed through one or more Elementary Streams. At this level, content is identified in terms of media objects. The spatiotemporal location of each object is defined by BIFS. The media content of the object, if synthetic and static, will also be described by BIFS, while natural and animated synthetic objects may refer to an Object Descriptor that points to one or more Elementary Streams that carry the coded representation of the object or its animation data. By conveying the session (or resource) description as well as the scene (or content composition) description through their own Elementary Streams it is made possible to change portions of the content composition and the number and properties of media streams that carry the media content separately and dynamically at well known instants in time. A homogeneous encapsulation of Elementary Streams carrying media or control ietf-avt-rtp-mpeg4-00.txt [Page 2] INTERNET-DRAFT - 3 - March 13th, 1998 (ODs, BIFS) data is defined by the Access Unit (AU) Layer that primarily serves to convey the synchronization between streams. The AU Layer organizes the Elementary Streams in Access Units, the smallest elements that can be attributed individual timestamps. Integer or fractional AUs are then encapsulated in AU Layer PDUs (AL-PDU). All consecutive data of one stream at this layer is called an AL-packetized Elementary Stream. The interface between the compression layer and the AU Layer is called Elementary Stream Interface (ESI). The ESI is informative. The Delivery Layer in MPEG-4 consists of the Delivery Multimedia Integration Framework defined in ISO/IEC 14496-6 [4]. This layer is media unaware but delivery technology aware. It provides transparent access to and delivery of content irrespective of the technologies used. The interface between the AU Layer and DMIF is called DMIF Application Interface (DAI). It offers content location independent procedures for establishing MPEG-4 sessions and access to transport channels. media aware +-----------------------------------------+ delivery unaware | COMPRESSION LAYER | 14496-2 Visual |streams from as low as Kbps to multi-Mbps| 14496-3 Audio +-----------------------------------------+ Elementary Stream ================================================================Interface (ESI) +-------------------------------------------+ media and | SYSTEMS LAYER | delivery unaware | manages elementary streams, their synch- | 14496-1 Systems | ronization and hierarchical relations | +-------------------------------------------+ DMIF Application ================================================================Interface (DAI) +-------------------------------------------+ delivery aware | DELIVERY LAYER | media unaware |provides transparent access to and delivery| 14496-6 DMIF | of content irrespective of delivery | | technology | +-------------------------------------------+ Figure 1: General MPEG-4 terminal architecture 1.2 MPEG-4 Elementary Stream Data Packetization Figure 2 below shows the MPEG-4 System data plane. For ease of explanation the encoding side is described next. The Elementary Streams from encoders are fed into the Access Unit Layer with indications of AU boundaries, Random Access Points, Desired Composition Time and the current time. ietf-avt-rtp-mpeg4-00.txt [Page 3] INTERNET-DRAFT - 4 - March 13th, 1998 The Access Unit Layer fragments the elementary streams into AL-PDUs each containing a header which encodes information conveyed through the ESI. If the AU is larger than a AL-PDU fragment then a subsequent PDU is generated with a smaller header until the complete AU is packetized into AL-PDU fragments. The syntax of the Access Unit Layer is not fixed but can be adapted to the needs of the stream to be transported. This includes the possibility to select presence or absence of individual syntax elements as well as configuration of their length in bits. The configuration for each individual stream is conveyed in an ALConfigDescriptor which is an integral part of the Elementary Stream Descriptor for this stream. The AL-packetized streams having the same priority and transport QoS requirements (as indicated through the DAI interface signaling) may then optionally be multi-plexed in FlexMux Streams in order to fill out the bandwidth on the network and reduce latency for each stream. Finally, as figure 2 shows, the AL-packetized stream or the FlexMux stream is passed on to any transport layer, generically called TransMux. E N C O D E R S and D E C O D E R S (elementary streams) ^ ^ ^ ^ ^ ^ ^ ~~|~~~~|~~~~|~~~~~~~~|~~~~|~~~~~~~~|~~~~~~~~~|~~~~~~~~ESI~~~ v v v v v v v +---++---++---+ +---++---+ +---+ +---+ Access Unit |ISO/IEC |AL ||AL ||AL | |AL ||AL | |AL | |AL | Layer |14496-1 +---++---++---+ +---++---+ +---+ +---+ |MPEG-4 ^ ^ ^ ^ ^ ^ ^ |Systems | | | | | | | / ===|====|====|========|====|========|=========|==================DAI= v v v v v v | +---------------+ +---------+ +-------+ |_______________|_ AL-packetized | FlexMux | | FlexMux | |FlexMux| | | Stream +---------------+ +---------+ +-------+ | FlexMux Layer | ^ ^ ^ | | | __ FlexMux- | | | | |/ Stream | | | | | | | | | |14496-6 +---+ +-----+ +----+ +----+ +-----+ +---+ |DMIF |RTP| |MPEG2| |AAL5| |AAL2| |H.223| |DAB| TransMux| |UDP| | TS | |ATM | |ATM | |PSTN | |mux|etc., Layer| |IP | | | | | | | | | | | | +---+ +-----+ +----+ +----+ +-----+ +---+ | ^ ^ ^ ^ ^ ^ / ~~~|~~~~~~~~|~~~~~~~~~|~~~~~~~~|~~~~~~~|~~~~~~~~|~~~~~~DNI~~~ v v v v v v (TransMux streams) N E T W O R K S ietf-avt-rtp-mpeg4-00.txt [Page 4] INTERNET-DRAFT - 5 - March 13th, 1998 Figure 2: The MPEG-4 System Data Plane MPEG does not restrict the permissible transport protocol stacks. Just the properties that such a protocol stack (the TransMux Layer) should have are specified by MPEG. 2 Encapsulation of packetized MPEG-4 data in RTP packets 2.1 Analysis of requirements The RTP specification recommends using a separate session for each media stream. So, a straightforward use of RTP for MPEG-4 payloads may require one RTP session for each Elementary Stream, i.e., one or more streams per audiovisual object. Since a typical MPEG-4 session may involve a large number of objects, that may be as high as a few hundred, this approach is not always practical. Allocating and controlling hundreds of destination addresses for each MPEG-4 session will pose insurmountable session administration problems. The input/output processing overhead at the end-points will be extremely high also. On the other hand, creating a single payload for the entire object collection defies the highly valued object based scalability property of MPEG-4 for Internet applications. Therefore, one RTP payload type for MPEG-4 data should allow selective bundling of several objects or Elementary Streams, respectively. The bundling technique needs to address the following requirements: a) The determination and announcement of the object bundles should be dynamic and may be done by the sender or the receiver(s) of an MPEG-4 session through non-RTP means. The required descriptors will be defined by DMIF and may either be encapsulated in a DMIF-defined protocol or may be part of an SDP [7] session description. They might be conveyed through native signaling, using e.g. SIP [8] INVITE or RTSP [9] DESCRIBE methods. b) Once an object bundle is defined, it is considered to be a single payload type MPEG-4 FlexMux Stream for RTP purposes and thus identified as a single RTP session. Given that there are also applications with fewer objects and, hence, Elementary Streams, a second RTP payload type for MPEG-4 data should allow efficient encapsulation of a single Elementary Stream: c) There need to be a payload type for MPEG-4 Single Stream. d) In general, an AL-PDU does not contain information about its size. Therefore an RTP packet in æMPEG-4 Single StreamÆ mode should contain exactly one AL-PDU since, in that case, its length can be derived from the packet ietf-avt-rtp-mpeg4-00.txt [Page 5] INTERNET-DRAFT - 6 - March 13th, 1998 length indication of the underlying protocol, usually UDP/IP. e) Different from other RTP payload formats both payload formats do not expose whether the payload is video or audio. This is no disadvantage since it is assumed that subsets of MPEG-4 streams of a presentation are identified by means of descriptive information, like stream priority and object dependencies, conveyed in Object Descriptors and DMIF descriptors, and not by the payload type. 2.2 MPEG-4 Single Stream Payload Type For this payload type a single MPEG-4 AL-PDU is mapped into one RTP packet. For an optimized encapsulation, the redundancies between the AL-PDU header and the RTP header are removed as far as possible. The AL syntax is flexible and may vary from stream to stream, therefore the RTP packer and unpacker processes need to have access to the ALConfigDescriptor for this stream that determines the variable syntax elements. Furthermore it is assumed that the MPEG-4 Access Unit Layer packer is aware of the path-MTU (Maximum Transfer Unit) of the network. Hence, the AL is responsible for splitting Access Units in appropriate AL-PDUs that do not lead to transport packets that are larger than the path MTU size. This includes that such an AL entity is responsible for re-packetizing Access Units when an AL-packetized stream is read from a file that has assumed a different path MTU size upon creation. An MPEG-4 AL-packetized Elementary Stream that does not respect the path-MTU of the underlying transport network and that cannot be re-packetized in an AL-aware manner for any reason has to use the FlexMux Stream payload type that does define means for fragmentation on the RTP layer. Note: An AU corresponds to Application Data Unit in ALF. An AL-PDU which carries less than a complete AU may be a stupid fragment made for the sole purpose to adapt packet size to some network requirements. Therefore AL-PDUs never have to be fragmented, since the AL packer (that is closely linked to the RTP packer for the purpose of our work here) is path MTU aware. The fallback solution is expressed in the previous paragraph. The Single Stream Payload type eliminates redundant transmission of sequence numbers and timestamps between RTP header and AL-PDU header. In conjunction with RTP header compression [6] it therefore allows relatively low overhead packetization. 2.2.1 RTP Header usage The payload type (PT) shall be set to the value identified for MPEG-4 Single Stream. ietf-avt-rtp-mpeg4-00.txt [Page 6] INTERNET-DRAFT - 7 - March 13th, 1998 The marker (M) bit shall be set to one for each AL-PDU that is the last AL-PDU of a fragmented Access Unit. Such an AL-PDU is identified either by: accessUnitEndFlag = 1, if this flag is present in the header, or looking ahead that the subsequent AL-PDU has accessUnitStartFlag=1 or knowing from ALConfigDescriptor that each AL-PDU contains a complete Access Unit. Note: M is used as indicator for fragmentation that occurs on the AU Layer. This may be seen as not being strictly the same as the original RTP intention to use it to signal the end of a presentation unit (e.g. a video frame). However, for the purpose of this document an AU should be seen as presentation unit. The extension (X) bit shall be set to zero. The sequence number shall be derived from the value encountered in the sequenceNumber field of the AL-PDU, if present, incremented by a constant random offset. If sequenceNumber has less than 16 bit length, the MSBs shall initially be filled with a random value that is incremented by one each time the sequenceNumber value of the AL-PDU returns to zero. As an exception, the MSBs shall not be incremented if the value sequenceNumber=0 is encountered in multiple consecutive AL-PDUs since this indicates a deliberate duplication of the AL-PDU. The sequenceNumber shall then be removed from the AL-PDU header by bit-shifting the subsequent header elements towards the beginning of the AL-PDU header. When unpacking the RTP packet this process can be reversed with the knowledge of the ALConfigDescriptor. If no sequenceNumber field is configured for this stream, acc. to the ALConfigDescriptor, then the RTP packer shall generate its own sequence numbers, starting at a random value. The timestamp shall be set to the value encountered in the compositionTimeStamp field of the AL-PDU, if present. If compositionTimeStamp has less than 32 bits length, the MSBs of timestamp shall be set to zero. If compositionTimeStamp has more than 32 bits length, MPEG-4 Single Stream payload type can not be used and MPEG-4 FlexMux Stream must be used instead for this stream. In case compositionTimeStamp is not present in this AL-PDU, but has been present in a previous AL-PDU, this same value shall be taken again as timestamp. The compositionTimeStamp, if present, shall then be removed from the AL-PDU header by bit-shifting the subsequent header elements towards the beginning of the AL-PDU header. When unpacking the RTP packet this process can be reversed with the knowledge of the ALConfigDescriptor and by evaluating the compositionTimeStampFlag. The AL-PDU header also allows a decodingTimeStamp to be present, if the decoding time is different from the composition time. For those AL-PDUs in which only a decodingTimeStamp or both, composition and decodingTimeStamp are present in the AL-PDU header the above procedure shall be applied to the decodingTimeStamp, leaving the compositionTimeStamp unaffected. If compositionTimeStamp is never present in AL-PDUs for this stream, acc. to the ALConfigDescriptor, the RTP packer shall convey a ietf-avt-rtp-mpeg4-00.txt [Page 7] INTERNET-DRAFT - 8 - March 13th, 1998 reading of a local clock at the time the RTP packet is sent. Note: Timestamps should start at a random value for security reasons. Since they are copied from the AL, this would involve changing the remaining timestamps in the AL-PDU Header as well. This includes changing OCR timestamps that may have a different accuracy. Therefore it seems to be difficult to satisfy the random start value constraint. An SSRC value for each RTP session shall be selected randomly, as described in RFC1889 [5]. 2.2.2 RTP Payload The RTP Payload consists of one single AL-PDU, including the AL-PDU header, omitting the sequenceNumber and decodingTimeStamp fields, as specified in the previous section. If the resulting, smaller, AL-PDU header consumes a non-integer number of bytes, zero padding bits shall be inserted to byte-align the AL-PDU payload. Note: 32 bit alignment of AL-PDU payload would be desirable for processing efficiency with high bitrate streams, while for low bitrate streams unfortunately it just increases the overhead. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : contributing source (CSRC) identifiers : : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AL-PDU Header (variable # of bytes) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP | | | AL-PDU Payload (byte aligned) | Payload | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...........RTP padding (opt.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The operation of the RTP unpacker for this payload type can be visualized by the figure below. Note that an implementation may as well integrate RTP parsing and AL-PDU regeneration in one unit. ietf-avt-rtp-mpeg4-00.txt [Page 8] INTERNET-DRAFT - 9 - March 13th, 1998 Natural/Synthetic Audio & Visual data, Scene Description & OD streams ^ ^ ^ ^ | | | | | | | | +---+ +---+ +---+ +---+ |AL | |AL | |AL |. . . . . . |AL | +---+ +---+ +---+ +---+ ^ ^ ^ ^ | | | | ==|====|======|=====================|===DAI=== | | | | +--------------------------------------+ | Regenerate AL-PDUs | +--------------------------------------+ MPEG-4 ^ Time ^ Sequence^ Payloads | Stamps | Numbers| | | | +-----------------------+ | RTP Parser | +-----------------------+ ^ I I I 2.3 MPEG-4 FlexMux Stream Payload Type This payload type is intended for use if the number of Elementary Streams in an MPEG-4 application are too high for the Single Stream payload type to be efficient, i.e., the number of RTP packets per second as well as the associated processing for the high number of RTP sessions becomes unmanageable. In this case multiple MPEG-4 Elementary Streams have to be mapped into one RTP session. Therefore this payload type defines how data from multiple streams can be aggregated in one RTP packet, encapsulated in MPEG-4 FlexMux-PDUs as specified in [1]. Notably this enables the use of FlexMux MuxCode mode that allows to merge AL-PDUs from different streams in a pre-agreed sequence and, hence, does not need any further overhead to label these AL-PDUs. This payload type is intended to carry an integer number of FlexMux-PDUs per RTP packet, however, it also defines a means to support fragmentation of large FlexMux-PDUs in case the MPEG-4 Access Unit Layer packer is not aware of the path-MTU of the network. 2.3.1 RTP Header usage ietf-avt-rtp-mpeg4-00.txt [Page 9] INTERNET-DRAFT - 10 - March 13th, 1998 The payload type (PT) shall be set to the value identified for MPEG-4 FlexMux Stream. The marker (M) bit shall be zero if the payload starts with the beginning of a FlexMux-PDU. It shall be one if the payload contains the continuation of a FlexMux-PDU. The FlexMux-PDU length indication allows to know whether such an RTP packet contains the last fragment of a fragmented FlexMux-PDU. The extension (X) bit shall be set to zero. The RTP packer shall generate sequence numbers, incrementing monotonically by one, for each RTP packet generated in order. For the initial RTP packet of a session a random value shall be chosen for sequence number. If two packets with the same sequence number are received immediately after each other, a duplication of the packet shall be assumed and the later packet may be discarded. If the sequence numbers are discontinuous, packet loss shall be assumed as soon as the timestamp of the packet after the discontinuity requires delivery of that packet. The MPEG-4 Elementary Streams encapsulated in the FlexMux Stream that forms the RTP payload need to implement their own AL-PDU loss detection using the sequenceNumber syntax element or need to rely on the error resiliency of the compression scheme used. The timestamp shall convey a reading of a local clock at the time the RTP packet is sent. An SSRC value for each RTP session shall be selected randomly, as described in RFC1889 [5]. 2.3.2 RTP Payload The RTP payload consists of one or more complete FlexMux-PDUs as visualized in the figure below. Each FlexMux-PDU consists of an index element that identifies the content of the FlexMux-PDU, the length of the payload, a version number (only for MuxCode mode) and the payload itself as specified in [1]. FlexMux-PDUs are byte-aligned in the payload of the RTP packet. Note: It may be computationally beneficial to word-align the FlexMux-PDUs. However, on average this means a 2 byte per FlexMux-PDU overhead for alignment. That seems to be rather high. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ietf-avt-rtp-mpeg4-00.txt [Page 10] INTERNET-DRAFT - 11 - March 13th, 1998 | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : contributing source (CSRC) identifiers : : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | index | length | version :FM-PDU Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...............+ | RTP | ...... ....... ........ ....... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload | ...... | index | length | ....... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : ...... FM-PDU Payload ........ ......... : : : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... ........ :...........RTP padding (opt.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The operation of the RTP unpacker for this payload type can be visualized by the figure below. Note that an implementation may as well integrate RTP parsing and FlexDemulitplexing in one unit. Natural/Synthetic Audio & Visual data, Scene Description & OD streams ^ ^ ^ ^ | | | | | | | | +---+ +---+ +---+ +---+ |AL | |AL | |AL |. . . . . . |AL | +---+ +---+ +---+ +---+ ^ ^ ^ ^ | | | | ==|====|======|=====================|===DAI=== | | | | +--------------------------------------+ | FlexMux demultiplexer | +--------------------------------------+ RTP packet ^ payload | includes signaling | of packet boundaries +-----------------------+ | RTP Parser | +-----------------------+ ^ I I ietf-avt-rtp-mpeg4-00.txt [Page 11] INTERNET-DRAFT - 12 - March 13th, 1998 I A Authors' Addresses Carsten Herpel Vahe Balabanian THOMSON multimedia Nortel Goettinger Chaussee 76 P.O.Box 3511, St. C 30453 Hannover Ottawa, Ontario Germany Canada K1Y 4H7 Email: herpelc@thmulti.com Email: balabani@nortel.ca Andrea Basso M. Reha Civanlar AT&T Labs - Research AT&T Labs - Research 100 Schultz Drive, 100 Schultz Drive, Red Bank, NJ 07701 Red Bank, NJ 07701 USA USA Email: basso@research.att.com Email: civanlar@research.att.com Don Hoffman Michael F. Speer Sun Microsystems, Inc Sun Microsystems, Inc 901 San Antonio Road 901 San Antonio Road Palo Alto, CA 94303-4900 Palo Alto, CA 94303-4900 USA USA Email: don.hoffman@eng.sun.com Email: michael.speer@eng.sun.com Henning Schulzrinne Columbia University Dept. of Computer Science 1214 Amsterdam Avenue New York, NY 10027 USA Email: schulzrinne@cs.columbia.edu B Bibliography [1] ISO/IEC 14496-1 CD MPEG-4 Systems Oct. 1997 [2] ISO/IEC 14496-2 CD MPEG-4 Visual Oct. 1997 [3] ISO/IEC 14496-3 CD MPEG-4 Audio Oct. 1997 [4] ISO/IEC 14496-6 CD Delivery Multimedia Integration Framework, Oct. 1997 ietf-avt-rtp-mpeg4-00.txt [Page 12] INTERNET-DRAFT - 13 - March 13th, 1998 [5] Schulzrinne, Casner, Frederick, Jacobson RTP: A Transport Protocol for Real Time Applications RFC 1889, Internet Engineering Task Force, Jan. 1996. [6] S. Casner, V. Jacobsen Compressing IP/UDP/RTP Headers for Low-Speed Serial Links, draft-ietf-avt-crtp-04, Internet Engineering Task Force, Nov. 1997 [7] M. Handley, V. Jacobson SDP: Session Description Protocol, Internet Engineering Task Force, Nov. 1997 [8] Handley, Schulzrinne, Schooler SIP: Session Initiation Protocol, Internet Engineering Task Force, Nov. 1997 [9] H. Schulzrinne, A. Rao, R. Lamphier Real Time Streaming Protocol (RTSP), Internet Engineering Task Force, Nov. 1997 ietf-avt-rtp-mpeg4-00.txt [Page 13]