Cost-Effective Video
Streaming Techniques
Kien A. Hua
School of EE & Computer Science
University of Central Florida
Orlando, FL 32816-2362
U.S.A
Server Channels
• Videos are delivered to clients as a
continuous stream.
• Server bandwidth determines the number
of video streams can be supported
simultaneously.
• Server bandwidth can be organized and
managed as a collection of logical channels.
• These channels can be scheduled to deliver
various videos.
Using Dedicated Channel
Video Server
Client
Client
Client
Client
Too Expensive !
• FCFS
Waiting queue
new
request
7
7
Resources
7
Batching
• MQL (Maximum Queue Length First)
longest queue length
Waiting queue for video i
new
request
Resources
Can multicast
provide true
VoD ?
• MFQ (Maximum Factored Queue Length)
l1
l1
f1
Access frequency
of video 1
Waiting queue for video i
new
request
Resources
ln
is the largest
fn
Challenges – conflicting goals
• Low Latency: requests must be served
immediately
• Highly Efficient: each multicast must
still be able to serve a large number
of clients
Some Solutions
• Patching
[Hua98]
• Range Multicast
[Hua02]
Patching
Video
Regular
Multicast
A
Proposed Technique: Patching
Skew point
Video
t
Patching Stream
Regular
Multicast
Video Player
Buffer
B
A
Proposed Technique: Patching
Video
2t
Skew point is absorbed by client buffer
Regular
Multicast
Video Player
Buffer
B
A
Client Design
Regular Multicast
Patching Multicast
Video
Server
Patching
Stream
Lr
Regular
Stream
Lp
Lr
Lp
Lr
Data Loader
Video
Player
Video
Player
Video
Player
Client A
Client B
Client C
Buffer
Server Design
Server must decide when to schedule a regular
stream or a patching stream
time
r
p
p
p
r
p
p
A
B
C
D
E
F
G
Multicast group
Multicast group
Two Simple Approaches
• If no regular stream for the same
video exists, a new regular stream is
scheduled
• Otherwise, two policies can be used
to make decision: Greedy Patching
and Grace Patching
Greedy Patching
Patching stream is always scheduled
Buffer Size
Buffer Size
Video Length
A
B
Shared Data
C
Shared Data
Shared Data
D
Time
Grace Patching
If client buffer is large enough to absorb the
skew, a patching stream is scheduled;
otherwise, a new regular stream is scheduled.
Buffer Size
Video Length
A
Shared Data
B
Regular Stream
C
Time
Performance Study
• Compared with conventional batching
• Maximum Factored Queue (MFQ) is
used
• Performance metric is average
service latency
Simulation Parameters
Parameter
Default
Range
Number of videos
100
N/A
Video length (minutes)
90
N/A
Video Access Skew factor
0.7
N/A
Server bandwidth (streams)
1,200
400-1,800
Client buffer (min of data)
5
0-10
Request rate (requests/min)
50
10-90
Number of requests
200,000
N/A
Effect of Server Bandwidth
Average Latency (Seconds)
600
500
Conventional Batching
Greedy Patching
Grace Patching
400
300
200
100
0
400
600
800
1000
1200
1400
1600
Server Communication BW (streams)
Defection
Request Rate
Client Buffer
No
50 arrivals/minute
5 minutes
1800
Effect of Client Buffer
200
Average Latency (seconds)
180
160
140
120
100
80
Conventional Batching
60
Greedy Patching
Grace Patching
40
20
0
0
1
2
3
4
5
6
7
8
Client Buffer Size (minutes of data)
9
Defection
Request Rate
Server Bandwidth
No
50 arrivals/minute
1,200 streams
10
Effect of Request Rate
Average Latency (seconds)
250
200
150
100
Conventional Batching
Greedy Patching
Grace Patching
50
0
10
20
30
40
50
60
70
80
90
Request Rate (requests/minutes)
100
Defection
Client Buffer
Server Bandwidth
No
5 minutes
1,200 streams
110
Optimal Patching
time
patching window
patching window
r
p
p
p
r
p
p
A
B
C
D
E
F
G
Multicast group
Multicast group
What is the optimal patching window ?
Optimal Patching Window
• D is the mean total amount of data
transmitted by a multicast group
• Minimize Server Bandwidth Requirement,
D/W , under various W values
Buffer Size
Buffer Size
Video Length
A
W
Optimal Patching Window
• Compute D, the mean amount of data
transmitted for each multicast group
• Determine  , the average time duration
of a multicast group
• Server bandwidth requirement is D/
which is a function of the patching period
• Finding the patching period that minimize
the bandwidth requirement
Candidates for Optimal
Patching Window
Piggybacking [Golubchik96]
new arrivals
C
+5%
-5%
B
A
departures
•Slow down an earlier service and speed up the new
one to merge them into one stream
•Limited stream sharing due to long catch-up delay
•Implementation is complicated
Concluding Remarks
• Unlike conventional multicast, requests can
be served immediately under patching
• Patching makes multicast more efficient by
dynamically expanding the multicast tree
• Video streams usually deliver only the first
few minutes of video data
• Patching is very simple and requires no
specialized hardware
Patching on Internet
• Problem:
– Current Internet does not support
multicast
• A Solution:
– Deploying an overlay of software
routers on the Internet
– Multicast is implemented on this overlay
using only IP unicast
Content Routing
Each router
forwards its
Find messages
to other routers
in a round-robin
manner.
Root
Router
Server
Router
A
Router
E
My
Router ?
Router
D
No
Find (1)
Find (2)
Router
C
Client
Client
Yes
Video
stream
Router
D
Find
Router
B
Client
Removal of An Overlay Node
Server
A
Server
B
A
E
D
F
G
D
B
G
C
C
Client
Client
Before adjustment
E
After adjustment
Inform the child nodes to reconnect to the
grandparent
Failure of Parent Node
A
A
E
D
D
B
F
E
B
G
G
C
C
Client
Client
Before adjustment
After adjustment
– Data stop coming from the parent
– Reconnect to the server
Slow Incoming Stream
B
A
E
A
D
Sl
ow
F
G
C
Before adjustment
E
D
B
F
G
C
After adjustment
Reconnect upward to the grandparent
Downward Reconnection
A
A
E
D
E
D
Slow
B
Slow
F
G
C
Before adjustment
B
F
G
C
After adjustment
• When reconnection reaches the server, future
reconnection of this link goes downward.
• Downward reconnection is done through a sibling node
selected in a round-robin manner.
• When downward reconnection reaches a leave node,
future reconnection of this link goes upward again.
Limitation of Patching
• The performance of Patching is
limited by the server bandwidth.
• Can we scale the application beyond
the physical limitation of the server ?
Multicast
Chaining
3 video
streams
Video server
7 video
streams
Video server
Video server
Dedicated Channels
Only one
video stream
Batch
1
Batch 2
Batch
3
client
A virtual
batch
Network
cache
• Using a hierarchy of multicasts
• Clients multicast data to other clients in the
downstream
• Demand on server bandwidth is substantially
reduced
Chaining
Video Server
Client A
Screen
Client B
disk
Screen
disk
Client C
Screen
– Highly scalable and efficient
– Implementation is complex
disk
Range Multicast
[Hua02]
• Deploying an overlay of software routers on
the Internet
• Video data are transmitted to clients through
these software routers
• Each router caches a prefix of the video
streams passing through
• This buffer may be used to provide the entire
video content to subsequent clients arriving
within a buffer-size period
Range Multicast Group
• Four clients join the
same server stream
at different times
without delay
• Each client sees the
entire video
Video
Server
0
C4
Root
R3
11
0
R1
C2
7
R6
11
7
R4
7
7
R7
0
Buffer Size: Each router
can cache 10 time
units of video data.
Assumption: No
transmission delay
R2
8
R5
8
R8
0
8
C1
C3
Multicast Range
• All members of a
conventional multicast
group share the same
play point at all time
– They must join at the
multicast time
• Members of a range
multicast group can have
a range of different play
points
– They can join at their own
time
Video
Server
0
C4
Root
R3
11
0
R1
C2
7
R6
11
7
R4
7
7
R7
0
R2
8
R5
8
R8
0
8
C1
C3
Multicast Range at time 11: [0, 11]
Network Cache Management
• Initially, a cache chunk is
free.
• When a free chunk is
dispatched for a new
stream, the chunk becomes
busy.
• A busy chunk becomes hot
if its content matches a
new service request.
New stream
arrives
busy
A service
request arrives
before the chunk
is full
free
Replaced
by a new
stream
Last
service
ends
hot
A service
request arrives
before the chunk
is full
RM vs. Proxy Servers
Proxy Servers
Range Multicast
Popular data are
heavily duplicated if
we cache long videos.
RM routers cache
only a small leading
portion of the video
passing through
Caching long videos is
not advisable. Many
data must still be
obtained from the
server
Majority of the data
are obtained from the
network.
2-Phase Service Model
(2PSM) [Hua99]
Browsing Videos in a Low
Bandwidth Environment
Search Model
• Use similarity matching or keyword
search to look for the candidate
videos.
• Preview some of the candidates to
identify the desired video.
• Apply VCR-style functions to search
for the video segments.
Conventional Approach
Server
S0
S1
S2
S3
...
Client
S0
display S0
S1
display S1
1. Download So
2. Download S1
3.
S2
display S2
S3
...
Time
Advantage:
while playing S0
Download S2
while. playing S1
.
.
Reduce wait time
Disadvantage: Unsuitable for searching video
Search Techniques
• Use extra preview files to support the
preview function
 Requires more storage space
 Downloading the preview file adds delay
• Use separate fast-forward and fastreverse files to provide the VCR-style
operations
 Requires more storage space
 Server can become a bottleneck
Challenges
How to download the preview frames for FREE ?
No additional delay
No additional storage requirement
How to support VCR operations without VCR files ?
No overhead for the server
No additional storage requirement
2PSM – Preview Phase
R
L
5
11 17 23 29 35 41 47 53 59 65 71 77 83 89 95 101 107 113 119 125 131 137 143 149 155 161 167 173 179 185 191
4
10 16 22 28 34 40 46 52 58 64 70 76 82 88 94 100 106 112 118 124 130 136 142 148 154 160 166 172 178 184 190
3
9
15 21 27 33 39 45 51 57 63 69 75 81 87 93 99 105 111 117 123 129 135 141 147 153 159 165 171 177 183 189
2
8
14 20 26 32 38 44 50 56 62 68 74 80 86 92 98 104 110 116 122 128 134 140 146 152 158 164 170 176 182 188
1
7
13 19 25 31 37 43 49 55 61 67 73 79 85 91 97 103 109 115 121 127 133 139 145 151 157 163 169 175 181 187
0
6
12 18 24 30 36 42 48 54 60 66 72 78 84 90 96 102 108 114 120 126 132 138 144 150 156 162 168 174 180 186
downloaded
during Step 1
90
42
18
6
114
66
30
.
.
.
downloaded
during Step 2
138
54
78
.
.
.
102
GOFs available for previewing after 3 steps
The preview quality improves gradually.
downloaded
during Step 3
162
126
.
.
.
150
174
downloaded
during
. Step 4
.
.
2PSM – Playback Phase
Server
PU0
L0
R0
PU1
L1
R1
PU2
L2
R2
PU3
L3
R3
PU4
L4
R4
PU5
L5
R5
PU6
L6
R6
L7
...
Client
L
R
0
0
display
PU0 L1
R
display1 PU1 L2
R
display2 PU2 L3
R
display3 PU3 L4
R
display4 PU4 L5
R
display5 PU5 L6
R
display6 PU6 L7
...
t
Download during Initialization Phase
Download during Playback Phase
Remarks
1. It requires no extra files to provide the
preview feature.
2. Downloading the preview frames is free.
3. It requires no extra files to support
the VCR functionality.
4. Each client manages its own VCR-style
interaction. Server is not involved.
2PSM Video Browser