A Lossless VOD Broadcasting Scheme for VBR Videos Using Available Channel Bandwidths

A Lossless VOD Broadcasting Scheme for VBR Videos Using Available Channel Bandwidths Tiko Kameda and Shufang Wu School of Computing Science, CMPT-TR 2003-09 Simon Fraser University Vancouver, British Columbia, Canada V5A 1S6 {tiko, vswu}@cs.sfu.ca Abstract We propose a new loss-less broadcasting scheme for variable bit rate (VBR) encoded videos. This is the first scheme that can use existing channels (e.g., 56Kbs or 64Kbps channels), without any special customized multiplexing requirement. The bandwidth of the available channels is an input to our algorithm. This is in contrast with all other known schemes which require channels with bandwidth of the form either k b or b / k, where b (bits/second) is the display rate of the video and k is an integer, or some other arbitrary bandwidth. Given communication channels of fixed bandwidth, we divide each video into a number (n) of segments of different sizes, starting from the end of the video. What is left over is a short initial segment, which is cached in the user s set-top box ahead of time. All other n segments are broadcast on separate channels simultaneously. Using data from real videos, we compare the total bandwidth needed by our scheme with the theoretical minimum bandwidth required if n channels/segments are used but different (non-standard) bandwidth can be allocated to each channel to minimize the total bandwidth. The experimental results demonstrate that the bandwidth requirement of our scheme is within 1% of the optimum for all the five real videos that we tested, indicating that our scheme enables us to use offthe-shelf channels at little extra cost in terms of total bandwidth required. Keywords Video-on-demand; VBR encoded videos; periodic broadcasting; lossless broadcasting; server bandwidth; segmentation. I. INTRODUCTION The client-server paradigm doesn t scale well, when the number of clients grows too large. One common way to overcome this difficulty in video-on-demand (VOD) is to use broadcasting, instead of serving individual client requests separately. Since the pioneering work on VOD broadcasting by Viswanathan and Imielinski [19] was published in 1995, a large number of broadcasting schemes have been proposed. Most of them deal with broadcasting constant bit rate (CBR) encoded videos. For a quick review on them, the reader is referred to survey articles (e.g., [1,4]). The reader will notice that all the existing schemes require channels of bandwidth of the form either k*b or b/k, where b (bits/second) is the display (or consumption) rate of the video and k is an integer, or some other arbitrary bandwidth. In other words, it is necessary to customize channels to provide the set of bandwidth values required by the given scheme. Our scheme presented in this paper eliminates this constraint, so that any existing channels (e.g., 56Kbs or 64kbps channels) can be used. To illustrate the essential idea used in recent broadcasting schemes, let us take a 120-minute video as an example and show how a user can start viewing it with only one minute of initial waiting time. We first divide the video into 120 oneminute blocks, and broadcast block 1 (the first block) repeatedly on a dedicated channel of bandwidth equal to the display rate b (bits/second). When a user selects a video to view at time t = 0, the user s set-top box (STB) spends one minute (from t = 0 to t = 1 minute) to download this segment (not necessarily from the beginning) and starts displaying it after one minute (at time t = 1 minute). Thus, we have t = 2 (minutes) when block 1 has been completely displayed. This implies that if we combine blocks 2 and 3 into a 2-minute segment and broadcast it on channel 2 (of bandwidth b), then the STB can download this segment completely by time t = 2 (minutes), to continue to display the video without any interruption. The remaining segments, consisting of 4 blocks, 8 blocks, etc., are similarly broadcast on other channels of bandwidth b. Since 1 + 2 + 2 2 + + 2 6 = 127 > 120, we need only seven channels and hence 7 b (bits/seconds) of bandwidth in this simple scheme. This is a slightly modified version of Fast Broadcasting (FB) [6]. This achieves a tremendous saving compared with Staggered Broadcasting [2], which would require 120 b (bits/second) of bandwidth to achieve the same amount of waiting time (i.e., one minute). We now review some concepts relevant to our scheme to be proposed in this paper. In fixed-delay [10,12] (or greedy [5]) broadcasting, the initial waiting time (or start-up latency) w (seconds) doesn t depend on the particular time that the user tunes in. Instead, it always incurs the same initial waiting time. The example in the previous paragraph was greedy. Such a scheme starts downloading from several channels immediately (i.e., starting at t = 0), without waiting for the beginning of segments, and always starts displaying the first segment after fixed latency w, which is the time needed to download segment 1. There is a trade-off between w and the bandwidth needed by the server to broadcast a video. The performance of a broadcasting scheme is commonly measured by the server bandwidth to achieve the given w (or alternatively, by the length of w for the given server bandwidth). The most bandwidth-efficient greedy scheme for CBR-encoded videos with equal bandwidth channels is 1

Greedy Equal Bandwidth Broadcasting (GEBB) [5]. As the name implies, this scheme uses equal bandwidth (c bits/second) for each channel. It can be shown that the bandwidth requirement of this scheme (n c) approaches the theoretical optimum quickly as the number of channels (= the number of segments) n is increased. There are other schemes whose performance also approaches the optimum but more slowly as n is increased. As we commented earlier, GEBB, like all other known schemes, cannot directly control c, i.e., c is determined as a function of other parameters. Since variable bit rate (VBR) encoding, used by MPEG- 1 and MPEG-2 for example, can achieve significant compression, most videos are VBR-encoded in practice. Therefore, we need a broadcasting scheme that works for VBR-encoded videos. There are a small number of schemes that can broadcast VBR-encoded videos. Saparilla et al. [18] proposed one such scheme, based on the segmentation used in Fast Broadcasting (FB) mentioned above, together with Group of Picture (GoP) smoothing, server buffering and user prefetching. The Trace Adaptive Fragmentation (TAF) [7] implements Saparilla et al. s scheme, obtaining lower aggregate bandwidth by taking into account the video trace. Salehi et al. [17] addressed the issue of reducing the rate variability to transmit a VBR-encoded video, given the STB buffer size. Pâris proposed a broadcasting protocol, Variable Bandwidth Harmonic Broadcasting (VBHB) [11], which is based on Cautious Harmonic Broadcasting (CHB) [13] designed for CBR videos. Unlike the others mentioned above, VBHB is lossless (i.e., all data are guaranteed to be downloaded in time for display). Hu et al. [4,5] designed a segmentation method (Loss-Less Bandwidth-Efficient, LLBE in short) using dynamic programming, which minimizes the total bandwidth used by a video if it is divided into a given number of segments, each of which is sent over a separate logical channel. But this scheme requires bandwidth values that are arbitrary real numbers and therefore it would be difficult to implement it. However, since LLBE generates the optimal segmentation, we will use it as a benchmark against which to compare the performance of our scheme. This paper proposes a new, practical, lossless broadcasting scheme for VBR-encoded videos, called Backward Segmentation with Equal Bandwidth (BSEB-PC). The suffix stands for prefix caching, which means that an initial segment of the video is downloaded into the STB s cache ahead of time, so that the user can start displaying the video from the moment he/she wants to view it. (Note that some authors use prefix caching and partial preloading synonymously, e.g., [14, 15], but we define the term preloading in Section 2 to mean something else.) We combine the greedy approach mentioned above with the idea of prefix caching by caching an initial segment of duration w (typically a few minutes) in the user s STB ahead of time, whereby eliminating the initial wait. We divide each video into a number (n) of segments of increasing sizes and each segment, except the cached initial segment, is broadcast on a communication channel of a fixed standard bandwidth (such as 64Kbps). By a set of experiments using real video traces, we compare the total bandwidth needed by BSEB-PC to deliver each video with that required by the optimal scheme (LLBE- PC; LLBE with prefix caching), which uses n channels but allocates a different amount of bandwidth to each channel to minimize the total bandwidth. The experimental results indicate that the bandwidth requirement of BSBE-PC is within 1% of the optimum. This implies that we reap great benefit, i.e., no need to customize channels to match the bandwidth requirement of a given scheme, at practically no cost in terms of extra bandwidth. In Section 2, we present our model and notation used throughout this paper. We also review GEBB [5], since it will be used for comparison. Section 3 presents BSBE-PC in detail, and compares its performance with the benchmark. Finally, the last section concludes the paper with a summary of our contribution and possible future work. II. PRELIMINARIES Both the greedy approach and prefix caching can be applied to practically all broadcasting schemes, although some schemes, e.g., VBHB [11], don t make sense if used with prefix caching. Since our scheme for VBR-encoded videos (BSEB-PC) to be presented in this paper is closely related to GEBB (for CBR-encoded videos) [5] with prefix caching, we discuss GEBB with prefix caching (called GEBB-PC) here. Figure 1. Illustration for Greedy Equal-Bandwidth Broadcasting. Consider a video of duration D. We divide it into (n + 1) segments S 0, S 1,, S n, where S 0 is the cached prefix. In Figure 1, D k denotes the duration of the k th segment, S k. For each k, segment S k is repeatedly broadcast in a channel of bandwidth B k = c b (bits/sec), where b is the display rate of the video. From the above diagram, we have the following equalities by equating the amount of data contained in each segment and the product of the bandwidth of the channel and the download time for the segment: D 1 b = c b D 0, D 2 b= c b (D 0 + D 1 ) = c b (1 + c) D 0, D n b = c b (1 + c) n-1 D 0. From the equality D = D 0 + D 1 + + D n = (1 + c (1 + + (1 + c) n-1 )) D 0 = (1 + c) n D 0, we get D / D 0 = (1 + c) n, hence c = (D / D 0 ) 1/n 1. 2

The total bandwidth is thus or B = n c b = n b ( (D/D 0 ) 1/n 1), B* = B / b = n ((D / D 0 ) 1/n 1) (1) in terms of the normalized bandwidth. Figure 2 plots B* vs. the normalized prefix duration D 0 / D for n = 16, 32, 64 and. Note from (1) that 5.5 5 B* ln (D 0 / D) as n. (2) n=16 n=32 n=64 Lower bound We concentrate on broadcasting one particular video. Let F denote the display rate in frames/second, which is a constant even for VBR-encoded videos. Typically F is within the range 25 ~ 30. If F = 25 (frames/sec), for example, then the total number of frames is N = 25 60 120 = 180,000 for a twohour video, which consists of N frames, F 1, F 2,, F N. The size or the number of bits in F k is denoted by f k. To give a feel for how frame sizes {f k } fluctuate, we show in Figure 3 the frame size distribution for a typical video, with the frame size as a function of the frame number. Server bandwidth (unit=b) 4.5 4 3.5 3 2.5 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 Cached prefix fraction (Do/D) Figure 2. Performance of GEBB with prefix caching. Let us analyze the limiting case where the frame size is made increasingly small using continuous variable approximation. In time interval [t, t + dt] we need to display b dt bits of data, for t in the range D 0 t D. This amount of data needs to be downloaded over interval [0, t] of length t. Thus, the bandwidth required for this is b dt / t = (b / t) dt, and the total bandwidth required is D b B = dt = b ln (D / D 0 ). D0 t We thus get the total (normalized) bandwidth = B* = B / b = ln(d 0 / D). GEBB can get arbitrarily close to this bound, as we can see from (2). Figure 2 shows the bandwidth required by GEBB with prefix caching (i.e., GEBB-PC). If an initial segment whose size is indicated by the fraction of the entire video shown on the horizontal axis is cached in advance, then the bandwidth required by GEBB-PC can be read from the vertical axis. Parameter n gives the number of segments (= number of channels) used. For example, in the case of n if the initial 2% of a video (2.4 minutes worth for a 120-minute video) is cached in advance, then the server bandwidth of less than 4.5 b suffices, where b (bits/second) is the display rate. This level of performance can be expected from BSEB-PC, if all frames have the same size. When n approach the relation given by (2). Figure 3. Frame size distribution of Star Wars [3]. We use n channels, one for each segment. Each channel has equal bandwidth c (bits/second). For j = 1,, n, S j will mean the number of frames in S j, and for k = 1,, N, A[k] denotes the number of bits in the first k frames, i.e., A[k] = f 1 + f 2 + + f k. Table I shows the total sizes (i.e., A[N]) of four video traces from [16], each consisting of 40,000 frames (about 26.7 minutes at F = 25 frames/sec), and another trace (Star Wars) from [3], consisting of 174,136 frames (about two hours at F = 25 frames/sec). The average display rate in the last column was obtained by dividing the total size by the video duration. TABLE I. SIZES OF REAL VIDEOS AND THEIR AVERAGE DISPLAY RATES Video Size (MB) Average Display Rate (bps) NEWS_2 73.231 383,941.820 BOND 115.912 607,711.625 MTV_1 117.322 615,105.900 FUSS 129.359 678,213.305 STARWARS 323.797 374,356.214 In this paper we use the term preloading to mean that a group of data is completely downloaded prior to its display; it has nothing to do with prefix caching ([14,15]). We assume that each video frame must be preloaded. It is often, but not always, required that each segment also be preloaded. An alternative to segment preloading is concurrent loading, which means that a segment is loaded concurrently with its display. For example, if a segment is broadcast at the display rate, concurrent loading is possible. Concurrent loading is useful, since it reduces both buffer and bandwidth requirement, but concurrent segment loading cannot be combined with greedy downloading. 3

Since we use frame preloading, frame F k+1 must be downloaded by the time the display of F k completes, i.e., by t = k / F (seconds). This means that the minimum bandwidth needed to download F k+1 is f k+1 / (k / F) = f k+1 F / k. Therefore, if the first p frames are cached as prefix, then the minimum total bandwidth required is ( f k+1 F / k ) (3) This lower bound is attainable in theory by using N p channels of bandwidths f k+1 F / k, for k = p, p+1,, N 1. For a large k, f k+1 F / k can be rather small. Since we will use segment preloading in our scheme, some frames must be downloaded earlier than the latest possible time (t = k/f (seconds) for F k+1, as explained above), bandwidth requirement is in general higher than the lower bound given by (3). With the current technology, neither the capacity nor the price of storage (disk) is a limiting factor. Therefore, minimizing the STB storage is not our concern and the local buffers size is not included in our model. III. BACKWARD SEGMENTATION WITH EQUAL BANDWIDTH (BSEB-PC) Notation Summary F (frames/second): display (or frame) rate. N: total number of frames in a video. F i (i = 1,, N): ith frame. f k : number of bits in F k. n: number of channels used by server = number of segments. c (bits/second): bandwidth of each channel. S j (j = 1,, n): jth segment. S j : number of frames in S j. S n = F m+1 F m+2 F N. F 1 N 1 k = p m/f (sec) F m F m+1 Segment S n Figure 4. Constructing the last segment in a video. Suppose that the last segment S n consists of frames F m+1 F N, as shown in Figure 4 above, where m is yet to be determined. We need to download (every frame in) segment S n using one channel of bandwidth c (bits/second) by the time the display of frame F m is completed, i.e., by time t = m / F (seconds). Note that S n contains A[N] A[m] (bits). Thus we can compute m as the minimum integer satisfying F N ( A[N] A[m] ) / ( m / F ) c (4) We compute S n 1, S n 2,, S 1 similarly, so that each segment can be broadcast on a channel with bandwidth c (bits/second). See the segmentation algorithm given below. We don t know n initially. We can stop generating segments when the number of remaining frames is less than a certain threshold, and let n be the number of segments generated so far. The total server bandwidth is therefore n c. S 0 (the prefix to be cached) consists of the leftover frames, and the number of frames it contains, S 0, as well as the number of segments (n), depends on the particular video. Clearly, it takes S 0 / F (seconds) to display the cached initial segment S 0. For each video, we first apply our algorithm below to compute the segments from the last segment on. When the number of leftover frames becomes no larger than a certain threshold T such as T = 25 3 60 = 4500, which is equivalent to 3 minutes of display time if the frame rate is 25 frames/second, then S 0 is formed out of those frames. Therefore, we cannot control the exact size of S 0. As we explained above, the number of segments n is also an output from our algorithm. We now present our segmentation algorithm more formally. It is convenient to count segments generated backwards from the last segment, since we generate the last segment first. Let I [k] denote the index of the last frame in the k th segment that we generate. In other words, I [k] is the index of the last frame in segment S n k+1. We thus have I [1] = N and I [2] = m, where m is the minimum index satisfying (4). So segmentation means determining I [k] for k = 2,, n+1. Segmentation for BSEB-PC Inputs: N (number of frames), F (frame rate) and T (threshold in seconds). Outputs: n and I [k] for k = 2,, n+1. I [1] = N; m = N 1; k = 1; while true do { if I [k] / F T then exit; while ( A[ I [k] ] A[m] ) / ( m / F ) c do m = m 1; k = k + 1; I [k] = m + 1; } n = k 1; // Number of segments as a function of T. p = I [k]; // Index of the last frame in the prefix. We applied the above segmentation algorithm to the five video traces listed in Table I. The results are summarized in Table II. The first column shows the threshold T, and the third column shows the output n from the above algorithm. Output p = I [n+1] is the index of the last frame of prefix S o. Therefore, p/f is the duration of the prefix, which is shown in minutes in column 4. Finally, the last column shows the ratio of the total bandwidth, n c, over the average display rate shown in Table I. Let us compare some data from Table II with the performance of CBR videos given in Figure I. We first define the CBR equivalent of a VBR video V as the imaginary CBR video whose display rate is equal to the average display rate of V. For threshold T = 2, for example, it is seen from Table II that, if the prefix of 1.728 (1.9787) minutes of BOND (MTV_I) is cached, then the bandwidth requirement is 2.738 4

(2.809) times the average display rate. Since the total duration of BOND (MTV_I) is 26.67 minutes, 1.728 (1.9787) minutes represents 6.48% (7.42%) of the total. If a horizontal line y = 0.0648 is drawn in Figure 2, its intersection with the curve for n = 26 (see column 3 of Table II) has value x 2.89 b. Since the value in the last column for BOND is 2.738, this implies that our scheme requires less bandwidth than the CBR equivalent of BOND broadcast with the theoretically best scheme. As for MTV_I, if a horizontal line y = 0.0742 is drawn in Figure 2, its intersection with the curve for n = 27 (see column 3 of Table II) has value x 2.73 b. Since the value in the last column for MTV_I is 2.809, this implies that our scheme requires more bandwidth than the CBR equivalent of MTV_I broadcast using GEBB-PC with n = 27 channels. TABLE II. SEGMENTATION RESULTS FOR DIFFERENT THRESHOLDS (T) Threshold T (minutes) 1 2 3 4 5 Video Number of Segments n Prefix Duration (minutes) Bandwidth over Average Display Rate BOND 30 0.8947 3.159 FUSS 37 0.8907 3.492 MTV_I 35 0.9160 3.642 NEWS_2 21 0.8633 3.501 STARWARS 32 0.9181 5.471 BOND 26 1.7280 2.738 FUSS 30 1.9493 2.831 MTV_I 27 1.9787 2.809 NEWS_2 17 1.7227 2.834 STARWARS 26 1.6826 4.445 BOND 22 2.9080 2.317 FUSS 24 3.0000 2.265 MTV_I 23 2.9067 2.393 NEWS_2 15 2.7047 2.500 STARWARS 23 2.8326 3.932 BOND 20 3.6527 2.106 FUSS 21 3.7407 1.982 MTV_I 20 3.9620 2.081 NEWS_2 13 3.6667 2.167 STARWARS 21 3.8181 3.590 BOND 18 4.7647 1.896 FUSS 19 4.6327 1.793 MTV_I 19 4.6247 1.977 NEWS_2 12 4.3687 2.000 STARWARS 20 4.3701 3.419 What we observed above is that the performance of BSBE- PC depends on the frame size distribution of the given video. If the distribution is skewed in such a way that there are larger frames later in the video, we will need smaller bandwidth, because a later frame uses a channel for a longer period of time. For example, Figure 5 below shows that this is the case for BOND, since the cumulative frame size distribution curve lies below the straight line connecting (0,0) and (40000, 115.912), where 40000 is the number of frames in BOND and 115.912(MB) is the size of video BOND. On the other hand, if the distribution is skewed in such a way that there are larger frames earlier in the video, we will need larger bandwidth, because an earlier frame uses a channel for a shorter period of time. For instance, Figure 6 below shows that this is the case for MTV_I, since the cumulative frame size distribution curve lies above the straight line connecting (0,0) and (40000, 117.322), where 40000 is the number of frames in MTV_I and 117.322 (MB) is the size of video MTV_I. Cumulative Frame Size (MB) 120 BOND Straight Line 100 80 60 40 20 0 0 500010000150002000025000300003500040000 Frame Number Figure 5. Cumulative frame size distribution of BOND. Cumulative Frame Size (MB) 120 MTV_I Straight Line 100 80 60 40 20 0 0 500010000150002000025000300003500040000 Figure 6. Cumulative Frame frame size Number distribution of MTV_I. We now run the segmentation algorithm of LLBE-PC with n (number of segments needed if threshold T is used) and p (number of leftover frames) from Table II (p is shown as p F in minutes in column 4) as inputs and obtain the theoretical minimum bandwidth B(n, p) as output. We have modified the pseudocode for segmentation used in LLBE from [4] to account for prefix caching used in our scheme. For p+1 i N and 1 j n, let Bmin [i, j] be the minimum bandwidth required to send frames numbered from p+1 to i, using j segments. We are interested in B(n, p) = Bmin [N, n]. Segmentation for LLBE-PC Inputs: N (number of frames), F (frame rate), n (number of segments) and p (size of the prefix). Output: Bmin[N, n]. // Initialize table Bmin [i, j] to infinity for ( i = p+1; i N; i++ ) for ( j = 1; j n; j++ ) Bmin [i, j] = // Initialize Bmin [ ] for one segment and 5

// frames p + 1 through i. for ( i = p+1; i N; i++ ) Bmin [i, 1] = ( A[i] A[p] )/( p/f ); for ( j = 2; j n; j++) for ( i = p+1+j; i N; i++ ) for ( k = p+ j; k i; k++ ) { B = Bmin [k, j 1] + ( A[i] A[k] )/( k/f ); if ( B < Bmin [i, j] ) Bmin[i, j] = B ; } We computed ( n c B(n, p) ) / B(n, p), (5) which is plotted in Figure 7 for the different video traces in Table I. The horizontal axis is the fraction of the cached prefix duration over the total duration of the video. For all videos that we tested, it is observed from the figure that the wasted bandwidth is less than 1%. Note that as for the cached prefix duration, 1% of a 2-hour video is 1.2 minutes, which is the same as 4% of a 30-minute video. A result in [4] implies that the quantity represented by (5) equals 0 for the CBR videos, if the bandwidth of each channel is fully utilized, namely, if there is always an m which makes the test in the segmentation algorithm for BSBE-PC, (A[I [k]] A[m]) / (m/f) c, an equality. Figure 7. Comparison of BSEB-PC and LLBE-PC. The time complexity of the segmentation algorithm used in LLBE-PC is O(n N 2 ). In contrast, the segmentation algorithm for BSEB-PC runs in linear time O(N). When programmed in C++, the algorithm for BSEB-PC ran in milliseconds for a 2-hour video (STARWARS, see Table I) on a PC with a 1.5GHz Pentium 4 CPU and 256MB of memory running under Windows 2000, while segmentation for LLBE- PC took close to one day. To see why BSEB-PC s performance may not be optimal in some cases, let us consider the simple case where a video is segmented into n = 2 segments, S 1 and S 2, by BSEB-PC. Suppose the cumulative data amount in frames p + 1 to N has the curve shown by the thick curve in Figure 8. Recall that frames 1 to p comprise the cached prefix. Let b denote the average bandwidth of channels 1 and 2, expressed in bits/frame, and let A 1 (bits) and A 2 (bits) denote the amounts of data in S 1 and S 2 respectively. Then channel 1 must broadcast A 1 in frame time p, i.e., at the rate of b = A 1 / p (bits/frame). Since the two channels have the same bandwidth, we have b = A 1 / p = A 2 / (p + S 1 ). Suppose now that S 1 is made smaller into S 1. The bandwidths of channels 1 and 2 will become b (bits/frame) and b (bits/frame), respectively, as shown in Figure 8. Figure 8. BSEB-PC vs. LLBE-PC This change will decrease the total bandwidth of the two channels, provided b + b < 2b. With simple analysis, we find that this inequality holds if and only if (A 1 A 1 ) / A 1 > ( S 1 S 1 ) / S 1, 6

where A 1 (bits) denotes the amount of data in S 1. If the cumulative data curve has a steep climb as in Figure 8, then it is likely that the above inequality is satisfied, and it is beneficial to reduce the size of S 1 to reduce the total bandwidth. In fact, LLBE-PC would generate a smaller S 1 than BSEB-PC for such a video and as a result, the channels would have different bandwidths. IV. CONCLUSION AND FUTURE WORK We have presented a new lossless scheme for broadcasting VBR-encoded streams, named BSBE-PC, based on prefix caching and greedy downloading. BSBE-PC segments a given video backwards from its end until a relatively small number of frames are left, which are made into an initial segment to be cached by each user in advance. All other segments are repeatedly broadcast on standard channels of equal bandwidth. The experimental results demonstrated that the bandwidth requirement of our scheme BSBE-PC is within 1% of the optimum. We believe that this is a small cost to pay in return for the benefit we get, namely no need for customization of channels. We used uniform channels with bandwidth equal to 64Kbps, but similar conclusions can be drawn for a wide range of relatively narrow bandwidths. It is straightforward to extend our scheme to the case where the given set of channels doesn t have equal bandwidth. In our experiments reported in this paper, we didn t distinguish among I, P, and B frames, so that it is possible, for example, that a B frame that references a frame in the next segment is at the end of a segment. Clearly, we need to prevent this kind of segmentation as in [20]. However, the effect of this constraint on the server bandwidth turns out to be negligible. In BSEB-PC a user must download segments from all the n (logical) channels at the same time. With the current technology, sorting out these data in real time into the appropriate locations in the local disk storage may be beyond the capability of an inexpensive STB, when n is large. We are interested in limiting the user bandwidth, as is done for CBRencoded videos in [21]. The heuristic in Staircase Broadcasting (SCB) [8] tries to limit the user bandwidth, but the channel bandwidth cannot be controlled in the scheme. Finally, prefix caching assumes that the prefixes are somehow downloaded using some channels. This means that some channels are either dedicated for this purpose, or prefix downloading is carried out during the wee hours, e.g., 2:00am ~ 5.00am, when channels could be deallocated from the less popular videos. The investigation into reasonable ways of prefix downloading is left as future work. ACKNOWLEDGMENT We thank the members of the Distributed Computing Laboratory in the School of Computing Science at Simon Fraser University for stimulating discussions. The second author gives his special thanks to his dear wife for her great support and patience. REFERENCES [1] S.W. Carter, D.D.E. Long and J.-F. Pâris, Video-on-demand broadcasting protocols, In Multimedia Communications: Directions and Innovations (Gibson, J.D., Ed.), Academic Press, San Diego, 2000, pp.179-189. [2] A. Dan, D. Sitaram and P. Shahabuddin, Scheduling policy for an ondemand video server with batching. Proc. ACM Multimedia 94, San Francisco, CA, Oct. 1994, pp.15-23. [3] M.W. Garrett and A. Fernandez, Telcordia Technologies, Inc. ftp://ftp.research.telcordia.com/pub/vbr.video.trace/mpeg.data. [4] A. Hu, Video-on-demand broadcasting protocols: A comprehensive study, Proc. INFOCOM 01, Anchorage, AK, April 2001, pp. 508-517. [5] A. Hu, I. Nikolaidis and P. Beek, On the design of efficient video-ondemand broadcast schedules, Proc. 7th Int l Symp. on Modeling, Analysis and Simulation of Computer and Telecommunication Systems (MASCOTS 99), 1999, pp. 262-269. [6] L. Juhn and L. Tseng, Fast data broadcasting and receiving scheme for popular video service, IEEE Trans. on Broadcasting 44 (1), Mar. 1998, pp.100-105. [7] F. Li and I. Nikolaidis, Trace-adaptive fragmentation for periodic broadcast of vbr video, Proc. 9th Int l Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV ' 99), June 1999. [8] F. Li and I. Nikolaidis, SCB: Staircase broadcast for media-on-demand systems, Proc. IEEE Mobile Multimedia Communications (MoMuC 00), 3B-1-1-3B-1-5. [9] I. Nikolaidis, F. Li and A. Hu, An inherently lossless and bandwidth efficient scheme for periodic broadcast of vbr video, Proc. ACM SIGMETRICS 00, 2000, pp.116-117. [10] J.-F. Pâris, A low-bandwidth broadcasting protocol for video-ondemand, Proc. 8th Int l Conf. on Computer Communications and Networks (ICCCN 98), Oct. 1998, pp. 690-697. [11] J.-F. Pâris, A broadcasting protocol for compressed video, Proc. EUROMEDIA 99 Conf., Munich, April 1999, pp. 78-84. [12] J.-F. Pâris, A fixed-delay broadcasting protocol for video-on-demand, Proc. 10th Int l Conf. on Computer Communications and Networks, 2001, pp. 418-423. [13] J.-F. Pâris, S.W. Carter and D.D.E. Long, Efficient broadcasting protocols for video on demand, Proc. 6th Int l Symp. on Modeling, Analysis and Simulation of Computer and Telecommunication Systems (MASCOTS 98), July 1998, pp. 127-132. [14] J.-F. Pâris and D.D.E. Long, The case for aggressive partial preloading in broadcasting protocols for video-on-demand, Proc. 2001 IEEE Int l Conf. on Multimedia and Expo, Tokyo, Aug. 2001, pp.113-116. [15] J.-F. Pâris, S.W. Carter and P.E. Mantey, Zero-delay broadcasting protocols for video-on-demand, Proc. 1999 ACM Multimedia Conf., Orlando, FL., Nov. 1999, pp. 189-197. [16] O. Rose, Statistical properties of MPEG video traffic and their impact on traffic modeling in ATM systems, Tech. Rept. 101, Universitaet Wuerzburg, Feb. 1995. [17] J. Salehi, Z. Zhang, J. Kurose and D. Towsley, Supporting store video: Reducing rate variability and end-to-end resource requirements through optimal smoothing, IEEE/ACM Tran. on Networking 6 (4), Aug. 1998, pp. 397-410. [18] D. Saparilla, K. Ross and M. Reisslein, Periodic broadcasting with vbrencoded video, Proc. IEEE INFOCOM 99, pp. 464-471. [19] S. Viswanathan and T. Imielinski, Pyramid Broadcasting for video on demand service, Proc. IEEE Conf. on Multimedia Computing and Networking, Vol. 2417, San Jose, CA, 1995, pp. 66-77. [20] S. Wu, General frame level segmentation for periodic broadcast of vbr videos, Proc. 12th Int l Conf. on Computer Communications and Networks (ICCCN 03), October 2003, in press. [21] E.M. Yan E.M. and T. Kameda, An efficient VOD broadcasting scheme with user bandwidth limit, Proc. SPIE/ACM Conf. on Multimedia Computing and Networking, Vol. 5019, Santa Clara, CA, January 2003, pp. 200-208. 7