Internet Engineering Task Force Audio/Video Transport Working Group INTERNET DRAFT Balabanian-Nortel draft-balabanian-rtp-mpeg4-dmif-00.txt September 16,1998 Expires: March 20,1999 The Role of DMIF in Support of RTP MPEG-4 Payloads 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 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), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. ABSTRACT This draft technical proposal describes how RTP carrying MPEG-4 payloads interacts with the MPEG-4 Sync layer through the MPEG (Delivery Multimedia Integration Framework) DMIF. Single or multiple MPEG-4 streams can be carried over one RTP session. MPEG-4 information essential for the efficient packing and unpacking of MPEG-4 streams into/from RTP is identified. The DMIF end-to-end signaling protocol is applied to identify the MPEG-4 RTP payload types and ensure stack compatibility at both sender and receiver locations. DMIF also interprets the RTCP reports by comparing its statistics to the requested MPEG-4 media based QoS. If the statistics fail to meet the requested QoS then action is taken to either continue with the impaired performance, upgrade the network service class, scale down the stream or delete the stream. This action is apart from scalability using the stream back-channel flow control which may be present between an encoder and its decoder. This is an update of the draft-ietf-avt-rtp-mpeg4-dmif-00. It reflects the latest MPEG-4 specs. In addition some clarifications are included and an open issues section is established based on feedback received. Balabanian [Page 1] Internet Draft Role of DMIF with RTP MPEG-4 Payloads September 16,1998 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 draft technical proposal specifies how DMIF is used to facilitate the generation and consumption of the RTP MPEG-4 payloads [5][6]. The MPEG-4 standards are versioned. Each version beyond V1 represents a backward compatible extension. MPEG-4 V1 is targeted to become ISO International Standard on December 1998 and each subsequent version will be displaced approximately by a year. MPEG-4 V2 is targeted for February 2000. DMIF is the part 6 of the MPEG-4 standard. Where indicated, parts of this draft technical proposal will impact on MPEG V2 International Standard targeted for February 2000. This draft technical proposal provides a solution for discussion in IETF AVT and ISO/IEC MPEG technical communities in order to identify issues in using of MPEG-4/DMIF with RTP and incorporate the results. This would lead to the finalization of the specification on RTP use of MPEG-4 with DMIF. 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 few Kbps to multiple Mbps. The MPEG-4 compression schemes are defined in the ISO/IEC specifications 14496-2 and -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 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 Sync 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. DMIF is primarily an integration framework. It provides a default DMIF signaling (DS) protocol which corresponds to DMIF Network Interface (DNI)primitives, see Figure 2. DS is used to complement the lack functionality in underlying control protocols in order to keep the Balabanian [Page 2] Internet Draft Role of DMIF with RTP MPEG-4 Payloads September 16,1998 integrity of the DMIF framework. media aware +-----------------------------------------+ delivery unaware | COMPRESSION LAYER | 14496-2 Visual | streams from few Kbps to multi-Mbps | 14496-3 Audio +-----------------------------------------+ Elementary Stream =============================================================Interface (ESI) +-------------------------------------------+ media and | SYSTEMS SYNC 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 The DMIF Model DMIF as an integration framework uses a uniform procedure at the DAI interface to access the MPEG-4 content irrespective whether the content is broadcast, stored on a local file or obtained through interaction with a remote end-system. The model is shown in Figure 2 below. The specific instance of interest in this memorandum is the interaction with a remote end-system. For this case DMIF uses internal (informative) DMIF-Network Interface(DNI)primitives to map the controls obtained from the application through DAI into the various signaling systems appropriate to the various networks. The default end-to-end DMIF signaling (DS)which corresponds to DNI is specified in DMIF V1 [4]. Balabanian [Page 3] Internet Draft Role of DMIF with RTP MPEG-4 Payloads September 16,1998 ! +---+ +-----------+ +-----------+ +-----------+ ! | | |Local DMIF | |Remote DMIF| |Remote App.| +-----+ ! | D | |for Brd'cst| |(locally | |(locally | Brd'cst | | ! | M | | | | emulated) | | emulated) |<-----source |Local| ! | I | +-----------+ +-----------+ +-----------+ | | ! | F | +-----------+ +-----------+ +-----------+ |App | ! | | |Local DMIF | |Remote DMIF| |Remote App.| File | | ! | F | |for Local | |(locally | |(locally |<-----source | | ! | i | | Files | | emulated) | | emulated) | | | ! | l | +-----------+ +-----------+ +-----------+ | | ! | t | +-----------+ ! +---+ / ---- \ | | ! | e | |Local DMIF | ! |Sig| | --- ---- | +-----+ ! | r | |for Remote | ! |map|<->( Network ) |Outside the ! | | | Service | ! | | | ---- ----- |scope of DMIF ! +---+ +-----------+ ! +---+ | ----- | DAI DNI | ^ | \_____|_________/ | | | +---+!+------+!+------+ | |Sig|!|Remote|!|Remote| +>|map|!| DMIF |!| App. | | |!|(real)|!|(real)| +---+!+------+!+------+ DNI DAI Figure 2: The DMIF model covers broadcast, local file storage and remote service with a uniform procedure for application transparency 1.3 Mapping between MPEG-4/DMIF and RTP Figure 3 below draws the correspondence between RTP and MPEG-4/DMIF. It is noted that DAI signaling allows the establishment of an MPEG-4 Service e.g., Video on Demand, the request of channels to carry MPEG-4 Elementary Streams for that service and the reading of Elementary Stream data when received. The control flows for various scenarios are defined in [4] Balabanian [Page 4] Internet Draft Role of DMIF with RTP MPEG-4 Payloads September 16,1998 RTP MPEG-4/DMIF +-----------------------------+ +---------------------------+ / DATA TRANSPORT CONTROL \ / DATA TRANSPORT \ (RTP) (RTCP) | (Elementary Stream) Audio, Video SR, RR, SDES . Audio, Video Simulated Data BYE, APP | Simulated Data . ^ ^ | ^ CONTROL (Scene, Object I | . I Descriptor(OD), Play/ I | | I Pause, Intellectual I v . I Property Management) I Corresponds to | I ^ I DAI SIGNALING . I | I | I | I . I / I | I / I . I / | I / In addition to . I / SIGNALING Audio, Video | I/ (Service, Channel, Simulated Data . I Data) to include Scene | I ^ and OD streams . ====I==========|=== DAI | I | . I v | Elementary Streams . in SL-PDU fragments Figure 3: Drawing some correspondence between MPEG-4/DMIF and RTP The MPEG-4 stream packets passed across the DAI are formatted in Sync Layer PDUs (SL-PDU). The SL-PDUs can be mapped to RTP-PDUs as follows [6]: RTP-PDU 1:1 SL-PDU RTP-PDU 1:N SL-PDU RTP-PDU N:1 SL-PDU The selection for a particular MPEG-4 stream from the above choices is based on a number of factors including the size of the SL-PDU compared to the RTP-PDU MTU size[6]. The first choice uses MPEG-4 single stream RTP payload type. The second case uses MPEG-4 RTP FlexMux payload type. The last choice also uses MPEG-4 FlexMux RTP payload type. It occurs when MPEG-4 Sync Layer is not able to adjust the MPEG-4 SL-PDU lengths to be within the path MTU. Since MPEG-4 FlexMux is optional, any other equivalent scheme could be used. Some muxing schemes under consideration now for RTP are provided in [8][9][10]. Balabanian [Page 5] Internet Draft Role of DMIF with RTP MPEG-4 Payloads September 16,1998 2 Operation of the RTP MPEG-4 payloads with DMIF This section covers the conceptual operation of the MPEG-4/DMIF with RTP. The DAI primitives shall be used to set up the MPEG-4 session[4]. When the RTP is used an originating (or a destination) DMIF entity could be used to start the RTP session with its corresponding RTP data transport (carrying one or more MPEG-4 Elementary Streams) and RTCP for control. RTCP packets use the same transport media over which the RTP data packets are sent. 2.1 Using MPEG-4 single stream mapping into RTP session The AVT WG encourages the initial experimentaion on MPEG-4 payloads using a single MPEG_4 stream per RTP session. This is in contrast to the mode of multiple streams per RTP session specified in section 2.2. | | v +---+ SIGNALING |SL | (MTU + SLConfigDescriptor) +---+ | ^ MPEG ------- MPEG -------- | | ===================|=================================|===DAI=== v v +------------------------------------+ +---------------+ | Regenerate SL-PDUs |<------| DMIF | +------------------------------------+ . | instance | MPEG-4 | Time | Sequence| . +---------------+ Payloads | Stamps | Numbers| ALConfig ^ ^ v v v Descriptor | | +-----------------------+ v | | RTP Coder | +-----------+| +-----------------------+ |RTCP Codec || I +-----------+| I ^ | I | | I +-----------------------+ v I | ~~~~~~~~DNI IETF ------ (DMIF Signaling V v Protocol) | MPEG ------ | v Figure 4: Conceptual view of the sender operating with MPEG-4 single stream RTP Payload type Balabanian [Page 6] Internet Draft Role of DMIF with RTP MPEG-4 Payloads September 16,1998 Figures 4 and 5 show the operation at the sender and receiver ends respectively. In case of a single MPEG-4 stream payload type, the SLConfigDescriptor is being received at the sender side and being used both at the sender and the receiver for efficient packing and unpacking of the streams into and from the RTP transport [6]. The horizontal lines across the flows indicate the standard to which the flow conforms to. It is noted that while the streams above the DAI conform to MPEG, the network streams consist of a combination of IETF RTP/RTCP and MPEG Default DMIF signaling protocol. ^ | | +---+ SIGNALING |SL | (MTU + ALConfigDescriptor) +---+ ^ ^ | | MPEG ------- MPEG -------- | | ===================|=================================|===DAI=== | v +------------------------------------+ +---------------+ | Regenerate SL-PDUs |<------| DMIF | +------------------------------------+ . | | MPEG-4 ^ Time ^ Sequence^ . +---------------+ Payloads | Stamps | Numbers| SLConfig ^ ^ | | | Descriptor | | +-----------------------+ v | | RTP Parser | +-----------+| +-----------------------+ |RTCP Parser|| ^ +-----------+| I ^ | I | | I +-----------------------+ | I | | IETF ------ | I | ~~~~~~~~DNI I v (Default DMIF Signaling Protocol) | MPEG ------ | v Figure 5: Conceptual view of the receiver operating with MPEG-4 single stream RTP Payload type Balabanian [Page 7] Internet Draft Role of DMIF with RTP MPEG-4 Payloads September 16,1998 2.2 Using MPEG-4 multiple stream mapping into RTP session Although using the method of MPEG-4 FlexMux to carry multiple MPEG-4 streams over an RTP session is technically sound, the AVT WG is in the process of examining methods of generic muxing of RTP streams which in effect will achieve the same end of MPEG-4 FlexMux but without unpredictable side effects on RTP[8][9][10]. Figure 6 (sender) and 7 (receiver) show that in the case of MPEG-4 FlexMux RTP payload type, information for the MTU and SLConfig is not required. The FlexMux decoder however needs the MuxCode information which is generated at the sending end by the FlexMux muxing code and passed to the receiver through the DMIF signaling (DS). DS is an out of band point-to-point protocol to MPEG-4 media streams. It complements RTCP. Multicast DMIF signaling is for DMIF V2 or later consideration. Audio, Video, Simulated Data, Scene, ODs | | | | | | | | v v v v +---+ +---+ +---+ +---+ |SL | |SL | |SL |. . . . . . |SL | +---+ +---+ +---+ +---+ SIGNALING | | | | ^ | | | | | ==|=====|=====|=====================|====================|===DAI=== v v v v v +--------------------------------------+ +---------------+ | FlexMux |------>| DMIF | +--------------------------------------+ . | instance | MPEG-4 | . +---------------+ Payloads | . ^ ^ v MuxCode | | +-----------------------+ Descriptor v | | RTP Coder | +-----------+| +-----------------------+ |RTCP Codec || I +-----------+| I ^ | I | | I +----------------------------+ | I | ~~~~~~~~DNI IETF ------ (Default DMIF Signaling I | Protocol) V v | MPEG ------ | v Figure 6: Conceptual view of the sender operating with MPEG-4 FlexMux RTP Payload type Balabanian [Page 8] Internet Draft Role of DMIF with RTP MPEG-4 Payloads September 16,1998 Audio, Video, Simulated Data, Scene, ODs ^ ^ ^ ^ | | | | | | | | +---+ +---+ +---+ +---+ |SL | |SL | |SL |. . . . . . |SL | SIGNALING +---+ +---+ +---+ +---+ ^ | | | | | ---------------------- MPEG ----------- MPEG ------ ==|=====|=====|=====================|====================|===DAI=== | | | | v +--------------------------------------+ +---------------+ | FlexDemux |<------| DMIF | +--------------------------------------+ . | instance | MPEG-4 | . +---------------+ Payloads | . ^ ^ v MuxCode | | +-----------------------+ Descriptor v | | RTP Coder | +-----------+| +-----------------------+ |RTCP Codec || ^ +-----------+| I ^ | I | | I +----------------------------+ | I | ~~~~~~~~DNI IETF ------ (Default DMIF Signaling I | Protocol) I v | MPEG ------ | v Figure 7: Conceptual view of the receiver operating with MPEG-4 FlexMux RTP Payload type 3 RTCP Sender and Receiver Reports RTP receivers provide reception quality feedback using RTCP report packets which may take one of two forms depending upon whether or not the receiver is also a sender. These reports shall be used by DMIF in the case of MPEG-4/DMIF-RTP to readjust the demand put on the network based on a predefined policy which may involve a decision to be made by the user. The sender report packet consists of three sections, possibly followed by a fourth profile-specific extension section if defined (none has been specified so far for MPEG-4 RTP payloads). Balabanian [Page 9] Internet Draft Role of DMIF with RTP MPEG-4 Payloads September 16,1998 The third section contains zero or more reception report blocks depending on the number of other sources heard by this sender since the last report. Each reception report block conveys statistics on the reception of RTP packets from a single synchronization source. Annex A provides the DMIF per channel (MPEG-4 elementary stream) "media based" QoS. This is adjusted for the RTP stream in both single and multiple stream MPEG-4 mappings. The remainder of this section attempts to match the "delivered" RTP stream performance as measured by the receiver reports to the expected performance calculated using the "media based" QoS. SSRC_n (source identifier): -------------------------- The SSRC identifier of the source to which the information in this reception report block pertains. This SSRC may either relate to an MPEG-4 single or FlexMux RTP payload session. fraction lost: ------------- The fraction of RTP data packets from source SSRC_n lost since the previous SR or RR packet was sent, expressed as a fixed point number. This type of loss is normally compensated by the decoder through mechanisms such as concealment. The fraction lost is compared to the LOSS_PROB in Annex A. It is important that the duration over which this metric is measured is 1 sec to correspond to the same duration used to express the LOSS_PROB. If the statistics consistently exceeds the LOSS_PROB then the policy enforcer is brought into action. As a result the load on the RTP stream is reduced. interarrival jitter: ------------------- An estimate of the statistical variance of the RTP data packet interarrival time, measured in timestamp units and expressed as an unsigned integer. The jitter calculation in RTCP is based on the variation of consecutive interarrival times: If Si is the RTP timestamp from packet i, and Ri is the time of arrival in RTP timestamp units for packet i, then for two packets i and j, D may be expressed as D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si) The interarrival jitter is calculated continuously as each data packet i is received from source SSRC_n, using this difference D for that packet and the previous packet i-1 in order of arrival (not necessarily in sequence), according to the formula J=J+(|D(i-1,i)|-J)/16 Balabanian [Page 10] Internet Draft Role of DMIF with RTP MPEG-4 Payloads September 16,1998 Whenever a reception report is issued, the current value of J is sampled. The synchronization between streams in MPEG-4 does not rely on the jitter value e.g., for lip sync. This function is carried out at the level of the Sync layer based on composition time stamps of the respective streams. In MPEG-4/DMIF V2 the jitter is used to ensure that the receive decoder buffers are not exceeded. It is noted that the RTCP interarrival jitter is intended as a comparison measure between streams or at different times rather than as an absolute measure. therefore the formula below is based on a specific method of managing the dejitter buffer. Assuming that the operation adjusts so that the pointer for decoding the stream is in the middle of the Dejitter_Buffer. The Buffer can accept an amount of burst or deficiency not exceeding twice the value of J x Maximum Rate where: Maximum Rate = MAX_RTP_SIZE* MAX_RTP_RATE Therefore, J must be <= to .5*Dejitter_Buffer/( MAX_RTP_SIZE* MAX_RTP_RATE) If this value is exceeded consistently for some time then the QoS policy enforcer is brought into action. As a result the load on the RTP stream is reduced. Round trip Delay: ---------------- This delay is calculated by measuring the time sending a sender report and receiving the associated receiver report and subtracting the delay it took to send the receiver report at the receiver. Delay must be <= 2*MAX_DELAY converted to seconds from microseconds Average Delay over 1 minute <= 2*AVG_DELAY converted to seconds from microseconds If either of the above values is exceeded consistently for some time then the QoS policy enforcer is brought into action. As a result the load on the RTP stream is reduced. 4. SDES When a DA_ChannelAdd() is requested by the application, DMIF decides whether to initiate a new RTP stream or use one of the existing ones with a FlexMuxed payload type. Only in the case if a new RTP stream is decided the SDES RTCP packet will be sent. This will coincide with the DS_TransMuxSetup() sent on DMIF Signaling [7]. Balabanian [Page 11] Internet Draft Role of DMIF with RTP MPEG-4 Payloads September 16,1998 5. BYE: Goodbye RTCP packet When a single stream is used in the case of the MPEG-4 single stream RTP payload, a BYE packet is sent along with the DS_ChannelDelete using DMIF-DMIF signaling[4]. At the receiver either a BYE packet or DS_ChannelDelete signal will cause DAI to pass DA_ChannelDelete to the application. When a FlexMux stream is used, the BYE packet is generated when no longer any MPEG-4 streams are carried on the RTP session. This means that DS_ChannelDeletes have already been sent for all the channels carried on the RTP session and the application has been notified by DA_ChannelDelete(s) across the DAI. A BYE message is followed by a DS_TransMuxDelete which at the reception will allow both the sending and receiving DMIF sides to reuse the RTP/IP ports[4]. 6. Open Issues: 1- Multicast operation and the inclusion of RTP mixers i.e., aggregation of the streams and adjustment of their QoSs from receivers up to the senders. 2- The inclusion of RTP Payload Format for User Multiplexing [8][9][10] Balabanian [Page 12] Internet Draft Role of DMIF with RTP MPEG-4 Payloads September 16,1998 A Derivation of the RTP QoS using MPEG-4/DMIF Media Based QoS The media based QoS and associated priority are important considerations in MPEG-4 [1][4] since they are used as a base for decision making on how to transport the streams over a network. The following table provides the media QoS specified by the content provider irrespective of the network used for the transport of the media. No QoS values will be available in DMIF V2 The only parameters being specified in V1 are for characterizing the traffic load of the stream (the last 3 rows in the table below). The values expressed in the table below relate to the MPEG-4 Access Units (AU), these are the smallest data entities to which timing information can be attributed. The AUs form the payload of the SL-PDUs and may undergo segmentation by the Sync Layer. For example the maximum SL-PDU size of an MPEG-4 stream can never be larger than the one that corresponds to the maximum AU size. +=====================+=====================================+ | Media | Meaning of the | | QoS_QualifierTag | ES Media QoS | +=====================+=====================================+ | MAX_DELAY |Maximum delay per AU (microseconds) | | (DMIF V2) |measured over 1 sec. | +---------------------+-------------------------------------+ | AVG_DELAY |Average delay per AU allowed | | (DMIF V2) |(microseconds) measured over 1 min | +---------------------+-------------------------------------+ | Dejitter Buffer | Bytes reserved for the removal of | | (DMIF V2) | transport jitter from the steam | +---------------------+-------------------------------------+ | LOSS_PROB |Probability of loss of any single AU | | (DMIF V2) |(Fraction (0.00 - 1.00) over 1 sec. | +===========================================================+ | MAX_AU_SIZE |Maximum size of an AU (Bytes) | | (DMIF V1) | | +---------------------+-------------------------------------+ | MAX_AU_RATE |Maximum arrival rate of an AUs | | (DMIF V1) |(AU-PDU/second) | +---------------------+-------------------------------------+ | AVG_RTP_SIZE |Average size of AUs (Bytes) | | (DMIF V1) | | +---------------------+-------------------------------------+ Balabanian [Page 13] Internet Draft Role of DMIF with RTP MPEG-4 Payloads September 16,1998 A.1 The case RTP-PDU 1:1 (or N:1) SL-PDU The table below shows the stream QoS for the case when a single ES is mapped into the RTP PDU. Only the traffic load parameters (the last 3 rows in the table below) are specified in DMIF V1 targeted to be an ISO/IEC International Standard in December 1998. Normally an RTP-PDU would carry an SL-PDU with a complete AU. In rare cases the SL-PDU would segment the AU in order to for its size to correspond the the RTP-PDU MTU (IP size) as dictated by the underlying network. +=====================+=====================================+ | RTP Stream | Derivation from the | | QoS_QualifierTag | ES Media transport-QoS | +=====================+=====================================+ | MAX_DELAY of RTP PDU|Maximum delay per AU (microseconds) | | (DMIF V2) |measured over 1 sec. | +---------------------+-------------------------------------+ | AVG_DELAY of RTP PDU|Average delay per AU allowed | | (DMIF V2) |(microseconds) measured over 1 min | +---------------------+-------------------------------------+ | Dejitter Buffer | Adjusted for the overhead of the | | for the RTP stream | RTP PDU | | (DMIF V2) | | +---------------------+-------------------------------------+ | LOSS_PROB of RTP PDU|Probability of loss of any single AU | | (DMIF V2) |(Fraction (0.00 - 1.00) over 1 sec. | +===========================================================+ | MAX_RTP_SIZE |Maximum size of an AU (Bytes) | | (DMIF V1) |Plus AL-PDU and RTP overhead | +---------------------+-------------------------------------+ | MAX_RTP_RATE |Maximum arrival rate of AUs | | (DMIF V1) |(RTP-PDU/second) | +---------------------+-------------------------------------+ | AVG_RTP_SIZE |Average size of AUs (Bytes) | | (DMIF V1) |Plus AL-PDU and RTP overhead | +---------------------+-------------------------------------+ Balabanian [Page 14] Internet Draft Role of DMIF with RTP MPEG-4 Payloads September 16,1998 A.2 The case RTP-PDU 1:N SL-PDU The table below shows the stream QoS for the case when multiple ES are aggregated into the RTP PDU. Only the traffic load parameters (the last 3 rows in the table below) are specified in DMIF V1 targeted to be an ISO/IEC International Standard in December 1998. In most cases this method will be used when the AU is <<256 bytes. Each SL-PDU therefore will carry a complete AU. +=====================+=====================================+ | RTP Stream | Derivation from the | | QoS_QualifierTag | ES Media QoS | +=====================+=====================================+ | MAX_DELAY of RTP PDU|Least Maximum delay per AU from | | (DMIF V2) |among the N AL-PDUs(microseconds) | | |measured over 1 sec. | +---------------------+-------------------------------------+ | AVG_DELAY of RTP PDU|Average delay per AU allowed | | (DMIF V2) |(microseconds) measured over 1 min. | +---------------------+-------------------------------------+ | Dejitter Buffer | Total of dejitter buffers adjusted | | for the RTP stream | for the overhead of the RTP PDU | | (DMIF V2) | | +---------------------+-------------------------------------+ | LOSS_PROB of RTP PDU|Least Probability of loss of any | | (DMIF V2) |single AU from the N AL-PDUs | | |(Fraction (0.00 - 1.00) over 1 sec. | +===========================================================+ | MAX_RTP_SIZE |Sum of the MAX_AU_SIZEs of from | | (DMIF V1) |each of the N AL-PDUs Plus AL-PDU | | |and RTP overhead | +---------------------+-------------------------------------+ | MAX_RTP_RATE |Highest MAX_AU_RATE of AUs from each | | (DMIF V1) |of the N AL-PDUs (RTP-PDU/second) | +---------------------+-------------------------------------+ | AVG_RTP_SIZE |Sum of Average size of AUs from | | (DMIF V1) |each of the N AL-PDUs Plus | | |AL-PDU and RTP overhead (Bytes) | +---------------------+-------------------------------------+ Note all the MPEG-4 streams chosen for aggregation over an RTP stream belong to the same stream priority level identified by the Sync Layer. B Authors' Addresses Vahe Balabanian Nortel P.O.Box 3511, St. C Ottawa, Ontario Canada K1Y 4H7 Email: balabani@nortel.ca Balabanian [Page 15] Internet Draft Role of DMIF with RTP MPEG-4 Payloads September 16,1998 B Bibliography [1] ISO/IEC 14496-1 FCD "MPEG-4 Systems" Oct. 1998, obtained from the MPEG Home Page http://drogo.cselt.it/mpeg/ [2] ISO/IEC 14496-2 FCD "MPEG-4 Visual" Oct. 1998, obtained from the MPEG Home Page http://drogo.cselt.it/mpeg/ [3] ISO/IEC 14496-3 FCD "MPEG-4 Audio" Oct. 1998, obtained from the MPEG Home Page http://drogo.cselt.it/mpeg/ [4] ISO/IEC 14496-6 CD "DMIF" Oct. 1998, obtained from the MPEG Home Page http://drogo.cselt.it/mpeg/ [5] Schulzrinne, Casner, Frederick, Jacobson 'RTP: A Transport Protocol for Real Time Applications' RFC 1889,Internet Engineering Task Force, Jan. 1996. [6] Carsten, Balabanian, Basso, Civanlar, Hoffman, Speer, Schulzrinne, 'RTP payload format for MPEG-4 Elementary Streams' draft-ietf-avt-rtp-mpeg4, Internet Engineering Task Force, March 1998. [7] Balabanian, 'The Use of MPEG-4/DMIF and RSVP with Integrated Services' draft-balabanian-intserv-dmif, Internet Engineering Task Force, August 1998. [8] J.Rosenberg, H.Schulzrinne 'An RTP Payload Format for User Multiplexing' draft-ietf-avt-aggregation, Internet Engineering Task Force, May 1998. [9] Keiko Tanigawa, Tohru Hoshi, Koji Tsukada 'An RTP Simple Multiplexing Transfer Method for Internet Telephony Gateway' draft-tanigawa-rtp-multiplex-00, Internet Engineering Task Force, June 16, 1998. [10] B. Subbiah, S. Sengodan 'User Multiplexing in RTP payload between IP Telephony Gateways' draft-ietf-avt-mux-rtp-00, Internet Engineering Task Force, Aug 31, 1998. Internet Engineering Task Force Audio/Video Transport Working Group INTERNET DRAFT Balabanian-Nortel draft-balabanian-rtp-mpeg4-dmif-00.txt September 16, 1998 Expires: March 20, 1999 Balabanian [Page 16]