Mul$media

 Networking  

#3  Mul$media  Networking  
Semester  Ganjil  
PTIIK  Universitas  Brawijaya  

#3  Requirements  of  Mul$media  

Networking  
 Schedule  of  Class  Mee$ng  
1.  Introduc$on     8.  Overlay  Mul$cast  
2.  Applica$ons  of  MN   9.  CDN:  Solu$ons  
3.  Requirements  of  MN   10. CDN:  Case  Studies  
4.  Coding  and   11. QoS  on  the  Internet:  
Compression   Constraints  
5.  RTP   12. QoS  on  the  Internet:  
6.  IP  Mul$cast   Solu$ons  
7.  IP  Mul$cast  (cont’d)     13. Discussion  
14. Summary  
#3  Requirements  of  Mul$media  
Networking  
 Today’s  Outline  
Requirements  of  Mul$media  Networking  
–  Client-­‐side  buffering  
–  Removing  Ji[er    
–  Recovering  from  Packet  Loss  
 
Coding  and  Compression  
–  Digital  Audio    
–  Digital  Video  

#3  Requirements  of  Mul$media  

Networking  
Cumulative data
Streaming  stored  video:    

2. video
sent
1.  video 3. video received,
recorded network delay played out at client
(e.g., 30 (fixed in this (30 frames/sec) time
frames/sec) example)

streaming: at this time, client

playing out early part of video,
while server still sending later
part of video
#3  Requirements  of  Mul$media  
Networking  
 Streaming  stored  video:  systems  
  UDP  Streaming  
  unpredictable  available  bandwidth    constant-­‐rate  
streaming  can  fail  
  requires  a  media  control  server    interac$vity  
  many  firewalls  block  UDP  traffic  
  HTTP  Streaming  &  Adap$ve  Streaming  
  TCP  conges$on  control  &  retransmission    delay  
playout  
  client-­‐side  buffering  &  prefetching    smooth  playout  
 
  Majority  of  today’s  systems  employ  HTTP  streaming  and  
adap$ve  HTTP  streaming  

#3  Requirements  of  Mul$media  

Networking  
 Streaming  stored  video:  revisited  
constant bit
rate video
Cumulative data

transmission

t0 t0+2Δ time
t0+Δ

•  Δ  =  fixed  $me,  each  video  block  played  out  

$me  
#3  Requirements  of  Mul$media  
Networking  
 Streaming  stored  video:  revisited  
constant bit
rate video client video
Cumulative data

transmission reception

variable
network
delay
t0 t0+2Δ t1 t2 time
t0+Δ t1+Δ

•  variable  end-­‐to-­‐end  delays,  each  video  

block  may  experience  different  delays  
#3  Requirements  of  Mul$media  
Networking  
 Streaming  stored  video:  revisited  
constant bit
rate video client video constant bit
Cumulative data

transmission reception rate video

playout at client

buffered
video
variable client
network playout
delay delay
t0 t0+2Δ t1 t2 t3 time
t0+Δ t1+Δ t3+Δ

•  Client-­‐side  buffering  is  used  to  mi$gate:  

•  varying  end-­‐to-­‐end  delays  
•  varying  available  bandwidth  
#3  Requirements  of  Mul$media  
Networking  
 Today’s  Outline  
Requirements  of  Mul$media  Networking  
–  Client-­‐side  buffering  
–  Removing  Ji;er    
–  Recovering  from  Packet  Loss  
 
Coding  and  Compression  
–  Digital  Audio    
–  Digital  Video  

#3  Requirements  of  Mul$media  

Networking  
Removing  Ji[er  in  VoIP  
•  Ji[er  can  be  removed  using:  
•  prepend  each  chunk  with  sequence  number  &  
+mestamp,  
•  delaying  playout  
•  VoIP  characteris$cs:  
–  64  kbps  during  talk  spurt  
–  pkts  generated  only  during  talk  spurts  
–  20  msec  chunks  at  8  Kbytes/sec:  160  bytes  of  data  
–  typical  maximum  tolerable  delay:  400  ms  

#3  Requirements  of  Mul$media  

Networking  
 Delay  ji[er  
constant bit
rate client constant bit
Cumulative data

transmission reception rate playout

at client
variable
network

buffered
data
delay
(jitter)

client playout time

delay
•  end-­‐to-­‐end  delays  of  two  consecu$ve  packets:  
difference  can  be  more  or  less  than  20  msec  
(transmission  $me  difference)  
#3  Requirements  of  Mul$media  
Networking  
VoIP:  fixed  playout  delay  
•  receiver  a[empts  to  playout  each  chunk  
exactly  q  msecs  ajer  chunk  was  generated.  
–  chunk  has  $me  stamp  t:  play  out  chunk  at  t+q    
–  chunk  arrives  ajer  t+q:  data  arrives  too  late  for  
playout:  data  “lost”  
•  tradeoff  in  choosing  q:  
–  large  q:  less  packet  loss  
–  small  q:  be[er  interac$ve  experience  

#3  Requirements  of  Mul$media  

Networking  
VoIP:  fixed  playout  delay  
   sender  generates  packets  every  20  msec  during  talk  spurt.  
   first  packet  received  at  $me  r  
   first  playout  schedule:  begins  at  p  
   second  playout  schedule:  begins  at  p’  
packets
Two  policies,  wait  p  or  wait  p’  
-­‐  p  has  less  delay,  but  one  missed  
-­‐  p’  has  no  missed,  but  higher  delay  

packets loss
generated
packets
playout schedule
received
p' - r

playout schedule
p-r

time

r
#3  Requirements  of  Mul$media  
p p'
Networking  
Adap$ve  playout  delay  (1)  
•  goal:  low  playout  delay,  low  late  loss  rate  
•  approach:  adap$ve  playout  delay  adjustment:  
–  es$mate  network  delay,  adjust  playout  delay  at  
beginning  of  each  talk  spurt  
–  silent  periods  compressed  and  elongated  
–  chunks  s$ll  played  out  every  20  msec  during  talk  spurt  
•  adap$vely  es$mate  packet  delay:  (EWMA  -­‐  exponen$ally  
weighted  moving  average,  recall  TCP  RTT  es$mate):  

di = (1-α)di-1 + α (ri – ti)

delay estimate time received - time sent

small constant,
(timestamp)
after ith packet e.g. 0.1
measured end-to-end delay
#3  Requirements  of  Mof ith packet
ul$media  
Networking  
Adap$ve  playout  delay  (2)  
   also  useful  to  es$mate  average  devia$on  of  delay,  vi  :  

vi = (1-β)vi-1 + β |ri – ti – di|

•  es$mates  di,  vi  calculated  for  every  received        

packet,  but  used  only  at  start  of  talk  spurt  

•   for  first  packet  in  talk  spurt,  playout  $me  is:  

playout-timei = ti + di + Kvi

remaining  packets  in  talkspurt  are  played  out          

periodically  
  #3  Requirements  of  Mul$media  
Networking  
Adap$ve  playout  delay  (3)  
Q:  How  does  receiver  determine  whether  packet  is  first  
in  a  talk  spurt?  
•  if  no  loss,  receiver  looks  at  successive  $mestamps  
–  difference  of  successive  stamps  >  20  msec    talk  spurt  
begins.  
•  with  loss  possible,  receiver  must  look  at  both  $me  
stamps  and  sequence  numbers  
–  difference  of  successive  stamps  >  20  msec  and  sequence  
numbers  without  gaps  -­‐-­‐>  talk  spurt  begins.  

#3  Requirements  of  Mul$media  

Networking  
 Today’s  Outline  
Requirements  of  Mul$media  Networking  
–  Client-­‐side  buffering  
–  Removing  Ji[er    
–  Recovering  from  Packet  Loss  
 
Coding  and  Compression  
–  Digital  Audio    
–  Digital  Video  

#3  Requirements  of  Mul$media  

Networking  
 VoiP:  recovery  from  packet  loss  (1)  
Challenge:  recover  from  packet  loss  given  small  tolerable  
delay  between  original  transmission  and  playout  
•  each  ACK/NAK  takes  ~  one  RTT  
•  alterna$ve:  Forward  Error  Correc+on  (FEC)  
–  send  enough  bits  to  allow  recovery  without  retransmission  
 
simple  FEC  
•  for  every  group  of  n  chunks,  create  redundant  chunk  by  exclusive  
OR-­‐ing  n  original  chunks  
•  send  n+1  chunks,  increasing  bandwidth  by  factor  1/n  
•  can  reconstruct  original  n  chunks  if  at  most  one  lost  chunk  from  n
+1  chunks,  with  playout  delay  

#3  Requirements  of  Mul$media  

Networking  
 VoIP: Loss

1 2 3 4 Encode

Transmit

Decode

#3  Requirements  of  Mul$media  

Networking  
 VoIP: Loss

1 2 3 4 Encode

1 4
Transmit

Decode

#3  Requirements  of  Mul$media  

Networking  
 VoIP: Loss

1 2 3 4 Encode

1 4
Transmit

1 ??? ??? 4 Decode

What to do about the missing packets?

#3  Requirements  of  Mul$media  
Networking  
 VoIP: Recovering from Loss

1 1 2 2 3 3 4 Encode

1 3 4 Transmit

Decode

#3  Requirements  of  Mul$media  

Networking  
 VoIP: Recovering from Loss

1 1 2 2 3 3 4 Encode

1 3 4 Transmit

1 1 3 4 Decode

#3  Requirements  of  Mul$media  

Networking  
 VoiP:  recovery  from  packet  loss  (2)  
another  FEC  scheme:  
 “piggyback  lower    
quality  stream”    
 send  lower  resolu$on  
audio  stream  as    
redundant  informa$on  
 e.g.,  nominal    
stream  PCM  at  64  kbps  
and  redundant  stream  
GSM  at  13  kbps  
 non-­‐consecu$ve  loss:  receiver  can  conceal  loss    
 generaliza$on:  can  also  append  (n-­‐1)st  and  (n-­‐2)nd  low-­‐bit  rate  
chunk  
#3  Requirements  of  Mul$media  
Networking  
 VoiP:  recovery  from  packet  loss  (3)  

interleaving  to  conceal  loss:   •  if  packet  lost,  s$ll  have  most  

•  audio  chunks  divided  into  
smaller  units,  e.g.  four  5  msec   of  every  original  chunk  
units  per  20  msec  audio  chunk   •  no  redundancy  overhead,  but  
•  packet  contains  small  units   increases  playout  delay  
from  different  chunks  
#3  Requirements  of  Mul$media  
Networking  
 End  of  Today’s  Lecture  
Do  you  have  any  ques$on?  

#3  Requirements  of  Mul$media  

Networking