7/23/2019 Paris 1998

1/8

roadcasting rotocol for Video and

Jehan-FranGois Pikist Steven

W.

Carter Darrell

D. E.

Long$

Department of Computer Science

University

of

Houston

Houston, TX

77204-34

paris

@

cs uh.edu

Department of Com puter Science

Baskin School

of

Engineering

University of California, Santa Cruz

Santa Cruz, CA 95064

{carter, darrell} @cse.ucsc.edu

Abstract

Broadcasting protocols can improve the eficiency of

video on demand services by reducing the bandwidth re-

quired to transmit videos that are simultaneously watched

by many viewers. We present here a polyharmonic broad-

casting protocol tha t requires less bandwidth tha n the best

extant protocols to achieve the same low maximum wait-

ing time.

We also show how to modify the protocol to accom mo-

date very

long

videos without incre asing the buffering ca-

pacity of the set-top box.

Keywords:

video on dema nd, video broadcasting, har-

monic broadcasting.

1 Introduction

Video on demand (VOD) proposes to provide sub-

scribers who are connected through a set-top box (STB)

with the possibility

of

ordering at any time the video of

their choice and starting immediately to watch it on their

television set. Despite its great potential, VOD has had a

slow start. None of the companies that invested in VOD

have been able to com e with a single successful commer-

cial system. The overall consensus now is that the com-

mercial deployment of VOD will have to wait until the

cost of building and maintaining the required infrastruc-

ture can be significantly lowered.

Broadcasting is one of several techniques that aim to

reduce the cost of VOD [9]. It is clearly not a panacea as

it only applies

to

videos that are likely to be watched by

many viewers. Even so, the savings that can be achieved

are nevertheless considerable, as it is often the case that

+Th is work was performed while this author was on sabbatical leave

at the Department of Computer Science, University of California, Santa

Cruz.

$This research

was

supported by the Office of Naval Research under

Grant

N00014-92-J-1807.

40

percent of the demand is for a small num ber, say,

10

to

20, of popular videos

[ 2 4 ] . A

naive broadcasting strat-

egy would simply consist of retransmitting the s ame video

on several distinct channels at equal time intervals. The

major problem w ith this approach is the number of ch an-

nels per video required to achieve a reasonable waiting

time. Consid er, for instance, the case of a video lasting

two hours, which happens to be close to the average du-

ration of a feature movie. To guarantee that no customer

would ever have to wait more than five minutes we would

have to broadcast twenty-four different copies of the video

starting every five minutes.

Many more efficient protocols have been proposed.

They include Viswanathan and Imielinskis pyramid

broadcasting protocol

[

81, Aggarwal, Wolf and Yus

permutation-based pyramid broadcasting protocol [ I] ,

Hua and Sheus skyscraper broadcasting protocol [5],

Juhn and Tsengs harmonic broadcasting protocol [ 6 ] nd

its variants

[ 7 ]

All these protocols sh are a similar organization. They

divide each video into segments that are simultaneously

broadcast on different data streams. One of these streams

transmits nothing but the first segment of the video in real

time. The other streams transmit the remaining segm ents

at lower bandwidths. Wh en custom ers want to watch a

video, they wait first for the beginning of the first segmen t

on the first stream. Wh ile they start watching that seg-

ment, their set-top box (STB) starts downloading enough

data from the other streams so that it will be able to play

each segment of the

video

in turn.

This approach requires an STB capable of storing a sig-

nificant fraction (around

40

percent for some protocols)

of each video while it is being watched. This extra cost

is more than compensated by the bandwidth savings that

can be achieved. W hile the staggered broadcasting tech-

nique we described above requires twenty-four channels

to guarantee a maximum waiting time of five minutes for a

two-hour video, harmonic broadcasting protocols require

slightly less than four channels to achieve the same qual-

0-8186-9014-3/98 10.00 998

IEEE

690

mailto:cse.ucsc.edumailto:cse.ucsc.edu

7/23/2019 Paris 1998

2/8

ity of service.

As we will see, even greater bandwidth savings could

be achieved if the STB could start downloading data from

the moment the customers select the video they want to

watch rather than waiting for the beginning of the first

segment on the first stream. We present a new

polyhar-

monic protocol that imposes the same fixed delay to all

customers wanting to watch

a

given video. Sin ce this de-

lay is the same for all customers, the protocol can take ad-

vantage of it to reduce the transmissions of

all

segments,

including the first one. As a result, the total bandwidth

can be further reduced by around ten percent.

The remainder of the paper is organized as follows.

Section 2 presents the harmonic broadcasting protocol

and its variants. Section 3 introduces our new protocol

and compares its bandwidth requirements to those of the

harmonic broadcasting protocols. Section 4 discusses the

main advantages and limitations of polyharmonic broad-

casting. Section

5

presents

a

possible extension of poly-

harmonic broadcasting that would let them handle videos

of arbitrary length. Section 6 contains ou r conclusions.

Harmonic Broadcasting

Harmonic Broadcasting (HB) divides a video into n

equally-sized

segments.

Each segment

Si ,

for 1 5

i n,

is broadcast repeatedly on its own channel with a band-

width b / i , where b is the consumption rate of the video

(see Figure

1).

When a client requests a video, it must wait for the start

of an instance of

S

nd then begin receiving data from

every stream for the video. That me ans that the client and

the server must be able to support a bandwidth of

n . n .

b

B H B n )

= = c

= b H n )

i=

1

i= 1

where H n ) s the harmonic number of n.

A

slot

is the amoun t of time it takes for a client to con-

sume

a

single segment of the video. We represent this

time by

d .

Since the first segment is broadcast with that

periodicity,

d

is is given by

b n

and is also the maximum amount of time a client must

wait before viewing its request.

subsegment is the amo unt of a segment the client re-

ceives during

a

slot of time. The first segment only has

one subsegment, the s egme nt itself; every other segment

Si has i equal subsegments, S ~ J ,~ J ,

. ,

Si,i.

Unfortunately HB does not always deliver all data on

time. Consider the first two streams in Figure 1.If the

client makes its request in time to receive the second in-

stance of

S 1

and starts receiving data at time t o then it

will need all of the data for S 2 , l by time t o + 3 d / 2 . How-

ever, it will not receive

all

of that data until time t o

+ 2d

It turns out HB will not work unless the client always

waits an ex tra slot of time before consum ing data.

Two variants on HB do not impose the extra waiting

time. Cautious Harmonic Broadcasting (CHB) broad-

casts the video in a similar fashion

as

HB. T he first stream

broadcasts

S

epeatedly as before, but the second stream

alternates between broadcasting

Sa

and

5 3 .

Then the re-

maining

n 3

streams broadcast segments

S,

to Sn such

that the stream for

Si

has bandwidth

b / i

1 ) .

As before, the client will receive data from all streams

for the video simultaneously. That means CH B requires a

bandwidth of

n-1 ,

i=

b

2

- + b H n - l )

or roughly b / 2 more than the original HB protocol.

Quasi-harmonic Broadcasting (QHB) uses

a more

comp lex schem e to break up the video. T he first segment

is left intact, but then each of the remaining segments Si,

for 2 5

i

5 n , is divided up into im 1 fragments for

some positive parameter m. Slots are also broken up into

m

equal

subslots,

and each subslot can be used to broad-

cast a single fragment. The key to Q HB is that the frag-

ments are not broadcast in order. The last subslot of each

slot is used to broadcast the first

i

1 fragments repeat-

edly, and the rest

of

the fragments are ordered such that

the

kth

subslot of slot

j

is used to broadcast fragment

i k +

j 1 mod

i m

1 )

+ i

(see Figure 2 ) .

Since the above ordering adds s ome redundancy-each

sequence of

im

fragments will contain one of the first

i

- 1 ragments tw ic en ac h subslot of st ream i will have

to broadcast

l / i m 1)

of segment

Si

instead of

l / i m

as in HB. This will increase the required bandwidth for

stream

i

from b / i to bm/ im 1 for 2 5

i

5 n. Thus

the total bandwidth required for Q HB is

n

with

691

7/23/2019 Paris 1998

3/8

Stream :

-d-

Stream

2:

s,

Stream 3:

-

s3

I

Figure : An illustration of the first three streams for a video u nder harmo nic broadcasting.

Sl Sl Sl

Figure 2: An illustration of the first three streams

for

a video under quasi-harmon ic broadcasting when

m

= 4 .

692

7/23/2019 Paris 1998

4/8

6 6 10 2 14

16

18 2

Bandwidth Per Video mult iples

of the

consumption ate)

Figure

3:

How harmonic broadcasting com pares to other

broadcasting protocols (from [7]

The major advantage of these three harmonic proto-

cols is their low bandwidth requirements. Figure 3 shows

the bandwidth versus client waiting times for the har-

monic and cautious harmonic broadcasting and compares

them with those of pyramid broadcasting

[8],

the uncon-

strained version of permutation-based pyramid broad-

casting [ 11 and skyscraper broadcasting with a maximum

width of 52

[ 5 ]

Both harmonic broadcasting protocols emerg e as clear

winners as none of the three other protocols even ap-

proaches their performance. One may then wonder

whether harmonic broadcasting does not provide the m in-

imum bandwidth required to guarantee a given maxim um

waiting time.

A s

we will see in the next section, this is

not the case. The sam e max imum waiting times can be

achieved at a lower cost by switching to a fixed wait pol-

icy and having the S TB download data from the moment

the customer selects the video.

3 Polyharmonic Broadcasting

Polyham onic broadcasting PHB) is a new broadcast-

ing protocol aiming at reducing the bandwidth cost of

providing a given maxim um waiting time. To achieve

its goal, polyharmonic broadcasting introduces two ma-

jor changes . First, it requires that the client STB starts

downloading data from the moment a customer requests

a specific video instead of waiting until the customer be-

gins watching the beginning of the first segmen t. Sec-

ond, polyharmonic broadcasting uses a fixed wait policy.

Under harmonic broadcasting and its variants,

customers

have to wait for the beginning of an instance of the first

segment of a video. Polyharmonic broadcasting requires

all customers to w ait exactly the same amount of time re-

gardlessly of the timing of their request.

Like harmonic broadcasting, polyharmonic broadcast-

ing breaks a video into

n

segments of duration

d = D / n

where D is the duration of the video. If b represents again

the video consumption rate, the total size of the video

S

will be equal to bD and the size of each segment equal to

Sln .

The protocol will allocate

n

distinct broadcasting

streams to these

n

segments. Each stream

i

will repeatedly

show segment S i Under polyharmonic broadcasting, no

client can start consuming the first segment of the video

before having downloaded d ata from all

n

streams during

a time interval of duration w =

m d

where m is som e inte-

ger m

2

1. As a result, segment Si will not be consumed

until

m+

i

- ) d

ime units have elapsed fro m the mo-

ment the client started downloading da ta from the server.

Ensuring that segment

Si

will be entirely broadcast over

this time interval would suffice to guarantee that all the

contents of segment Si will be already loaded in the STB

before the customer starts viewing that segment. This can

be achieved by retransmitting segment Si at a transmis-

sion rate bi

=6

he total bandwidth B ~ H Be-

quired by the polyharmonic broadcasting protocol is given

by

n

i 1

1

m + i - 1

= b f :

=

i=l

b H n+m 1 H m 1)Xl)

where

H k )

epresents again the harmonic number of

IC

Since the whole contents of segment Si will be received

by the STB before the customer starts viewing that seg-

ment, these data can be received in any arbitrary order.

There is thus no need to wait as before for the beginning

of a transmission of the first segment of the video. Hence

the minimum waiting time w required by the protocol is

also the maximum time a customer will ever have to wait.

Whenever the number of segments n is a multiple

k

of

m,

equation can be rewritten as

Since w

= m d

and

d = D / n ,

he waiting time

w

is

linked with the duration of the video D by the relation

w = D/ k .

In oth er words, all combinations of the two p arameters

n

andm keeping the ratio

n / m

constant, will achieve the

same waiting time

w.

693

7/23/2019 Paris 1998

5/8

Server Stream

1:

S1,l SL2

S lJ

s1,2

elay -

I

Server Stream

2:

Sl s s3

Server Stream

3:

Figure

4:

An illustration of th e first three streams for a video und er polyharmonic broadcasting with

m

=

2 .

6

I

m

2 5

-

2 4

8

Quasi Harmonic (m = 4) -

uasi Harmonic

(m

=

16) - ---

Polyharmonic(m

=

I ) - * - - -

Polyharmonic(m =

4

x

Polyharmonic

(m

= 16) A

Lower Bound

for

Polyharmonic

- x

-

I

0

20 40

60

80 loo 120

SegmentsISegmentGroups

Figure 5 : Bandwidth requirements

of

quasi-harmonic and

polyharmonic broadcasting. The numbers on the x-axis

represent number

of

segments for QHB and number

of

groups

of

m segments for PH B.

When m = 1, k becomes equal to n and equation 1

degenerates into

B P H B ~ ,

)

=

b ( H ( ( k )

H 0 ) )=

b H n ) .

The polyharmonic protocol w ith m = 1 equires thus the

same bandwidth a s the harmonic protocol, while guaran-

teeing a maximum waiting delay equal to D l n , which the

harmonic protocol can not achieve.

Observing that

H ( ( k+

l ) (m+ 1) 1

-

H m )

=

1

I C l ) m

H ( ( k

1)m- 1)

+ . . . +

1

m

-

H m

1

k l ) (m+ 1 1

and that

1

< -

k + l ) m

I C +

l ) ( m

+

1 1-

I

m

1 1

. . .

for all

k

2 1and

m 4

,we obtain

H ( ( k l ) (m

1 1

H m ) , m + j - 1

j= i -m+l

l o i = n + m

We can also comp ute the amount of data consumed during

a time slot as

Finally, we can define

i

as the amount of data the client

has in its buffer after each time slot i and calculate it as

where Bo =

0.

The maximum i gives the storage re-

quirements for the protocol.

Figure

7

represents the storage requirements of the

polyharmonic broadcasting protocol for videos having up

to 200 segments at selected values of the parameter m.

Since polyhannonic broadcasting stores every segment

before broadcasting it, its storage requirements are par-

ticularly high when the video is subdivided into a small

number

n

of segments with the worse case being

n

=

1.

It is however very unlikely that polyhmonic broadcast-

ing would be used in this context as it would be much

simpler then

to

rebroadcast the video

at

normal speed on

a single channel.

More reasonable values of n , say n > 20 and

m

2 2

lead to storage requirements below 50 percent of the video

695

7/23/2019 Paris 1998

7/8

gOl

Polyhamonic(rn=

1)

olyharmonic (m = 2 -----

Polyharmonic (m =

4)

Polyharmonic rn

= 16)

0

20 4 60 80 100 120 140 160

180

200

Numberof Segments

Figure

7:

Storag e requirements of polyharmonic broad-

casting.

7

6.5

6

5.5

5

4.5

4

3.5

3

2.5

0 I 2

3

4

5 6 7 8 9 10

Average Waiting Time (percentage

of

video length)

Figure

8:

Bandwidth versus average waiting times for

polyharmonic and quasi-harmonic broadcasting.

size for all values

of m

5

4.

Higher values of

m

are not

likely to be used since they do not provide significantly

lower bandwidths than

m = 4.

4 Discussion

As

one can see, polyharmonic broadcasting requires

less bandwidth than the best extant harmonic broadcasting

protocol to guarantee a given maximum response time. It

does not require the complex encoding scheme of quasi-

harmonic broadcasting and, unlike harmonic broadcast-

ing, it never fails to deliver the data on time. Despite these

major advantages, our new broadcasting protocol presents

two limitations that need to be addressed.

First, polyharmonic broadcasting requires

m

times

more streams than o ther harmonic broadcasting protocols.

This will require additional bookkeeping from the server

and the client an d will undeniably complicate their tasks.

Second, polyharmonic broadcasting forces all cus-

tomers to wait for the maximum waiting delay while

other harmonic protocols only require few customers to

wait that long. If we were indeed comparing their mean

waiting times as in Figure

8,

polyharmonic broadcasting

would be no better than extant harmonic protocols. The

real issue here is custom er response to service delays. We

believe the average waiting time is not the best perfor-

manc e indicator for the quality of the service being pro-

vided be cause it assu mes that the customer is insensitive

to the variance of the service time. This is not true. Mo st

customers are more annoyed when experiencing unusu-

ally long waiting times than they are elated when the ex-

perience a very fast service. A fixed waiting time has the

advantage of being predictable. Many providers

of video

on dem and services will probably use this delay to let their

customers watch some previously downloaded announce-

ments such as trailers for coming attractions and stern

warnings to potential copyright violators. This w ould not

be very different of what is already done on most video

cassettes even though the customer would not have the

option to fast forward until the beginning of the video

itself.

5 Handling Long Videos

All efficient broadcasting protocols require enough

buffer space in the user set-top box to store about 40 per-

cent of each video. Hence they cannot be used to broad-

cast videos whose duration exceeds the capacity of the set-

top box. Th e following extension eliminates this problem.

Let us assume without

loss

of generality that the set-top

box buffer cannot hold more than segments of the video.

Then th e client can operate in the following fashion:

1.

It captures and stores in its buffer the

I

first segments

of the vide o-th at is, segments

S

o

Sl;

2.

It plays these seg ments in sequence;

3.

When it has finished playing a segment S with

1

5

j

5 n

it starts capturing segment Sl j

us-

ing the buffer that was previously used by Sj for that

purpose.

The major drawback of this solution is the additional

bandwidth. The client will have to capture segment Sl j

during the

I

1 ime fram es occurring within the time in-

terval between the time when its has finished playing seg-

ment

S

and the time wh en it must start playing segment

Sl j. s

a result, all segments Sl jwith 0 < j

5

n

will have to be transmitted at a minimum bandw idth

instead of . Instead of having a bandwidth of

696

7/23/2019 Paris 1998

8/8

b H n

+m 1

b H m l ,

he new protocol would

require a bandwidth of

b n -

1 - 1

b H m

+ 1 1 b H m 1)+

and the bandwidth overhead of the method w ould be given

by

b n

1 - 1

b H m + n

1

+

b H m

+ 1

1

These results are better illustrated in an example. Con-

sider a video lasting four hours and assume we want to

achieve a maximum w aiting time of two minutes. With

m = 4, that would require 4 x 240/2 = 480 segments

and a total bandwidth equal to 4.925 times the video con-

sumption rate. If we do not want to have more than one

half of these segments simultaneously stored in the STB,

the total server bandwidth would increase to 5.243 times

the video consump tion rate, that is still 10 percent less

than the total bandwidth that cautious broadcasting would

require to provide the same response time without restrict-

ing the number of stored segments. Since the client never

has to capture more then 240 strea ms at the same time, the

total client bandwidth will be somewhat lower and never

exceed 4.239 times the video consumption rate.

6

Conclusions

Video broadcasting protocols can improve the effi-

ciency of video on demand services by reducing the band-

width required to transmit videos that are simultaneously

watched by many viewers. Some of the newest broadcast-

ing protocols to be proposed, harmonic broadcasting and

its variants require much less bandwidth than other broad-

casting protocols to guarantee the same maximum waiting

time.

We have presented a new broadcasting protocol that

provides the same maximum waiting time as the harmonic

broadcasting protocol while consuming significantly less

bandwidth. We also have shown how to modify the proto-

col to accommodate very long videos without increasing

the buffering capacity of the set-top box.

More work needs to be done to investigate the possible

existence of a theoretical lower bound for the bandwidth

required to achieve a given maximum waiting time under

any feasible broadcasting protocol.

video-on-dem and systems. In Proceedings of the

International Conference on Multimedia Computing

and Systems, pages 118-26, Hiroshima, Japan, June

1996. IEEE Computer Society Press.

1994.

The W all Street Journal,

November

10,

1993.

[2] D. Clark. Oracle predicts interactive gear by early

[3]

A. Dan, D . Sitaram, and P. Shahabuddin. Scheduling

policies for an on-demand video server with batch-

ing. In ACM Multimedia, pages 15-23, San Fran-

cisco, California, Oct. 1994.

[4] A. Dan, D. Sitaram, and P. Shahabuddin. Dynamic

batching policies for an on-demand video server.

Multimedia Systems, 4(3):112-121, June 1996.

[5] K. A. Hua and S . Sheu. Skyscraper Broadcasting: a

new broadcasting scheme for metropolitan video-on-

demand systems. In SIGCOMM 97, pages 89-100,

Cannes, France, Sept. 1997. ACM.

[6] L. Juhn and L. Tseng. Harmonic broadcasting for

video-on-demand service. IEEE Transactions on

Broadcasting,

43(3):268-271, Sept. 1997.

[7] J.-E Pgris, S. W. Carter, and D. D. E. Long. Efficient

broadcasting protocols for video on demand. In 6 t h

International Symposium on Modeling, Analysis and

Simulation

of

Computer and Telecommunication Sys-

tems (MASCOTS 98),

pages 127-132, July 1998.

[8]

S.

Viswanathan and T. Imielinski. Metropolitan area

video-on-demand service using pyramid broadcast-

ing. Multimedia Systems, 4(4):197-208, A ug. 1996.

[9] J. W. Wong. Broadcast delivery. Proceedings of the

ZEEE,

76(12):1566-1577, Dec. 1988.

References

[ I ] C . C . Aggarwal, J.

L.

Wolf, and

P. S .

Yu.

A

permutation-based pyramid broadcasting scheme f or

697