Implementing MPEG-4 video on demand over IP Differentiated Services

Abstract

In this article an implementation of a JAVA-based MPEG-4 video on
demand service over IP with DMIF signaling is proposed. The focus is on
performance evaluation on transmitting 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

Full text

Abstract- In this artic le an implementation of a JAVA- based
MP EG -4 Video on D emand service over IP w it h DM IF si gnali ng is
proposed. Focus i s on performance evaluation on transmitting such
a video st reams over IP Different iated Servic es w ith linux -based IP
Diffs erv gatew ay s and real M PEG video sequences . Our
contribution i s to demonstrate that IP Di ffserv’s Assured
Forw arding PHB is a serious candidat e for supporting re al-time
video communications in association with intelligent packet
marking and scheduling mechanisms.
I. INTRODUCTION
Tod ay, Internet is the spectrum o f 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
su pported by the Internet.
To improve the best effort model, two approaches for
achieving
QoS
(Quality of Service) are being developed by the
IETF
(Inte rnet Engi neering T ask Fo rce) .
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]. T he second function
may be provid ed in a number of ways, but is freq uently
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, well-
defined 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
networ k node called
PHB
(Per-Hop Behavior). T he 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 gro up to pr ovide d ifferential t reatment of tra ffic 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 intende d to p rovi de ser vice di fferentia tion among
the traffic aggregates to different users over a long timescale. In
this ca se, the r oute r is c ap ab le fo r d istinguish 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 heterogene ous clie nts. T he c lient can be a
simple PC connected to the network or any terminals as mobile
phone (G SM, UM TS) capa ble o f r endering MP EG-4 vid eo
sequences. The network elements such as routers are Diffserv
routers.
We investiga te Qo S inter actio n provis ioning b etween
MPE G-4 vide o ap plic ation and Diffser v network. T o achieve a
best possible QoS, all the components involved in transmission
process must collaborate to gether. The server must use stream
properties to describe the QoS requirement for each stream to
the network.
Fig. 1. An MPEG 4 Vi deo On De mand Ser vic e ove r IP
Th is function is ac hieved b y making distinc tion 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 rout ers achieve t his late r tas k.
Th e Qualit y of Servic e is p erformed through t he mapp ing of
MPEG-4 ES characteristics (video, audio and ODs) on
Diffs erv’s PHB AF/EF.
It is no t d esir able t o let the networ k (edge route r) mar king the
incoming traffic as several algorithms do. The marking
algorithms such as
TSWTCM
(T ime Slidi ng Window Th ree
Im pleme ntin g MP EG-4 Video On D ema nd Over IP Diffe ren tiated Services
Toufik AHM ED, Ahm ed MEHAOUA and Guillau me BURIDANT
University o f Versa illes - CNRS-PRiS M Lab.,
45, av. des Etats Unis 78035 – Versailles - F ranc e
0-7803-7208-5/01/$17.00 (C) 2001 IEEE

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 di stinction 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 exper imental tes tbed using Linux Diffserv implementat ion
[12].
The remaining of the article is as follows. Section 2 presents
how QoS of M PEG -4 video is managed using the pr opos ed IP
packet-mar king algorithm. The different component of t he
VOD testbed implementation is described in section 3.
Measurements result and performances analysis are detailed in
section 4. We co nclude in section 5.
II. Q
OS MANAGEM ENT
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 enco ding pr oces s and to ols can be f ound in t he [13 ].
In Be st Effor t IP servi ce, when network c ongestion oc curs,
packets are discarded by the gateways with no distinction.
Therefore, important information such as decoding control
informatio n may be dr o ppe d while less r el evant i nformat ion ar e
pres erved (e.g . comple mentary raw video data) .
The result of this situation is that the decoder cannot
regenerate correctly the video sequences. The solution of this
pro blem is to d istinguis h between impor tant vid eo d ata from
less important one. Marking the packet at the video server
before transmission can do this. Consequently, IP packets can
be dropped acco rding 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 conge stion. In addition, when
the video is structured as a multi-layered video application,
multiple heterogeneous clients can receive simultaneously the
video by selecting the numb er of layers that they can manage.
III. MPEG -4 VOD S
YSTEM IMPLEMENTATION
A. MPEG-4 Sever and Client Implementation
We have d eve lop ed an MPE G-4 system consi sting o f a c lient
and a server communicating over an IP-based local area
network using MP EG-4 Delive ry Media Integra ted Framework
signaling (DMIF) (see Fig. 2). The developed system is based
on JMF
1
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.,
client by addi ng DMIF API to communicate with the server
using DMIF signaling. T he D MIF imple menta tion is out o f 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 p acketized Stream to FluxMux tools
witch encapsulates ES packet in RTP packets. [11] explains in
more de tails the e ncapsul ation p roto col used for this
experiment. For our testbed we used a video sequence with
three hierarchically enco ded streams that are transported in
distinc t RT P sessi ons.
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 appropri ate IP DiffServ Per Hop Behavior
(PHB ) using o ur “IP DiffServ Video Packet Marking
Algorithm” (DVMA).
DMI F
DNI
MPEG4
Pum
p
DAI
RTP
DMI F
DNI
MPEG4
Pl a
y
er
DAI
RTP
JM F
Pla yer
MP E G-4 S erv e r MP E G-4 Clie n t
JMF- b a s e d
D MIF-T O -D MIF
Si gnal in g
IP -base d
N
et wo rk
MPEG-4
Mark er
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 T CP/IP ne twork. We meas ure QoS p aramete rs for
differe nt network configur ations (i .e. Best E ffort servic e 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. Available at: //java.sun.c om/products/java-
media/jmf/index.html
0-7803-7208-5/01/$17.00 (C) 2001 IEEE

Wi thin the Diffse rv domain, band width 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 D iffserv region.
The edge router limits the amo unt 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 queui ng delay. T his is exte nsively sufficient
since we use EF only for sensitive information such as Objects
Descriptors and Scene Descriptor (BIFS) that should be
transpo rte d with maximal guarantee to the client ( i.e. no l oss
and minimum jitter). The EF flow is bounded and isolated in
every router queue.
For the edge router we also use a simp le Class Based
Queuing ( CBQ) di scipli ne to c lassify 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 Exp edited forwardi ng (EF) , Assured Forwarding (AF),
and Best Effort (BE) service classes so that each user can get
appropriate resources b ased on packets marki ng.
The CBQ mechanisms includ e:
1. a
classifier
to classify arriving packets to the approp riate
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 vari ous class es will be sent to the outp ut po rts. Linux
Kernel implements s evera l queuing d iscipli nes (e.g.
RED/GRED). The GRED queuing discipline is used to
suppo rt multipl e dro p pr iori ties a s requir ed fo r 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 ind ependent average que ue estimate as r equire d 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. M
EASUREMENT
& P
ERFORMANCES
A
NALYSIS
The Figure 3. shows the MPEG-4 video transmitted from the
MPEG-4 server to the client. The network i s loaded by
backgr ound tr a ffic tha t is c o nveyed with best effor t.
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 l oad the
netwo rk 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 ba ndwidth. T his lea ds to some losses essentia lly 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 l ow 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 M PEG -2 video stre ams where Intra picture s
are bigger than Predictive and Bi-directional predictive
pictures. In this case, the Intra-frame p acket losses must be
lower than for the other video packets types. When dealing with
MPE G-4, the b ase la yer sub-stre am must have the lo west IP
packet loss com pared to the two other enhanced layers.
In the Diff serv scenario, we can observe that the video packet
losses are almo st equals to 0, since we have ensured that the
base la yer has no losses . T he Fig. 6 and 7 illust rate 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 Effor t, the most e ssential video layer (i.e . base la yer)
obta ins the highest loss with 60 % for an 80% network loa d.
Using IP Diffserv and DVMA, the base layer faces the lowest
drop probability with a m aximum 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 networ k 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 o f 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
availab le b andwidth.
Figure 8. illustrates the drama tic 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
networ k 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 midd l e of the tra nsmissio n p r o c ess.
V. C
ONC LUSION
In this article, we have designed and imp lemented an MPEG-
4 Video On Demand service over IP Differentiated Services.
We demonstrate that an packet-marking algorithm that takes
into co nsider ation MP EG-4 video prope rties c an sensibly
improve quality measurements of such multimedia streams over
IP ne twor ks. We also investigat ed p erformance s on mapping
the di fferent MP EG-4 video sub-str eams (audio , layered vide o,
BIFS a nd OD signali ng…) over EF a nd AF IP Diffserv PH Bs.
We no ticed that se nsitive multimedia streams would under go 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.
R
EFERENCE
[1] J. Wroclawski «RFC2210: The Use of RSVP with IETF Integrated
Services» September 199 7.
[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
Guar ant eed Qu ali ty of S ervi ce » Sep t ember 19 97 .
[4] R. B raden, L. Zha ng, Be rson, S. Herzog,S. Jam in « R FC 220 5: Resou rce
ReSerVation Protocol (RSVP) -- Version 1 Functional Specificat ion»
September 1997.
[5] S. Blake, D. Black M. Carlson,E. Davies, Z. Wang, W. Weiss «RFC
2475: An Architecture for D ifferentiat ed Se rvice s » D ec ember 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. Heinane n, , F.Baker , W. Wei ss, J. Wrocla wski; «RFC 2 597 : Assured
Forwarding PHP Group», June 1999.
[9] W. Fang, Seddigh, B. Nandy «RFC2859: A Ti me Sliding Window Three
Colour M arker (TSWTCM) » Jun e 200 0.
[10] J. Heinanen, R. Guerin «RFC2698: A Two Rate Three Color Marker
(TRTCM) » September 1999
[11 ] T. Ahm ed, G. B urid an t, A. M ehaou a, «Enca psul ati on a nd Ma rki ng of
MPEG-4 Video over IP Differentiated Services» i n IEEE ISCC 01.
Tuni sia, Jul y 2001.
[1 2] Werner Alm esb erger, Ja mal H adi Sal im, Alexey Kuzn ets ov
«Di fferentiated 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(517.8ro)1 (n)-8)-7.e)20.3(.1( o-.8ro)1v9(51 S)1-18s9 -1.1-7.e)20(n)-8)l(.1( ]TJ2.239(51b7.e)20jS)1-18e(si)2.6()-8)tS

Fig. 3: MPEG-4 Video Layered Streams
Fig. 4: Packet dro ps in Best Effort
scenario
- Network Load 80%-
Fig. 5: Packet dro ps in Best Effort
scenario
Network Load > 95%
Fig. 6: Packet drops with IP Diffserv
- Network Load of 80% -
Fig. 7: Packet dro ps with IP Diffserv
- Network Load > 95% -
Fig. 8 : End- to-end transfer d ela y with IP
Be st E ffo rt
- 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 Lo ad o f 80% -
Fig. 11: End-to-end Transfer Delay with
IP Di ffse r v
- Network Load > 95% -
0-7803-7208-5/01/$17.00 (C) 2001 IEEE