Internet DRAFT - draft-balabanian-rtp-mpeg4-dmif
draft-balabanian-rtp-mpeg4-dmif
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]
