Mounr A. Tantaou School of Electrcal Engneerng and Computer Scence Unversty of Central Florda Orlando, FL 3286-407-823-393 tantaou@cs.ucf.edu Interacton wth Broadcast Vdeo Ken A. Hua School of Electrcal Engneerng and Computer Scence Unversty of Central Florda Orlando, FL 3286-407-823-5342 Kenhua@cs.ucf.edu Smon Sheu Computer Scence Natonal Tsng Hua Unverstty Tawan, ROC 886-3-5753 Sheu.cs.nthu.edu.tw ABSTRACT In vdeo-on-demand (VOD) applcatons, t s desrable to provde the user wth the vdeo-cassette-recorder-lke (VCR) capabltes such as fast-forwardng a vdeo or jumpng to a specfc frame. We address ths ssue n the broadcast framework, where each vdeo s broadcast repeatedly on the network. Exstng technques rely on data prefetchng as the mechansm to provde ths functonalty. Ths approach provdes lmted usablty snce the prefetchng rate cannot keep up wth typcal fast-forward speeds. Fast-forwardng a vdeo for several seconds would nevtably exhaust the prefetch buffer. We address ths practcal problem n ths paper by repeatedly broadcastng the nteractve versons of the vdeos. For nstance, an nteractve verson mght contan only every ffth frame n the orgnal vdeo. Our clent software leverages these nteractve broadcasts to provde better VCR servce. We formally prove the correctness of ths approach, and compare ts performance to a prefetch method, called actve buffer management. Ths scheme has been shown to offer, n the broadcast envronment, the best performance to date. Our smulaton results ndcate that the new technque s superor n handlng long-duraton VCR actons. General Terms Algorthms, Performance, Desgn, Expermentaton, Theory. Keywords Vdeo on demand, fast forward, fast reverse, perodc broadcast, latency.. INTRODUCTION Vdeo communcaton s now one of the most mportant aspects of our lves. Vdeos are not only for entertanment, but also for educaton, and nformaton. In partcular, vdeo on demand (VOD) has emerged as a base technology for many mportant new applcatons such as home entertanment, news on demand, dgtal lbrares, dstance learnng and electronc commerce, to name but a few. A typcal VOD servce allows remote users to play back any vdeo from a large collecton stored on one or more servers. In response to a servce request, a server delvers the specfed vdeo to the user n an sochronous data stream. The unt of server capacty requred to support the playback of one server stream s referred to as a channel. The number of such channels s determned by the server bandwdth. In ts smplest form, delvery of a vdeo stream requres a dedcated channel for each vdeo sesson. Ths approach s excessvely expensve and nonscalable. To conserve server bandwdth, several users can share a channel smultaneously usng multcast. Two types of multcast have been studed: n-perodc multcast: In ths envronment, users make requests of vdeos to the server; and t serves requests accordng to some schedulng polcy. To conserve server bandwdth, requests made by several clents for the same vdeo wthn a short perod of tme can be served as a group usng a sngle channel; ths s referred to as Batchng. Much prevous works has been done especally n how to batch requests effcently [,6,7]. One technque referred to as Patchng [7,20] allows a new ncomng request to jon an already exstng multcast and therefore takes advantage of the same data stream. In ths case, the user downloads the mssed porton of the vdeo through a new patchng stream, whle smultaneously bufferng the rest comng from the exstng multcast. Another technque, called Channg [4], constructs a herarchy of multcasts to serve requests for the same vdeo. A clent s allowed to multcast the cached data to other clents n the downstream of the herarchy. Ths scheme s smlar to the Patchng technque except that Patchng s smpler to mplement snce clents do not act as servers to forward data. A dfferent approach s Adaptve Pggybackng technque [2], n whch a clent beng served can be joned by another clent to form a batch. Ths s accomplshed by slowng down the former clent and speedng up the latter one to merge them nto one communcaton stream. Perodc Broadcast: In ths envronment, users do not make requests to the server. Rather, the server broadcasts the vdeo perodcally, e.g., a new stream of the same vdeo s started every t seconds. Although, ths type of technque does not guarantee true VOD, the worst servce latency experenced by any clent s less than t seconds. A dstnct advantage of ths approach s that t can serve a very large communty of users usng mnmal server bandwdth. In fact, the bandwdth requrement s ndependent of the number of subscrbers to the system.
The beneft of Perodc Broadcast s lmted to popular vdeos. It was shown n [3] that usng both Perodc Broadcast and nperodc Multcast offers the best performance. Nevertheless, snce more than 80% of the servce requests are typcally for less than 20% of the vdeos for most applcatons [8], perodc broadcast s very crucal to the overall performance of a vdeo-ondemand system. In ths paper, we focus on the dssemnaton of these popular vdeos. An early perodc broadcast technque [7] parttons a vdeo nto fragments of equal szes, and repeatedly broadcasts them at fxed ntervals. The access latency can be mproved only lnearly wth ncreases to the server bandwdth. Pyramd Broadcastng (PB) [2] addresses ths lmtaton by broadcastng the vdeo fragments at a very hgh data rate, and allowng the clents to prefetch data nto a local buffer. Ths soluton requres expensve clent machnes wth enough bandwdth to cope wth the hgh data rate on each broadcast channel. Permutaton Based Broadcastng (PBB) [3] mproves ths condton by dvdng each channel nto s sub-channels that broadcast a replca of the vdeo fragment wth a unform phase delay. Ths strategy reduces the requrement on clent bandwdth by some factor s although the data rate remans very hgh, whch can stll flood the prefetch buffer wth half of the total data [5] (e.g., 50 mnutes of a typcal move). To reduce the data rate to a practcal level, Skyscraper Broadcastng (SB) [5] employs low-bandwdth channels, each at the playback rate. The szes of ts frst few vdeo fragments ncrease geometrcally. However, the szes of the larger fragments are restrcted to W. The tny sze of the frst vdeo fragment allows t to be broadcast more frequently to ensure low servce latency. The unform szes of the larger fragments enable the clent to download them serally at the playback rate to avod floodng the prefetch buffer. SB also avods the complex synchronzaton technque used n PPB. The Clent-Centrc Approach (CCA) [6] has the characterstcs of SB. However, t s more general n the sense that the clent can explot ts hgh bandwdth, f avalable, to further reduce the servce delay. Another technque the Greedy-dsk Conservng Scheme (GDB) [] conserves the clent dsk space by lettng t receve data as late as possble. A more recent technque, the Harmonc Broadcastng (HB) [9], adopts a conservatve stream allocaton polcy by transmttng dfferent segments at dfferent rates to reduce the demand on server bandwdth and offer better clent watng tme. Ths scheme, however, employs a very large number of channels makng t dffcult to mplement. As an example, n order to broadcast a 2-hour move wth a worst-case access latency of 0 seconds, the server and ts storage subsystem need to multplex among more than 700 vdeo streams, one for each channel. Today s storage technology s far from beng able to support such a hgh degree of concurrency. In ths paper, we extend our CCA technque to provde vdeocassette-recorder-lke (VCR) nteractve functons. We base our work on CCA due to ts feasble requrements [6]. It has also been shown to be more sutable for VCR mplementaton [0]. Our work s drven by the followng observaton. Exstng technques (e.g., [9][0]) rely on prefetched data to provde VCR servce. Ths approach offers lmted beneft snce a prefetchng stream cannot keep up wth a fast forward for more than several seconds. The stuaton for a fast reverse s worse snce the prefetchng streams are loadng data n the opposte drecton. To address these drawbacks, we propose to broadcast also the nteractve versons of the vdeos. For nstance, an nteractve verson mght consst of only every n th frame of the orgnal vdeo. The clents can share these nteractve broadcasts to provde sgnfcantly better VCR servce. Our challenge s the synchronzaton of the regular and nteractve broadcasts to ensure lttle nteractve delay. The remander of ths paper s organzed as follows. We dscuss related work n Secton 2. In Secton 3, we descrbe the CCA technque to make the paper self-contaned. We present our nteractve technque, n the CCA framework, and prove ts correctness n Secton 4. In Secton 5, we show smulaton results to compare the proposed technque to a recent method. Fnally, we conclude n Secton 6. 2. RELATED WORK 2. Type of Interactons A vdeo s a sequence of contnuous frames. The frame beng rendered by the user s the current frame that we also refer to as the play pont. A user watchng the vdeo has the ablty to change the poston of the play pont to another pont (frame) that we call the destnaton pont. We can dstngush between two dfferent types of nteractvty:. Contnuous nteractve functons: These are the nteractons where the user contnuously advances the play pont one frame at a tme at a hgh speed. The user has full control of the duraton of the nteracton. Examples of ths type of nteracton nclude fast forward and fast reverse. 2. Dscontnuous nteractve functons: These are the nteractons where the user nstantaneously changes the play pont to a future frame (.e., jump-forward) or a frame n the past (.e., jump-backward). We can further dvde all nteractons nto forward nteractons and backward nteractons. If we denote by t the tme taken by the nteracton, l the vdeo length of the nteracton n tme unt,.e., the dfference between the play pont and the destnaton pont, and b the playback rate of the vdeo, we can ntroduce the parameter x = l t b that determnes all types of nteractons. Table gves the possble forward nteractons, and table 2 gves the backward nteractons wth the possble values of the parameter x. Table : Forward Interactons Acton Play Fast Forward Jump Forward x (,x ) + Table 2: Backward Interactons Acton Pause Play Backward Fast Reverse Jump Back. x 0 - [-x,-) - A play acton s when the length of the acton over the tme taken by the acton s equal to the playback rate. For fast-forward, l t > b and the value of x wll prmarly depend on l and t. In the case of a jump forward, snce the acton s nstantaneous, t = 0 and therefore x s nfnte. A pause acton s when l =0. Snce l s negatve n a play-backward the value of x s.
Group Channel Channel 2 management technques. In the current paper, we use ABM as a base to assess the benefts of the proposed technque. Group 2 Group Channel 3 Channel 4 Channel 5 Channel K W 3. CCA BROADCASTING To make the paper self-contaned, we brefly descrbe the Clent Centrc Approach (CCA) [6] n ths secton. A perodc broadcast desgn conssts of a channel desgn, a data fragmentaton technque, a broadcast schedule, and a playback strategy. The CCA s prmarly desgned to take full advantage of the clent s capablty,.e., the clent buffer space and ts downloadng bandwdth. Fgure : CCA wth K channels and 3 channels per group Fast Reverse and jump-backward are the opposte of fast forward and jump-forward, respectvely. It s nterestng to note that the pause acton belongs to the backward nteractons. Ths s due to the fact that ncomng frames make the destnaton pont moves backward of the current play pont. To complete the canoncal world of nteractons we can add the slow forward, x (0,) and the slow backward, x (-,0). Both nteractons are backward nteractons for the same reason as the pause nteracton. We note that the parameter x was frst ntroduced n [0]. We nclude the above dscussons n order to defne few concepts, and clarfy the varous nteractve functons. 3. Channel desgn and Data fragmentaton CCA dvdes the communcaton bandwdth of the server nto K logcal channels, where every channel has the bandwdth of the playback rate. Each channel perodcally broadcasts one segment S of the vdeo. The fragmentaton technque uses the followng recursve formulae:, f n =, f(n) = 2. f(n ) f n mod (c), () f(n ) f n mod (c) =. The closed form of ths functon can be presented as : f(n) = 2 n n/c, where n K. (2) 2.2 Related Work on VCR Interactons n a Multcast/Broadcast Envronment. An early work on provdng nteractve servce n a multcast envronment s presented n [4][5]. In ths scheme, f the data n the prefetch buffer cannot accommodate a jump request, the clent requestng the nteracton s moved to an exstng stream whose play pont matches the clent s destnaton pont. If such a stream does not exst, the server ssues an emergency stream to provde the servce. Emergency streams are expensve snce they serve only one clent. To reduce ths cost, the technques, ntroduced n [8] and [2], try to move the clent of an emergency stream to an exstng multcast whose play pont s ahead of the clent s play pont, but not further than some amount. In any case, usng emergency streams defeats the benefts of the multcast paradgm. Ths approach s too expensve to provde VCR-lke servce to a large user communty. In the broadcast envronment, t was observed n [9][0] that the play pont can be mantaned at the mddle of the vdeo segment currently n the prefetch buffer n order to accommodate nteractve actons n ether forward or reverse drecton equally well. Ths s accomplshed n [0] by selectvely prefetchng the segments to be loaded dependng on the current poston of the play pont. Ths scheme s called Actve Buffer Management (ABM). In general, ABM can be set to take advantage of the user behavor. If the user shows more forward actons than backward actons, the play pont can be kept near the begnnng of the vdeo segment n the buffer, and vce versa. Ths scheme has been shown to offer better performance than conventonal buffer The parameter c denotes the maxmum number of fragments a clent can download at one tme. To conserve buffer space, the szes of the largest segment are fxed to W D, where D denotes the playback duraton of the frst segment. In the remander of ths paper we wll refer to those segments as W-segments. CCA organzes the vdeo fragments nto g = K/c transmsson groups, each wth c tems except the last one. The sze of the last segment of a group s equal to the sze of the frst segment n the next group. Fgure llustrates the data fragmentaton, channel desgn, and transmsson groups for the CCA technque, where each group contans 3 fragments. 3.2 Recepton and Playback of Vdeo Fragments To play back a vdeo, the clent starts usng c loaders and a vdeo player. Each loader downloads ts predetermned segments sequentally at the playback rate. When a loader fnshes downloadng a segment S j from a group, the loader s allocated to the next group + to download segment S j+c at ts next broadcast. Once the frst W-segment s encountered, only one loader s used to download all the W-segments sequentally. The motvaton behnd the CCA fragmentaton technque s to wsely utlze the full capacty of the clent resources, whle guaranteeng the contnuous playback of the vdeo. Snce two consecutve segments n the same group ether start at the same tme or fnsh at the same tme (Fgure ), the contnuty n playng back segments from the same group s guaranteed. Snce the frst loader always downloads the frst and smallest segment of
Cr Kr-3 a group, ths loader s avalable before the consumpton of the last segment of the same group. Ths loader, therefore, can be used to download the frst segment of the next group. Segments across a group boundary are always of the same sze, so the contnuty across group boundares s satsfed. The CCA technque not only shows good performance n term of access latency, but can also be extended to support VCR operatons as we shall dscuss n the next secton. Interactve Group Cr Cr 2 Cr 3 Cr 4 C Cr 5 W 4. A BROADCAST BASED INTERACTION TECHNIQUE (BIT) The proposed technque s an extenson of the Clent Centrc Approach. We assume that we have two versons of the same vdeo: a normal verson and a verson compressed by a factor f that we call the compresson factor. Compresson of the vdeo s beyond the scope of ths paper but t s well researched and tools are readly avalable for dong so, an example of compresson could be selectng each f frame of the orgnal vdeo. The user watchng the compressed verson of the vdeo at the playback rate wll have the mpresson of fast playng the normal vdeo. Snce we use broadcast as the mechansm to provde VCR servce thus the name Broadcast-Based Interacton Technque (BIT). The motvaton for ths approach (nstead of usng emergency channels) s to retan the most desrable property of the broadcast approach, namely unlmted scalablty - the bandwdth requrement s ndependent of the number of users the system s desgned to support. 4. Channel Desgn As n the CCA technque, the server bandwdth s dvded nto K logcal channels. Each channel perodcally broadcasts a dfferent segment of the vdeo. If we refer to K as the total number of channels, K can be dvded nto K = K r + K, where K r s the number of regular channels used to broadcast the regular verson of the vdeo, and K the number of nteractve channels used to broadcast the compressed verson of the same vdeo. 4.2 Data fragmentaton For the normal verson we use the same fragmentaton technque desgned for CCA (refer to Secton C. formulae ()). We denote the segment broadcast by a regular channel as S, and ts compressed verson as S. The segments of the compressed verson are concatenated nto group of f as follows: Group,V : S ' S 2 ' S f ' Group 2,V 2 : S f+ ' S f+2 ' S 2f '.. Group,V : S (-)f+ ' S (-)f+2 ' S f '.. Group K,V K : S (k-)f+ ' S (k-)f+2 ' S Kr ' Interactve Group K Cr Kr-2 Cr kr- Cr Kr C k Fgure 2: Broadcastng scheme for BIT (K r +K channels, f =4) For convenence, we wll refer to each of these groups as a compressed segment hereafter. The reader should not confuse a compressed segment wth a compressed verson of a regular segment. Each compressed segment, denoted by V, s broadcast on an nteractve channel c. Thus, the number of nteractve channels s determned by the nunmber of compressed segments, or K = K r / f. Fgure 2 shows the channel desgn for the BIT technque wth a compresson factor f of 4. Cr s represent regular channels and C s nteractve channels. We note that there s one nteractve channel for every four regular channels. As an example, Table 4. shows the sze n mnutes of the compressed segments when K=30, c =3, f =4, the maxmum segment sze s 7 mnutes, and the length of the vdeo s 20 mnutes. Table 4. sze n mnutes of the compressed segments Segments V V 2 V 3 V 4 V 5 V 6 Sze 0.29.87 6.84 7 7 7 4.3 Implementng VCR functons wth BIT The clent storage space s dvded nto two parts: a normal buffer holds the normal vdeo, and an nteractve buffer caches the compressed verson of the same vdeo. To acheve nteractons usng BIT, clent nodes are requred to have c+2 loaders where c s the CCA parameter that refers to the normal loaders L,L 2,, L c. The two extra loaders L and L 2, called nteractve loaders, are used to download the compressed segments. A Clent ssung an nteractve functon swtches from normal mode to nteractve mode. Durng the normal mode, the clent renders the content of the normal buffer; and durng the nteractve mode the clent renders the content of the nteractve buffer. The sze of the normal buffer should be large enough to store a W-segment n order to guarantee contnuous normal playback [6]. The sze of the nteractve buffer s set twce the sze of the normal buffer to ensure good nteractve servce. To play back and provde VCR functons, we dentfy two components that work together: () the Player responsble for
renderng the frames and acceptng nteractons, (2) the Loader responsble for tunng to the approprate channels and downloadng the segments. We dscuss these two components as follows. Ext Yes End Of Vdeo Intal Mode = rmal User renders frames n rmal Buffer VCR operaton ntated 4.3. BIT Player The player keeps playng the content of the normal buffer untl t accepts a request for a VCR operaton. At ths tme, the behavor of the player s determned by the content of the buffer, the closest pont beng broadcast wth respect to the current play pont, and the type of the nteracton. We descrbe the player behavor n the followng: Play Acton: Durng the playback of the vdeo, the player renders the current play pont of the normal buffer, and the play pont of the nteractve buffer moves accordngly. Fast-Forward/Fast-Reverse/Pause actons: When a contnuous acton s ntated, the player swtches to the nteractve mode to render the frames n the nteractve buffer. Two scenaros can follows: () If the user resumes the normal play before ths buffer s exhausted, the player swtches to the normal mode, and allocates the loaders to download the approprate segments such that the normal playback s resumed at a frame closest possble to the destnaton pont. We wll refer to such a pont as closest pont hereafter. (2) If the user contnues the nteractve acton beyond the frames n the nteractve buffer, the player forces the user to resume the normal play by settng the destnaton pont to the newest frame of the nteractve buffer n case of a Fast-Forward acton, or the oldest frame n case of a Fast-reverse or pause actons. The player then allocates the loaders, and resumes the normal play at the closest pont as n the prevous case. We note that jumpng to the closest pont wll show some dscontnuty that we refer to as a dsplacement. Ths ssue s consdered n ths paper for completeness. In practce, t can be avoded by allocatng suffcent buffer space for a gven applcaton. Ths s feasble consderng the low cost of today s dsk technology. Fve US dollars of dsk space would be more than enough to allow a contnuous fast-forward for ten mnutes (assumng MPEG-2 wth a compress rato of :4). It s also nterestng to note that the parameter x (refer to secton 2.) has a value for both Fast-forward and Fast-Reverse actons, whch s due to the use of the same play back rate n the normal mode as well as n the nteractve mode. Jump Forward/Jump Backward actons: If the destnaton pont s n the normal buffer, the player smply moves the play pont to the destnaton pont, and contnues the normal play. Otherwse, the player allocates the loaders to start downloadng the approprate segments, and contnues the normal play from the closest pont. Durng these types of nteractons there s no swtch of modes. The algorthm for the player s descrbed formally n Fgure 3. 4.3.2 BIT Loader The Loader s responsble for tunng to the approprate channels and loadng the segments. When no nteracton s taken place, the behavor of the loader s smlar to the CCA technque. Playback of a vdeo conssts of two phases. Frst, the clent downloads and Mode = rmal User renders frames n rmal Buffer Destnaton Pont s n the rmal buffer and Accessble Exhausted = true Yes Operaton s Contnuous Jump to destnaton pont Yes Exhausted = true OR Mode =Interactve Yes Call Loaders: Load Approprate segments Mode = Interactve User renders frames n Interactve buffer User Resumes Yes rmal Play Interactve buffer Exhausted Yes Exhausted = true Fgure 3: BIT Player plays back the unequal-szed fragments durng the unequal phase, and then contnues wth the equal-szed fragments durng equal phase. A clent node uses c+2 loaders f the current segment,.e. the segment vewed by the user, s n the unequal phase. Only three loaders are needed f the current segment s n the equal phase. Ether way, f the current segment s n the frst half of ts nteractve group group j, the two nteractve loaders are allocated to the prevous and to the current nteractve groups,.e. group j- and group j. If, however, the current segment s n the second half of ts nteractve group, the nteractve loaders are allocated to the current and future nteractve groups,.e. group j and group j+. By prefetchng the compressed segments, we make sure that the play pont of the nteractve buffer s always n the mddle. Such choce wll depend on the behavor of the user. For nstance, users ntatng more forward actons than backward actons can set the loader to always prefetch group j and group j+. When an nteractve operaton s completed, f the VCR acton was contnuous or f the destnaton pont exhausted the buffer, then the loader reallocates the normal and nteractve loaders to the approprate segments. If the nteractve segments are not beng downloaded or are not n the nteractve buffer, the segments are downloaded mmedately; otherwse no acton s takng place. Once the current segment s beng downloaded and vewed, the play pont of the nteractve buffer s logcally shfted to match the play pont of the normal buffer. Fgure 4 gves the algorthm of the loader. Fgure 5 shows the clent buffer before and after a contnuous operaton wth f=4. The play ponts of both the normal buffer and the nteractve buffer are shown as arrows. Before the nteracton begns, the normal play pont s n segment S +. Smlarly the nteractve play pont s adjusted to the same frame. When the fast Reverse nteracton s completed, the loader starts downloadng the destnaton pont n segment S -2. Snce the destnaton segment s n the second half of ts group, nteractve loaders are allocated to the current group and to the next group,.e. V - and V I
respectvely. The nteractve loader does not download the latter segments snce they are already stored n the nteractve buffer. We assume that the current play pont s n the normal segment S And S s n the nteractve group j. f (S s n the unequal phase) Allocate the loaders L,L2,, Lc as n CCA; Download the approprate segments; Call to allocate nteractve loaders.e. L and L 2; f (S s n the equal phase) Allocate one loader L k; Download the segment Call to allocate nteractve loaders // Allocaton of nteractve loaders f(s s n the frst half of ts nteractve group j) Allocate L to the nteractve group j-; Allocate L 2 to the nteractve group j; Download the compressed segments f not n the buffer; f(s s n the second half of ts nteractve group j) Allocate L to the nteractve group j; Allocate L 2 to the nteractve group j+; Download the compressed segments f not n the buffer; Fgure 4: Loader Algorthm V V - V V - S +3 S +2 S + S S - S -2 S -3 S -4 S +3 S +2 S + S S - S -2 S -3 S -4 S + S -2 S + Before the nteracton After the nteracton Fgure 5: Buffer Content Before and After a Fast Reverse nteracton case. case.2 case.3 case.4 case 2. case 2.2 case 3. case 3.2 Fgure 6: Closest Broadcast Pont durng the Unequal phase (c=3, : Destnaton pont, : Broadcast pont). The shaded areas represent the frames to be downloaded gven 4.4 Analyss of the Closest Broadcast Pont In ths secton we dscuss the varous cases that guarantees a normal play back after an nteractve acton s completed. We gve the worst dsplacement that our technque can encounter. We then show that ths worst case can be avoded by allowng the user n the nteractve mode an extra small amount of tme. Fgure 6 shows dfferent cases of the closest broadcast pont after the completon of an nteractve operaton. The parameter c s 3, however smlar logc s appled for greater values. We refer to as the destnaton pont, the ponts s are the broadcast ponts. The closest broadcast pont relatve to a destnaton pont s dfferently studed n the unequal phase and n the equal phase as follows: Unequal phase: (Fgure 6) Durng ths phase, we dfferentate the followng cases: () All segments are of unequal szes, (2) The frst two segments are of equal sze but not the last one, and (3) the last two segments are of the same sze but not the frst one. We further dstngush the subsequent cases when all segments are of unequal sze. Case.: The segments are all left algned. If segment was loaded at ts broadcast pont, the user wll consume t before the broadcast of the next cycle of segment +, smlarly for segment +. Hence the closest broadcast pont n ths case s the broadcast pont of segment +2. When the loadng of segment +2 starts, the two other avalable loaders are reallocated to the next round. Case.2: Snce segments and + are rght algned. The closest broadcast pont s at segment. After the consumpton of segment, the begnnng of segment + s avalable and the begnnng of segment +2 s avalable after the consumpton of segment +. Case.3: Segments and + are not rght algned, but segments + and +2 are. Thus the closest broadcast pont s at segment +. When the user consumes segment +, segment +2 s avalable. Case.4: Snce all segments are left algned, the closest broadcast pont s at segment. When the frst two segments are of equal sze and the last segment s of a dfferent sze, we dstngush two more cases (case 2 Fgure 6). In both cases the closest broadcast pont s at segment. The dfference between these cases s the tme of loadng segment +2 and +. For case 2., segment +2 s loaded after the consumpton of segment +. Whle n case 2.2, segment +2 and + are loaded at the same tme. Smlar logc s appled for the thrd case where case 3. s smlar to case.3 and case 3.2 s smlar to case 2.2. Equal Phase: Durng the equal phase, the closest broadcast pont s always at the same segment as the destnaton pont. Snce we use only one regular loader n the equal phase, once the user consumes segment segment + s always avalable. A mnmal dsplacement occurs when the destnaton pont s the closest broadcast pont. However, there are stuatons where the dsplacement s maxmal. In Fgure 6, the worst dsplacement s shown n case.. If the destnaton pont s the frst frame of segment and the broadcast ponts are at the last frame of the same segment, because for ths specfc case the closest broadcast pont s at segment +2, then the worst dsplacement s twce the sze of segment +.
If we denote by k, k+, k+2, the segments of unequal szes such that the k+2 segment s the frst W-segment. Therefore, usng formulae (2) (Secton 3.), the worst dsplacement s gven by the followng: Worst_dplacement = 2 2 k+- k+/c (3) Consderng the case. n Fgure 6, f we afford the user n the nteractve mode an extra small amount of tme, we can avod ths specfc case. For example, when performng a Fast Forward acton, by forcng the user to render the content of the nteractve buffer, we can move from case. to the.2 case that shows a smaller dsplacement. Pause m pause the sake of expermentaton, we make the followng assumptons to conduct our smulatons. We frst assume that duratons for a play and for nteractve actons are exponentally dstrbuted wth ther respectve mean shown n Fgure 7. Furthermore, we assume that the duraton of all nteractve operatons are of equal mean.e. m ff = m fr = m pause = m jf = m jb, that we refer to as m or the nteractve mean. Fnally, we set the nteractve probabltes to be equal,.e., P pause = P ff = P fb = P jf = P jb. Therefore, P pause = P ff = P fb = P jf = P jb = P /5. We refer to the duraton rato dr as the average amount of nteracton (m ) over the average duraton of a normal playback nterval (m p ), hence dr = m. Ths rato measures the degree of nteracton. mp Fast Reverse m fr P fr P play P jb Jump Backward m jb Play m p P pause P jf P ff Jump Forward m jf Fgure 7: User Interacton Model Fast Forward m ff 5. PERFORMANCE STUDY To evaluate the performance of the BIT technque, we mplemented detaled smulators to compare t wth the Actve Buffer Management (ABM) scheme. We dscuss the smulaton study n ths secton. We frst present the user behavor model, and then dscuss the performance metrcs, and the smulaton results. 5. User Behavor Model Users can ntate an nteracton followng the model gven n Fgure 7. Smlar user nteracton model have been ntroduced n [2] and also used n [0]. Our model gves the probabltes of ssung an nteracton and the duraton of each nteracton. The probabltes defne the frequency of nteractons; and the m s defne the average amount of vdeo story, n tme unt, fast forwarded or fast reversed n a contnuous nteracton. Ths amount of contnuous nteracton s n terms of the orgnal uncompressed verson of the vdeo. For nstance, m fr = 50 seconds ndcatng that the users, on the average, fast reverse 50 seconds of the vdeo story; ths s not the same as pressng the fast-reverse button for 50 seconds. Snce Jump Forward and Jump Backward are nstantaneous, ther duraton refers to the length of vdeo skpped. A user starts playng the vdeo wth duraton m p. After ths duraton, the user may ssue an nteracton wth the probablty P = -P p or returns to play the vdeo wth the probablty P p. Once the VCR acton s fnshed, the user always returns to play a porton of the vdeo. Fndng typcal values for those parameters s out of the scope of ths paper. However, for 5.2 Performance Metrcs An nteracton can be successful or unsuccessful. An nteracton s consdered unsuccessful f the data currently n the buffers fal to accommodate the nteracton. For nstance, a jump to a destnaton pont outsde the buffer s consdered unsuccessful. In the case of contnuous actons, a long-duraton fast forward pushng the play pont off the nteractve buffer s consdered as an unsuccessful nteracton. To measure the percentage of unsuccessful cases, we use Percentage of Unsuccessful Actons as the frst performance metrc n our study. For those unsuccessful cases, we would lke to know the degree of ncompleteness. Therefore, we use Average Percentage of completon as our second performance metrc. As an example, f the user wshes to fast forward the play pont for 20 seconds, but s forced to resume the normal play after only 5 seconds, the percentage of completon s 5/20 or 75%. Fnally, when the user resumes a normal play after a successful or unsuccessful nteractve acton, the begnnng play pont mght be slghtly dfferent from the desred destnaton pont of the nteractve acton. To capture these dsplacements n the performance comparsons, we use Average Dsplacement as the thrd metrc n our study. A good nteracton technque should have a low percentage of unsuccessful nteractve actons, hgh percentage of VCR acton completon, and low average dsplacement. 5.3 Smulaton results Wthout loss of generalty, we set the CCA parameter c to be 3 n ths study. That s, all clents use three loaders to load the regular segments. We use two more loaders to load the compressed segments. We conduct our smulatons on a vdeo of two hours. The smulaton results are presented n the followng subsectons. We show that our technque outperforms the Actve Buffer Management technque for longer nteractons. We examne the effect of the clent buffer sze on performance, and demonstrate that good average dsplacement can be acheved. Fnally, we llustrate the effect of changng the compresson factor on the percentage of unsuccessful actons and the average percentage of completon. 5.3. Effect of the duraton rato We frst set the compresson factor to 4. The regular clent buffer s 5 mnutes; and the total buffer space s 5 mnutes. The server
uses 40 channels, from whch 32 are used for the regular vdeo, and 8 for the compressed verson of the same vdeo (.e. K r =32, K =8). Ths confguraton shows 0 segments of unequal sze and 22 segments of equal sze. The sze of the smallest segment s 2.84 seconds. Hence, the average access latency s.42 seconds. The parameters for the user behavor are as follows. We set an equal probablty for a normal play and for all the nteracton types combned (.e., P p = 0.5, P = 0.5, P pause = P ff = P fr = P jf = P jb = 0.). The mean duraton of a play operaton m p s 00 seconds. We vary the duraton rato dr from 0.5 to 3.5. The values selected for ths rato are hgh for two reasons: () Jump actons ncur a bg change n the poston of the play pont causng a larger dr; (2) we want to study the technques durng perods of ntense nteractve actvtes such as searchng for a desred vdeo segment. In other words, we model the user nteracton behavor, not vdeo watchng behavor. Our objectve s to compare BIT and ABM n supportng nteractons. Fgure 8 shows the effect of changng the duraton rato on the percentage of unsuccessful actons and the average percentage of completon. For dr =0.5, 20% of the nteracton actons are dened under ABM, compared to only % under BIT. We notce that BIT s much less senstve to changng the duraton rato. When dr = 3.5, BIT outperforms ABM by a factor of 48% n terms of percentage of unsuccessful actons, and 3% n terms of average percentage of completon. The poorer performance of ABM s partally due to a very fragmented buffer. The prmary reason, however, s due to the fact that cachng a compressed verson s more effectve n supportng longer-duraton nteractve actons. Average Percentage of Completon 0.95 0.9 0.85 0.8 0.75 0.7 0.65 0.6 0.95 0.90 0.85 0.80 0.75 0.70 0.65 0.60 0.55 0.50 Actve Buffer Management BIT 0.5.5 2 2.5 3 3.5 Duraton rato Fgure 8: Effect of changng the duraton rato 2 3 4 5 6 7 regular buffer sze A.B.M, d_rato = BIT, d_rato A.B.M, d_rato =.5 BIT, d_rato =.5 Percentage of Unsuccessful Actons Percentage of Unsuccessful Actons 0.55 0.5 0.45 0.4 0.35 0.3 0.25 0.2 0.5 0. 0.65 0.60 0.55 0.50 0.45 0.40 0.35 0.30 0.25 0.20 0.5 0.0 Actve Buffer Management BIT 0.5.5 2 2.5 3 3.5 Duraton rato A.B.M, d_rato = BIT, d_rato = A.B.M, d_rato =.5 BIT, d_rato =.5 2 3 4 5 6 7 regular buffer sze 5.3.2 Effect of the buffer sze In ths study, we vared the clent buffer sze from 3 mnutes to 2 mnutes. We kept the same parameters for the user behavor as n the last experment except for the duraton rato that we set to.0 and.5 for two dfferent smulaton runs. Snce the sze of the regular playback buffer n our technque s a thrd of the total buffer sze (the other two thrds s used to hold the compressed segments), we had to use at least 20 regular channels to broadcast the entre vdeo f the regular buffer sze s mnute. However, f the regular buffer sze s 7 mnutes only 8 channels are needed. We use 32 regular channels, 4 of them broadcast segments of unequal sze and 8 channels broadcast segments of equal sze. Snce the compresson factor s 4, the total number of nteractve channels s 33 (wth K r =32 and K =33). Fgure 9 shows the effect of changng the buffer sze for a duraton rato of.0 and.5. We can see from the fgure that BIT does not requre nearly as much buffer space as ABM to acheve an average percentage of completon of more than 80%. When the buffer sze s small (.e., mnute), BIT doubles the performance of ABM n terms of number of unsuccessful actons. As the buffer sze ncreases, both technques show better performance; but BIT contnues to perform sgnfcantly better. Agan, the advantage of BIT can be attrbuted to cachng the compressed verson n the nteractve buffer. 5.3.3 Effect of server bandwdth to the total average dsplacement We recall that a dsplacement occurs when the resumpton from an nteractve acton starts the normal playback at a play pont dfferent from the desred destnaton pont of the nteractve acton. In ths experment, we nvestgate the effect of server bandwdth on the average dsplacement. We fxed the same user behavor parameters as n the prevous experments, wth the duraton rato set at.5. We vared the server bandwdth between 30 channels and 65 channels. The szes of the W-segment correspondng to dfferent server bandwdths are gven n Table 5.. The table also shows the number of regular channel (Kr) and the number of nteractve channels (K). In all of these confguratons, the smallest segment s less than 0 seconds. The plot for the average dsplacement under varous server bandwdth (n terms of number of regular channels) s presented n Fgure 0. We observe that the average dsplacements of BIT and ABM are comparable. Ther dfference decreases wth the ncreases n the server bandwdth. Ths s due to the fact that the sze of the W- segment s smaller for a larger server bandwdth. When the W- segment s very small, the average dsplacement becomes small regardless of the nteracton technque. Table 5. W-segments and ther respectve Kr and K W-segments (mn) 2 3 4 5 6 7 K r 32 72 48 36 32 28 24 K 33 8 2 9 8 7 6 Fgure 9: Effect of changng the buffer sze
Fgure 9: The effect of the server bandwdth on the average dsplacement Average Percentage of Completon 0.94 0.92 0.9 0.88 0.86 0.84 0.82 0.8 Average dsplacement n mnutes 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0. 0 24 28 32 36 48 72 32 Total number of channels 2 4 6 8 2 f Fgure 0: The effect of changng the compresson factor 5.3.4 The Effect of Changng the compresson factor f: In ths experment, we nvestgate the effect of changng the compresson factor f. We set the sze of the regular playback buffer at 5 mnutes and the total number of regular channels K r to 48. We set the mean duraton of a play to half the sze of the total buffer space and the duraton rato to.5. Table 5.2 gves the total number of nteractve channels along wth ther respectve compresson factor. The smulaton results are shown n Fgure. We observe that by ncreasng the compresson factor we ncrease the performance of BIT. However, an excessvely hgh compresson factor wll result n a lower resoluton of frames beng rendered durng a contnuous nteractve acton. Table 5.2 Compresson factor for a Total of 48 regular channels f 2 4 6 8 2 K r,k 48,24 48,2 48,8 48,6 48,4 6. CONCLUDING REMARKS BIT 0.25 0.23 0.2 0.9 0.7 0.5 0.3 0. 0.09 0.07 0.05 In ths paper we surveyed several technques that provde nteractve functons n the multcast/broadcast envronment. Although multcast delvery scales well to a very large number of users, the problem of provdng nteractve functons wthout compromsng the multcast paradgm remans. We frst showed Percentage of Unsuccessful Actons A.B.M BIT BIT 2 4 6 8 2 f that exstng technques solved only partally the problem of VCR nteractvty n a broadcast framework. There have been two approaches to date. The frst approach reles on guard channels to delver the emergency streams to provde VCR functons. Snce each emergency stream s dedcated for one clent, ths approach s lmted to small-scale deployment. The second approach attempts to mantan the play pont at the mddle of the vdeo segment currently cached n the prefetch buffer. Although ths strategy offers some advantage, t does not address the prmary requrement of VCR nteractvty whch demands the data stream to arrve at a much greater speed than the normal playback rate. The contrbuton of ths paper s the ntroducton of a new vdeo nteracton technque, for the broadcast envronment, that addresses the lmtatons of exstng solutons. Our scheme, called Broadcast-based Interacton Technque (BIT), offers better nteracton qualty by repeatedly broadcastng the nteractve (compressed) verson of the vdeo. By prefetchng data from ths verson and cachng them n the local buffer, the clent s able to support longer-duraton nteractve actons. In terms of scalablty, snce the clents can share the nteractve broadcasts, the bandwdth requrement of BIT s ndependent of the number of users the system s desgned to support. Ths strategy s consstent wth the broadcast paradgm. To assess the benefts of BIT, we mplemented two detaled smulators to compare BIT to a recent technque called Actve Buffer Management scheme. The smulaton results ndcate that BIT usng the same amount of buffer space can offer sgnfcantly better performance. 7. REFERENCES [] E. L. Abram-Profeta and K. G. Shn: Schedulng vdeo programs n near vdeo-on-demand systems. In Proc. ACM Multmeda 97, vember 997. [2] E. L Abram-Profeta and K. G. Shn: Provdng unrestrcted VCR functons n multcast vdeo-on-demand servers. In Proc. of IEEE Internatonal Conference on Multmeda Computng and Systems (ICMCS 98), Austn, Texas, 998. [3] C.C. Aggarwal, J. L. Wolf, and P.S. Yu. A permutatonbased pyramd broadcastng scheme for vdeo-on-demand systems. In Proc. of the IEEE Int l conf. on Multmeda Systems 96, Hroshma, June 996. [4] K. C. Almeroth and M. Ammar: A scalable nteractve vdeoon-demand servce usng multcast communcaton. In Proc. of Int l Conf. on Computer Communcaton Networks, pp. 292-30, 994. [5] K.C. Almeroth and M. Ammar: On the use of multcast delvery to provde a scalable and nteractve vdeo-ondemand servce. IEEE Journal of Selected Areas n Communcatons, vol. 4, August 996. [6] K. C. Almeroth and M. Ammar: The nteractve multmeda jukebox (IMJ): A new paradgm for the on-demand delvery of audo/vdeo. In Proc. of the 7th WWW conference, Brsbane, Australa, Aprl 998. [7] A. Dan, D. Staram, and P. Shahabudn. Schedulng polces for an on-demand vdeo server wth batchng. In Proc. of
ACM. Multmeda, pages 5-23, San Francsco, Calforna 994. [8] A. Dan, D. Staram, and P. Shahabudn. Dynamc batchng polces for an on-demand vdeo server. Multmeda Systems, 4(3) : June 996. [9] Z. Fe, I. Kamal, S. Mukherjee, M. Ammar: Provdng nteractve functons for staggered multcast near vdeo-on demand systems. In Proc. of the IEEE Internatonal Conference on Multmeda Computng and Systems, June 999. [0] Z. Fe, I. Kamel, S. Mukherjee, and M. Ammar: Provdng nteractve functons through actve clent buffer management n parttoned vdeo broadcast. Proc. of Frst Internatonal Worlshop on Networked Group Communcaton, (NGC 99) Psa, Italy, v. 999. [] L.Gao, J. Kurose, and D. Towsley: Effcent schemes for broadcastng popular vdeos. In Proc. of NOSSDAV 98, 998. [2] L. Golubchk, J.Lu, and R. Muntz. Adaptve pggybackng: A novel technque for data sharng n vdeo-on-demand storage servers. ACM Multmeda Systems, 4(3): 40-55, 996. [3] K. A. Hua., JungHuang Oh, and Khan Vu. An Adaptve Vdeo Multcast Scheme for Varyng Workloads Proc. Int l Conf. on Computer Communcatons and Networks, 998, pp. 227-234. [4] K. A. Hua., S. Sheu, and W. Tavanapong. Channg: A generalzed batchng technque for vdeo on demand. In Proc. of the Int l Conf On Multomeda Computng and System. June 997. [5] K. A. Hua and S. Sheu. Skyscraper Broadcastng: A new broadcastng scheme for metropoltan vdeo-on-demand systems. In Proc. of the ACM SIGCOMM 97, Cannes, France, September 997. [6] K. A. Hua, Y. Ca, and S. Sheu: Explotng clent bandwdth for more effcent vdeo broadcast. In Proc. of 998 Int l Conf. on Computer Communcatons and Networks. [7] K. A. Hua, Y. Ca and S. Sheu. Patchng: A multcast technque for true vdeo-on-demand servces. In Proc. of ACM Multmeda, Brstol, Unted Kngdom, September 998. [8] W. Lao and V. O. L. The splt and merge (SAM) protocol for nteractve vdeo-on-demand. IEEE Multmeda, vol.4 pp. 5-62, October-December 997. [9] J.F. Pars, S.W. Carter, and D.D.E. Long. Effcent broadcastng protocols for vdeo on demand. In Proc. of SPIES s Conf. on Multmeda Computng and Networkng (MMCN 99), pages 37,326, San Jose, CA, USA, January 99. [20] [S.Sen, L.Gao, J.Rexford, and D. Towsley. Optmal patchng schemes for effcent multmeda streamng. In Proc. of IEEE NOSSDAV, NJ, USA, June 999. [2] Vswanathan and T. Imelnsk. Metropoltan area vdeo-ondemand servce usng pyramd broadcastng. Multmeda systems, 4(4): 79-208, August 996