Overview of MPEG-21 Testbed

The purpose of the MPEG-21 Testbed is to provide a flexible and fair test environment for evaluating delivery technologies for MPEG contents over IP network. It also supports scalable media streaming, which is a crucial topic in MPEG-21 Digital Item Adaptation (DIA).

Because each component in this test bed is highly modulized, users can integrate their customized components into this test bed easily. For example, they can replace the media codec to evaluate the decoding algorithm, or replace the streamer to simulate the performance of different streaming methods. With this test bed, users can simulate different channel characteristics of various networks [9].

The overall architecture of the test bed is shown in Figure 4-4. The entire test bed is divided into three parts: Server, Client, and the Network Emulator.

Figure 4-4 Architecture of MPEG-21 Testbed [8]

The Server system accepts the request for a specific media content form the Client. A Client is connected to the streaming Server. It sends a request using the RTSP message, DESCRIBE, to the Server. In this message, the terminal capability and user characteristics are included. Then, the Server prepares the requested file and sets up the streaming system in order to stream out the media content over the Network. The server sends an acknowledging message called DESCRIBE_ACK to Client indicating that the media data at the Server side is ready. An RTSP message, SETUP, is then received form the Client to request for setting up the transport session. After setting up the RTP channel for content delivery, the Server acknowledged the Client with a message called SETUP_ACK. After receiving this acknowledging message, the Client sends the message, “PLAY” to inform the Server that the Client is ready for content consumption. Then, the content consumption begins after the PLAY_ACK message is sent to the Client. During the content consumption, whenever the user stops the procedure of the content consumption, an RTSP message, TEARDOWN, is sent from Client to Server to stop the content delivery [9].

Because there are several common modules in Server and Client, the descriptions below are divided into four parts, Server components, Client components, Common components,

RTSP

and Network Emulator.

4.2.1 Server Components

The functionality of the server is to provide digital media content with streaming technology to the Clients. One Server can provide services to several Clients. There are seven components within the Server: Media Database, DIA (Digital Item Adaptation), Streamer, Packet Buffer, QoS Decision, Server Controller, and IPMP Subsystem.

The functionalities of each component are described below. The IPMP Subsystem and the QoS Decision will be discussed later.

Media Database

All the Media Contents are offline encoded and stored in the Media Database using a directory tree structure. The Media Database is responsible for opening the file of the Media Content that the Client requests. [9]

DIA

DIA (Digital Item Adaptation) performs media resource adaptation by the DIA processing engine. The CDI (Content Digital Item) and static XDI (Context Digital Item) information are required for initialization, and the dynamic XDI will be set during adaptation. The DIA component receives the information from the Server Controller and generates the adapted resource. [9]

Streamer

When a specific Media Content is requested by the Client, the Streamer gets this content from the DIA module. The Streamer accepts commands from the Server Controller, and segments this content into video packets according to the MPEG-4 specification. [9]

Server Controller

Server Controller handles the control messages sent by the Client side through the RTSP channel, such as REQUEST, SETUP, PLAY, and TEARDOWN. After receiving

these messages, the Server Controller processes these messages and sets up the system for processing different protocols. The Server Controller also sends the corresponding ACK messages to the Client side. [9]

4.2.2 Client Components

The Client consumes the digital media content coming from the Server. It receives the media data through the Network Interface and playbacks the content including video and audio. There are eight components at Client side: Packet Buffer, Stream Buffer, Decoder, Output Buffer, Packet Loss Monitor, QoS Decision, Client Controller, and IPMP Subsystem.

The functionalities of each component are described below. The IPMP Subsystem and QoS Decision will be discussed later.

Stream Buffer

The Stream Buffer is designed as a circular buffer which temporally stores the bitstream data. The data saved in the Stream Buffer will be accessed by the decoder for decoding. There is a flag that records the current access location in the Stream Buffer.

When there is no data in the Stream Buffer, the Decoder waits for the Stream Buffer to get the data from the Packet Buffer and resumes decoding. [9]

Decoder

The Decoder component is the root class for all decoders, including real-time and offline decoders. A Decoder fetches coded units from the Stream Buffer and decodes the data. After decoding, Decoder stores the decoded units into the Output Buffer for display.

[9]

Output Buffer

The Output Buffer component holds the decoded data produced by the Decoder.

The data will be fetched by the player and returned on the output device. [9]

Packet Loss Monitor

The Packet Loss Monitor handles the lost packet monitoring and retransmission.

The component checks the Packet Buffer for any lost packets. The action is triggered by the Client-side timer. If there are packet losses, Packet Loss Monitor informs the Client Controller to issue the retransmission request to the Server side. [9]

Client Controller

The Client Controller integrates and controls all the components at the Client side.

It processes the GUI user’s inputs. When there are lost packets detected by the Packet Loss Monitor, the Client Controller is informed to send the retransmission request to the Server side. [9]

4.2.3 Common Components

In this section, we introduce the modules that are common in both client and server.

Packet Buffer

Real-time Transport Protocol/ Real-time Control Protocol (RTP/ RTCP, RFC-1889) is used as the media transport mechanism. The Packet Buffer implements an RTP packet buffer data structure.

At Server side, the Packet Buffer holds the video packets produced by the Streamer.

The stored packets are then sent to the Client side via RTP protocol according to the pre-scheduled time set by the Streamer. At the Client side, the Packet Buffer receives and stores all the packets that coming from the RTP protocol. This component is used at both Server and Client side with different initializations. [9]

QoS Decision

This component estimates the channel condition and provides some QoS information for rate adaptation. In the current implementation, the channel condition is the network profile designed in the system. Therefore, users could modify the network profile as they wish to test different channel conditions. [9]

IPMP Subsystem

The IPMP Subsystem performs the functionalities of intellectual property protection,

such as encryption, decryption, and watermarking. The IPMP Subsystem is mainly composed of five parts, namely Message Router (MR), Tool Manager (TM), IPMP Filters (or IPMP Control Points), IPMP Tools, and Terminal. Because the MPEG-4 IPMP system is a message-based infrastructure, we need a module called Message Router routing the messages to the corresponding destination. The messages may come from IPMP Tools, Terminal, or other IPMP devices. The Tool Manager manages the IPMP Tools, such as maintaining the Tool mapping table or retrieving the missing IPMP Tools from a remote site. It is also responsible to initialize and destroy the IPMP Tools. There can be several IPMP Tools working within one IPMP system. For instance, at Client side, there would be a DES decryption algorithm, a video watermarking extractor, and an authentication tool. The IPMP Filter is the control point where the IPMP Tools can exercise their functions. The Terminal is provided as the interface between the test bed system and the IPMP system. The details about the IPMP system in the test bed will be discussed in section 4.3.

4.2.4 Network

In order to connect the Server and the Client via a simulated transmission channel, a standard RTSP/RTP-based network interface is used. Three categories of network protocols including the network-layer protocol, transport protocol, and session control protocol are shown in Figure 4-5.

Layered Video Data Application Control

Commands Base Layer Enhancement Layer

RTSP RTP/RTCP TCP UDP

IP Data Link Physical Layer

Figure 4-5 Network protocol [9]

The Real-time Transport Protocol (RTP) is to transmit multimedia streams from end to

end. And the Real-time Streaming Transport Protocol (RTSP) is used to transmit the control messages reliably. RTSP specifies the messages and procedures to control the media streaming passing through an established channel. There are four basic message types used in the test bed: DESCRUBE, SETUP, PLAY, and TEARDOWN. The DESCRIBE message is sent from Client to Server for requesting a specific media content. It also contains the information such as terminal capability or user characteristics. The SETUP message is to setup a media delivery session between Server and Client with the information contained in the DESCRIBE message. After setting up the channel, Client sends a PLAY message to inform the Server of starting to transport the media content. Finally, the TEARDOWN message ends the transport and closes the session.

In the test bed, an IP network emulator named NISTnet [29] is used to provide repeatable network environments. NISTnet can simulate practical wide-area heterogeneous network environments. It is a LINUX based IP network emulator developed by the National Institute of Standard Technology, USA. The testbed provides a GUI to parse a network profile and controls the time-varying network conditions via the NIST Net kernel module.

4.3 Integrate MPEG-4 IPMP Extension into MPEG-21