Source: MPEG Systems
Status: Approved at the
55th Meeting
Title: MPEG Systems (1-2-4-7) FAQ, Version 16.0
Editors: Olivier Avaro, Alexandros Eleftheriadis, Carsten Herpel,
Niels Rump, Vishy Swaminathan, Javier Zamora, Michelle Kim
This document provides answers to Frequently Asked Questions
relating to MPEG Systems activities and standards. It is subject to continuous
update and improvements. Any comments or suggestions should be forwarded to the
general Systems reflector (gen-sys@advent.ee.columbia.edu
).
DMIF stands for Delivery Multimedia Integration Framework. The name emphasizes the need for an integrated framework to deliver multimedia content regardless of the location of the content, as well as, the method used to retrieve or deliver the content.
DMIF is a Session Level Protocol with support for Quality of Service (QOS) streams (i.e., multimedia content). DMIF hides the delivery technology details from the application in order to create a network independent multimedia delivery framework. DMIF ensures interoperability between the application space and the delivery layer through the DMIF-Application Interface (DAI) and interoperability among DMIF peers through the DMIF-Network Interface (DNI).
Above the DAI, the application is media aware (e.g., MPEG-4) and delivery unaware. In other words, the application is designed based on the media technology independently of the network technology. Below the DAI, the DMIF layer is delivery aware (e.g., DSL) and media unaware. In other words, the media content is opaque to the delivery mechanism.
DMIF provides a common API for an application to request transport channels suitable in quality appropriate to resolution and use. DMIF therefore performs a natural mapping function for an application's network service requests. This ensures efficiencies in network technology can be tracked and exploited by the DMIF layer, rather than in any application level coding space.
DMIF, and its extensions, can provide a comprehensive solution in a world of distributed object-to-object communications with heterogeneous QOS requirements and multiple communications infrastructures (e.g., cable, DSL, current internet, broadband, wireless, satellite, etc.). Therefore, DMIF, in particular the DAI, is not customized to a specific network architecture.
The main motivations of DMIF are:
- To create a framework that separates the multimedia processing aspects from the delivery technology aspects. In this way, multimedia applications can be designed independently of a specific delivery technology.
- To enable reusability of multimedia applications in multiple delivery scenarios.
- To have a separation between the User plane, which carries the multimedia content, and the Control Plane, which carries the required signaling messages to deliver the multimedia content.
- To enable multiple multimedia object-to-object (e.g., ESs in MPEG-4) communications in a single multimedia session.
- To enable different quality of service (QOS) requirements for each multimedia object in a multimedia session.
DMIF deals with primitives related to the User plane (i.e., transport of media) and to the Control plane (i.e., session signaling messages). We can classify the primitives according to:
- Service primitives, which deal with the Control plane and allow the management of service sessions (e.g., Attach and Detach sessions).
- Channel primitives, which deal with the Control plane and allow the management of channels (e.g., Add, Delete, and User Commands over specific channels inside a session).
- Data primitives, which deal with the User plane and serve the purpose of transferring data through channels (e.g, Send and Receive data).
DMIF defines two interfaces: the DAI and the DNI. On one hand, the DAI defines the boundary between the application space and the delivery layer. All interaction between the application and the delivery layer is done through the interchange of primitives through the DAI. On the other hand, below the DAI the delivery layer processes the DAI primitives related to the User plane (i.e., media transport mechanisms) and the ones related to the Control plane (i.e., signaling). The DAI primitives related to the Control plane traverse the DNI, which allow the interaction among remote DMIF peers involved in a multimedia session.
DMIF abstracts the generic requirements for the retrieval or delivery of multimedia content, and uses MPEG-4 Systems as a reference environment. DMIF defines a uniform interface (DMIF/Application Interface – DAI) through which multimedia applications (e.g. MPEG-4 players) can access content irrespectively of the delivery scenario and network technology.
The DMIF layer makes use of the available underlying network protocols to establish sessions and channels, as well as, to transfer the multimedia content for each of the channel of a session. The Control plane DAI primitives are mapped in underlying connection management mechanisms to establish and control the network resources needed in a DMIF session.
On one hand, the Control plane DAI primitives are mapped into DNI messages, which can be subsequently mapped into existing network signaling protocols (e.g., UNI 4.0) and/or mapped into application-to-application signaling protocols (e.g., RTSP). In the absence of an application-to-application signaling protocol, DNI defines a syntax for a default signaling protocol (i.e., DS messages).
On the other hand, the payload of the User plane DAI primitives (i.e., send and receive) are delivered using a multiplexing channel structure, called FlexMux, which is transported using any available and suitable transport stack (e.g., UDP/IP, AAL-5/ATM, etc.).
Sometimes, current standard network protocols are extended to accommodate the delivery of multimedia content among DMIF terminals. One example is ITU-T H.245 V6 which introduces extensions to support DMIF messages.
As a session level protocol, DMIF allows the management of multiple heterogeneous channels in the User plane (e.g., ESs in MPEG-4) under a unified application-to-application signaling channel in the Control plane.
In DMIF the “delivery technology” covers a wide front. Delivery technology in DMIF refers to a transport network (e.g. the Internet, or an ATM infrastructure), broadcast distribution channels or local storage files. DMIF derives its power by integrating all these delivery technologies for simultaneous transparent access under DAI using URL addressing schemes.
DMIF defines an interface called DMIF-Application Interface (DAI), in order to allow the development of applications irrespectively of the delivery technology. By using the DAI, an application can seamlessly access content from local storage devices, from broadcast channels and from remote servers. Moreover, different delivery technologies would be hidden as well (e.g., IP as opposed to native ATM, MPEG2 broadcast as opposed of IP broadcast, etc.).
DMIF is a realization of the session layer of the OSI. The DAI represents the Session Service Access Points (SSAP) under which within DMIF different Transport Service Access Points (TSAP) are integrated.
By separating the delivery details from the development of multimedia software, the latter can proceed and mature without worrying about the development or success of new delivery technologies (e.g.: Internet with QoS support, or native ATM). This process is extended by allowing seamless access through DAI to Local Storage and Broadcast distribution channels. By using media related QoS metrics at the DAI interface, applications are able to express their need for QoS without the knowledge of the specific delivery technology. This discipline in DMIF allows applications to be developed once.\
Multimedia applications need to concentrate their development efforts on composing many different object elements, assume the timely and transparent availability of their data. DMIF relieves the application from the details of connection and transport of scene elements.
The DAI is expressed in DMIF V1 as a semantic interface that is the first step in establishing a normative API. Though only the semantics are defined, the DAI identifies the formats of the acceptable URLs which correspond to the technologies it integrates within the DMIF framework. DAI in DMIF V1 does not impose any programming language. Moreover it provides only the minimal semantics, which should then be extended by a real implementation e.g., for getting status information. Thus the DAI as specified in DMIF V1 is not an API, but it provides the rules to implement an API able to fulfill the DMIF requirements.
DMIF V2 (ISO/IEC 14496-6 Amd.1.) defines an informative Annex with a syntax of the DAI, following the semantic specifications given in clause 10 of ISO/IEC 14496-6 (i.e., DMIF V1). This Annex specifies the syntax for ANSI C/C++ programming language. This ANSI C/C++ syntax declaration is derived directly from ISO/IEC 14496-6, permitting an accurate evaluation of reference software's semantic adherence to standard. The definition of a DAI syntax in ANSI C/C++ intends to:
Provide a clean and clear design, allowing the DMIF separation principle between application and delivery layers.
Allowing having interoperability between Applications (e.g., based on MPEG-4 technology) and delivery mechanisms based on different networking technologies (e.g., IP, broadband, wireless, cable, satellite, x-DSL, etc.). There, to ensure and facilitate interoperability and reusability of application code the definition of a DAI syntax enables this goal.
Dictate the way the application interoperates with the delivery layer, that is to say, a non-blocking architecture, which is an additional requirement to ensure the aforementioned interoperability.
Align with the majority of implementations of available MPEG-4 players and servers, as well as, with the rest of the MPEG-4 reference source code. However, the definition of a C/C++ interface does not preclude the definition or use of other platforms such as JAVA.
Not necessarily. It depends on whether application development is required to fully factoring its data sourcing. For matters of expedience, budget, and requirements, single case application development is indicated. The advantages of normalized data access through the DAI are self evident.
The DMIF/Network Interface – DNI – abstracts the semantics required for the network signaling messages. DS messages are defined as a default mapping for such semantics: in that respect DS messages define a new signaling protocol. However, since the DNI semantics can also be mapped to any relevant standards protocol and since some DMIF semantics are already supported by existing standards signaling protocols (or extensions put in place for DMIF), DMIF will use those standard signaling protocol functions through the appropriate mapping. DS messages will be used to complement the existing standards (as default) only if necessary in order to accomplish a full mapping.
DMIF supports MPEG-4 but its operation is independent of MPEG-4. Any application that correctly implements the DAI, is a valid DMIF application (e.g., streaming of MPEG-2 TS). Detailed walkthrough describing how exactly MPEG-4 Systems specific information is handled inside DMIF are provided as examples.
DMIF was conceived as a semantic solution to the efficient aggregation and transport of complex MPEG-4 elementary stream sets. This means a given MPEG broadcast may need to manage tens or hundreds of elementary streams which would be referenced through systems definition, but delivered via the structured normalized channel API defined by the DAI.
The utility of DMIF transcends MPEG-4 formatted multimedia broadcast services. Many broadcast formats could utilize the DAI for their client/server network interface.
The DMIF Reference Architecture includes the definition of a "Target application" which is responsible to manage the peculiarities due to the content characteristics. This model however has not been further developed outside the context of MPEG-4, and the standardization efforts as well as the practical implementations available so far have only concentrated in the support of MPEG-4 content. In particular, the MPEG-4 reference software provides examples of DMIF instances for local retrieval targeted to only manage MPEG-4 content.
This limitation is not in the overall design of the DMIF Reference Architecture, but in the current partial exploitation of it. To actually remove the current constraint, an interface between Target DMIF and Target Application (for scenarios not involving a second terminal) should be defined: this seems easy (the DAI, once again), but no in depth study has been accomplished yet.
DMIF is a symmetric networking architecture. That is to say, any DMIF terminal can assume the role of producer or consumer of information (i.e., support for bi-directional transport channels). DMIF is a departure from the classic server/client paradigm. The role of a DMIF terminal in a session (e.g., video server or video player) is assigned exclusively by the application layer. In other words, the DMIF layer implementation is the same for all peers involved in a session
However, in the MPEG-4 case more emphasis and time has been dedicated to the receiver side, for which a uniform DAI has been conceived to accommodate all possible scenarios. The transmitter side, in the MPEG tradition, is out of the scope of the specification. DMIF is somehow an exception to this rule, since support to bi-directional communication scenario was considered essential as well.
A valid DMIF implementation must comply with the semantics of the DAI. In case the DMIF implementation is intended to operate on a networked scenario, it must also comply with the syntax and semantics of the particular DS messages syntax selected for that network or any corresponding protocol standards to which the semantics can be mapped to. Similarly if a DMIF implementation is also to operate in a broadcast scenario, it must also comply with the specifications of that particular broadcast technique. The same applies for Local File Systems.
The choice of scenario is solved through the use of URLs to correspond to the technologies integrated within DMIF.
MPEG has had an active liaison with ITU-T/SG16, and has proposed extensions to H.245 (now included in H.245 V6) to support DMIF in H.324 terminals. This does not imply however that DS messages always map to H.245 messages: this is only a mode of operation that allows H.324 terminals to be enhanced with MPEG-4 and to inter-operate with MPEG-4 capable terminals.
DMIF V1 defines how to map DNI primitives into signaling messages when using Internet, with and without RSVP. The exact syntax of the DS messages is specified and covers the management of both UDP and TCP sockets. Extensions to cover the peculiarities of the RTP/RTCP connectivity are expected soon. For retrieval only services the mapping into RTSP is being defined, including support to RTP/RTCP.
The FlexMux is a tool specified in ISO/IEC 14496-1, Systems, but is then used in a valid ISO/IEC 14496-6, DMIF implementation. DMIF provides the signaling means for configuring the FlexMux. The DAI provides primitives in both the control plane and the user plane, which hide the application on top of the DAI of the delivery technology details as well as of the FlexMux details: the application on top of the DAI only manages Elementary Streams, not FlexMuxed Streams, and is therefore FlexMux unaware. This model has been proved effective at the receiver side, but requires further consideration at the transmitter side.
Whenever an application needs to access a URL, it invokes a particular DAI primitive (DA_ServiceAttach) and passes the URL. The DMIF implementation would parse the URL and determine which kind of delivery technology it needs to manage.
DMIF supports the subset of URL schemes for which a complete mapping of DAI primitives into "bits on the wire" is defined. This set includes the newly defined schemes making use of DMIF Signaling over IP and ATM networks:
x-dtcp://<user>:<password>@<target dmif>:<dmif port>/<url-path> for DS messages over a TCP signaling channel, with or without RSVP
x-dudp://<user>:<password>@<target dmif>:<dmif port>/<url-path> for DS messages over an UDP signaling channel, with or without RSVP
x-datm:<user>:<password>@<target dmif>:<dmif port>/<url-path> for DS messages over an ATM signaling channel, with Q.293
Support is also/will soon be provided to additional schemes:
file:///<file-path> for MPEG-4 content in MP4 file format
http://<user>:<password>@<target>:<port>/<url-path> for (possibly progressive) downloading of MPEG-4 content
rtsp://<user>:<password>@<target>:<port>/<url-path> for streaming MPEG-4 content through RTSP
There is currently no explicit URL syntax to access (at least MPEG-4) content in the following cases:
broadcast with MPEG-2 TS
multicast with IP multicast
broadcast with DAB
remote interactive through H.245
although private implementations are proving that the DMIF Reference Model can be applied.
DMIF V2 starts addressing the QOS Architecture by extending the DAI primitives with QOS monitoring capabilities. The QOS architecture for DMIF should address different ways of dealing with QOS in different networks. Basically, there are two approaches. On one hand, proactive networks that allocate resources during connection set-up. On the other hand, reactive networks that react according to the available resources during the life of a connection. In order to accommodate both types of networks there is a need of three types of DAI primitives:
REQUEST OF QOS
These primitives are already specified in DMIF V1 (i.e., DAI_ChannelAdd). The QOS parameters are specified inside the ChannelDescriptor in terms of:
Priority (qualitative QOS)\
Profile (quantitative QOS in terms of delay and loss)
Traffic (amount of resources in terms of bit rate)
MONITORING OF QOS
These primitives are already specified in DMIF V2 (i.e., DAI_ChannelMonitor, DAI_ChannelEvent). They provide feedback mechanisms from the DMIF layer to the Application to inform about the underlying available resources.
RENEGOTIATION OF QOS
These primitives shall be added in a future amendment of DMIF (e.g., DAI_ChannelReneg) to allow changing the ChannelDescriptor of an already established channel in a DMIF session.