Implementing MPEG-4 Video On Demand Over IP ...

Implementing MPEG-4 Video On Demand Over IP Differentiated Services Toufik AHMED, Ahmed MEHAOUA and Guillaume BURIDANT University of Versailles - CNRS-PRiSM Lab., 45, av. des Etats Unis 78035 – Versailles - France Abstract-In this article an implementation of a JAVA-based MPEG-4 Video on Demand service over IP with DMIF signaling is proposed. Focus is on performance evaluation on transmitting such a video streams over IP Differentiated Services with linux-based IP Diffserv gateways and real MPEG video sequences. Our contribution is to demonstrate that IP Diffserv’s Assured Forwarding PHB is a serious candidate for supporting real-time video communications in association with intelligent packet marking and scheduling mechanisms.

I. INTRODUCTION Today, Internet is the spectrum of communication modes: data, voice and video, both with real-time and non-real-time constraints. Multimedia applications with real-time constraints need a guarantee delivery of packets in term of packet delay and packet losses that is not assured by best effort service model supported by the Internet. To improve the best effort model, two approaches for achieving QoS (Quality of Service) are being developed by the IETF (Internet Engineering Task Force). The Intserv (Integrated Service) approach is motivated by the ability for applications to choose among multiple, controlled levels of delivery service for their data packet [1]. In the integrated service framework, many functions are used to provide QoS: the first function is control services such as Controlled-Load [2] and Guaranteed [3]. The second function may be provided in a number of ways, but is frequently implemented by a resource reservation setup protocol such as RSVP [4]. The Diffserv (Differentiated Services) approach [5], to providing quality of service in networks, employs a small, welldefined set of building blocks from which a variety of aggregate behaviors may be built [6]. Packets marked with a particular manner will receive a particular forwarding treatment at each network node called PHB (Per-Hop Behavior). The PHB is invoked by the DS-filed in the IP packet’s header. A small number of specific PHBs has been standardized by the Diffserv working group to provide differential treatment of traffic which are EF (Expedited Forwarding) PHB [7] and AF (Assured Forwarding) PHB group [8] and BE (Best Effort) PHB. The key difference between Intserv and Diffserv is that while Intserv provides end-to-end QoS service on a per-flow basis, Diffserv is intended to provide service differentiation among the traffic aggregates to different users over a long timescale. In

this case, the router is capable for distinguish a small number of aggregated classes of packets, where a class represents all packets with the same marking. In this article, we consider the application scenario given in the Fig. 1 where the media server is MPEG-4 video server that plays video for many heterogeneous clients. The client can be a simple PC connected to the network or any terminals as mobile phone (GSM, UMTS) capable of rendering MPEG-4 video sequences. The network elements such as routers are Diffserv routers. We investigate QoS interaction provisioning between MPEG-4 video application and Diffserv network. To achieve a best possible QoS, all the components involved in transmission process must collaborate together. The server must use stream properties to describe the QoS requirement for each stream to the network.

Fig. 1. An MPEG4 Video On Demand Service over IP This function is achieved by making distinction between important stream and less important one. The Client describes it requirement in term of QoS by asking some stream among several available on the server. Finally the network (network elements such as routers) must assure the QoS of the video stream asked by the client. Multiple algorithms implemented in the routers achieve this later task. The Quality of Service is performed through the mapping of MPEG-4 ES characteristics (video, audio and ODs) on Diffserv’s PHB AF/EF. It is not desirable to let the network (edge router) marking the incoming traffic as several algorithms do. The marking algorithms such as TSWTCM (Time Sliding Window Three

0-7803-7208-5/01/$17.00 (C) 2001 IEEE

III. MPEG-4 VOD SYSTEM IMPLEMENTATION A. MPEG-4 Sever and Client Implementation We have developed an MPEG-4 system consisting of a client and a server communicating over an IP-based local area network using MPEG-4 Delivery Media Integrated Framework signaling (DMIF) (see Fig. 2). The developed system is based on JMF1 2.1 API (Java Media Framework). We augmented the 1

The JMF 2.0 API was developed by Sun Microsystems, Inc. and IBM. The JMF 1.0 API was developed by Sun Microsystems, Inc., Silicon Graphics Inc.,

JMF-based DAI

MPEG4 Player

Marker

DNI

RTP

DMIF-TO-DMIF Signaling

DNI

RTP

We used the IP Packet marking algorithm described in [11] to tag the MPEG-4 ESs (see Annex for further details). The used MPEG-4 video stream is composed of three hierarchically encoded layers offering tree levels of quality. More details on MPEG-4 encoding process and tools can be found in the [13]. In Best Effort IP service, when network congestion occurs, packets are discarded by the gateways with no distinction. Therefore, important information such as decoding control information may be dropped while less relevant information are preserved (e.g. complementary raw video data). The result of this situation is that the decoder cannot regenerate correctly the video sequences. The solution of this problem is to distinguish between important video data from less important one. Marking the packet at the video server before transmission can do this. Consequently, IP packets can be dropped according to their contribution to the perceived picture quality. If the packet is marked as no important, then it will be dropped first in case of congestion. In addition, when the video is structured as a multi-layered video application, multiple heterogeneous clients can receive simultaneously the video by selecting the number of layers that they can manage.

MPEG4 Pump

II. QOS MANAGEMENT

client by adding DMIF API to communicate with the server using DMIF signaling. The DMIF implementation is out of the scope of this article and further information can be found in [14]. The MPEG-4 Server consists of MPEG-4 pump, DMIF Instance for IP network, and tools for RTP/UDP/IP stack. The server delivers ES packetized Stream to FluxMux tools witch encapsulates ES packet in RTP packets. [11] explains in more details the encapsulation protocol used for this experiment. For our testbed we used a video sequence with three hierarchically encoded streams that are transported in distinct RTP sessions. When the VOD session is setup by DMIF, the client requests one or more stream channels for presentation, afterwards, the server push the audio visual data in the RTP channel and marks the stream with the appropriate IP DiffServ Per Hop Behavior (PHB) using our “IP DiffServ Video Packet Marking Algorithm” (DVMA).

MPEG-4

Colour Marker) [9] and TRTCM (A Two Rate Three Color Marker) [10] cannot be used in the case of multimedia traffic. These algorithms make no distinction between important data and less important one and cannot mark the packet correctly for future control. The verification of our proposed algorithm [11] is evaluated by experimental testbed using Linux Diffserv implementation [12]. The remaining of the article is as follows. Section 2 presents how QoS of MPEG-4 video is managed using the proposed IP packet-marking algorithm. The different component of the VOD testbed implementation is described in section 3. Measurements result and performances analysis are detailed in section 4. We conclude in section 5.

IP-based Network

DMIF

DMIF

MPEG-4 Server

DAI

JMF

Player

MPEG-4 Client

Fig. 2. A JAVA-based MPEG-4 VoD and DMIF Signaling Implementation B. Experimental IP DiffServ Network testbed Our environment testbed is composed of a video server application that plays MPEG-4 video stream for different heterogeneous clients. The server and clients are connected through a TCP/IP network. We measure QoS parameters for different network configurations (i.e. Best Effort service and IP Differentiated Services). We’ve also implemented an MPEG-4 video streaming system to test the marker algorithm and a simple video client to receive the packets sent by the server. The network topology is composed of two edge routers and one core router conforming with the IP Diffserv model. The links are 10Mb/s Ethernet. C. Edge router configuration Edge routers accept and filter the incoming traffic. They can characterize, police, and mark entering IP traffic.

and Intel Corporation. media/jmf/index.html

0-7803-7208-5/01/$17.00 (C) 2001 IEEE

Available

at:

//java.sun.com/products/java-

Within the Diffserv domain, bandwidth is dynamically allocated to traffic based on the DiffServ code Point (DSCP) located in each IP packet’s header. Therefore, the video application must mark the packets correctly to obtain a particular level of quality of service within the Diffserv region. The edge router limits the amount of Expedited Forwarding (EF) traffic to 15% of the total bandwidth capacity (i.e. 1.5Mbit). We use a policing mechanism (i.e. a token bucket) to limit the EF traffic. Furthermore, the router must make sure that the departure rate configured is greater than the arrival rate for minimizing the queuing delay. This is extensively sufficient since we use EF only for sensitive information such as Objects Descriptors and Scene Descriptor (BIFS) that should be transported with maximal guarantee to the client (i.e. no loss and minimum jitter). The EF flow is bounded and isolated in every router queue. For the edge router we also use a simple Class Based Queuing (CBQ) discipline to classify and schedule the incoming packets. D. Core router configuration Core routers are also configured to perform packet classification based on DSCP, packet scheduling, queue management, policing and packet dropping. We also use CBQ as suggested in [15]. With CBQ a single set of mechanisms is proposed to implement link-sharing and real-time services. In our implementation, CBQ is used to manage Expedited forwarding (EF), Assured Forwarding (AF), and Best Effort (BE) service classes so that each user can get appropriate resources based on packets marking. The CBQ mechanisms include: 1. a classifier to classify arriving packets to the appropriate class. This classification is based on DSCP field in the IP packet header, 2. a scheduler to determine the order in which packets from the various classes will be sent to the output ports. Linux Kernel implements several queuing disciplines (e.g. RED/GRED). The GRED queuing discipline is used to support multiple drop priorities as required for AF PHB group. One physical GRED queue is composed of multiple VQ (Virtual Queue). GRED can operate in RIO mode [16], with coupled average queue estimates from the virtual queues, or in standard mode where each virtual queue has its own independent average queue estimate as required for RED [17]. In our testbed, we used GRED for the AF classes, to give different levels of QoS. For the AF classes we allocated 1.5Mbit/s for each AF1, AF2, AF3 and AF4, all of them are bounded. For the best effort traffic, we allocated 3.5Mbit and can use any available bandwidth.

IV. MEASUREMENT & PERFORMANCES ANALYSIS The Figure 3. shows the MPEG-4 video transmitted from the MPEG-4 server to the client. The network is loaded by background traffic that is conveyed with best effort. The first set of measurements concern IP video packet losses in both best effort and Diffserv scenarios. Second we evaluate the end-to-end one way delay experimented by video packet from the server to the client. In each scenario, we load the network differently to simulate real working conditions. A. IP Video Packets Losses Figure 4. depicts the percentage of video packets losses when the amount of background traffic is about 80% (6.5 Mbit/s) of the bandwidth. This leads to some losses essentially at time t=30s i.e. when the server sends at its peak rate (i.e. Fig. 3). The majority of the packet losses occur at the base layer stream. This gives a low level of QoS to the receiver. Consequently, the end terminal cannot decode the complementary video streams without reception of the video base layer. Losses increase dramatically when network load increases (i.e. Fig. 5). The highest level of packet losses for the base layer is due to the demand of a greater bit rate. We can compare this phenomenon with MPEG-2 video streams where Intra pictures are bigger than Predictive and Bi-directional predictive pictures. In this case, the Intra-frame packet losses must be lower than for the other video packets types. When dealing with MPEG-4, the base layer sub-stream must have the lowest IP packet loss compared to the two other enhanced layers. In the Diffserv scenario, we can observe that the video packet losses are almost equals to 0, since we have ensured that the base layer has no losses. The Fig. 6 and 7 illustrate this fact. In the performed evaluation tests, the variations of the video packet loss versus the network load for IP Best Effort and IP Diffserv respectively are very important. Individual MPEG-4 video layers encounter different packet loss probability. With IP Best Effort, the most essential video layer (i.e. base layer) obtains the highest loss with 60 % for an 80% network load. Using IP Diffserv and DVMA, the base layer faces the lowest drop probability with a maximum of about 0.2 %. B. End-to–end Video Packet Transmission Delay Figures 8 and 9 illustrate the end-to-end IP packet transmission delay, which is as much important as the packet losses. A delayed video packet is no more useful at destination due to the real-time nature of the VOD application. We can also notice that with this scenario, the video packet’s losses are the same when the network load is 80% of the bandwidth and when it is 95%. It proves that traffic increase has no effect upon the video traffic, mainly due to the statistical properties of the packet priority mechanism. We also note that

0-7803-7208-5/01/$17.00 (C) 2001 IEEE

best effort traffic (background traffic) can dynamically use available bandwidth. Figure 8. illustrates the dramatic increase of the transmission delay during peak rates. When the network load is about 95%, the delay is very high and leads to a low QoS guarantee to the video on demand service. With the IP Diffserv scenario, the measured video packet transmission delay is lower and doesn’t really increase when the network load reaches 95%. In both figure 10 and figure 11, we can also see that the highest delay appears at the peak rate around the middle of the transmission process. V. CONCLUSION In this article, we have designed and implemented an MPEG4 Video On Demand service over IP Differentiated Services. We demonstrate that an packet-marking algorithm that takes into consideration MPEG-4 video properties can sensibly improve quality measurements of such multimedia streams over IP networks. We also investigated performances on mapping the different MPEG-4 video sub-streams (audio, layered video, BIFS and OD signaling…) over EF and AF IP Diffserv PHBs. We noticed that sensitive multimedia streams would undergo a privileged processing by the Diffserv routers when using our “IP DiffServ Packet Video Marking Algorithm” (i.e. DVMA in short). This is particularly noticeable with hierarchically encoded video streams such as MPEG-4 and MPEG-2. REFERENCE [1]

J. Wroclawski «RFC2210: The Use of RSVP with IETF Integrated Services» September 1997. [2] J. Wroclawski MIT «RFC2211: Specification of the Controlled-Load Network Element Service » September 1997. [3] S. Shenker, C. Partridge, R. Guerin «RFC 2212: Specification of Guaranteed Quality of Service » September 1997. [4] R. Braden, L. Zhang, Berson, S. Herzog,S. Jamin « RFC 2205: Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification» September 1997. [5] S. Blake, D. Black M. Carlson,E. Davies, Z. Wang, W. Weiss «RFC 2475: An Architecture for Differentiated Services » December 1998. [6] K. Nichols, S. Blake, F. Baker, D. Black «RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers» December 1998. [7] V. Jacobson, K. Nichols, K.Poduri «RFC 2598 An Expedited Forwarding PHB» June 1999. [8] J.Heinanen, , F.Baker , W. Weiss, J. Wroclawski; «RFC 2597 : Assured Forwarding PHP Group», June 1999. [9] W. Fang, Seddigh, B. Nandy «RFC2859: A Time Sliding Window Three Colour Marker (TSWTCM) » June 2000. [10] J. Heinanen, R. Guerin «RFC2698: A Two Rate Three Color Marker (TRTCM) » September 1999 [11] T. Ahmed, G. Buridant, A. Mehaoua, «Encapsulation and Marking of MPEG-4 Video over IP Differentiated Services» in IEEE ISCC 01. Tunisia, July 2001.

[12] Werner Almesberger, Jamal Hadi Salim, Alexey Kuznetsov «Differentiated Services on Linux», June 1999 Work in progress. [13] p Ais I. E.4(111.7(o)15([)96-289 -1.1«.3(F)2-8.)4.9(rS)-10.6( S)1-18.6(30( .3(n34.9(

Fig. 3: MPEG-4 Video Layered Streams

Fig. 4: Packet drops in Best Effort scenario - Network Load 80%-

Fig. 5: Packet drops in Best Effort scenario Network Load > 95%

Fig. 6: Packet drops with IP Diffserv - Network Load of 80% -

Fig. 7: Packet drops with IP Diffserv - Network Load > 95% -

Fig. 8: End-to-end transfer delay with IP Best Effort - Network Load of 80% -

Fig. 9: End-to-end Transfer Delay with IP Best Effort - Network Load > 95% -

Fig. 10: End-to-end Transfer Delay with IP Diffserv - Network Load of 80% -

Fig. 11: End-to-end Transfer Delay with IP Diffserv - Network Load > 95% -

0-7803-7208-5/01/$17.00 (C) 2001 IEEE