Saleable Techniques for Video on Demand Kien A. Hua School of EE & Computer Science University of Central Florida Orlando, FL U.S.A
Server Channels The unit of server capacity required to deliver a video stream is referred to as a channel. These channels are dispatched to deliver various video streams at different times.
Using Dedicated Streams Video Server Client Expensive Client Dedicated stream Not scalable
A Solution Using broadcast to share channels among users Broadcast is essentially “free” for a large user community
Traditional Multicast Video Server Client
Low Latency: requests must be served as soon as possible Conflicting Goals in Video Multicast ? High Efficiency: each multicast should wait to serve a larger number of clients Can we achieve both ?
Broadcast for VOD Requirement on server bandwidth is independent of the number of users the system is designed to support. Less expensive & more scalable !! Broadcast cannot deliver videos on demand ? True False ??
Simple Periodic Broadcast Staggered Broadcasting A new stream is started every interval for each video. The worst service latency is the broadcast period.
Limitation of Simple Periodic Broadcast Access latency can be improved only linearly with increases to the server bandwidth Double the number of channels to reduce the service latency in half Can we do better ?
Odd groupEven groupOdd group Even group Each video is fragmented into K segments, each repeatedly broadcast on a dedicated channel at the playback rate. The sizes of the K segments have the following pattern: [1, 2, 2, 5, 5, 12, 12, 25, 25, …, W, W, …, W] Skyscraper Broadcasting Size of larger segments are constrained to W (width of the “skyscraper”)
Generating Function The broadcast series is generated using the following recursive function: 1If n = 1, 2If n = 2 or 3, 2 · f(n - 1)+1If n mod 4 = 0. f(n-1)If n mod 4 = 1, 2 · f(n - 1) + 2If n mod 4 = 2, f(n – 1)If n mod 4 = 3 f(n) =
Skyscraper Broadcasting Playback Procedure The Odd Loader and the Even Loader download the odd groups and the even groups, respectively. The W-segments are downloaded sequentially using only one loader. As the loaders fill the buffer, the Video Player consumes the data in the buffer.
SB – Multiuser Example Each segment is available before it is needed for the playback Playback schedule:
Advantages of Skyscraper Broadcasting Unlimited scalability Service latency can be reduced exponentially with increases in server bandwidth Since W-segments are downloaded sequentially, buffer requirement is minimal. Skyscraper
Client Centric Approach (CCA) Segments are grouped according to the number of channels the clients can download simultaneously Inside each group, each segment is twice the size of the last segment The first segment of any group is the same size as the last segment of the previous group C = 3 (Clients have three loaders)
CCA Broadcasting Server broadcasts each segment at playback rate Clients use c loaders Each loader downloads its streams sequentially, –e.g., i th loader is responsible for segments i, i+c, i+2c, i+3c, … Equal-size W-segments are downloaded sequentially using one loader C = 3 (Clients have three loaders)
A CCA Example
Advantages of CCA It has the advantages of Skyscraper Broadcasting. It can leverage client bandwidth to improve performance.
UCF Video Jukebox
Cautious Harmonic Broadcasting (Segmentation Design) A video is partitioned into n equally-sized segments The first channel repeatedly broadcasts the first segment S 1 at the playback rate The second channel alternately broadcasts S 2 and S 3 repeatedly at half the playback rate Each of the remaining segment S i is repeatedly broadcast on its dedicated channel at 1/(i–1) the playback rate
Cautious Harmonic Broadcasting (Download & Playback Strategy) The client receives data from all streams for the video simultaneously. The client starts the playback as soon as it can download the first stream.
Cautious Harmonic Broadcasting Advantage: Better than Skyscraper Broadcasting in terms of server bandwidth requirement. Disadvantage: Requires many times more client bandwidth then Skyscraper Broadcasting does. Implementation Issues: The client must receive data from many channels simultaneously (e.g., 240 channels are required for a 2-hour video if the desired latency is 30 seconds). A storage subsystem capable of moving the read heads fast enough to multiplex among so many concurrent streams would be very expensive, if possible
Pagoda Broadcasting Data Fragmentation Each video is divided into equally-sized segments Using the following series to determine the number of segments for each channel {1, 3, 5, 15, 25, 75, 125, …} Segments appearing on a channel do not have to be consecutive 3 rd segment
Pagoda Broadcasting Download and Playback Strategy Each channel broadcasts data at the playback rate The client receives data from all channels simultaneously. It starts the playback as soon as it can download the first segment.
Pagoda Broadcasting Advantage & Disadvantage Advantage: Server bandwidth requirement is lower compared to Skyscraper Broadcasting Disadvantage: Client bandwidth requirement is many times higher than Skyscraper Broadcasting Achieving a maximum delay of 138 seconds for a 2-hour video requires each client to have a bandwidth five times the playback rate, e.g., approximately 20 Mbps for MPEG-2 System cost is significantly more expensive
New Pagoda Broadcasting New Pagoda Broadcasting improves on the original Pagoda Broadcasting. Client bandwidth requirement remains very high Example: Achieving a maximum delay of 110 seconds for a 2-hour video requires each client to have a bandwidth five times the playback rate. Approximately 20 Mbps for MPEG-2 System cost is very expensive
Total System Cost Service latency can be improved by increasing bandwidth in two ways: –Increasing client bandwidth, e.g., Harmonic Broadcasting, Pagoda Broadcasting, etc. This approach is expensive –Increasing server bandwidth, e.g., Skyscraper Broadcasting, CCA, etc. This approach is less expensive
Support Client Heterogeneity Using multi-resolution encoding Bandwidth Adaptor HeRO Broadcasting
Multi-resolution Encoding Encode the video data as a series of layers A user can individually mould its service to fit its capacity A user keeps adding layers until it is congested, then drops the higher layer Drawback: Compromise the display quality
Bandwidth Adaptors Advantage: All clients enjoy the same quality display
Requirements for an Adaptor An adaptor dynamically transforms a given periodic broadcast into another less demanding one The segmentation scheme must allow easy transformation of a broadcast into another CCA segmentation technique has this property
Two Segmentation Examples
Adaptation (1) Adaptor downloads from all broadcast channels simultaneously
Adaptation (2) Each sender routine retrieves data chunks from buffer, and broadcast them to the downstream For each chunk, the sender routine calls deleteChunk to decide if the chunk can be deleted from the buffer
Buffer Management insertChunk implements an As Late As Possible policy, i.e., –If another occurrence of this chunk will be available from the server before it is needed, then ignore this one, else buffer it. deleteChunk implements an As soon As Possible policy, i.e., –Determine the next time when the chunk will need to be broadcast to the downstream. –If this moment comes before the availability of the chunk at the server, then keep it in storage, else delete it.
The Adaptor Buffer Computation is not intensive. It is only performed for the first chunk of the segment, i.e., –if this initial chunk is marked for caching, so will be the rest of the segment. Same thing goes for deletion.
The start-up delay The start-up delay is the broadcast period of the first segment on the server
HeRO – Heterogeneous Receiver- Oriented Broadcasting Allows receivers of various communication capabilities to share the same periodic broadcast All receivers enjoy the same video quality Bandwidth adaptors are not used
HeRO – Data Segmentation The size of the i th segment is 2 i-1 times the size of the first segment
HeRO – Download Strategy The number of channels needed depends on the time slot of the arrival of the service request Loader i downloads segments i, i+C, i+2C, i+3C, etc. sequentially, where C is the number of loaders available. Global Period
HeRO – Regular Channels The first user can download from six channels simultaneously Request 1
HeRO – Regular Channels The second user can download from two channels simultaneously Request 2
Worst-Case for Clients with 2 loaders Worst-case latency is 11 time units The worst-cases appear because the broadcast periods coincide at the end of the global period Request 2 Coincidence of the broadcast periods require more loaders 11 time units
Worst-Case for Clients with 3 loaders Worst-case latency is 5 time units The worst-cases appear because the broadcast periods coincide at the end of the global period Request 5 time units Coincidence of the broadcast periods
Observations of Worst-Cases For a client with a given bandwidth, the time slots it can start the video are not uniformly distributed over the global period. The non-uniformity varies over the global period depending on the degree of coincidence among the broadcast periods of various segments. The worst non-uniformity occurs at the end of each global period when the broadcast periods of all segments coincide. The non-uniformity causes long service delays for clients with less bandwidth. We need to minimize this coincidence to improve the worst case.
We broadcast the last segment on one more channel, but with a time shift half its size. We now offer more possibilities to download the last segment; and above all, we eliminate the coincidence of all segments (i.e., no longer requiring 6 loaders). Regular Group Shifted Channel Adding one more channel
Shifted Channels To reduce service latency for less capable clients, broadcast the longest segments on a second channel with a phase offset half their size. HeRO
Under a homogeneous environment, HeRO is –competitive in service latencies compared to other protocols –the most efficient protocol to save client buffer space HeRO is the first periodic broadcast technique designed to address the heterogeneity in receiver bandwidth Less capable clients enjoy the same playback quality HeRO – Experimental Results
Hybrid Approach Periodic broadcast is better for very popular videos Batching (scheduled multicast) is more appropriate for less popular videos A hybrid of these two approaches offers the best performance
Adaptive Hybrid Approach (AHA) Popularity of each video is assessed periodically based on the distribution of recent requests. Popular videos are served using Skyscraper Broadcasting Less popular videos are served using batching Number of channels used for periodic broadcast depends on the current mix of popular videos Remaining channels are allocated to batching
Worst delay for Staggered Broadcasting Number of channels required for periodic broadcast AHA – Determine Popularity A video V i is popular if the following two conditions are true: Test 1 verifies that V i is relatively popular to deserve the periodic broadcast channels Test 2 ensures that V i is indeed popular (i.e., small inter-arrival rate)
Batching (Scheduled Multicast) Batching Scheduler Channel Pool Multicast A channel is available
AHA Schedulers Popularity Evaluator periodically assigns each video to either Batching Scheduler or Broadcast Scheduler When a request arrives for a popular video, Broadcast Scheduler informs the client which channels to download the video For less popular videos, Batching Scheduler assigns the next available channel to multicast the video with largest aggregated waiting time
We can use periodic broadcast for VOD Can we use scheduled multicast for VOD ?
Patching – First Client Regular Multicast Video A
Patching: Second Client Regular Multicast A Video Player Buffer B Video t Patching Stream Skew point
Patching: Clients Arrive at Different Times Regular Multicast A Buffer B Video 2t Skew point is absorbed by client buffer Video Player
Optimal Patching Window A r B p C p D p E r F p G p patching window W Multicast group time What is the optimal patching window ? patching window W
Simple Patching Patching is used if the client has enough buffer space to “absorb” the skew. Too greedy. May result in many long patching streams
Optimal Patching Window Compute D, the mean amount of data transmitted for each multicast group (a function of the patching period W ) Determine , the average time duration of a multicast group (a function of W ) Server bandwidth requirement is D/ which is a function of the patching period Finding the patching period W that minimizes the bandwidth requirement (D/ )
Candidates for Optimal Patching Window
Limitation of Patching Performance of Patching is limited by server bandwidth. Can we scale the application beyond the physical limitation of the server ?
Range Multicast RM Router 1 Client 1 RM Router 2 Video Server 4 Client 2 5 Client 1Client 2 6 Client 1Client 2 7 Client 1Client 2Client Client 1 Client 3Client 2 Client 3 10 Client 1Client 2 123
Range Multicast
Multicast Range All members of a conventional multicast share the same play point at all time –They must wait until the multicast time Members of a range multicast can have a range of different play points –They can join a range multicast at their leisure without waiting Multicast Range at time 11: [0, 11]
Prototype – RM Routers
Support VCR-like Operations in a Broadcast Environment ?
VCR-Like Interactivity Continuous Interactive functions –Fast forward –Fast rewind –Pause Discontinuous Interactive functions –Jump forward –Jump backward Useful for many VoD applications
VCR Interaction Using Client Buffer Video stream
Interaction Using Batching Requests arriving during a time slot form a multicast group Jump operations can be realized by switching to an appropriate multicast group Use an emergency stream if a destination multicast group does not exist Jump
Continuous Interactivity under Batching Pause: –Stop the display –Return to normal play as in Jump Fast Forward: –Fast forward the video frames in the buffer –When the buffer is exhausted, return to normal play as in Jump Fast Rewind: –Same as in fast forward, but in reverse direction
Split and Merger (SAM) Protocol Uses 2 types of streams, S streams for normal multicast and I streams for interactivity. When a user initiates an interactive operation: –Use an I channel to interact with the video –When done, use the I channel as a patching stream to join an existing multicast –Return the I channel Advantage: Unrestricted fast forward and rewind Disadvantage: I stream, used by one user, is expensive
Resuming Normal Play in SAM Use the I stream to download segments 6 and 7, and render them onto the screen At the same time, join the target multicast and cache the data, starting from segment 8, in a local buffer The user just finished the interactivity
Interaction with Broadcast Video The interactive techniques developed for Batching can also be used for Staggered Broadcast However, Staggered Broadcast does not perform well
Client Centric Approach (CCA) Server broadcasts each segment at the playback rate Clients use c loaders Each loader downloads its streams sequentially, –e.g., i th loader is responsible for segments i, i+c, i+2c, i+3c, … Equal-size W-segments are downloaded sequentially using one loader C = 3 (Clients have three loaders)
CCA is Good for Interactivity Segments in the same group are downloaded at the same time –Facilitate fast forward The last segment of a group is of the same size as the first segment of the next group –Ensure smooth continuous playback after interactivity
Broadcast-based Interactive Technique (BIT) Compression ratio is 4
BIT Two Buffers –Normal Buffer –Interactive Buffer When Interactive Buffer is exhausted, client must resume normal play
BIT Loaders: Receiving Data c+2 loaders, where c is the group size c regular loaders download the regular segments as in CCA The 2 interactive loaders function as follows: –If the current playback segment is in the first half of its group, the two interactive loaders are allocated to the previous and current interactive segments –Otherwise, they are allocated to the current and next interactive segments Keeping play point at middle of interactive buffer
BIT: Resume-Play Operation Tune to these three segments simultaneously Actual destination point is chosen from among frames at broadcast point to ensure continuous playback
BIT – Resume-Play Operation (All Scenarios) Tune to these three segments simultaneously Actual destination point is chosen from among frames at broadcast point to ensure continuous playback
BIT - User Behavior Model m x : duration of action x P x : probability to issue action x P i : probabilty to issue interaction m i : duration of the interaction m ff = m fr = m pause = m jf = m jb, P pause = P ff = P fb = P jf = P jb = P i /5. dr : m i /m p interaction ratio.
Two Performance Metrics 1.Percentage of unsuccessful action –Interaction fails if the buffer fails to accommodate the operation –e.g., a long-duration fast forward pushes the play point off the Interactive Buffer 2.Average Percentage of Completion –Measure the degree of incompleteness –e.g., if a 20-second fast forward is forced to resume normal play after 15 seconds, the Percentage of Completion is 15/20, or 75%.
BIT - Simulation Results
P2P Live Broadcast
Live Broadcast Video on Demand: Each user plays the video from the beginning Live Video Broadcast: A user joins an on-going live broadcast at the current play point of the video. ZIGZAG is a peer-to-peer technique for live broadcast
Chaining – First P2P Streaming P2P Streaming is another way to scale beyond the bandwidth limitation of the server Video Server disk Screen disk Screen disk Client A Client B Client C
Requirements in P2P Live Broadcast Low Overhead High Liveness Robustness
Liveness & Load Balancing Server I am overloaded Is it too far? new I want to join fast
Robustness Server The server is already busy Too many reconnections!
Control Overhead Peers periodically exchange information to maintain its position and connections. The overhead of this task should be small and independent of the number of peers
ZIGZAG Live Broadcast A peer, at its highest level, connects to peers from a different cluster in the next level Peers that are not leaders get data from a leader of a different cluster
ZIGZAG - Advantages Short broadcast tree improves liveness Small fanout keeps reconnecting cost low Hierarchy helps reduce control message overhead
Pull-based P2P Streaming Join the network as a new peer Obtain information of desired data through a gossip- based mechanism Pull data from different peers
Pull vs Push Push –Peers at the edges of the multicast structures do not contribute resources Pull –A lot of redundant data in the network –Searching for data (gossiping or using DHT) incurs overhead
Many P2P Streaming Systems on Internet PPLive PopCast PPStream Coolstreaming TV Ants QQLive 96
2-Phase Service Model (2PSM) Browsing Video in a Low Bandwidth Environment
Search Model 1.Use similarity matching or keyword search to look for the candidate videos. 2.Preview some of the candidates to identify the desired video. 3.Apply VCR-style functions to search for the video segments.
Conventional Streaming Advantage: Reduce wait time 1. Download S o 2. Download S 1 while playing S Download S 2 while playing S 1... Disadvantage: Not suitable 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 fast- reverse files to provide VCR-style operations Requires more storage space Server can become a bottleneck
VCR-like Functionality is Expensive Supporting VCR-like operations demands substantial network bandwidth, and requires significant server resources Can we avoid these costs ?
2PSM – Preview Phase
2PSM – Playback Phase t
Advantages 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. Server is not involved in the VCR-style interaction.
–UCF Video Browser
iSEE - Intelligent Sensors Exploration Environment