A Hybrid Architecture - Scalable Continuous Media Streaming Systems - page 339

static multicast channel and then restarts it at another point within the video stream. Hence a
simple method to support interactive control is to treat them just like a new request. Clearly,
this approach will increase loads at the dynamic multicast channels and result in increased
waiting time for both new session and interactive control requests. As there is no generally
accepted user-activity model, we do not attempt to quantify the performance impact of this
approach in this study.
In the following sections, we present algorithms that take advantage of the staggered static
multicast schedule to support pause-resume, slowmotion, and seeking in SS-VoD in a resource-
free way. In other words, no additional server resource or client buffer is needed to support
these interactive controls in SS-VoD.
19.2.1 Pause-Resume
We use a simple channel-hopping algorithm to implement pause-resume in SS-VoD. Specifi-
cally, since a client has a buffer large enough to cache T R seconds of video, it can just continue
buffering incoming video data after the user has paused playback. If the user resumes playback
before the buffer is full, then no further action is required. By contrast, if the buffer becomes
full, then the client simply stops receiving data and enters an idle state.
When the user resumes playback, the client can resume playback immediately and at the
same time determine the nearest multicast channel that is currently multicasting the video.
Since a movie is repeated every T R seconds and the client buffer already contains T R seconds'
worth of video data, we can guarantee that the client can locate and merge back into an existing
static multicast channel.
19.2.2 Slow Motion
Slowmotion is playback at a rate lower than the normal playback rate. As video data are always
being transmitted and received at the normal video bit-rate, it is easy to see that once slow
motion is started, data will begin to accumulate in the client buffer. Now if the user resume
normal speed playback before the buffer is full, then no additional action needs to be undertaken.
However, if playback continues in slow motion state for a sufficiently long time, the client
buffer will eventually be completely filled with video data. Note that at the instant when the
buffer becomes full, the buffer will contain T R seconds' worth of video data. This is equivalent
to the buffer full state in performing a pause operation. The only difference is that in performing
a pause, the client will stop receiving data until the user resumes playback, at which time a
nearby (in time)multicast channel will be located tomerge back into. For slowmotion, however,
playback continues at that instant and hence it is necessary to immediately locate a nearby
multicast channel other than the current one to merge back into. As any play point is at most T R
seconds away due to the staggered static multicast schedule, the T R seconds' worth of data in
the buffer guarantees that the client can locate and merge back into a static multicast channel.
If slow motion continues after merging, then data will begin to accumulate in the buffer again
and the cycle repeats until normal playback speed is resumed.
Using this algorithm, slow motion at any rate slower than the normal playback rate can be
supported without the need for any additional resource from the server. Client buffer require-
ment also remains the same.