Assessment of Jitter in Live Streaming for QoS support in NGN

S.K Singh Research Scholar-Mukesh atel School of !echnolog" Management an# $ngineering NM%MS &niversit"' Santacru( Mum)ai-*+++,!elephone num)er' ./0/1/2*3*+1,

Mahen#ra Sharma
!hakur 4ollege of Science an# 4ommerce !hakur 5illage' Kan#ivali 6$ast7 Mum)ai -*++0+0 !elephone num)er' ./0/8-/08-*80

Sneha oo9ar"
.G Stu#ent-!hakur 4ollege of Science an# 4ommerce !hakur 5illage' Kan#ivali 6$ast7 Mum)ai -*++0+0 !elephone num)er' ./0//18*0328+

sksingh@tcsc.org.in

smahendra@live.com

sneha.poojary@yahoo.com

Abstract: During the last decade, the multitude of advances attained in terminal computers and the deployment of high speed networks have led to a recent surge of interest in Quality of Service (QoS) for multimedia applications. When a multimedia file is sent, the number of packets and their si es are more than the normal ones resulting in an efficiency drop. !omputer networks able to support multimedia applications with diverse QoS performance re"uirements are evolving. #o ensure that multimedia applications will be guaranteed the re"uired QoS, it is not enough to merely commit resources. $t is important that distributed multimedia applications ensure end%to%end QoS of media streams. #hus there is a need to provide real%time QoS monitoring that is capable of monitoring the multimedia file while transmitting it over the network. #he &ava 'edia (ramework (&'() enables audio, video and other time%based media to be added to )ava applications. #he transmission of the file over the network can be brought about by &'( and &'(*+#,. #he &'( -,$ is used to read the source and converts it into packeti ed +#, data. #he +#, -,$ implementation included in &'( will then stream the media using the +#, protocol.+#, applications are often divided into those that need to be able to receive data from the network (+#, !lients) and those that need to be able to transmit data across the network (+#, Servers). $n this paper $ have discussed about +#, server which streams a stored*live video to the +#, client where the video is then played. #he main ob)ective here is to assess the +eceiver +eports(++) sent by the client to the server consisting of the (eedback +eport which includes )itter. #his paper aims to compare the reports generated for different video and audio codec.s for determining which codec is most suitable for media transmission, depending on the bandwidth available. +eception "uality feedback will be useful not only for the sender but also for the receiver and third%party monitors. Keywords-QoS; RTP; Multimedia;Java Medi Framework;

%. %N!R;<&4!%;N !he heterogeneous nature of the %nternet makes the unicast an# multicast transmission of real-time multime#ia #ata a challenge. !he propose# mechanism uses real-time transmission protocol=real-time control transmission protocol 6R! =R!4 7 for the transmission of the multime#ia #ata. !he R! protocol seems to )e the stan#ar# protocol for the transmission of multime#ia #ata over % . Real-Time Streaming: !o ena)le real-time streaming' #e#icate# streaming me#ia servers an# streaming protocols' such as Real-!ime !ransport rotocol 6R! 7' Real-!ime 4ontrol rotocol6R!4 7 are re>uire#. The system proposed centers on the following key technologies: R! as media transport protocol. R! the Real-time !ransport rotocol is use# for the transmission of the multime#ia #ata from the sen#er to the receiver. RTP Session is esta)lishe# for each multime#ia stream. A session consists of an % a##ress ?ith a pair of ports for R! an# R!4 . @or eAample' au#io an# vi#eo streams ?ill have separate R! sessions' @or eAample' if )oth au#io an# vi#eo are use# in a conference' one session is use# to transmit the au#io #ata an# a separate session is use# to transmit the vi#eo #ata. !his ena)les participants to choose ?hich me#ia t"pes the" ?ant to receive .

RTCP offers the following service to applications: 0. QoS monitoringB !his is one of the primar" services of R!4 . R!4 provi#es fee#)ack to applications a)out the transmission >ualit". R!4 uses sen#er reports an# receiver reports' ?hich contain useful statistical information #uring the transmission of the #ata. !his statistical information is ver" useful' )ecause it can )e use# for the implementation of congestion control mechanisms.

%%. SCS!$M AR4D%!$4!&R$ !he s"stem is compose# of a source an# a receiver' or a group of receivers' ?hich all )ecome mem)ers of a multicast group )" 9oining this group using a multicast % a##ress an# a given port num)er. !he source sen#s to the receiver its compresse# live au#io an# vi#eo content for the streame# session each on a separate R! stream. !he receiver is capa)le then of receiving the R! streams an# pla"ing them )ack. <uring the session time each receiver issues a series of R!4 reports for each receive# stream perio#icall". !hese reports are #estine# to the same multicast % a##ress an# port num)er. !he" help in i#entif"ing the most recent receiving status of this receiver mainl" regar#ing 9itter. R! applications are often #ivi#e# into those that nee# to )e a)le to receive #ata from the net?ork 6R! 4lients7 an# those that nee# to )e a)le to transmit #ata across the net?ork 6R! Servers7. RTP ServerB streams a store# vi#eo or captures the me#ia from a Ee)cam an# a Microphone an# then streams it to the clients )" specif"ing a Multicast % a##resses an# port num)ers. !he R! 4lient listens on a specific port for streams coming from the sen#er. RTP ClientB its #evelopment is )ase# on a Java program that uses JM@. !hrough the graphical user interface' the users can select the Me#ia stream that the" ?ant to pla")ack. RTCP Receiver Reports: After receiving several #ata packets' the R! -)ase# client calculates some performance measurements 6or statistics7 ?hich is then sent to the me#ia streaming component6R! server7 in the form of Receiver Report 6RR7 through the R!4 channel. 0. Interarrival Jitter (IJ : the mean #eviation 6smoothe# a)solute value7 of the #ifference in packet spacing at the receiver compare# to the sen#er for a pair of packets.

@ig 0. Architecture of &nicast !ransmission

@ig 2. Architecture of Multicast !ransmission The server architect!re consists of the following mod!les: 0. "!ltimedia #ata: !he a#aptive transmission application ma" support various multime#ia formats 6for eAample M $G' J $G' D.2-3 etc7 .@or eAample M $G format can )e use# to serve the users of the local area net?ork 6?ho have faster net?ork connection ?ith the sen#er7 an# D.2-3 format in or#er to serve #istant users ?ith slo? net?ork connections. $eed%ack analysis: !his mo#ule logicall" eAists )et?een the source an# the receiver. %n or#er to trace an# monitor the receiving status of receivers. !he role of this mo#ule is to #etermine the net?ork con#ition mainl" #ela" 9itter information' ?hich are provi#e# )" R!4 receiver reports. &!ality adaptation: %t is responsi)le for the a#aptation of the multime#ia transmission >ualit"' in or#er to match ?ith the current net?ork con#itions.

2.

!he architecture propose# for the implementation of the streaming application is )ase# on the client F server mo#el.

3.

*. ,.

!his mo#ule can )e implemente# )" changing the Au#io=5i#eo enco#ing . Packet sched!ler: !his mo#ule is responsi)le for the encapsulation of multime#ia information in the R! packets. %n a##ition' this mo#ule is responsi)le for the transmission of the R! packets in the net?ork Receiver %!ffer: !he use of the )uffer on the receiver for the implementation of such applications is ver" important. !he receiver application stores the incoming #ata to the )uffer )efore starting to present #ata to the user. !he presentation of the multime#ia #ata to the user starts onl" after the necessar" amount of the #ata is store# in the )uffer. $eed%ack: !his mo#ule is responsi)le of monitoring the transmission >ualit" of the multime#ia #ata an# informing the sen#er. !he monitoring of the transmission >ualit" is )ase# on R!4 receiver reports that the receiver sen#s to the sen#er. Eith the a)ove information the fee#)ack anal"sis mo#ule of the sen#er #etermines the net?orkGs con#ition. #ecoder: !his mo#ule rea#s the #ata packets from the receiver )uffer an# #eco#es the enco#e# multime#ia information. <epen#ing on the packet losses an# the #ela" #uring the transmission of the packets' the >ualit" of the multime#ia presentation can var". !he #eco#ing an# the presentation of the multime#ia #ata can stop' if the appropriate amount of #ata #oes not eAist in the )uffer. 'ser #isplay: %t is responsi)le for the presentation of the multime#ia #ata to the user. %%%. %M L$M$N!A!%;N

()

Streaming So!rce

The client architect!re consists of the following mod!les: 0.

2.

@ig 3. R! Stream ro#ucing in JM@ @ig.3 sho?s the R! stream pro#ucing steps in JM@. !he re>uire# components to stream an au#io=vi#eo session are namel" a <ata Source' rocessor' an# R! Manager. !he <ataSource can either )e a real-time capture# me#ia or store# me#ia file' the processor is use# to enco#e this <ataSource an# then the role of the R! Manager is to manage the esta)lishe# session. ;ur mission ?as to make our streaming source real-time a#aptive )" a##ing processing transmission controls to it in or#er to affect the me#ia transco#ing. !hese controls ena)le changing the me#ia enco#ing parameters . !he co#e use# in this 9o) containe# the JM@ !rack4ontrol class an# its get!rack4ontrols67 an# get@ormat67 metho#s. Dence the transmission controls are responsi)le for the a#aptation of the multime#ia transmission >ualit"' in or#er to match ?ith the current net?ork con#itions. !aking eAample enco#ing algorithms for )oth au#io an# vi#eo use# in our s"stem ?e ?oul# mention G283HR! ''M $GA&<%;HR! for au#io streams an# D2-3HR! 'J $GHR! for vi#eo streams. *) Receivers JM@ Players an# Processors provi#e presentation mechanisms for the R! streams. A separate pla"er is use# for each receiving stream. Cou ma" construct a Player for an R! stream through the stan#ar# Manager createPlayer( mechanism. @ig.* - sho?s )oth the au#io an# vi#eo pla"ers of JM@. !he vi#eo pla"er is at the top an# the au#io is at the )ottom section of the figure.

3.

*.

;ur s"stem is #emonstrate# using the Java Me#ia @rame?ork 6JM@7 as a me#ia-#eveloping tool. JM@ has the a#vantage of implementing R! =R!4 functionalities in real time using frien#l" A %s an# saving the effort of )uil#ing these capa)ilities from scratch. Ee can take a closer look to the implementation of each of our s"stem mo#ules ?hich are the Streaming Source6R! Server7' Receiver6R! 4lient7 an# @ee#)ack Anal"sis.

!he RTCPReport also has a metho# calle# get$eed%ack( that returns a vector of RTCP$eed%ack o)9ects. $ach RTCP$eed%ack o)9ect conve"s information a)out the reception of one incoming stream.

%5.

SCS!$M $R@;RMAN4$ J ASS$SSM$N!

@ig *. 5i#eo an# Au#io la"ers Iesi#es receiving an# presenting the R! stream' Receiver also has QoS self-a#aptation a)ilit". !he receiver has the option to #eselect a stream' au#io or vi#eo to make most use of his )an#?i#th. !he +!fferControl( A % allo?s the receiver to a#9ust the actual receiving )uffer si(e an# threshol# . ,) $eed%ack -nalysis

;ur test-)e# environment consists of t?o or more laptops connecte# either via ?ire# or ?ireless a#-hoc net?ork running Microsoft Ein#o?s Kp or Ein#o?s8 ;perating S"stem . !he Source laptop uses either store# or real-time capture# au#io=vi#eo me#ia to stream to net?ork. !his me#ia normall" passe# )" t?o live compression processesL one for au#io an# another for vi#eo' each )" one of the compression techni>ues supporte# )" JM@. ;nce the Receiving laptops 9oin the multicast group' it pla"s )ack the streame# me#ia through JM@ pla"ers. !he ?hole setup is )elieve# to resem)le the real?orl# %nternet environment. resentl"' there are various kin#s of net?orksL ?ire# an# ?ireless that co-eAists ?ith each other. !hese net?orks have QoS parameters that #iffer consi#era)l". Ehen ?e speak of the availa)ilit" of the )an#?i#th the transmission is #epen#ent upon ho? much of )an#?i#th is availa)le. Lo? )an#?i#th automaticall" lea#s to poor transmission rates. !he s"stem ?ill )e teste# at var"ing levels of )an#?i#th an# the efficienc" ?ill )e calculate# )ase# on a pre#efine# set of >ualit" criteria. !he >ualit" criteria inclu#es Jitter. !he interarrival 9itter fiel# provi#es short-term measure of net?ork congestion. !he 9itter measure ma" in#icate congestion )efore it lea#s to packet loss. Since the interarrival 9itter fiel# is onl" a snapshot of the 9itter at the time of a report' it ma" )e necessar" to anal"se a num)er of reports from one receiver over time or from multiple receivers' e.g.' ?ithin a single net?ork. @irst ?e investigate# the feasi)ilit" ofB07 G823HR! J M $GA&<%;HR! au#io co#ec. 27D2-3HR! J J $GHR! vi#eo co#ec.

!he role of this mo#ule is to collect the Receiver Reports sent )" multicast session receivers a))reviate# as RR. %n JM@' there is an interface calle# RTCPReport to represent )oth R!4 SR an# RR packets. !he metho# getReports( returns a vector containing the last SR or RR reports sent )" the participants.

IAN<E%<!D

4;<$4

J%!!$R L%5$

J%!!$R S!;R$< 30 3+ 3* 32 30 -0+ -+2 -0+ -22 -0, -2, /2+ 0-*+ *88+1 0022 0+0+2 0,1 220-,

IAN<E%<!D

4;<$4

J%!!$R L%5$

J%!!$R S!;R$< 03/ 02/ 0-* 0/0 0*/ 03+3 0+38 03// 0*0* 0*20,31 *-* -3* 8+1 0-/, 1/0 -81*2*/ ,0/1 0-101-,

0++M)ps

G823HR!

*/* */* */8 */3 ,++

,*M)ps

G823HR!

,+2 */2 *** *88 */8

0++M)ps

M $GA&<%;H R!

,2,* ,++0 ,3++ ,203 ,*,/ ,200

,*M)ps

M $GA&<%;H R!

*,** *28+ *223 *+32 *-+2 **00

0++M)ps

D2-3HR!

*108 **3+ *0/* *1/*382

,*M)ps

D2-3HR!

03/2 /,3 0-8+ 0**, 0,/0

0++M)ps

J $GHR!

-, 02* 31 3+ 08

,*M)ps

J $GHR!

233, *,8* 310/ 2,3, 3320

!AIL$ 0B-S!A!%S!%4S ;@ J%!!$R @;R A&<%; AN< 5%<$; 4;<$4GS E%!D 5ARC%NG IAN<E%<!D

@igB, Jitter for G823HR! 6L%5$7 ?ith ,*M)ps )an#?i#th

@igB1 Jitter for G823HR! 6S!;R$<7 ?ith 0++M)ps )an#?i#th

@igB- Jitter for G823HR! 6S!;R$<7 ?ith ,*M)ps )an#?i#th

@igB/ Jitter for M $GA&<%;HR! 6L%5$7 ?ith ,*M)ps )an#?i#th

@igB8 Jitter for G823HR! 6L%5$7 ?ith 0++M)ps )an#?i#th

@igB0+ Jitter for M $GA&<%;HR! 6S!;R$<7 ?ith ,*M)ps )an#?i#th

@igB00 Jitter for M $GA&<%;HR! 6L%5$7 ?ith 0++M)ps )an#?i#th

@igB0* Jitter for D2-3HR! 6S!;R$<7 ?ith ,*M)ps )an#?i#th

@igB02 Jitter for M $GA&<%;HR! 6S!;R$<7 ?ith 0++M)ps )an#?i#th

@igB0, Jitter for D2-3HR! 6L%5$7 ?ith 0++M)ps )an#?i#th

@igB03 Jitter D2-3HR! 6L%5$7 ?ith ,*M)ps )an#?i#th

@igB0- Jitter for D2-3HR! 6S!;R$<7 ?ith 0++M)ps )an#?i#th

@igB08 Jitter J $GHR! 6L%5$7 ?ith ,*M)ps )an#?i#th

@igB2+ Jitter for J $GHR! 6S!;R$<7 ?ith 0++M)ps )an#?i#th 5. 4;N4L&S%;N AN< @&!&R$ E;RK %n this paper ?e have #iscovere# a ?a" to support applicationlevel QoS control for streaming applications over the highl" heterogeneous %nternet. !he streaming applications #eplo"ment has the )enefit that there is no nee# for changes or an" eAtra configuration in net?ork #evices #ue to the fact that the a#aptation takes place at the en# point 6sen#er an# receiver applications7 an# not in the net?ork. Ee ma" conclu#e that G823=R! is more suita)le than M $GA&<%;HR! au#io co#ec. D2-3=R! vi#eo enco#ing is ver" tolerant to ?ork un#er lo? )it rates' it manage# to )e clear in )oth store# an# live vi#eo ?hereas J $G=R! enco#ing offers lo? 9itter )ut is suite# onl" to a high-)an#?i#th environment. !here are man" QoS relate# issues that coul# )e consi#ere# as continuation ?ork for this research' such as au#io-visual s"nchroni(ation' resource reservation' etc. A4KN;EL$<GM$N! ;ur sincere thanks to !hakur e#ucational trust an# management to provi#e all the facilities an# infrastructure to carrie# out the research ?ork. R$@$R$N4$S
M0N Moh# @arhan Ngatman ' M# Asri Nga#i ' Johan M. SharifL !omprehensive Study of #ransmission #echni"ues for +educing ,acket /oss and Delay in 'ultimedia over $,, %J4SNS %nternational Journal of 4omputer Science an# Net?ork Securit"' 5;L.1 No.3' March 2++1. Jeongnam CounL Jun KinL Ming-!ing SunL (ast video transcoding architectures for networked multimedia applications %S4AS 2+++ Geneva. !he 2+++ %$$$ %nternational S"mposium on 5olume *' 21-30 Ma" 2+++. Ra9a' G.L Mir(a' M.J.L ,erformance comparison of advanced video coding 0.123 standard with baseline 0.124 and 0.1245 standards. 4ommunications an# %nformation !echnolog"' 2++*. %S4%! 2++*. %$$$ %nternational S"mposium. 5olume 2' 2--2/ ;ct. 2++*.

@igB01 Jitter for J $GHR! 6S!;R$<7 ?ith ,*M)ps )an#?i#th

M2N

@igB0/ Jitter for J $GHR! 6L%5$7 ?ith 0++M)ps )an#?i#th

M3N