114
On Multiple Smoothed Transmission of MPEG4 Video Streams with Error Resilience Dongzhao Sun Submitted in partial fulfillment of the requirements for the degree of Doctor of Engineering The Graduate School of Information Systems The University of Electro-Communications March 2007

On Multiple Smoothed Transmission of MPEG4 Video Streams with

Embed Size (px)

Citation preview

On Multiple Smoothed Transmission of

MPEG4 Video Streams with Error Resilience

Dongzhao Sun

Submitted in partial fulfillment

of the requirements for the degree of

Doctor of Engineering

The Graduate School of Information Systems

The University of Electro-Communications

March 2007

On Multiple Smoothed Transmission of

MPEG4 Video Streams with Error Resilience

Approved by Supervisory Committee:

Chairpersion: Prof. Hiroyoshi Morita

Member: Prof. Hideki Koike

Member: Prof. Kazuyuki Suzuki

Member: Prof. Mamoru Hoshi

Member: AscP. Hiroshi Nagaoka

Copyright

by

Dongzhao Sun

2007

エラー耐性を考慮したMPEG4動画像

の多重伝送方式

孫 東照

概要

MPEG4の符号化方式には,動画像の動きの激しさに合わせて

ビットレートを変化させる可変ビットレート (Variable Bit Rate:VBR)

と,動きの激しさに関わらず常に一定のビットレートで符号化す

る固定ビットレート (Constant Bit Rate:CBR)の 2つ方法が存在する.

同じデータサイズの動画像データであれば,VBRの方がCBRより

も画質が良くなるが,シーンの状況に合わせてビットレートが大

きく変動するため,効率の良い伝送には工夫が必要である.

本論文では,可変ビットレートMPEG4動画像を対象として,ネッ

トワーク伝送における,主要な二つの問題,

1. 複数多種のビデオの多重平滑化,

2. 伝送誤りがビデオ再生に与える影響の抑制,

に取り組んでいる.一つのビデオサーバから複数のクライアント

にビデオデータを伝送する場合,先に各クライアントに対する伝

送すべきデータに対して平滑化してから,多重化する個別平滑化

方式と先に各クライアントに対する伝送すべきデータに対して多

重化してから,平滑化する一括平滑化方式が挙げられる.一括平

滑化方式の方がサーバ側の伝送レートを抑えることが期待できる

が,伝送レートを個々のビデオデータに戻して割り当てる場合,

レートが不足する問題が生じる.一方,伝送誤りがビデオ再生に

与える影響を抑えるため,MPEG4では双方向復号符号や再同期

マーカを用いている.しかしながら,再同期マーカは同期取れる

ため,定期的にMPEG4符号系列に挿入されているが,MPEG4動画

像の冗長度を増やしてしまう問題が生じる.

本論文で得られた主要な成果は以下の二つである.

1. 一括平滑化方式におけるレート配分時にレートが不足する問

題が生じないための必要条件と十分条件を与え,その条件に

基づくレート配分算法を提案し,その有効性を実験結果から

確かめた.

2. 再同期マーカが符号語として含む双方向符号の新しい構成

法を提案した.本構成法をMPEG4 動画像に用いることによっ

て,MPEG4動画像の冗長度を抑え,圧縮率を向上することが

期待できる.

On Multiple Smoothed Transmission of

MPEG4 Video Streams with Error Resilience

Dongzhao Sun

Abstract

In this thesis, we are concerned with an transmission system of multiple

MPEG4 video streams with error resilience from one server to many clients.

We will give solution for the following problems:

1. Smoothing of multiple video streams,

2. Adding the functions of error resilience to MPEG4 with less redun-

dancy.

In the first part of this thesis, we proposed an SaA(Smoothing after

Aggregation) scheme for multiple video streams which first aggregates all

the video streams into one stream, then smoothes it to obtain the entire

transmission schedule. Also, we examined the conditions for splitting the

transmission schedule for aggregated stream into each video streams without

client buffer overflow nor underflow. Under these conditions, we proposed a

rate spltting algorithm for aggregated stream. Based on our algorithm, the

peak rate of the transmission schedule for aggregated stream can be reduced

for about 15%.

Secondly, error resilience with less redundancy can be implemented by

using of synchronous RVLC which including resynchronization marker(re sync)

as codewords. we proposed the conditions of being a re sync for an RVLC.

Moreover, we proposed a construction algorithm for synchronous RVLC. Syn-

chronous RVLC obtained by the proposed algorithm for MPEG4 contains

re sync with probability about 0.3003 and redundancy about 0.65 which

is more effective than RVLC defined by ISO. Finally, we examined re sync

constructed by two codewords, and the probability for proposed synchronous

RVLC is about 0.09310 which is much higher than that of RVLC defined by

ISO.

Contents

1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objectives of this dissertation . . . . . . . . . . . . . . . . . . 13

1.2.1 Smoothing of multiple video streams . . . . . . . . . . 13

1.2.2 Adding the functions of error resilience to MPEG4 with

less redundancy. . . . . . . . . . . . . . . . . . . . . . . 15

1.3 Structure of this dissertation . . . . . . . . . . . . . . . . . . . 15

2 Optimal Smoothing 18

2.1 Optimal Smoothing Algorithm . . . . . . . . . . . . . . . . . . 18

2.1.1 Notations and definitions . . . . . . . . . . . . . . . . . 18

2.1.2 Optimal smoothing algorithm . . . . . . . . . . . . . . 20

2.1.3 Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.1.4 Optimality of the smoothing algorithm . . . . . . . . . 24

2.2 Online smoothing algorithm . . . . . . . . . . . . . . . . . . . 25

2.3 Simulation results . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 Multiple Smoothing 33

3.1 On splitting smoothed rate of aggregate stream of two clients . 34

3.2 Rate splitting algorithm . . . . . . . . . . . . . . . . . . . . . 43

3.3 Rate splitting of multiple video streams . . . . . . . . . . . . . 53

3.4 Simulation results . . . . . . . . . . . . . . . . . . . . . . . . . 55

i

3.4.1 On aggregation of two streams . . . . . . . . . . . . . . 55

3.4.2 On aggregation of multiple streams . . . . . . . . . . . 56

4 Synchronous RVLC 61

4.1 RVLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.1.1 Definitions and notations . . . . . . . . . . . . . . . . . 61

4.1.2 Construction of RVLC . . . . . . . . . . . . . . . . . . 63

4.2 Synchronous Codes . . . . . . . . . . . . . . . . . . . . . . . . 67

4.2.1 Synchronous prefix-free codes . . . . . . . . . . . . . . 68

4.2.2 Synchronous RVLC . . . . . . . . . . . . . . . . . . . . 69

5 Minimal Forbidden Words 71

5.1 MFWs(Minimal Forbidden Words) . . . . . . . . . . . . . . . 71

5.2 Construction of s[3] . . . . . . . . . . . . . . . . . . . . . . . . 74

6 Construction of Synchronous RVLC 81

6.1 Construction algorithm . . . . . . . . . . . . . . . . . . . . . . 81

6.2 Experiment results . . . . . . . . . . . . . . . . . . . . . . . . 83

6.3 Probability consideration . . . . . . . . . . . . . . . . . . . . . 86

6.4 Consideration of Re sync Constructed by Two Codewords . . 90

6.5 Synchronizing sequence of RVLC . . . . . . . . . . . . . . . . 91

7 Conclusion 94

Acknowledgments 96

References 97

Appendix 101

List of Publications Related to this dissertation 105

ii

Chapter 1

Introduction

1.1 Background

Users of broadband internet remarkably increased in resent years. As shown

in Figures 1.1 and 1.2 now, more than half of the internet users are broadband

users in Japan. Also, since the maximal transfer speed reaches 100Mbps for

broadband users, it is possible for broadband users to enjoy video programs

through online transmission1. In this dissertation, we consider a server stor-

ing lots of video data, responses to transmission requests from clients through

the network.

In order to increase the efficiency of the network transmission, the video

data should be compressed. The MPEG and H.26x are common compression

format for video data.

MPEG[2], which stands for Moving Picture Coding Experts Group, is

a working group of ISO/IEC in charge of the development of international

standards for compression, decompression, processing, and coded represen-

tation of moving pictures, audio and their combination. So far MPEG has

produced:

• MPEG-1 [3], the standard for storage and retrieval of moving pictures

1up to March 2007

1

0

10000

20000

30000

40000

50000

60000

70000

80000

2006 2005 2004 2003

User

s(th

ousa

nd p

eopl

e)

Year

56,45362,844

70,07273,619

15,96222,145

32,24437,568

Internet usersBroadband users

0

10

20

30

40

50

60

2006 2005 2004 2003

Perc

enta

ge(%

)

Year

28.27

35.24

46.02

51.03

Broadband user percentage

Figure 1.1: Number of inter-net users and broadband users inJapan according to [1].

Figure 1.2: Percentage of numberof broadband users

and audio on storage media (approved Nov. 1992)

• MPEG-2 [4], the standard for digital television (approved Nov. 1994)

• MPEG-4 [5], the standard for multimedia applications

– version 1 was approved Oct. 1998,

– version 2 was approved Dec. 1999.

SourceSourcebit rate

Compressedbit rate

Compressionratio

MPEG1 VHS 30Mbps 1.5Mbps 20MPEG2 Television 100Mbps 4Mbps 25

HDTV 1.2Gbps 30Mbps 40

Table 1.1: Compression ratio of MPEG1 and MPEG2

In [6], there is an example of compression ratio for MPEG1 and MPEG2

shown in Table 1.1. From Table 1.1, we can know that MPEG1 got a com-

pression ratio of 20, MPEG2 got a compression ratio of at most 40. Also, the

2

applications based on the MPEG4 standard applied by Microsoft2, DivX3

and XviD4 achieved higher compression ratio than MPEG2.

The ITU-T(International Telecommunication Union Telecommunication

Standardization Sector) has designed so far another video compression for-

mats called H.26x as follows:

1. H.261. A video coding standard originally designed for transmission

over ISDN lines on which data rates are multiples of 64 kbit/s(approved

Dec. 1990).

2. H.262. It is identical in content to the video part of the ISO/IEC

MPEG-2 standard. This standard was developed in a joint partnership

between the ITU-T and ISO/IEC JTC 1 organizations, and thus it

became published as a standard of both organizations(approved Nov.

1994).

3. H.263. A video codec designed as a low-bitrate compressed encoding

solution for videoconferencing (approved Dec. 1990).

4. H.264. A digital video codec standard which is noted for achieving very

high data compression. It was written by the ITU-T Video Coding

Experts Group (VCEG) together with the ISO/IEC Moving Picture

Experts Group (MPEG) as the product of a collective partnership effort

known as the Joint Video Team (JVT). So it is also known as MPEG-

4/AVC(Advanced Video Coding).

The MPEG and H.26x support both VBR(Variable Bit Rate) and CBR(Constant

Bit Rate) compression mode. Here, CBR means the bit rate is constant for

a video data and VBR means the contrary. The CBR video is suitable for

2http://www.microsoft.com/3http://www.divx.com/4http://www.xvid.org/

3

network transmission because of its contant bit rate. But comparing with

VBR video, the CBR video contains much more redundancy because it ig-

nores the compression between video frames which will introduced below.

In other words, the CBR video comprises duplicate data for similar frames.

So in this dissertation, we consider only the video data compressed by VBR

mode.

Note that almost all the video transmission systems used on internet are

now based on video data compressed by CBR mode. The other systems

use small video data to avoid the buffer underflow of the client. Figure 1.3

shows the network transmission rate of one the clients of YouTube5 where

the playing time of the video stream is about two minutes.

Figure 1.3: Network transmission rate for one the clients of YouTube

From Figure 1.3, we can see that the server transmits the entire video

data into the client buffer at the beginning of the playback and after that

5http://www.youtube.com/

4

the client just play the video data in the buffer. Thus, under this kind of

system, the small sizes of the video data cause degradation of the video data’s

quality and the server’s network transmission rate could be bursty large when

many clients apply for transmission at the same time. In this dissertation, we

focus on how to reduce the server’s bursty peak rate of network transmission

which will be discussed later.

The MPEG and H.26x use three technologies to achieve a high compres-

sion ratio,

1. Compression inside a frame.

The MPEG and H.26x use a DCT(Discrete Cosine Transform) [7] tech-

nology to improve compression which is also used in image compression,

such as JPEG. The details of the DCT is omitted in this dissertation.

2. Compression between frames.

The MPEG and H.26x use a motion compensation technique to im-

prove compression. Motion compensation describes a frame in terms

of where each section of that frame came from, in a previous frame. A

video sequence consists of a number of frames and subsequent frames

are very similar, thus, containing a lot of redundancy. Removing this

redundancy helps achieve the goal of better compression ratios. The

frames of video data are partitioned in blocks of pixels. Each block is

predicted from a block of equal size in the reference frame. The blocks

are not transformed in any way apart from being shifted to the position

of the predicted block. This shift is represented by a motion vector as

shown in Figure 1.4.

3. Entropy encoding.

The MPEG and H.26x use variable length codes to encode the results

of DCT and motion vectors based on their statistical distribution to

5

reference frame

current frame

motion vector

Figure 1.4: An example of motion vector

reduce the average length of them.

The use of variable length codes to encode video data is a challenge theme

for the video transmission. Here, we consider two issues: rate variability and

synchronization.

In the first issue, the use of variable length codes in combination with

motion compensation technique causes significant rate variability of video

data as shown in Figure 1.5. Thus, consider a server that transmits video

data to client through a network. In order to deliver the video data losslessly

to the client, the network has to reserve its capacity, which size is at least

equal to the largest frame size of the video data. Hence, the network resource

is not efficiently utilized.

To reduce the rate variability of VBR video stream, we can apply a

smoothing technique, which sends data according to the schedule that is

6

0x100

5x103

10x103

15x103

20x103

25x103

30x103

35x103

40x103

0 500 1000 1500 2000

Size

(Byt

es)

Frames No.

Frame size of MPEG4

Figure 1.5: Frame size of an MPEG4 video data for about 90 seconds

produced based on the playback time and the client machine. This kind of

techniques for smoothing that generate the transmission schedule before the

video transmission starts, are studied in [8, 9, 10, 11, 12, 13]. Especially,

an optimal smoothing algorithm to alleviate the rate variability as small as

possible has been proposed by Salehi et al. [9]. Here the optimality means

to minimize the peak and variance of transmission rate under the condition

that there is neither buffer overflow nor underflow at the client buffer.

However, Salehi’s algorithm [9] can obtain the optimal result only for

transmission of one video stream. Consider a transimission system that the

server transmits two or more video streams to different clients at the same

time, as shown in Figure 1.6. One basic technique for reducing the rate

variability of multiple video streams is just to aggregate the video streams

without smoothing. The frame sizes of aggregation of 2, 8, 32, 128 MPEG4

video streams are given in Figure 1.7. As it shown in Figure 1.7, the frame

sizes of aggregated video streams are still variable.

7

Server

Router

Client2

Client3

Router Client4Client5

Network

Client1

Figure 1.6: An example of a trasmission system that the server transmits 5video streams to different clients at the same time

0

2

4

6

8

10

0 20 40 60 80 100 120 140

Fram

e Si

ze(x

104 By

tes)

Frame No.(x103)

2 videos

(a) 2 video streams

0

5

10

15

20

0 20 40 60 80 100 120 140

Fram

e Si

ze(x

104 By

tes)

Frame No.(x103)

8 videos

(b) 8 video streams

10

15

20

25

30

35

40

0 20 40 60 80 100 120 140

Fram

e Si

ze(x

104 By

tes)

Frame No.(x103)

32 videos

(c) 32 video streams

50

60

70

80

90

100

110

0 20 40 60 80 100 120 140

Fram

e Si

ze(x

104 By

tes)

Frame No.(x103)

128 videos

(d) 128 video streams

Figure 1.7: Aggregation of 2, 8, 32, 128 MPEG4 video streams

8

Also, the variance of frame sizes of aggregation of 2,4,8,16,32,64,128 video

streams are shown in Figure 1.8.

0

50

100

150

200

250

300

0 20 40 60 80 100 120

Varia

nce*

n(x1

07 )

n (number of video streams)

Variance

Figure 1.8: Variance of frame sizes of aggregation of n video streams

As shown in Figure 1.8, the variance of frame sizes grows as the number

of video streams increases.

Moreover, Salehi’s algorithm calculates optimal smoothed rate for each

client individually. But from the view of the sever, as shown in Figure 1.6,

we observed that the transmission rate of the server side is much higher

comparing with that of any client. So Salehi’s algorithm is not sufficient

for transmission of multiple video streams. Thus, a smoothing algorithm

for trasmission of more video streams is still needed to reduce the peak of

transmission rate of the server side.

The second issue is synchronization. Usually, the variable length codes

obtained from entropy encoding require synchronization between the server

and the client. Once an error occurs in transmitting a stream as well as

a client mis-functioning, it may cause a loss of synchronization and conse-

9

quently make it impossible to decode the subsequent data as shown in Figure

1.9. For transmission of the MPEGs, since the MPEGs use motion vector

to improve compression ratio, a transmission error on the reference frame,

shown in Figure 1.4, influences the subsequent frames. Thus, even a small

transmission error effects the realtime playback of the client greatly.

������������������������������������������

������������������������������������������

Error Buffer

data can be decoded data cannot be decoded

forward decoding

Figure 1.9: Decoding process for code without re sync

In order to solve this problem, the MPEG4 standard innovates RVLC

(Reversible Variable Length Code) and resynchronization marker (denote by

re sync in this dissertation) for error resilience. An RVLC is a code such that

no codeword is a prefix or a suffix of any other codeword, which is able to be

decoded both forward and backward. A re sync, denoted by σ, is a string

in a sequence of codewords that whenever σ is received (without errors),

the decoder must automatically resynchronize regardless of the preceding

synchronization slippage. Figure 1.9, Figure 1.10 and Figure 1.11 shows how

they works in decoding process. As shown in Figure 1.11, an RVLC with

re sync drastically improves the error correctability because of slippage.

Although XviD and MSMPEG4v3 which are applications of MPEG4 pro-

vided by XviD and Microsoft, respectively, do not support error resilience6,

the error resilience functions as bidirectional coding in DivX which is another

implementation of MPEG4. See Figure 1.12 where the option panel of DivX

is illustrated.

Unfortunately, the details of the error resilience of DivX is unknown.

According to MPEG4’s standard [5], the re sync is defined as a binary string6up to March 2007

10

������������������������������������������

������������������������������������������

������������������������������������

������������������������������������

Error Buffer

data can be decoded

Re_sync

data cannot be decoded

forward decoding forward decoding

data can be decoded

Figure 1.10: Decoding process for non-RVLC with re sync

�����������������������������������

�����������������������������������

���������������������������

���������������������������

Error BufferRe_syncforward decoding forward decodingbackward decoding

data cannot be decoded data can be decodeddata can be decoded

Figure 1.11: Decoding process for RVLC with re sync

of at least 16 zero’s followed by a one likes ’0 0000 0000 0000 0001’ which

shall only be located immediately before a macroblock and aligned with a

byte. Table B.23 in part2 of [5] defines re sync for RVLC of Tcoef7, which

is used inside a macroblock as shown in Figure 1.13.

The re sync shown in Figure 1.13 contains the data of uncoded source

with length of 30 bits. Comparing with the maximal code length 16 of the

RVLC of Tcoef [5], it is too redundant.

In order to reduce the redundancy of the re sync, a technique for finding

shorter re sync is needed. Also, the synchronous codes can be used to

reduce the redundancy. A synchronous code possesses at least one re sync

as codeword. Synchronous codes contain less redundancy since the re sync

itself is also a codeword. In the literature [18, 19, 20, 21, 22], there are a lot of

researches on synchronous codes. However they have been mainly concerned

with only synchronous prefix-free codes.

In this dissertation, we are interested in making an RVLC synchronous.

Some codewords of a given RVLC will be replaced by other codewords using

7Tcoef stands for Transform Coefficient, it is usd in DCT of MPEG

11

Figure 1.12: The bidirectional coding option of DivX 6.4

a deterministic procedure to attain error resilience for MPEG4 with less re-

dundancy. So, from now on, we specify MPEG4 for our transmission system.

12

ESCAPE LAST RUN marker bit LEVEL marker bit ESCAPE

1 1 0000s00001 (1 bit) (6 bits) (11 bits)s = 0 when LEVEL is positive and s = 1 when LEVEL is negative

LAST : “0”: there are more nonzero coefficients in this block: “1”: this is the last nonzero coefficient in this block

RUN : the number of successive zeros preceding the coded coefficientLEVEL : the non-zero value of the coded coefficient

Figure 1.13: Re sync for RVLC of Tcoef in part2 of [5]

1.2 Objectives of this dissertation

In this dissertation, we are concerned with an transmission system of multiple

MPEG4 video streams with error resilience from one server to many clients.

Our goal is two-fold:

1. To make the total output stream of the server as smooth as possible;

and

2. To embed the functions of error resilience for MPEG4 with less redun-

dancy.

1.2.1 Smoothing of multiple video streams

In general, there are two approaches to smooth out multiple video streams.

1) Aggregation after Smoothing (AaS): The server first smooths out each

of video streams individually and then aggregate all the smoothed video

streams. Usually, most algorithms besides Salehi’s algorithm [9] use

AaS scheme for smoothing of transmission rate.

2) Smoothing after Aggregation (SaA): The server first aggregates (or

statistically multiplexes) all the video streams into one stream, then

smoothes it to obtain the entire transmission schedule.

13

Figure 1.14 shows the smoothing results for aggregation of 128 video streams

both by AaS scheme and SaA scheme, where the original frame sizes are

given in Figure 1.7(d).

50

60

70

80

90

100

110

0 20 40 60 80 100 120 140

Fram

e Si

ze(x

104 By

tes)

Frame No.(x103)

AaS scheme for B=2048KB

(a) AaS Scheme

50

60

70

80

90

100

110

0 20 40 60 80 100 120 140Fr

ame

Size

(x10

4 Byte

s)

Frame No.(x103)

SaA scheme for B=2048KB

(b) SaA Scheme

Figure 1.14: Smoothing results for aggregation of 128 video streams

From Figure 1.14, we can know that SaA scheme achieves better perfor-

mance than AaS scheme on the view of minimal peak and variance. This is

because of the optimality of optimal smoothing proposed by Salehi et al[9].

Moreover, comparing with the AaS scheme the SaA scheme lightens signifi-

cantly the computational burden for the server since the aggregate stream is

smoothed only once. Of course, given the smoothed result for the aggrega-

tion of multiple streams, it is not always possible to split it into results for

each video streams that ensures no overflow and underflow of client buffer.

In this dissertation, we will obtain a sufficient and necessary conditions when

the splitting is possible for aggregation of two streams. By using these con-

ditions, we propose an online algorithm for splitting the smoothed result for

the aggregation of two video streams into two results for each video stream.

Moreover, this algorithm can be extended to multiple video streams by using

a binary tree structure.

Computer simulations for transmission of a set of 128 MPEG compressed

video streams show that the SaA scheme alleviates the variability of the

14

aggregate video transmission comparing with the AaS scheme using the tra-

ditional online smoothing algorithm. Besides, as for the total processing

time, the SaA scheme is faster than the AaS scheme.

1.2.2 Adding the functions of error resilience to MPEG4with less redundancy.

As we stated in Section 1.1, usage of synchronous RVLC could obtain less re-

dundancy for error resilience of MPEG4. First, we give a definition of being a

re sync in an RVLC that the re sync does not appear in any other combani-

tions of codewords. we present a method for constructing an RVLC in which

some codewords function as re syncs based on our definitions. Note that

these codewords also convey source information in a usual sense. The main

idea is to replace some codewords of a given RVLC with minimum forbidden

words (MFWs) of a sequence of codewords in which every combination of t

consecutive codewords appears where usually t = 3 in practical applications.

Our experiment results on VLC of Tcoef for MPEG4 [5](part2) show

that re sync appears with probability of no less than 0.03003. Also, the

redundacy of our experiment results is approximately 0.66 bits per word which

is smaller than 30 × 0.03003 = 0.9009 of the current MPEG4 RVLC.

Finally, the synchronous RVLC results of our experiment can be imple-

mented by replacing of VLC of RVLC for an MPEG4 encoder.

1.3 Structure of this dissertation

This dissertation consists of six chapters and the overview of each chapter is

described below.

Chapters 2 and 3 focus on smoothing algorithm of video transmission.

The basic definitions and smoothing algorithms for transmission of one video

stream are introduced in Chapter 2. Section 2.1 introduces the optimal

15

smoothing algorithm proposed by Salehi et al.. Section 2.2 introduces an

online smoothing algorithm proposed by Rexford et al. [14] and Section 2.3

shows simulation results of offline and online smoothing algorithm and dis-

cusses how parameters of the smoothing algorithm affect smoothing results.

Chapter 3 discusses smoothing algorithm for transmission of multiple video

streams. We focus on the SaA scheme since AaS scheme achieves smoother

transmission of the aggregate stream, as we stated in Section 1.2. In Sec-

tion 3.1, we discuss the aggregate transmission system with two clients and

a rate splitting algorithm is given in Section 3.2. The aggregate transmission

system with more than two clients will be discussed in Section 3.3. Finally,

Section 3.4 gives some simulation results of proposed AaS scheme and makes

a comparison with SaA scheme.

Chapters 4, 5 and 6 focus on error resilience for MPEG4 video data.

Chapters 4 and 5 introduce knowledge concerning synchronous RVLC and

MFW(Minimal Forbidden Word), respectively. Section 4.1 gives some defini-

tions and notations of RVLC and introduces the LV algorithm for construc-

tion of RVLC proposed by Lakovic and Villasenor [24]. Synchronous codes

will be discussed in Section 4.2 and the definition of synchronous RVLC will

be given. The definition of MFW will be given in Section 5.1 and Section

5.2 will introduce an algorithm for construction of s[3], a string contains ev-

ery 3 combinations of number 1, . . . ,m with minimal length, which will be

used for construction of synchronous RVLC. We show our results for error

resilience for MPEG4 in Chapter 6. Section 6.1 introduces an algorithm for

construction of synchronous RVLC. By using proposed algorithm, we ob-

tained a synchronous RVLC for MPEG4 video data, it will be introduced

in Section 6.2. Also, discussion of probability on re sync appears in Buffer

of size θ bits will be introduced in Section 6.3. The re syncs constructed

by two codewords will be discussed in Section 6.4. In Section 6.5, we wil

consider synchronizing sequence (SS) which consists of two non re syncs.

16

Finally, Chapter 7 summaries our results and concludes this dissertation.

17

Chapter 2

Optimal Smoothing

In this chapter, we consider a simple transmission system shown in Figure

2.1. A server transfers pre-recorded video data immediately to the network,

and the client receives the data from the network into a buffer. The data in

the client buffer is played in real time.

Network BufferServer Play

Client

Figure 2.1: A simple transmission system

We will introduce the optimal smoothing algorithm proposed by Salehi et

al. [9] in Section 2.1. An online smoothing algorithm proposed by Rexford

et al. [14] will be introduced in Section 2.2. The simulation results of these

algorithms will be given in Section 2.3.

2.1 Optimal Smoothing Algorithm

2.1.1 Notations and definitions

First, we give same basic notations concerning to optimal smoothing algo-

rithm proposed by Salehi et al.. First, we consider a discrete-time model at

18

the frame level of the video. That is t ∈ {1, . . . , N}, where N is the length of

the video in frame. A finer-granularity time discretization can be considered

without loss of generality. Table 2.1 summarizes the relevant notation.

b : Client buffer capacity for storing unplayed frames.d(t) : Amount of data consumed by the client at time t (size of the tth frame).

Data is consumed from the buffer after any arrivals at t.

D(t) : Cumulative data consumed by the client over [1, t]:∑t

i=1 d(i).a(t) : Amount of data sent by the server at time t.

A(t) : Cumulative data sent by the server over [1, t]:∑t

i=1 a(i)B(t) : Maximum cumulative data that can be received by the client over [1, t],

without buffer overflow:B(t) = min{D(t − 1) + b,D(N)} for t = 2, . . . , N , B(1) = b, B(0) = 0.

Table 2.1: Notations

We define the N -dimensional real vector S = {a(1), . . . , a(N)} as a server

transmission schedule in discrete time and vector S ′ = {A(1), . . . , A(N)} as

a server transmission schedule in continuous time. S ′ can be calculated from

S according to the definition of A(t) in Table 2.1.

Definition 1. A transmission schedule S is said to be feasible if

1.N∑

t=1

a(t) = D(N)

2. D(t) ≤ A(t) ≤ B(t) for all t ∈ [1, N ].

Note the second constraint ensures that the client buffer neither under-

flows nor overflows during stream playback. Figure 2.2 shows feasible and

infeasible transmission schedules in continuous time.

Define expect of a transmission schedule S by E(S) =N∑

t=1

a(t)/N , the

variance of S is given by V(S) =N∑

t=1

(a(t)−E(S)

)2/N . Also, define max(S) =

max1≤t≤N

a(t) as peak rate of S.

19

Figure 2.2: Feasible and infeasible transmission schedules, in continuous time

Let S denote the set of all feasible server transmission schedules. The

task of optimal smoothing algorithm is to find the feasible schedule S∗ which

is as smooth as possible, where smooth here means minimum variance and

peak rate.

2.1.2 Optimal smoothing algorithm

Define cmax as the maximum rate at which the server may transmit over a

given interval [a, b], without overflowing the client buffer, starting from initial

buffer level q:

cmax = mina+1≤t≤b

B(t) − (D(a) + q)

t − a

20

and define tB as the latest time t at which the client buffer is full when the

server transmits at cmax over [a, b], starting with initial buffer level q:

tB = maxa+1≤t≤b

{t :

B(t) − (D(a) + q)

t − a= cmax

}.

Similarly, define cmin as the minimum rate at which the server may transmit

over a given interval [a, b], starting with initial buffer level q:

cmin = mina+1≤t≤b

D(t) − (D(a) + q)

t − a

and define tD as the lastest time t at which the client buffer is empty when

the server transmits at cmin over [a, b], starting with initial buffer level q:

tD = maxa+1≤t≤b

{t :

D(t) − (D(a) + q)

t − a= cmin

}.

Optimal Algorithm A

Input: d(t) for t ∈ [1, N ], b.

Output: a∗(t) for t ∈ [1, N ].

Step 1. Calculate D(t), B(t) for t ∈ [1, N ] based on d(t).

Step 2. As the initial value, set ts = 0, te = 1, q = 0, cmax = b, tB = 1,

cmin = d(1), tD = 1.

Step 3. t′e = te + 1.

Step 4. If cmax < D(t′e)−(D(ts)+qt′e−ts

, then end segment at tB:

a∗(t) = cmax for t ∈ (ts, tB].

Start new segment at tB: ts = tB, te = tB + 1, q = B(tB) − D(tB).

If ts = N , then goto Step 7, else goto Step 3.

Step 5. If cmin > B(t′e)−(D(ts)+q)t′e−ts

or t′e = N , then end segment at tD:

a∗(t) = cmin for t ∈ (ts, tD].

Start new segment at tD: ts = tD, te = tD + 1, q = B(tD) − D(tD).

If ts = N , then goto Step 7, else goto Step 3.

21

Step 6. Set te = t′e, Compute cmax, tB, cmin and tD over [ts, te].

Goto Step 3.

Step 7. Stop. ¤

The algorithm given above operates as follows. Each iteration begin with

a feasible CBR segment over [ts, te], and its corresponding values of cmax, tB,

cmin and tD. Let q denote the client buffer level at ts. A considers whether the

CBR segment can be extended by one time unit, by setting t′e to te + 1(Step

3) and testing the feasibility of the extension:

• Case 1(Step 4): If cmax is too small to avoid buffer underflow at t′e, the

CBR segment must be ended before t′e, and a new one established at

a higher rate. The segment is ended at tB and is assigned the highest

feasible rate, cmax (see Figure 2.3 (a)). In this manner, the rate increase

for the next segment(beginning at tB) will be as small as possible.

• Case 2(Step 5): Otherwise, if cmin would result in buffer overflow at t′e,

the CBR segment must be ended before t′e, and a new one established

at a lower rate. The segment is ended at tD and is assigned the smallest

feasible rate, cmin (see Figure 2.3 (b)). In this manner, the rate decrease

for the next segment(beginning at tD) will be as small as possible.

Otherwise, there exists a feasible CBR segment over [ts, te+1], so te is updated

and new values of cmax, tB, cmin and tD are computed (Step 6). The process

continues until the entire video is segmented.

Thus S∗ consists of some number of CBR transmission segments, each

ending with a change in transmission rate. w is said to be a change point

of S∗ = {a∗(1), . . . , a∗(N)} if a∗(w) 6= a∗(w + 1), w ∈ [1, . . . , N − 1]. A

change point w is said to be convex when a∗(w) < a∗(w + 1), and concave

when a∗(w) > a∗(w + 1). Also, the client buffer is full at the convex change

points of S∗, and empty at the concave change points of S∗. These properties

22

will be useful for smoothing algorithm for multiple video streams in the next

chapter. Aslo, we define 0 and N as concave change points. All the CBR

transmission segments of S∗ start and end with a change point. From now,

we simply call a CBR transmission segment of S∗ a segment.

(a) (b)

Figure 2.3: Operation of A

At last, it should be noted that the computation complexity of the optimal

smoothing algorithm is O(N2) since the algorithm computes cmax, tB, cmin

and tD over [ts, te](Step 6) every time as te increases.

2.1.3 Jitter

In this subsection, we discuss how optimal smoothing algorithm accommo-

date with jitter. Jitter is defined as irregular delay variation of received

packets. At the sending side, packets are sent in a continuous stream with

the packets spaced evenly apart. Due to network congestion, improper queu-

ing, or configuration errors, this steady stream can become lumpy, or the

delay between each packet can vary instead of remaining constant.

Let ω be the maximum of the jitter, in time units of frames. In un-

smoothed case, the client playback is delayed by ω, and the server simply

follows the unsmoothed transmission schedule. Under optimal smoothing,

we shift B(t) by ω units to the right, and then perform smoothing between

23

shifted B and unshifted D. That is, set

N ′ = N + ω

and set

d(t) = d(N) for t ∈ [N + 1, N ′],

d′(t) =

{0 for t ∈ [1, ω]

d(t − ω) for t ∈ [ω + 1, N ′].

Define D(t) and B(t) as

D(t) =t∑

i=1

d(i) for t ∈ [1, N ′]

B(t) = max

{t∑

i=1

d(i) + b,D(N ′)

}for t ∈ [1, N ′].

And apply optimal smoothing algorithm A on D(t) and B(t).

2.1.4 Optimality of the smoothing algorithm

Salehi et al. use the theory of majorization in [17] to prove the optimality of

the result of optimal smoothing algorithm. The basic definitions are given

in Definition 2 and Definition 3.

Definition 2. Given two n-dimensional real vectors X = {x1, . . . , xn} and

Y = {y1, . . . , yn}, let x[1], . . . , x[n] and y[1], . . . , y[n] denote the non-increasing

orderings (i.e., arrangement of vector elements from largest to smallest) of

X and Y , respectively.

X ≺ Y if

k∑

i=1

x[i] ≤k∑

i=1

y[i] k = 1, . . . , n − 1,

n∑i=1

x[i] =n∑

i=1

y[i].

When X ≺ Y , X is said to be majorized by Y (Y majorizes X).

24

Definition 3. A real-valued function φ defined on a set A ⊂ Rn is said to

be Schur-convex on A if

X ≺ Y on A ⇒ φ(X) ≤ φ(Y ).

The basic idea of Salehi et al.’s proof is to prove that S∗ ≺ S holds for any

feasible transmission schedule S. Moreover, by proving that function max(S)

and V(S) are Schur-convex, the transmission schedule S∗ is optimal with

minimized max(S) and V(S) then any other feasible transmission schedules.

Refer to [9] and [17] for the details of the proof.

2.2 Online smoothing algorithm

In section 2.1 we introduced an optimal smoothing algorithm A. As input of

A, the frame size d(t) for the entire stored video and client buffer capacity

b are necessary. In another word, A could not deal with live video with

unknown frame size. So it is called an offline smoothing algorithm.

Rexford et al. proposed an online smoothing algorithm based on op-

timal smoothing algorithm in [14]. The basic idea of the online smoothing

algorithm is to apply optimal smoothing algorithm to small segments of the

video stream as the frames server generated. We call here the small segments

of the video stream smoothing windows and the size of the smoothing window

window size. Window size of W frames introduces a playback delay of W

time units at the client; in addition, the server must include sufficient buffer

space to store up to W frames of the video stream feed.

As shown in Figure 2.4, the algorithm computes the transmission sched-

ule, by using offline optimal smoothing algorithm, every α time units over

the next W frames, where α ≤ W . α here is called slide length. At time t

the algorithm smooths a video segment from frame position p to p + W . At

25

Figure 2.4: Online smoothing algorithm

time t + α, when α additional video frames are generated for transmission,

the algorithm starts to smooth frame positions starting from (p + α + 1) to

(p + α + W + 1).

Comparing with offline smoothing algorithm, the result of online smooth-

ing algorithm depends on smoothing window size W and slide length α. The

larger the window size W or the smaller the slide length α is, the result

could be smoother and it costs more calculation time, which will be shown

in section 2.3 in our simulation results.

Finally, since online smoothing algorithm calculate the transmission sched-

ule in real time, the transmission schedule of each α frames must be calculated

in time of α frames. This is very important especially when calculating of

transmission schedule of multiple streams which will introduced in Chapter

3.

2.3 Simulation results

In this section, we will show simulation results of both offline and online

smoothing algorithm for MPEG4 video, and discuss how input parameters

affect results of the algorithms. Some of the simulation results are also given

in [9] and [14] for MPEG1 video.

26

0

10

20

30

40

50

60

0 20 40 60 80 100 120 140 160 180 200

Size

(x10

3 Byte

s)

Frames No.(x103)

Original Frame Size

Figure 2.5: Frame size of the MPEG4 video data

Here, we use an MPEG4 video data of 195947 frames(about 2 hours) with

peak rate 56799 Bytes and variance 1.71 × 107. The original frame size is

shown in Figure 2.5, where the horizontal axis corresponds to frame number.

The transmission schedule of applying the offline optimal smooth algo-

rithm to the video data with client buffer size of 128 KBytes and jitter of

0 frame is shown in Figure 2.6 with peak rate 30892.75 Bytes and variance

9.61 × 106, where the horizontal axis corresponds to frame number. This

result is similar to Salehi et al.’s result of MPEG1 video data.

Also, we examined the relationship between the client buffer size B and

the optimal smoothing results in Figure 2.7 where Salehi et al. didn’t discuss

this relationship in [9]. For client buffer size from 128 KBytes to 1280 KBytes,

2.7(a) shows the peak(Bytes) of the offline smoothing results and 2.7(b) shows

the variance. From 2.7, we can know that the optimal smoothing algorithm

reduced the peak and variance almost to half of the original video data. Also,

27

0

10

20

30

40

50

60

0 20 40 60 80 100 120 140 160 180 200

Size

(x10

3 Byte

s)

Frames No.(x103)

B=128K, Jitter=0

Figure 2.6: Simulation results of offline optimal smooth algorithm, with B =128KBytes and jitter=0

0

10

20

30

40

50

60

0 200 400 600 800 1000 1200

Peak

(x10

3 Byte

s)

Buffer Size(KBytes)

Jitter=0No smoothing

(a) Peak

0

5

10

15

20

0 200 400 600 800 1000 1200

Varia

nce(

x106 )

Buffer Size(KBytes)

Jitter=0No smoothing

(b) Variance

Figure 2.7: Simulation results of offline optimal smooth algorithm, with B =128KBytes and jitter=0

we examined that the more client buffer size is, the smoother the offline

smoothing results will be. This is because with more client buffer size, the

distance between B(t) and D(t) will be larger, thus there contains more

28

feasible transmission schedules between them.

We also did the same experiments for jitter of 5, 10 and 15 frames. But

their results are almost same as ones for jitter of 0 frame. So from now on,

we will ignore the parameter jitter and its default value is 0 frame.

Also, the transmission schedule of applying the online optimal smooth

algorithm to the video data with client buffer size B of 128 KBytes, jitter

of 0 frame, window size W of 30 frames, slide length α of 5 frames is shown

in Figure 2.8 with peak 31498.24 Bytes and variance 1.08 × 107, where the

horizontal axis corresponds to frame number. This result is similar to Rexford

et al.’s result for MPEG1 video data.

0

10

20

30

40

50

60

0 20 40 60 80 100 120 140 160 180 200

Size

(x10

3 Byte

s)

Frames No.(x103)

B=128KB, Jitter=0, W=30, Alpha=5

Figure 2.8: Simulation results of online optimal smooth algorithm, with B =128KBytes, jitter=0, W=30, α=5

Also, we examined the relationship between window size W , slide length

α and online smoothing results in Figure 2.9 and Figure 2.10 where Rexford

et al. discussed only the results of fixed ratio between slide length α and

29

window size W in [14]. For slide length α from 1 to 30 frames, Figure 2.9

shows the results of online smoothing algorithm with buffer size B of 128

KBytes, jitter of 0 frame, window size W of 30 frames. Figure 2.10 shows

the results with buffer size B of 128KBytes, jitter of 0 frame, slide length α

of 5 frames for window size W from 10 to 150 frames.

31

33

35

37

39

41

0 5 10 15 20 25 30

Peak

(x10

3 Byte

s)

Alpha(frames)

B=128KB, Jitter=0, W=30offline smoothing

(a) Peak

0

5

10

15

20

0 5 10 15 20 25 30

Varia

nce(

x106 )

Alpha(frames)

B=128KB, Jitter=0, W=30offline smoothing

(b) Variance

Figure 2.9: Simulation results of online optimal smooth algorithm, with B =128KBytes, jitter=0, W = 30

3.05

3.10

3.15

3.20

3.25

3.30

3.35

20 40 60 80 100 120 140

Peak

(x10

4 Byte

s)

Window size(frames)

B=128KB, Jitter=0, Alpha=5offline smoothing

(a) Peak

0

5

10

15

20

20 40 60 80 100 120 140

Varia

nce(

x106 )

window size(frames)

B=128KB, Jitter=0, Alpha=5offline smoothing

(b) Variance

Figure 2.10: Simulation results of online optimal smooth algorithm, withB = 128KBytes, jitter=0, α = 5

From Figure 2.9 and Figure 2.10, we can know that the more window

size W or the less slide length α is, the smoother the results of the online

smoothing algorithm will be. also, comparing with window size w, slide

30

length α affects the results of the online smoothing slightly when α ≤ 15

frames. Occasion of α > 15 frames can be ignored because of its remarkably

aggravation of the peak rate of the smoothing results.

Also, the relationship with the window size W , slide length α and online

smoothing algorithm calculation time, under the experimental environment

shown in Table 2.2, is shown in Figure 2.11. Rexford et al. didn’t discuss

about this either in [14], either. The horizontal axis of Figure 2.11 (a) corre-

sponds to slide length α and that of Figure 2.11 (a) corresponds to window

size W .

0.5

1

1.5

2

2.5

3

3.5

4

0 5 10 15 20 25 30

Calcu

latio

n tim

e(se

cond

s)

Alpha(frames)

B=128KB, Jitter=0, W=30

(a)

0

2

4

6

8

10

12

14

20 40 60 80 100 120 140

Calcu

latio

n tim

e(se

cond

s)

Window size(frames)

B=128KB, Jitter=0, Alpha=5

(b)

Figure 2.11: Calculation time of online optimal smooth algorithm, with B =128KBytes, jitter=0

CPU Intel Pentium 4 3.0GMemory 1GHard Disk 80GOS Linux 2.6.15-1.2054 FC5Compiler gcc 4.1.0 20060304

Table 2.2: Experimental environment for measuring the calculation time ofonline smoothing algorithm

From Figure 2.11 and results above, we can know that better performance

needs more calculation time in online smoothing algorithm. For only one

31

transmission stream, the calculation time could even be ignored because the

great power of computers today. But for a multiple transmission system with

more than 100 clients, the server should computes all transmission schedules

for clients in time. Thus calculation time should be considered as the most

important part of the system. In the next chapter, we will introduce a

smoothing algorithm for multiple transmission system and discuss about how

to reduce the calculation time while using online smoothing algorithm for

multiple transmission.

32

Chapter 3

Multiple Smoothing

In this chapter, we consider smoothing algorithm for multiple transmission of

video streams simultaneously from a server to many clients using a smoothing

technique based on the optimal smoothing algorithm introduced in Chapter

2. As we stated in Section 1.2, we assume the connection from the sever

to each client to be point-to-point. Our purpose is to make the total out-

put stream of the server smoother. In general, there are two approaches to

smooth out multiple video streams.

1) Aggregation after Smoothing (AaS): The server first smooths out each

of video streams individually and then aggregate all the smoothed video

streams.

2) Smoothing after Aggregation (SaA): The server first aggregates (or

statistically multiplexes) all the video streams into one stream, then

smoothes it to obtain the entire transmission schedule.

According to Figure 1.14, the SaA scheme can improve the peak band-

width at the server side than AaS scheme, Moreover, the SaA scheme light-

ens significantly the computational burden for the server since the aggregate

stream is smoothed only once. In this chapter, we will focus on the SaA

scheme and discuss how can we allocate the rate of the obtained schedule to

33

individual video for each client. In Section 3.1, we will discuss the aggregate

transmission system with two clients and a rate splitting algorithm is given in

Section 3.2. The aggregate transmission system with more than two clients

will be discussed in Section 3.3. At last, Section 3.4 gives some simulation

results of proposed AaS scheme and make a comparison with SaA scheme.

3.1 On splitting smoothed rate of aggregate

stream of two clients

In this section, we consider the aggregation of two transmission schedules

for a transmission system shown in Figure 3.1. System of transmission for

multiple video streams will be discussed in Section 3.3. As shown in Figure

3.1, a server is connected with two clients by a switching hub. The server

transmits different video streams to client1 and client2, respectively.

HUBServer

Client1

Client2

Figure 3.1: A transmission system with one server and two clients

we use the notations introduced in Chapter 2 that are indexed by 1 and 2

to to associate client1 and client2, respectively. The aggregate transmission

schedule of the server, indexed by s, is given by

As(t) = A1(t) + A2(t) (3.1)

34

for t ∈ [1, N ]. Note that if S1 and S2 are feasible, Ss is also feasible for

Ds(t) = D1(t) + D2(t), (3.2)

Bs(t) = B1(t) + B2(t). (3.3)

Given Ds(t) and Bs(t) of the server, we first apply the optimal smooth-

ing algorithm to get optimal transmission schedule S∗s , which is, of course,

feasible. However, it is not necessarily that S∗s can be separated into two

feasible schedules S1 and S2 for client1 and client2, respectively, such that

A∗s(t) = A1(t) + A2(t).

Also, based on the notations and definitions in section 2, here we add a

new definition for Sk(k = 1, 2).

Definition 4. A transmission schedule Sk(k = 1, 2) is said to be feasible

over interval [ts, te] if Sk satisfies

Ak(ts) ≤ Ak(ts + 1) ≤ · · · ≤ Ak(te)

Dk(t) ≤ Ak(t) ≤ Bk(t) for t ∈ [ts, te].

If ts = te, we will simply say Sk is feasible at ts.

Comparing with Definition 1, Definition 4 adds property of monotoni-

cally increase of A(t). It will be useful in our introduction of rate splitting

algorithm.

Fact 1. At each change point t0 of S∗s , Ak(t0) (k = 1, 2) can be calculated by

Ak(t0) =

{Bk(t0) if A∗

s(t0) = Bs(t0)

Dk(t0) if A∗s(t0) = Ds(t0)

(3.4)

so that Sk is feasible at t0.

Proof:

When

A∗s(t0) = Bs(t0),

35

We assume that there exists feasible S1 and S2 such that

A1(t0) 6= B1(t0),

A2(t0) 6= B2(t0).

Then since S1 is feasible at t0

A1(t0) < B1(t0),

Thus,

A2(t0) = As(t0) − A1(t0)

= Bs(t0) − A1(t0)

= B2(t0) + (B1(t0) − A1(t0))

> B2(t0).

That means S2 is not feasible at t0, a conflict. So,

A1(t0) = B1(t0)

and

A2(t0) = As(t0) − A1(t0)

= Bs(t0) − B1(t0)

= B2(t0).

In the same way, we can proof when

A∗s(t0) = Ds(t0),

we have

A1(t0) 6= D1(t0),

A2(t0) 6= D2(t0).

36

¤Hence, for each segment [ts, te] of Ss, we can calculate Ak(ts) and Ak(te)

(k = 1, 2) to ensure Sk (k = 1, 2) is feasible. All we have to do is to determine

the values of Ak(t) (t ∈ [ts+1, te−1], k = 1, 2) so that Sk (k = 1, 2) is feasible

on [ts, te].

We check segment by segment if there exists feasible schedules S1 and

S2 such that A∗s(t) = A1(t) + A2(t). If it is true, then we employ S∗

s as an

aggregate transmission schedule Ss and split it into two feasible transmission

schedules S1 and S2. Otherwise, we rejecting S∗s and then we calculate two

optimal schedules S∗1 and S∗

2 as S1 and S2, respectively.

Now, we give two definitions to describe our theorem.

Definition 5. For segment [ts, te] of a transmission schedule Ss, we define

P1(t) = max{D1(t), A1(ts), As(t) − B2(t)} (3.5)

Q1(t) = min{B1(t), A1(te), As(t) − D2(t)} (3.6)

for t ∈ [ts + 1, te − 1], and

P1(ts) = Q1(ts) = A1(ts) (3.7)

P1(te) = Q1(te) = A1(te). (3.8)

We also define P2(t) and Q2(t) in the same way.

It should be verified that P1(t) and Q1(t) are irrelevant to A1(t), t ∈

[ts + 1, te − 1].

From the symmetry between two schedules, we can say the same thing by

interchanging them. Hereafter, we do not give such a note to each symmetry

between S1 and S2 that appears in this chapter.

37

Definition 6. For segment [ts, te] of a transmission schedule Ss, we define

L1(t) =

{P1(ts) t = ts

max{P1(t), L1(t − 1)} t ∈ [ts + 1, te](3.9)

U1(t) =

{min{Q1(t), A1(t + 1)} t ∈ [ts, te − 1]

Q1(te) t = te.(3.10)

We also define L2(t) and U2(t) in the same way.

Note that L1(t) is irrelevant to A1(t), t ∈ [ts + 1, te].

Let us show the theorem that is used to guarantee an aggregate trans-

mission schedule Ss to be separated into two feasible schedules.

Theorem 1. A sufficient condition to separate Ss into two feasible trans-

mission schedules S1 and S2 on segment [ts, te] is:

Lk(t) ≤ Qk(t) for t ∈ [ts + 1, te − 1] and k = 1, 2. (3.11)

Proof : We can use mathematical induction to prove the theorem.

First, note that, for k = 1, 2, Sk is feasible at te and Lk(te) ≤ Ak(te)

because

Lk(te) = max{Pk(te), Lk(te − 1)}

≤ max{Ak(te), Qk(te − 1)}

≤ max{Ak(te), Ak(te)} = Ak(te).

Next, let us suppose that there exists some τ ∈ [ts + 1, te − 1] such that,

for k = 1, 2, Sk is feasible on [τ + 1, te] and

Lk(t) ≤ Ak(t) for t ∈ [τ + 1, te] (3.12)

as an assumption of the induction. Then, we will show that Sk is feasible on

[τ, te] and

Lk(t) ≤ Ak(t) for t ∈ [τ, te]. (3.13)

38

From (3.9), the definition of Lk(t), and (3.12), we have

Lk(τ) ≤ Lk(τ + 1) ≤ Ak(τ + 1).

Combining with (3.11), we obtain

Lk(τ) ≤ Uk(τ). (3.14)

Moreover, we can derive

L1(τ) + L2(τ) ≤ As(τ) ≤ U1(τ) + U2(τ), (3.15)

which is proven later.

Here, we choose A1(τ) and A2(τ) such that

L1(τ) ≤ A1(τ) ≤ U1(τ), (3.16)

L2(τ) ≤ A2(τ) ≤ U2(τ), (3.17)

As(τ) = A1(τ) + A2(τ). (3.18)

Then, we can derive

A1(τ) ≤ A1(τ + 1), (3.19)

L1(τ) ≤ A1(τ) ≤ B1(τ), (3.20)

which implies that S1 is feasible on [τ, te] and (3.13).

Finally, it is shown that S1 is feasible on [ts + 1, te]. Moreover, since

A1(ts) ≤ L1(ts + 1), our choice in A1(ts + 1) satisfies

A1(ts) ≤ A1(ts + 1).

Note that S1 is feasible at ts.

Now we turn back to the proof of of (3.15):

First, we show

L1(τ) + L2(τ) ≤ As(τ).

39

Note that L1(τ) can be expressed as

L1(τ) = max

{D1(τ), A1(ts), max

ts≤t≤τ{As(t) − B2(t)}

}.

Though we have nine possibilities for values of L1(τ) and L2(τ), the following

four cases cover all the possibilities.

Case 1 : When L1(τ) = D1(τ), we have

L1(τ) + L2(τ) ≤ D1(τ) + Q2(τ)

≤ D1(τ) + As(τ) − D1(τ)

= As(τ).

Case 2 : When Lk(τ) = Ak(ts) (k = 1, 2), we have

L1(τ) + L2(τ) = A1(ts) + A2(ts)

= As(ts) ≤ As(τ).

Case 3 : When L1(τ) = A1(ts) and L2(τ) = maxts≤t≤τ{As(t)−B1(t)}, we

obtain

L1(τ) + L2(τ) = A1(ts) + As(t∗) − B1(t

∗)

≤ As(t∗) ≤ As(τ),

where t∗ is an integer in [ts, τ ] such that L2(τ) = As(t∗) − B1(t

∗).

Case 4 : Assume that

L1(τ) = maxts≤t≤τ

{As(t) − B2(t)} and

L2(τ) = maxts≤t≤τ

{As(t) − B1(t)}.

Then, we can derive

L1(τ) + L2(τ) = As(t∗1) − B2(t

∗1) + As(t

∗2) − B1(t

∗2)

≤ As(t∗1) + As(t

∗2) − min{As(t

∗1), As(t

∗2)}

= max{As(t∗1), As(t

∗2)} ≤ As(τ),

40

where t∗1 and t∗2 be integers in [ts, τ ] such that L1(τ) = As(t∗1) − B2(t

∗1) and

L2(τ) = As(t∗2) − B1(t

∗2), respectively.

Next, we show

U1(τ) + U2(τ) ≥ As(τ).

Since A1(τ + 1) ≤ A1(te) from the assumption of induction, U1(τ) can be

expressed as

U1(τ) = min {B1(τ), A1(τ + 1), As(τ) − D2(τ)} .

Hence, we have nine possibilities for values of U1(τ) and U2(τ). However, the

following four cases are enough.

Case 1 : Assume that U1(τ) = B1(τ). If U2(τ) = A2(τ + 1), then we have

U2(τ) ≥ L2(τ + 1) ≥ L2(τ) from the assumption of induction. Otherwise,

from (3.10) and (3.11), we have U2(τ) = Q2(τ) ≥ L2(τ). In either event, we

obtain U2(τ) ≥ L2(τ). Hence, we have

U1(τ) + U2(τ) ≥ B1(τ) + L2(τ)

≥ B1(τ) + P2(τ)

≥ B1(τ) + As(τ) − B1(τ)

= As(τ).

Case 2 : When U1(τ) = A1(τ + 1) and U2(τ) = A2(τ + 1), we have

U1(τ) + U2(τ) = A1(τ + 1) + A2(τ + 1)

= As(τ + 1) ≥ As(τ).

Case 3 : Assume that U1(τ) = A1(τ + 1) and U2(τ) = As(τ) − D1(τ).

Using

D1(τ + 1) ≤ P1(τ + 1) ≤ L1(τ + 1) ≤ A1(τ + 1),

we obtain

U1(τ) + U2(τ) ≥ D1(τ + 1) + As(τ) − D1(τ)

≥ As(τ).

41

Case 4 : When U1(τ) = As(τ) − D2(τ) and U2(τ) = As(τ) − D1(τ), we

have

U1(τ) + U2(τ) = 2As(τ) − Ds(τ)

≥ As(τ).

In consequence, on segment [ts, te], we obtain feasible transmission sched-

ules S1 and S2 such that As(t) = A1(t) + A2(t) (t ∈ [ts, te]). ¤Theorem 1 does not state the necessity. We will show a necessary condi-

tion similar to the sufficient condition.

Theorem 2. If an aggregate transmission schedule Ss consists of two trans-

mission schedules S1 and S2 feasible on segment [ts, te], the following condi-

tion has to be satisfied:

Pk(t) ≤ Qk(t) for t ∈ [ts, te] and k = 1, 2. (3.21)

Proof : Since S1 is feasible at t ∈ [ts, te], we have

D1(t) ≤ A1(t) ≤ B1(t).

By adding A2(t) to each term of the above inequalities, we obtain

D1(t) + A2(t) ≤ As(t) ≤ B1(t) + A2(t),

which yields

As(t) − B1(t) ≤ A2(t) ≤ As(t) − D1(t).

From (3.5) and (3.6), we have

P2(t) ≤ A2(t) ≤ Q2(t). (3.22)

In the same way, we can get

P1(t) ≤ A1(t) ≤ Q1(t). (3.23)

¤Comparing (3.21) with (3.11), we should note that L1(t) is a monotoni-

cally increasing function based on P1(t).

42

3.2 Rate splitting algorithm

For SaA smoothing scheme, given the frame sizes d(t) and client buffersize B

for each client 1 and 2, we first calculate D1(t), D2(t), B1(t), B2(t). Then by

using (3.2) and (3.3), we can get Ds(t) and Bs(t). The optimal transmission

schedule S∗s can be calculated by applying the optimal smoothing algorithm

on them. In this section, we focus on a segment [ts, te] of S∗s . Based on

the sufficient condition of feasible rate splitting described in Section 3.1, we

propose an algorithm to split the optimal aggregate schedule S∗s into two

feasible schedules S1 and S2 on each segment [ts, te]. It should be noted that

S∗s is obtained by the offline optimal smoothing algorithm and it is optimal.

Nevertheless, the algorithm is easily applicable to the online one as well

since it runs for a given segment [ts, te] described below. Note that Ak(ts)

and Ak(te) for k = 1, 2 are already given in (3.4) since ts and te are change

points of S∗s .

Rate Splitting Algorithm

Input: D1(t), D2(t), B1(t), B2(t) and A∗s(t) for t ∈ [ts, te].

Output: A1(t) and A2(t) for t ∈ [ts + 1, te − 1].

Step 1. If A1(ts) > A1(te) or A2(ts) > A2(te), then go to Step 4. Otherwise

calculate Pk(t), Qk(t), and Lk(t) (k = 1, 2) for t ∈ [ts, te].

Step 2. If there exists at least one t ∈ [ts, te] such that Q1(t) < L1(t) or

Q2(t) < L2(t), then go to Step 4.

Step 3. For τ from te − 1 to ts + 1 (with decreasing τ by −1)

(i) Calculate U1(τ) and U2(τ) according to their definitions in (3.10).

(ii) Calculate A1(τ), A2(τ) as follows:

43

A1(τ) := (As(τ) − Ds(τ))B1(τ) − D1(τ)

Bs(τ) − Ds(τ)+ D1(τ)

A2(τ) := As(τ) − A1(τ)

(iii) Adjust the values of A1(τ) as follows:

If A1(τ) > U1(τ), then

A1(τ) := U1(τ), A2(τ) := As(τ) − A1(τ),

If A1(τ) < L1(τ), then

A1(τ) := L1(τ), A2(τ) := As(τ) − A1(τ).

(iv) Adjust the values of A2(τ) as follows:

If A2(τ) > U2(τ), then

A2(τ) := U2(τ), A1(τ) := As(τ) − A2(τ),

If A2(τ) < L2(τ), then

A2(τ) := L2(τ), A1(τ) := As(τ) − A2(τ).

Step 4. Stop. ¤

In the above algorithm, Steps 1 and 2 check whether the sufficient condi-

tions on the feasibility of S1 and S2 hold or not. If they do so, the algorithm

outputs A1(t) and A2(t) for t ∈ [ts, te]. The computational complexity of this

algorithm is linear to the length te − ts +1 of the segment. For these output,

we have the following theorem.

Theorem 3. If the Rate Splitting Algorithm outputs S1 and S2 on [ts, te],

they are feasible transmission schedules.

Proof According to Theorem 1, it is sufficient to show that we have (3.16),(3.17)

and (3.18) when Step 3 is done for each τ .

After Step 3(iii) of the algorithm, A1(τ) satisfies (3.16) and (3.18). Now,

there are three possibilities for the status of A2(τ) at the beginning of Step

3(iv).

44

Case 1 : If L2(τ) ≤ A2(τ) ≤ U2(τ), then the values of A1(τ) and A2(τ)

are not adjusted in Step 3(iv). Hence we have (3.17).

Case 2 : Assume that A2(τ) > U2(τ). In this case, the value of A1(τ) is

adjusted to

A1(τ) = As(τ) − U2(τ).

From

As(τ) − U2(τ) ≤ U1(τ) and

As(τ) − U2(τ) > As(τ) − A2(τ) = A1(τ) ≥ L1(τ),

we have

L1(τ) ≤ A1(τ) ≤ U1(τ).

Case 3 : Assume that A2(τ) < L2(τ). Then the value of A1(τ) is adjusted

to

A1(τ) = As(τ) − L2(τ)

in Step 3(iv). From

As(τ) − L2(τ) ≥ L1(τ) and

As(τ) − L2(τ) < As(τ) − A2(τ) = A1(τ) ≤ U1(τ),

we have

L1(τ) ≤ A1(τ) ≤ U1(τ).

In any case, we have (3.17) and (3.18) at the end of Step 3(iv). ¤When the condition of Step 1 or Step 2 fails, the Rate Splitting Al-

gorithm halts, and then we calculate two optimal schedules S∗1 and S∗

2 on

the segment and obtain an aggregate schedule Ss = S∗1 + S∗

2 . Thus, letting

Segments be the union of segment where the algorithm fails, we obtain a

new transmission schedule S ′s:

45

A′s(t) =

{A∗

s(t) t ∈/ Segments

A∗1(t) + A∗

2(t) t ∈ Segments

Note that because of the optimality of S∗s , S ′

s may have a larger peak and vari-

ance of the transmission rate than S∗s , and the longer the length of Segments

is, the larger the peak and variance of S ′s might be.

As for video samples used in the experiments in Section 3.4, we observed

that for rate splitting of 2 video streams, the number of segments in Segments

decreases as the client buffer size b increases as shown in Table 3.1.

buffer size number of number of segments percentage(KBytes) total segments in Segments

128 2794 28 1.00%256 1594 19 1.19%384 1104 20 1.81%512 835 16 1.92%640 672 15 2.23%768 564 9 1.60%896 483 8 1.66%

1024 406 8 1.97%1152 344 8 2.33%1280 301 8 2.66%1408 265 8 3.02%1536 237 3 1.27%1664 219 2 0.91%1792 207 2 0.97%1920 186 2 1.08%2048 173 1 0.58%2176 155 1 0.65%2304 148 1 0.68%2432 137 0 0.00%2560 130 0 0.00%

Table 3.1: number of segments in Segments for 2 video streams

46

Here, we consider the reason for the decrease of number of segments in

Segments.

Segments appears when the transmission schedule Ss does not satisfy the

sufficient condition proposed in Theorem 1. We consider the conditions that

there exists some t0 ∈ [ts, te] such that

L1(t0) > Q1(t0)

holds while rate splitting. Then based on the definition of L1(t) and Q1(t),

there are 9 prosibilities:

Case 1 : D1(t0) > B1(t0).

This formula does not hold since we always have

D1(t) ≤ B1(t)

for any t.

Case 2 : A1(ts) > B1(t0).

This formula does not hold since

A1(ts) ≤ B1(ts) ≤ B1(t0).

Case 3 : maxts≤t≤t0

(As(t) − B2(t)) > B1(t0).

Assume As(t) − B2(t) takes its max value on [ts, t0] at t′, where t′ ∈

[ts, t0]. We have

As(t′) − B2(t

′) ≤ Bs(t′) − B2(t

′)

≤ B1(t′)

≤ B1(t0).

So, this formula does not hold either.

47

Case 4 : D1(t0) > A1(te).

This formula does not hold since

D1(t0) ≤ D1(te) ≤ A1(te).

Case 5 : A1(ts) > A1(te).

Since

D1(ts) ≤ D1(te) ≤ B1(te), and

B1(ts) ≤ B1(te),

this formula is possible only when

A1(ts) = B1(ts), and

A1(te) = D1(te).

And because of Fact 1, we have

As(ts) = Bs(ts), and

As(te) = Ds(te).

Because transmission schedule Ss is feasible, we have

Bs(ts) ≤ Ds(te).

Case 6 : maxts≤t≤t0

(As(t) − B2(t)

)> A1(te).

This formula is possible to hold only when A1(te) = D1(te) since for

any t′ ∈ [ts, te],

As(t′) − B2(t

′) ≤ Bs(t′) − B2(t

′)

= B1(t′)

≤ B1(te).

48

Case 7 : D1(t0) > As(t0) − D2(t0).

This formula does not hold since

As(t0) − D2(t0) ≥ Ds(t0) − D2(t0)

= D1(t0).

Case 8 : A1(ts) > As(t0) − D2(t0).

This formula is possible to hold only when A1(ts) = B1(ts) since

D1(ts) ≤ D1(t0) ≤ As(t0) − D2(t0)

Case 9 : maxts≤t≤t0

(As(t) − B2(t)

)> As(t0) − D2(t0).

Since

As(t0) − B2(t0) ≤ As(t0) − D2(t0),

this formula is possible to hold only when for t′ = arg maxts≤t≤t0

(As(t) −

B2(t)),

As(t′) − B2(t

′) > As(t0) − D2(t0), where t′ 6= t0.

As a summary of the formulae above, the sufficient condition does not

hold only when

1. B1(ts) > D1(te) on the condition at Bs(ts) ≤ Ds(te).

Here,

Bs(ts) = B1(ts) + B2(ts)

= D1(ts − 1) + D2(ts − 1) + 2b

= Ds(ts − 1) + 2b.

So, when buffer size b increases to more than(Ds(te) − Ds(ts − 1)

)/2,

Bs(ts) will be greater than Ds(te), the optimal smoothing algorithm

49

will choose some other change points. Moreover, when buffer size b is

large enough, segments that start with Bs(ts) and end with Ds(te) will

disappear.

2. maxts≤t≤t0

(As(t) − B2(t)

)> D1(te).

Since

As(te) = Ds(te),

we have

As(t) − D1(te) ≤ As(te) − D1(te)

≤ Ds(te) − D1(te)

≤ D2(te) for t ∈ [ts, t0]

Also, when buffer size b is large enough,

D2(te) ≤ B2(t) for t ∈ [ts, t0].

Thus,

As(t) − B2(t) ≤ D1(te)

holds for any t ∈ [ts, t0].

3. B1(ts) > As(t0) − D2(t0).

Since

As(ts) = Bs(ts),

we have

As(t0) − B1(ts) ≥ As(ts) − B1(ts)

≥ Bs(ts) − B1(ts)

≥ B2(ts).

50

Also, when buffer size b is large enough, we have

B2(ts) ≥ D2(t0) for t0 ∈ [ts + 1, te].

Thus,

As(t0) − D2(t0) ≥ B1(ts)

holds for any t0 ∈ [ts + 1, te].

4. maxts≤t≤t0

(As(t) − B2(t)

)> As(t0) − D2(t0).

We assume t′ = arg maxts≤t≤t0

(As(t) − B2(t)

)where t′ 6= t0, then the for-

mula can be written as

As(t′) − B2(t

′) > As(t0) − D2(t0)

As(t′) − As(t0) > Bs(t

′) − D2(t0)

Here, for any t < t0, we have

As(t) − As(t0) < 0.

Also, when buffer size b is large enough, we have

Bs(t) − D2(t0) > 0 for any t ∈ [ts, t0 − 1].

Thus, for any t ∈ [ts, t0 − 1],

As(t) − As(t0) < Bs(t) − D2(t0)

always holds, which equals to

As(t′) − B2(t

′) < As(t0) − D2(t0).

In consequence, the increasement of buffer size b leads to decreasement

of numbers of segments in Segments.

51

128KB client 256KB clientNumber of videos buffer size buffer size

2 1.69% 2.54%4 1.48% 1.89%8 0.49% 1.55%16 0.29% 0.88%32 0.60% 0.00%

Table 3.2: Percentage of length of Segments in frames

Also for multiple video samples used in the experiments in Section 3.4, we

observed that the percentage of length of Segments decreases as the number

of videos increases as shown in Table 3.2.

For multiple transmission system with n clients which will be introduced

in Section 3.3, we assume the transmission schedule of the server to be S(1)s ,

and the transmission schedule of each client i to be Si, we have

d(1)s (t) = d1(t) + d2(t) + · · · + dn(t)

D(1)s (t) = D1(t) + D2(t) + · · · + Dn(t)

B(1)s (t) = B1(t) + B2(t) + · · · + Bn(t)

So, according to the definition of B(t), we have

B(1)s (t) = D(1)

s (t − 1) + nb,

where b is the buffer size for each client. Thus the distance between B(1)s (t)

and D(1)s (t) is

B(1)s (t) − D(1)

s (t) = D(1)s (t − 1) + nb − D(1)

s (t)

= nb − d(1)s (t)

=n∑

i=1

(b − di(t)

)Also, since for each client i, we have

b ≥ max0≤i≤n

di(t),

52

So the distance between B(1)s (t) and D

(1)s (t) increases as the number of video

streams n increases. It is the same to the increasement of buffer size b for

2 video streams. So the percentage of length of Segments decreases as the

number of video streams n increases.

3.3 Rate splitting of multiple video streams

In this section, we consider transmission system with one server and n (n > 2)

clients. An example of this system with 5 clients is shown in Figure 3.2.

Server

Router

Client2

Client3

Router Client4Client5

Network

Client1

Figure 3.2: An example of multiple transmission system with 5 clients

As shown in Figure 3.2, the server connects to each client through network

and transmits different video streams to each client respectively.

For the n video streams the server transmits, the proposed SaA scheme

performs, in advance, n − 1 time aggregation of video streams based on

a binary tree structure as shown in Figure 3.3. At each internal node of

the tree, we obtain the aggregation of two streams associated with its child

nodes. After smoothing the aggregate schedule on the root by the optimal

smoothing algorithm, we split the schedule S(1)s associated with the root node

53

Root

Internal Node

External Node

Ralation

S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11

S(7)sS(6)

s

S(5)s

S(2)s

S(8)s S(9)

s

S(4)sS(3)

s

S(1)s

S(10)s

Figure 3.3: An example of binary tree data structures for rate splitting ofmultiple video streams with 11 clients.

into feasible ones and allocate them to its child nodes. Then, we continue to

do this produre recursively for S(`)s (2 ≤ ` ≤ n − 1) associated with the `-th

internal node until we obtain feasible schedules Si (1 ≤ i ≤ n) to individual

videos, each of which corresponds to an external node of the tree.

The relation between parent node and child nodes is same as we described

before for two video streams, the relation between transmission schedule

S and transmission schedule 1,2. So by using the rate splitting algorithm

for transmission system with two video streams repeatedly, we can get the

transmission schedule for all the clients of the aggregated transmission system

with multiple video streams.

Here, for n video streams of size N frames, we estimate the calculation

time for both AaS scheme and SaA scheme. First, for the AaS scheme, since

54

the calculation time is O(N2) for optimal smoothing, the calculation time

for AaS scheme is

T = nO(N2).

For the SaA scheme, the smoothing processes in turn of aggregation, smooth-

ing and rate splitting. Here, the calculation time for aggregation of 2 video

streams is O(N), which is easy to see. And the calculation time of the rate

splitting algorithm proposed in Section 3.2 is O(N). So the calculation time

for SaA scheme is

T = (n − 1)O(N) + O(N2) + (n − 1)O(N)

= O(N2) + 2(n − 1)O(N)

In our experiment, we also estimate the calcultion time for online smooth-

ing algorithm, which will be introduced in Section 3.4.

3.4 Simulation results

3.4.1 On aggregation of two streams

For two MPEG video data with length of about two hours, the ratio of

the variability (peak or variance or transmission rate) of the proposed SaA

scheme to that of the traditional AaS scheme defined as

the variability of the SaA

the variability of the AaS

is shown in Figure 3.4 where the horizontal axis corresponds to buffer size

(KBytes) of each client and jitter is set to 0 frame. We summarize statistical

properties of these video data in Table 3.3 (a). On Figure 3.4, we observe

that the ratio of the peak rates decreases linearly in the range of the buffer

size b ≥ 2000. Moreover, Figure 3.4 shows that the proposed SaA scheme

achieves about 10% and up to 20% reduction of the variance and peak bit

rate, respectively, compared to the traditional AaS scheme.

55

75

80

85

90

95

100

105

0 500 1000 1500 2000 2500 3000 3500 4000

Ratio

(%)

Buffer size(KBytes)

VariancePeak

Figure 3.4: Simulation results of aggregation of two streams with jitter=0.

(a) Statistical properties for two videos1 2

Average rate(bytes) 5297.54 5239.49Variance 3.84 × 107 3.45 × 107

Peak (bytes) 98577 72471

(b) Statistical properties for 128 videosAverage

rate (bytes) variance peak (bytes)Maximum 9367.74 7.81 × 107 184077Minimum 3982.89 6.90 × 106 39290Mean 6409.25 2.13 × 107 76821.55Deviance 1051.42 1.19 × 107 21188.15

Table 3.3: Statistical properties for two videos and 128 videos

3.4.2 On aggregation of multiple streams

For aggregation with 128 different video streams with length of about two

hours, the ratio of the variability of the proposed SaA scheme to that of

56

traditional AaS scheme is shown in Figure 3.5. The statistical charactors of

these 128 videos are given in Table 3.3(b). In both schemes we adopted the

offline optimal smoothing algorithm.

75

80

85

90

95

100

105

0 500 1000 1500 2000

Ratio

(%)

Buffer size(KBytes)

VariancePeak

Figure 3.5: Simulation results for aggregation of 128 streams with jitter=0.

As shown in Figure 3.5, the SaA scheme gives at least 10% reduction of

the peak bit rate than the AaS scheme.

Moreover, the simulation results by using online algorithm are shown in

Figure 3.6, 3.7, 3.8 and 3.9. Figure 3.6 and Figure 3.7 show the peak rate of

AaS scheme, SaA scheme and SaA scheme using offline algorithm, the ratio

of the variability of the SaA scheme to that of the AaS scheme.

Figure 3.8 and Figure 3.9 show the calculation time, under the experimen-

tal environment shown in Table 2.2, of both the AaS and SaA schemes, and

the ratio of calculation time of the SaA scheme to that of the AaS scheme,

respectively. In each graph, the horizontal axis corresponds to the window

size w while the value of slide length α, which is the number of frames to

57

be transmitted by the online algorithm, is always given by α = 5. Also, the

client buffer size B is 256KBytes and jitter is 0 frame. The variance was not

shown in Figure 3.6 since the difference of SaA scheme and AaS scheme is

very slight. The experiment results for fixed w and variable α are omitted

as we stated in Chapter 2, the effects of slide length α can be ignored.

8.08.59.09.5

10.010.511.011.512.012.5

0 20 40 60 80 100 120 140

Peak

(x10

5 Byte

s)

window size(frames)

SaA SchemeAaS Scheme

Offline

Figure 3.6: Peak rate

85

90

95

100

105

0 20 40 60 80 100 120 140

Ratio

(%)

window size(frames)

PeakVariance

Figure 3.7: Ratio of the variability

0

200

400

600

800

1000

1200

1400

1600

0 20 40 60 80 100 120 140

Calcu

latio

n tim

e(se

cond

s)

Window size(frames)

SaA schemeAaS scheme

Figure 3.8: Calculation time

0

50

100

150

200

0 20 40 60 80 100 120 140

Ratio

(%)

Window size(frames)

Calculation time ratio

Figure 3.9: Ratio of calculation time

As shown in Figure 3.6, the larger window size w is, the smaller peak rate

of both SaA scheme and AaS scheme will be. Comparing with offline SaA

scheme, proposed online SaA scheme’s peak is less than 6% higher when win-

dow size w ≥ 80. Also, the proposed online SaA scheme improves the peak

and variance of transmission rate for the aggregation of 128 video streams

using the online smoothing algorithm as well. Moreover, it is remarkable

58

that the calculation time of the SaA is linear to the window size while that

of the AaS is quadratic. The ratio of the calculation time is less than half

when w ≥ 80.

At last, we examine how to choose window size w and slide length α for

a mutliple transmission system.

9.29.39.49.59.69.79.89.9

10.010.1

0 20 40 60 80 100 120 140

Peak

Rat

e(x1

05 Byte

s)

window size(frames)

0.10.20.30.40.5

(a) Peak rate

0

50

100

150

200

0 20 40 60 80 100 120 140

Calcu

latio

n Ti

me(

Seco

nds)

window size(frames)

0.10.20.30.40.5

(b) Calculation time

Figure 3.10: Results of proposed SaA scheme

94

95

96

97

98

99

100

101

0 20 40 60 80 100 120 140

Ratio

(%)

window size(frames)

0.10.20.30.40.5

(a) Peak rate

0

50

100

150

200

0 20 40 60 80 100 120 140

Ratio

(%)

window size(frames)

0.10.20.30.40.5

(b) Calculation time

Figure 3.11: Comparision bwtween traditional AaS scheme and the proposedSaA scheme with repect to peak rate and calculation time

According to our experiment in Chapter 2, slide length α slightly affects

the peak and variance for smoothed result, we set α = w × η. Figure 3.10

and Figure 3.11 show our results for η = 0.1, 0.2, 0.3, 0.4, and 0.5, where

window size W is from 10 to 150 frames. Figure 3.10 shows the values of

59

9.6

9.7

9.8

9.9

10

10.1

10.2

10.3

0 20 40 60 80 100 120 140

Peak

Rat

e(x1

05 Byte

s)

window size(frames)

0.10.20.30.40.5

Figure 3.12: Peak rates of traditional AaS scheme

the results of the proposed SaA scheme and Figure 3.11 shows the ratio of

the results. From Figure 3.10, we can know that calculation time slightly

depends on window size w for fixed η. Also from Figure 3.11 (b), we can

know that η does not affect the ratio of calculation time. Ratios in Figure

3.11 (a) vary because the results of traditional AaS scheme, the denominator

of the ratio, vary when window size W and slide length α both increases as

shown in Figure 3.12.

So consider a multiple transmission system with maximal transmission

delay Γ frames. According to Figure 3.6, we can choose window size W as

large as possible to be Γ. Moreover, we can select large η when we prefer less

calculation time or small η when we prefer less peak rate.

60

Chapter 4

Synchronous RVLC

From this chapter, we change our focus to the error correcting of MPEG4

data. Some basic definitions and properties will be given in this chapter and

chapter 5.

Synchronous RVLC will be discussed in this chapter. Section 4.1 gives

some definitions and notations of RVLC and introduces the LV algorithm for

construction of RVLC proposed by Lakovic and Villasenor [24]. Synchronous

codes will be discussed in Section 4.2 and the definition of synchronous RVLC

will be given.

4.1 RVLC

4.1.1 Definitions and notations

For a finite set D = {0, . . . , a − 1} called alphabet, define Dn =n∏1

D , the

set of words of length n, with letters from D and D∗ =∪n≥0

Dn, the set of

all finite length words including the empty word λ with length 0. In this

dissertation, we consider only binary alphabet, in other words, D = {0, 1}.

We call an element wn ∈ D∗ a word, where wn = w1 . . . wn, and define

|wn| as the length of the word wn, where |wn| = n.

Definition 7. A source code C for a random variable X is a mapping from

61

X , the range of X, to D∗. Let C(x) denote the codeword corresponding to

x and let `(x) denote the length of C(x). Or simply, we can call C ⊂ D∗ a

code.

For example, ASCII code is a source code for X ={Numbers, Alphabets,

Symbols} with alphabet D = {0, 1}.

Definition 8. The average length L(C) of a source code C for random variable

X with probability mass function p(x) is given by

L(C) =∑x∈X

p(x)`(x).

Definition 9. For a string x of length n, where x = x1x2 . . . xn, we define

pi = x1 . . . xi(1 ≤ i ≤ n) as prefix of x and si = xi . . . xn(1 ≤ i ≤ n) as

suffix of x.

Definition 10. A code is called a prefix-free(suffix-free) if no codeword

is a prefix(suffix) of any other codeword. A code, which is simultaneously

prefix-free and suffix-free, is called biprefix or fix-free.

Definition 11. A code is called a fixed length code if all the codewords

are with the same length. On the contrast, a code is called a variable length

code if the length of codewords are variable.

Lemma 1. All fixed length codes are fix-free codes.

Proof:

For a fixed length code C, if a codeword α ∈ C is the prefix of another

codeword β ∈ C, also because of the definition of fixed length code in Def-

inition 11, |α| = |β|, So α = β. So no codewords is the prefix of any other

codewords.

In the same way, we can proof that no codewords is the suffix of any other

codewords. ¤

62

A fix-free variable length code is also called an RVLC (Reversible Vari-

able Length Code). In this dissertation, we consider only RVLC for fix-free

code. Because of the prefix-free and suffix-free properties of RVLC, an RVLC

is able to decode any finite sequence of codewords in both forward and back-

ward directions. This property is very useful for transmission error resilience.

4.1.2 Construction of RVLC

The algorithms for constructing an RVLC from the Huffman code were stud-

ied in [24, 25, 26]. Especially, Lakovic and Villasenor [24] considered a formal

relationship between the number of available RVLC codewords of length k

and the structure of other codewords of length less than k, and proposed an

effective algorithm, denoted by LV algorithm in this dissertation, to obtain

a suboptimal RVLC from the Huffman code.

In this subsection, we will introduce the LV algorithm proposed by Lakovic

and Villasenor [24].

Definitions and Notations

First, we give a definition to describe the LV algorithm.

Definition 12. Define the prefix set Pk(w) of a word w = w1 . . . w` as

Pk(w) = {x ∈ Dk | x1 . . . x` = w} k ≥ `.

Similarly, the suffix set Sk(w) is defined as

Sk(w) = {x ∈ Dk | xk−`+1 . . . xk = w} k ≥ `.

The cardinality of the prefix set |Pk(w)| is obviously equal to the cardi-

nality of the suffix set

|Pk(w)| = |Sk(w)| = 2k−`. (4.1)

63

Let W = {w(1), . . . , w(m)} be a set of fix-free codewords where we denote

the length of w(i) by `i. And, we assume that `1 ≤ `2 ≤ · · · ≤ `m. Let na(k)

be the number of codewords of length k > `m that are neither prefixes nor

suffixes of any other codewords of W . Since the total number of strings of

length k is equal to 2k, it holds that

na(k) = 2k −

∣∣∣∣∣( ∪

w∈W

Pk(w)

)∪

( ∪w∈W

Sk(w)

)∣∣∣∣∣= 2k −

∣∣∣∣∣ ∪w∈W

Pk(w)

∣∣∣∣∣ −∣∣∣∣∣ ∪w∈W

Sk(w)

∣∣∣∣∣+

∣∣∣∣∣ ∪v,w∈W

Pk(v) ∩ Sk(w)

∣∣∣∣∣ (4.2)

Recall that no RVLC is prefix or a suffix of another codeword. This

implies that all the prefix sets, as well as all the suffix sets, are disjoint. That

is, we have the following equation:

|Pk(v) ∩ Pk(w)| = |Sk(v) ∩ Sj(w)| = 0,

v,w ∈ W, v 6= w. (4.3)

Therefore,

na(k) = 2k −∑w∈W

(|Pk(w)| + |Sk(w)|)

+∑v∈W

∑w∈W

|Pk(v) ∩ Sk(w)|

= 2k −m∑

i=1

2k−`i+1 +∑v∈W

∑w∈W

|Pk(v) ∩ Sk(w)| . (4.4)

It can be easily shown that the cardinalities of Pk(w(i)) ∩ Sk(w

(j)) are

given as follows[27].

64

In the case that max(`i, `j) < k < `i + `j, we have

∣∣Pk(w(i)) ∩ Sk(w

(j))∣∣ =

1, if (w

(i)k−`j+1 · · ·w

(i)`i

)

= (w(j)1 · · ·w(j)

`i+`j−k)

0, if (w(i)k−`j+1 · · ·w

(i)`i

)

6= (w(j)1 · · ·w(j)

`i+`j−k)

(4.5)

while for `i + `j ≤ k ∣∣Pk(w(i)) ∩ Sk(w

(j))∣∣ = 2k−`i−`j . (4.6)

We also define that

Ak(v, w) = Pk(v) ∩ Sk(w), (4.7)

ak(W ) =∑v∈W

∑w∈W

|Ak(v, w)| (4.8)

to simplify the formula.

As an example, Table 4.1 shows all Ak(v,w) for code W1 = {000, 001, 010, 100}

and W2 = {000, 010, 101, 111}.

W1 W2

wk wl A4(wk, wl) A4(w

l, wk) wk wl A4(wk, wl) A4(w

l, wk)000 000 {0000} 000 000 {0000}000 001 {0001} φ 000 010 φ φ000 010 φ φ 000 101 φ φ000 100 φ {1000} 000 111 φ φ001 001 φ 010 010 φ001 010 {0010} φ 010 101 {0101} {1010}001 100 φ {1001} 010 111 φ φ010 010 φ 101 101 φ010 100 {0100} φ 101 111 φ φ100 100 φ 111 111 {1111}

Table 4.1: An example of Ak(v,w) for code W1 = {000, 001, 010, 100} andW2 = {000, 010, 101, 111}

From Table 4.1, we can compute that a4(W1) = 6 and na(4) = 6 for W1,

while a4(W2) = 4 and na(4) = 4 for W2.

65

Construction algorithm

LV algorithm proposed by Lakovic and Villasenor [24] for construction of

fix-free codes is as follows:

Step 1) Let nL = (n(1), . . . , n(L)) be a vector, called profile, in which n(i) is

a nonnegative integer for 1 ≤ i ≤ L. Let C(nL) be a binary variable-

length code containing n(i) codewords of length i, for each i = 1, . . . , L.

For a given profile vector nL = (n(1), . . . , n(L)), start the assignment

of RVLC codewords at level i = arg mink

(n(k) 6= 0).

Step 2) Identify the set of available codewords of length i, which are neither

prefixes nor suffixes of codewords obtained in the earlier levels. The

number of available codewords, denoted by na(i), is equal to 2i at level

i = arg mink

{n(k) 6= 0}. At levels i > arg mink

{n(k) 6= 0}, na(i) depends

on RVLC codewords in C(ni−1) that have been already obtained.

Step 2.1) If na(i) ≥ n(i), the n(i) RVLC codewords should be assigned at the level

i. Denoting the set of available codewords by Xa(i,W ) = {x(1), . . . , x(na(i))},

we select an n(i)-element subset X ⊆ Xa(i,W ) as the set of RVLC

codewords of length i. The set of all possible candidate codeword sets

can be written as

X(i, W ) = {X|X ⊆ Xa(i,W ), |X| = n(i)}. (4.9)

Suppose that all the elements in Xs ∈ X(i,W ) are selected as RVLC

codewords of length i. Then, according to (4.2) and (4.8), the number

of available codewords na(j) at a level j > i is given by

na(j) = 2j −m∑

k=1

2j−`k+1 − n(i) · 2j−`k+1 + aj(Xs ∪ W ). (4.10)

66

Consequently, the highest na(j) is achieved by selecting the set X∗s (j)

such that

X∗s (j) = arg max

Xs∈X(i,W )aj(Xs ∪ W ) (4.11)

Therefore, we perform the selection in the following manner: At level

i, we assign the codewords from the set

X∗s (i + 1) = arg max

Xs∈X(i,W )ai+1(Xs ∪ W ) (4.12)

Note that there may be several candidate sets Xc ∈ X(i,W ) with

ai+1(Xc ∪ W ) = ai+1(X∗s (i + 1) ∪ W ) which yield the same na(i + 1).

In this case we choose the set Xc that yields the highest na(i + 2).

Step 2.2) If na(i) < n(i), all the available RVLC codewords are assigned, and the

ith and i + 1st components of the profile vector n(i) is updated as

n(i + 1) = n(i + 1) + n(i) − na(i) (4.13)

n(i) = na(i). (4.14)

The obtained vector is set to n(i + 1).

Step 3) The number of the assigned codewords is updated as m = m + n(i).

If m <L∑

i=1

n(i) the codeword assignment (Step 2) continues for level

i = i + 1. Otherwise, the construction ends.

4.2 Synchronous Codes

A synchronous code C is a code such that at least one codeword σ ∈ C

functions as a resynchronization marker (re sync). Whenever σ is received

(without errors), the decoder must automatically resynchronize regardless of

the preceding synchronization slippage.

67

4.2.1 Synchronous prefix-free codes

Definition 13. According to [18], a codeword σ of a binary prefix-free code

C is a re sync if it satisfies the following two conditions:

• if σ is a substring of a codeword τ of C, then σ is a suffix of τ but not

equal to any other substrings of τ .

• if σ = αβ, where αβ means concatenation of α and β, α 6= σ is a suffix

of a codeword of C, then β ∈ C∗.

As an example, prefix-free code C for English alphabet shown in Table 4.2

is a synchronous code with re syncs 100001 and 1000001. The probability

of the re syncs is 0.01868 + 0.00867 = 0.02735, which means the re sync

appears in every1

0.02735≈ 37 codewords on average.

A synchronous prefix-free code can be useful to recover the decoding pro-

cess against slippage errors. But from Table 4.2, we can notice that re sync

100001 appears in 001|00001, 010|0001 and 1100|001, etc. and 1000001 ap-

pears in 001|000001, 010|00001 and 1100|0001, etc. Hence for a transmission

Encoder Channel DecoderSource Buffer

Figure 4.1: A transmission system

system as shown in Figure 4.1, an encoder encodes source symbols and trans-

mits the codewords immediately into a channel. The decoder receives data

into a buffer and decodes the received data in the buffer. If an error occurs,

with a synchronous prefix-free code the decoder can decode the data follow-

ing a re sync. However, the data preceding the re sync(including re sync

itself) can not be decoded as shown in Figure 4.2.

68

Letter Probability Codeword re sync

E 0.14878 001T 0.09351 010A 0.08833 0001O 0.07245 0110R 0.06872 0111N 0.06498 1010H 0.05831 1011I 0.05644 1100S 0.05537 1111D 0.04376 00001L 0.04124 10010U 0.02762 10011P 0.02575 11010F 0.02455 11011M 0.02361 11100C 0.02081 11101W 0.01868 100001 yesG 0.01521 100010Y 0.01521 100011B 0.01267 000001V 0.01160 000000K 0.00867 1000001 yesX 0.00146 10000001J 0.00080 100000001Q 0.00080 1000000001Z 0.00053 1000000000

Table 4.2: An example of synchronous prefix-free code

4.2.2 Synchronous RVLC

Since an RVLC is able to be decoded both forward and backward, the data

preceding the re sync can also be decoded correctly if the re sync is found

in a sequence of codewords. An RVLC can solve the problem in the previous

subsection. Also, since re sync defined by Definition 13 does not satisfy the

suffix-free condition of RVLCs, we introduce the definition of being a re sync

69

error

Buffer

data can be decodeddata cannot be decoded

re_sync

Figure 4.2: An error occurs while decoding

of an RVLC as follows:

Definition 14. A codeword σ in an RVLC C is a re sync if the following

two conditions hold:

1. σ is not a substring of any other codeword of C.

2. σ can not be written as αγβ, where α 6= σ is a suffix of some codeword

of C, β is a prefix of some codeword of C and γ ∈ C∗.

An RVLC is said to be synchronous if one of codewords is a re sync. Note

that the condition 1 and condition 2 of Definition 14 ensures the uniquely

appearance of the re sync in the sequence of codewords. Unlike re sync of

the synchronous prefix-free codes, whenever the re sync of a synchronous

RVLC appears in the sequence of codewords, it is not a substring of any

combinations of other codewords.

The main idea for construction of synchronous RVLC is to replace some

codewords with re syncs. According to Definition 14, the words that never

appear in the the sequence of codewords can be used as re syncs. In the

next chapter, we will introduce the minimal words that never appear in a

sequence, which are called MFWs(Minimal Forbidden Words).

70

Chapter 5

Minimal Forbidden Words

In this chapter, we will introduce the MFW(Minimal Forbidden Word). By

using MFWs, it is easy to find out a re sync that can be used for an RVLC.

The definition of MFW will be given in Section 5.1 and Section 5.2 will

introduce an algorithm for construction of s[3], a string contains every 3

combinations of number 1, . . . ,m with minimal length, which will be useful

for search for a re sync in the next chapter.

5.1 MFWs(Minimal Forbidden Words)

MFWs are minimal words that never appear in a string of symbols, which are

used in data compression using antidictionary (DCA) proposed by Crochemore

et al.[28].

Definition 15. The dictionary D(x) of string x ∈ X ∗ is defined as the set

of all the substrings of x, that is,

D(x) = {xlxl+1 · · ·xm|1 ≤ l ≤ m ≤ |x|} ∪ {λ}.

where |x| is the length of x.

71

Definition 16. A string v = v1v2 · · · vm such that

i) v ∈ X ∗ \ D(x)

ii) v1v2 · · · vm−1 ∈ D(x) and v2v3 · · · vm ∈ D(x)

is called minimum forbidden word (MFW) of x.

Definition 17. The antidictionary of x, denoted by AD(x), is defined as

the set of all the MFWs of x.

For example, for string x = 0101100100, AD(x) = {000, 1010, 1101, 111}.

The DCA uses automaton shown in Figure 5.1 for data compression.

0 1

42

0 0 0

1

0

1 1

1 0

1

1

0 1

10

7

85

9

11

10

63

Figure 5.1: Automaton for string x = 0101100100.

As shown in Figure 5.1, Since 000, 1010, 1101 and 111 are MFWs of string

x = 0101100100, state 6, 9, 10 and 11, marked as red, are unreachable. So

72

during the encoding of string x = 0101100100, the encoder outputs an empty

letter λ at state 3, 5, 7 and 8, marked as yellow, which means the next state

is unique. So the output string of the encoder for string x = 0101100100 is

0101λλλλ00 = 010100. The DCA will send {AD(x), 010100, |x| = 10} to

the decoder. By using automaton, the calculation time for construction of

AD(x) is O(N log N)

Ota et al.[29] improved Crochemore’s DCA algorithm and shown that the

decoder can restore the original string x by using only AD(x). Moreover,

Ota et al.[31] proposed an algorithm to construct AD(x) with calculation

time O(N). The details are omitted in this dissertation.

Consider the condition 1 and 2 in Definition 14. Suppose that C consists

of m codewords. And let C[t] be a concatenation of codewords w1w2 . . . wN

where N = mt + t − 1 and substrings wiwi+1 · · ·wi+t−1 are distinct for

i = 1, . . . , N − t + 1, that is,

|{wiwi+1 · · ·wi+t−1 | i = 1, . . . , N − t + 1} | = mt.

Define s[t] as the maximum periodic sequence over an alphabet of size m of

order t. We can use s[t] to be the indices of codewords to construct C[t]. For

example, for m = 2 and t = 3 where C = {c1, c2}, we have

s[3] = 1112221211,

C[3] = c1c1c1c2c2c2c1c2c1c1.

The details of the construction for s[3] will be introduced in next section.

For a given t, there is a possibility that an MFW of C[t] is used as a

re sync in an RVLC. In fact, an MFW of C[t] satisfies Condition 1 of Def-

inition 14 since, from the definition of MFW, it never appears in C[t]. As

for Condition 2 of Definition 14, theoretically, there exists tmax such that an

MFW of C[tmax] satisfies this condition. However, practically, it is not easy

to estimate the value of tmax in advance. In our experiments described in the

73

next chapter, with t = 3 we can obtain MFWs that can be added to C as a

re sync.

5.2 Construction of s[3]

First, we consider C = {1, 2}, then C3 = {111, 112, 121, 122, 211, 212, 221, 222}.

Our purpose is to construct a string s[3] with the minimal length that con-

tains each element w ∈ C3 as substring. We can construct s[3] by using a

de Bruijn graph of order 3 proposed by de Bruijn [34] constructed in the

following way:

1. Make each of the elements from C3 a node, where in total there are 23

nodes.

2. Make a directed edge from node a = a1a2a3 to b = b1b2b3 if a2a3 = b1b2.

Label the edge with symbol b3. For example, an edge from 111 to 112

is labeled as 2.

The de Bruijn graph of order 3 for C = {1, 2} is shown in Figure 5.2.

Also, Figure 5.3 shows one of the Hamiltonian paths of that de Bruijn graph

of order 3. The s[3] can be constructed by the label of start node and all the

labels of the edges of the Hamiltonian path.

Thus,

s[3] = 1112221211,

where |s[3]| = 3 + 23 − 1 = 10, and every element of C3 is the substring of

s[3].

The de Bruijn graph is useful for construction of s[3] when m = |C| ≥ 2.

But when m is very large, the number of nodes in the de Bruin graph is m3 in

order to construct s[3] and the calculation complexity increases drastically.

74

112211

111

212

122221

222

1211

2

21

1

1

2

2

1

2

1 2

1

2

1

2

Figure 5.2: de Bruijn graph of order3 for C = {1, 2}

112211

111

212

122221

222

1211

2

21

1

1

2

2

1

2

1 2

1

2

1

2

Figure 5.3: one of the Hamiltonianpaths of the de Bruijn graph of order3

Here, we propose an algorithm to construct s[3] for any C with m = |C| ≥

2. The idea is to separate the de Bruijn graph into several parts and connect

the Hamiltonian path for each part.

The de Bruijn graph of s[3] for m = |C| ≥ 2 can be divided as follows:

1. nodes constructed by only one element from C, such as 111, 222, . . .,

mmm.

75

2. graphs of nodes constructed by two different elements from C. An

example of such graphs is shown in Figure 5.4. Define graph in Figure

5.4 as F (1, 2). Then we have F (1, 2), . . ., F (m − 1,m), which the

number of the these graphs is

(m2

)=

m(m − 1)

2.

112211

212

122221

121

2

1

2

1

1

2

1

2

2

1

Figure 5.4: An example of graphs of nodes constructed by two differentelements from C

3. graphs of nodes constructed by three different elements from C. Two

examples of such graphs are shown in Figure 5.5 (a) and (b). Define

graphs in Figure 5.5 (a) and (b) as G(1, 2, 3) and G(2, 1, 3) respectively,

we have G(1, 2, 3), G(2, 3, 1), . . ., G(m−2,m−1,m), G(m−1, m,m−2),

which the number of these graphs is 2 ×(

m3

)=

m(m − 1)(m − 2)

3.

Note the total number of the nodes is still m3 since

m + 6 × m(m − 1)

2+ 3 × m(m − 1)(m − 2)

3

=m + 3m2 − 3m + m3 − 3m2 + 2m

=m3.

76

231123

312

1

23

(a)

213

1323211

23

(b)

Figure 5.5: Examples of graphs of nodes constructed by three different ele-ments from C

The three kinds of graphs described above can be connected into one

graph in the following way:

1. Node 111 can be thinked as the start node of the Hamiltonian path.

Also, node 222, . . ., mmm can be inserted into F (1, n) n = 2, . . . ,m as

shown in Figure 5.3. We define the graphs F (1, n) n = 2, . . . ,m with

node nnn as F ′(1, n).

2. Each node nnn (n = 2, . . . ,m − 1) in F ′(1, n) can be thinked as the

start node of graph F (n, k) k = n + 1, . . . ,m. The F (n, k) stops at

node knn and there exists an edge from knn to nn1 which is the next

node of nnn in F ′(1, n). Figure 5.6 shows an example of 222 being the

start node of F (2, 3).

3. Graph G(a, b, c) (a < b < c) can be connected from node aab(or bab)

of F (a, b) and there exists an edge from cab, the node G(a, b, c) stops

at, to abb(or aba) which is the next node of aab(or bab) in F (a, b). In

the same way, graph G(b, a, c) (a < b < c) can be connected from node

aba(or bba) of F (a, b). Figure 5.7 shows an example of G(1, 2, 3) and

G(2, 1, 3) connecting with F ′(1, 2).

77

111

222

223

322

323

233

332

232

112

211

212

122

221

121

1

21

1

1

12

2

21

21

1 2

22

1

32

1

2

23

3

3

3

1

Fig

ure

5.6:

An

exam

ple

ofco

nnec

ting

node

222

wit

hF

(2,3

)

78

231

123

312

213

132

321

112

211

212

122

221

222

121

3

1

2

2

21

2

1

3

2

1

1

33

12

2

2

11

12

2

Fig

ure

5.7:

An

exam

ple

ofG

(1,2

,3)

and

G(2

,1,3

)co

nnec

ting

wit

hF

′ (1,

2)

79

Figure 5.8 gives a quasi-C program for construction of s[3] with C = m to

illustrate our algorithm. The F (1, i, true) in the program implements F ′(1, i)

and F (b, j, false) implements F (b, j).

1. s[3] = “111”;2. for(int i=2;i<=m;i++) F(1,i,true);3.4. void F(a,b,apostrophe){5. s[3] += “b”;6. for(int j=b+1;j<=n;j++) G(a,b,j);7. s[3] += “b”;8. if(apostrophe){9. s[3] += “b”;

10. for(int j=b+1;j<= n;j++) F(b,j,false);11. }12. s[3] += “aba”;13. for(int j=b+1;j<=n;j++) G(b,a,j);14. s[3] += “a”;15. }16.17. void G(a,b,c){18. s[3] += “cab”;19. }

Figure 5.8: A quasi-C program for construction of s[3]

In this way, we can construct s[3] with length 3 + m3 − 1 = m3 + 2. For

3 is length of the start node 111 of the Hamiltonian path of the de Bruijn

graph and m3 − 1 is the number of edges of the Hamiltonian path.

80

Chapter 6

Construction of SynchronousRVLC

In this chapter, we will introduce an algorithm for construction of syn-

chronous RVLC. The basic idea is to replace a codeword of an RVLC C with

re sync. In Section 6.1, we introduce the construction algorithm and the

experiment results will be given in Section 6.2. Finally, Section 6.3 discussed

the probability that re sync appears in a buffer of size θ bits.

6.1 Construction algorithm

In order to construct a synchronous RVLC, we first prepare an RVLC by

means of the LV algorithm, then replace one codeword with a re sync.

Here is an algorithm for constructing synchronous RVLCs:

Algorithm MakeSyncRVLC

input: an RVLC C.

output: a synchronous RVLC C+.

Step 1 Select a codeword w ∈ C to be replaced, define C ′ = C \ {w}.

Step 2 Given t, generate C ′[t].

81

Step 3 Construct AD(C ′[t]) of the string C ′[t].

Step 4 For each x ∈ AD(C ′[t]), decide if C ′ ∪ {x} is still an RVLC or not.

And let W be the set of x’s that satisfy the condition.

Step 5 Let T be the set of all the y ∈ W that satisfies condition 2 of

Definition 14 for C ′ ∪ {y}.

Step 6 Select the shortest t+ from T , and then set C+ = C ′ ∪ {t+}.

Step 7 Stop. 2

Here we give some remarks on Algorithm MakeSyncRVLC presented above. In

Step 3, usually t = 3 in practical applications. We use a linear complexity

algorithm [31] to construct the antidictionary AD(C ′[t]) of C ′[t]. In Step

4, because of the definition of MFW, any element w ∈ AD(C ′[t]) is not a

substring of codewords of C ′, we only need to decide if w begins or ends with

any codeword of C ′. In Step 5, as discussed in Section 3, every MFW of

C ′[t] satisfies 2.1) in Definition 14. Also, an MFW y of C ′[t] can be used as

a re sync for C ′, we check here if it still a re sync for C ′ ∪ {y}. Thus, it is

guaranteed that C+ is a synchronous RVLC.

Among algorithms for constructing an RVLC from the Huffman code, we

choose the LV algorithm since it obtains less average code length than others

while MakeSyncRVLC accepts any RVLC as an input.

Being a re sync, a codeword should satisfies both condition 1 and 2 of

Definition 14. Shorter and longer codewords tend to satisfy condition 1 and

condition 2 of Definition 14 more often, respectively. On the other hand,

because of the suboptimality of the LV algorithm, the obtained re sync t+

will be longer than w selected at Step 1 of MakeSyncRVLC. Therefore, w

should be chosen to maximize the number of codewords that satisfy condition

2 of Definition 14 and contain w as a substring. In our observation on

82

the RVLCs constructed by the LV algorithm, a zero-run 0 . . . 0 or one-run

1 . . . 1 among the shortest codewords are often selected as w, where the

LV algorithm always produces a zero-run or one-run as one of the shortest

codewords.

6.2 Experiment results

The results of MakeSyncRVLC for an i.i.d. source over English alphabet given

in [24] are shown in Table 6.1, where p(a) denotes the probability of symbol

a. The re sync 00000011 is found by MakeSyncRVLC with eliminating the

codeword 000 which has the highest probability. And as a by-product, four

codewords of the input RVLC also become re syncs as indicated in Table

6.1 .

We can see that the proposed synchronous RVLC has a probability 0.03454

that re sync occurs in spite of increasing the average codeword length for

0.20387 bits. In other words, for the i.i.d. source in Table 6.1, a re sync

appears once in1

0.03454≈ 29 codewords on the average.

Also, the results of MakeSyncRVLC for Tcoef VLC of MPEG4 [5](Table

B.16) is shown in Table 6.2. Here, Table 6.2 only gives the profile of the

results, where details will be shown in Appendix 7.

Because the probability distribution of Tcoef is unknown, we assume that

the probability on the condition that the VLC of Tcoef for MPEG4 satisfies

d`(x)e = log2

1

p(x)(6.1)

where `(x) indicates the length of codeword for symbol x, and p(x) indicates

the probability of symbol x. We define here the length of codeword in VLC

83

a p(a) RVLC in [24]proposedRVLC

re sync

E 0.14878 000 001T 0.09351 001 0100A 0.08833 0100 0101O 0.07245 0101 0110R 0.06872 0110 1010N 0.06498 1010 1011H 0.05831 1011 1100I 0.05644 1100 1101S 0.05537 1101 01110D 0.04376 01110 01111L 0.04124 01111 10010U 0.02762 10010 10011P 0.02575 10011 11110F 0.02455 11110 11111M 0.02361 11111 100010C 0.02081 100010 100011W 0.01868 100011 1000010G 0.01521 1000010 1000011Y 0.01521 1000011 1110111B 0.01267 1110111 00000011 yesV 0.01160 10000010 10000010 yesK 0.00867 10000011 10000011 yesX 0.00146 11100111 11100111J 0.00080 100000010 100000010 yesQ 0.00080 1000000010 1000000010 yesZ 0.00053 1110000111 1110000111average length 4.25145 4.45529re sync prob. 0.00000 0.03454

Table 6.1: The RVLC in [24] and RVLC obtained by MakeSyncRVLC

code for symbol x as `V (x). Then (6.1) can be written as

d`V (x)e = log2

1

p(x)

`V (x) ≤ log2

1

p(x)

2`V (x) ≤ 1

p(x)

p(x) ≥ 2−`V (x) (6.2)84

length of VLC of the LV proposed number ofcodeword MPEG4 code∗ RVLC re syncs

2 1 1 03 1 1 14 3 3 35 3 3 36 10 10 107 9 6 68 13 4 49 21 11 11 2

10 14 13 13 211 12 22 22 512 16 29 29 713 0 0 0 014 0 0 0 015 0 0 0 016 0 0 1 1

∗ the LV code is RVLC obtained by the LV algorihtm [24].

∗ the LV code is RVLC obtained by the LV algorihtm

Table 6.2: The profile of VLC in [5], RVLC obtained by the LV algorithm[24] and RVLC obtained by MakeSyncRVLC

By using (6.2), we can obtain that the proposed synchronous RVLC in

Table 6.2 has a probability of no less than 0.03003. Also, we estimate the

average code length by

L(C) =∑x∈X

2−`V (x)∑x∈X

2−`V (x)`(x), (6.3)

and obtained the average length for VLC of MPEG4, RVLC obtained by the

LV algorithm [24] and proposed RVLC are approximately 4.56, 4.76, 5.22,

respectively. Thus, the redundancy of our algorithm is 5.22 − 4.56 = 0.66.

It is smaller than redundancy of RVLC of MPEG4 which is 30 × 0.03003 =

0.9009.

85

6.3 Probability consideration

We will evaluate the probability that there is at least one re sync in a buffer

of size θ at the receiver side. If there exists a re sync in the buffer, we can

decode data backward up to the position where an error occurred. For an

RVLC C, denote the set of all re syncs that belong to C by M. And then

let N = C \M.

0 X

Buffer

String constructed by codewords of N

re sync

Figure 6.1: An illustration of X

Let X be the position of the first re sync appears as shown in Figure

6.1. We would like to obtain the probability Pr{X ≤ θ}.

This problem can be solved by generating function in [32]. Let G be the

set of all the strings that consist of a sequence over N followed by a re sync

in M. In other words, G can be written as

G =∪n≥0

N n · M. (6.4)

where u ∈ N n · M means that there exist v ∈ N n and w ∈ M such that

u = vw.

For a codeword w, let p(w) denote the probability of w. If w is the

codeword for a, then p(w) = p(a). The equation on sets in (6.4) can be

86

translated into the equation of the probability generating function as follows:

N(z) =∑v∈N

p(v) · z`(v) (6.5)

M(z) =∑

w∈M

p(w) · z`(w) (6.6)

G(z) =∑n≥0

(N(z))n · M(z) (6.7)

Here, we consider that z ∈ R. Then G(z) in (6.7) can be written as

G(z) =M(z)

1 − N(z)when |N(z)| < 1. (6.8)

According to the definition of the probability generating functions, we

have

G(z) =∞∑

n=1

Pr{X = n} · zn when |N(z)| < 1. (6.9)

Theorem 4. The probability of re sync appears in buffer of size θ satisfies:

Pr{X ≤ θ

}≥ sup

0<s<ϕ

(1 − e−sθ · G(es)

),

where ϕ ∈ (0,∞) is a real root of N(es) = 1.

Proof :

According to the Chernoff bound, we have

Pr{X ≥ α

}≤ e−sα ·

∑x

p(x)esx for any s > 0. (6.10)

Then we can put z = es into (6.9) and obtain

G(es) =∞∑

n=0

p(x = n) (es)n when |N (es)| < 1. (6.11)

By putting (6.11) and θ = α into (6.10), we can obtain

Pr{X ≥ θ

}≤ e−sθ · G(es) for any s > 0, when |N (es)| < 1

Pr{X ≥ θ

}≤ inf

s>0e−sθ · G(es) when |N (es)| < 1. (6.12)

87

Considering the condition of (6.12),

|N (es)| < 1 for s > 0. (6.13)

Since p(v) > 0 for v ∈ N , es > 1 for s > 0, So

N(es) =∑v∈N

p(v) · es`(v) > 0.

The (6.13) can be written as

N (es) < 1 for s > 0. (6.14)

Also, from N ⊂ C(since M 6= φ), for s = 0,

N(1) =∑v∈N

p(v)

< 1

Also, since p(v) > 0 for v ∈ N ,

N(z) =∑v∈N

p(v) · z`(v)

is a monotonically increasing function, there exists a root ϕ ∈ (0,∞) for

N(es) = 1. So the (6.14) can be written as

s < ϕ. (6.15)

Therefore, combine (6.15) into (6.12), we get

Pr{X ≥ θ

}≤ inf

0<s<ϕe−sθ · G(es).

So, the probability we want is

Pr{X ≤ θ

}≥ sup

0<s<ϕ

(1 − e−sθ · G(es)

). (6.16)

¤

88

We did a simulation experiment to examine Pr{X ≤ θ} for buffer size

θ ∈ [1, 2000] bits base on code shown in Table 6.1. In our experiment, we

randomly produce source symbols and the encoder encodes them into buffer

where the random number is produced by Random Master TOSHIBA c©1. For

100,000,000 times of our simulations, we examine how many times X ≤ θ

holds, and Pr{X ≤ θ} is calculated by the quotient of frequency for X ≤ θ

to 100,000,000. We set θ ≤ 2000 since Pr{X ≤ 2000} = 0.99999987 in our

experiment and Pr{X ≤ 2000} ≥ 0.999996 according to (6.16), the difference

is very slight for θ ≥ 2000.

Figure 6.2 shows the value of Pr{X ≤ θ} calculated in our computer

experiment and its estimated probability in (6.16). Figure 6.2 (a) shows

the probability for θ ∈ [0, 2000] and Figure 6.2 (b) shows the value of 1 −

probability for θ ∈ [1000, 2000]. Note that the y axis of Figure 6.2 (b) uses

logarithmic scale and has inverse direction.

0.0

0.2

0.4

0.6

0.8

1.0

0 500 1000 1500 2000

Prob

abilit

y

Buffer Size(Bits)

estimated probabilityexperiment

(a) Pr{X ≤ θ}

10-7

10-6

10-5

10-4

10-3

10-2 2000 1800 1600 1400 1200 1000

Prob

abilit

y

Buffer Size(Bits)

estimated probabilityexperiment

(b) 1-Pr{X ≤ θ}

Figure 6.2: The value of Pr{X ≤ θ} calculated by computer experiment andits estimated probability in (6.16)

1http://www.toshiba.co.jp/efort/product/rmaster/

89

6.4 Consideration of Re sync Constructed by

Two Codewords

In Section 6.1, we discussed an algorithm for construction of synchronous

RVLC with codewords act as re syncs. In this section, we will examine the

existence of re syncs constructed by two codewords.

Definition 18. Conbination φψ of codeword φ,ψ in an RVLC C is a re sync

if the following three conditions hold:

1. Neither φ nor ψ is a re sync of C.

2. φψ is not a substring of any codeword of C.

3. φψ is not a substring of any other conbinations of codewords of C.

Under these conditions of Definition 18, we examine that there are re syncs

constructed by two codewords in synchronous RVLC shown in Table 6.1. Ta-

ble 6.3 shows the result, where probability is calculated by P (φ) × P (ψ).

φ ψ probability1000010 001 0.0027791000010 1110000111 0.0000101110000111 1110000111 2.809×10−7

sum of probability 0.002789

Table 6.3: re syncs constructed by two codewords in RVLC shown in Table6.1

From Table 6.3, we can know by using re sync constructed by two code-

words, the RVLC shown in Table 6.1 got 0.002789 more probabilities of

re syncs with no increasement of redundancy.

Moreover, for synchronous RVLC of MPEG4 Tcoef, which profile is given

in Table 6.2 and details are given in Table A.2, Table 6.4 shows the number

of re syncs with comparing to RVLC obtained by the LV Algorithm [24].

90

the LV code∗ proposed RVLCaverage code length 4.75783∗∗ 5.22449∗∗

number of re syncs 0 17re sync probability 0.0000 0.03003∗∗∗

numbers of re syncsconstructed by two codewords

0 1634

probability of re syncsconstructed by two codewords

0.00000 0.09310∗∗∗

∗ the LV code is RVLC obtained by the LV algorihtm [24].∗∗ the average codelength is calculated under (6.3)∗∗∗ the probability is calculated under (6.2)

Table 6.4: Number of re syncs in RVLC obtained by the LV algorithm [24]and RVLC obtained by MakeSyncRVLC for MPEG4 Tcoef

From Table 6.4, we can know there are 1634 re syncs constructed by

two codewords, and the probability of re syncs appear increased 0.09310 for

synchronous RVLC for MPEG4 Tcoef.

6.5 Synchronizing sequence of RVLC

In order to combat slippage errors, we have considered re sync of RVLC

so far. There is another way of getting synchronization by using a certain

combination of codewords to detect the boundary of codewords. Such a

combination of codewords is called a synchronizing sequence which is defined

as follows.

A synchronizing sequence(SS) is a finite length segment of a sequence

of codewords which enables the decoder to determine codeword synchroniza-

tion when it is observed.

We consider that the decoder decodes in forward direction. Then, de-

pending on the position of codeword synchronization, we categorize SS into

4 types:

Type 1 Codeword synchronization should be decided both at the beginning

91

and at the end of the SS. An example of this type of SS constructed by

two codewords codeword1 and codeword2 is shown in Figure 6.3 (a).

A re sync of an RVLC is this type of SS.

Type 2 Codeword synchronization should be decided at the end of the SS.

Figure 6.3 (b) shows an example of this type of SS. Usually, a re sync

of a prefix-free code is this type of SS.

codeword1 codeword2

synchronizationsynchronization

synchronizing sequence

(a) type 1

codeword1 codeword2

synchronization

synchronizing sequence

(b) type 2

codeword1 codeword2

synchronization

synchronizing sequence

(c) type 3

codeword1 codeword2

synchronization

synchronizing sequence

(d) type 4

Figure 6.3: Examples of SS constructed by codewords codeword1 and code-word2

Type 3 Codeword synchronization should be decided at the beginning of

the SS. Figure 6.3 (c) shows an example of this type of SS. Usually, a

re sync of a suffix-free code is this type of SS.

Type 4 Codeword synchronization should be decided at a position inside

the SS. Figure 6.3 (d) shows an example of this type of SS. In fact,

all the SSs of type 1,2 or 3 are belong to this type. Moreover, since

some of the SSs does not include the prefix of codeword1 and the suffix

of codeword2, it could be shorter than other types of SSs. For syn-

chronous RVLC of English alphabet given in Table 6.1, examples of

92

type 2 type 3 type 4000010001 1000010001 0000100010000101110000111 100001011100001 0000101110000100001111110000111 111000011110000001 000011111100001

Table 6.5: Examples of SSs conctructed by two codewords of type 2,3 and 4for English alphabet synchronous RVLC

SSs constructed by two codewords of type 2,3 and 4 are given in Ta-

ble 6.5, where those of type 1 is given in Table 6.3. The SSs of type

2(type 3) are got by erase bits from the beginning (ending) from those

of type1.

For the following Propostion, we consider the SSs of type 4.

Proposition 1. For an RVLC C and a substring t of a string in C∗, if one

of the substrings of t is an SS of C, then t is also an SS of C.

Proof:

If a string α which is substring of t is an SS, then the decoder may

determine the codeword synchronization at some position of α, it equals

to that the decoder may determine the codeword synchronization at some

posision of t. That means t is an SS of C. ¤Corollary For an RVLC C and a substring t of a string in C∗, if t is not an

SS of C, then any substrings of t are not SSs either.

Proof:

This is the contrapositive of Proposition 1. ¤The Corollary is very useful in finding SSs contructed by n codewords of

an RVLC C for a given n ≥ 2. First we find out all the re syncs constructed

by n codewords, and all the SSs are substrings of the re syncs.

93

Chapter 7

Conclusion

In this thesis, we are concerned with a transmission system of multiple video

streams with error resilience from one server to many clients.

1) We proposed a new SaA scheme where the server first aggregates all

the video streams into one stream, then smoothes it. Although the SaA

scheme is superior to the AaS scheme to alleviate the variability of the

rate of multiple video transmitted from the server, there was a problem

how to split the smoothed schedule to each video so as to satisfy the

following conditions: a) Nonnegative amount of data should be sent to

clients at any time; b) No buffer overflow nor underflow occurs at any

client.

To solve this problem, we obtained sufficient and necessary conditions

for possible feasible rate splitting for the aggregation of two streams. By

using these conditions, we proposed an online rate splitting algorithm

to split the schedule for the aggregation of two video streams into two

feasible schedules. Moreover, we extended this algorithm to multiple

video streams by constructing a binary tree structure of schedules.

Our simulation results showed that the proposed SaA scheme improved

peak for about 15% of the aggregated transmission rate. By using the

online smoothing algorithm, the SaA scheme achieves more than 50%

94

reductions of the total calculation time compared to the traditional

AaS scheme for the aggregation of 128 MPEG video streams.

2) We proposed an algorithm for constructing a synchronous RVLC and

applied it to an RVLC constructed by the LV algorithm [24]. First,

we find MFWs of a specific sequence of codewords, in which any t-

plet of codewords appear for a certain value of t. Then, one of these

MFWs takes the place of a codeword of the original RVLC. This MFW

functions as a re sync as well as a codeword in a usual sense.

Our experiment got a probability of re sync for no less than 0.03003

for MPEG4’s VLC of Tcoef [5](part2).

Also, by using basic properties of generating functions, we evaluated

the probability of occurrence of re sync in a buffer of size θ bits.

Finally, we consider re syncs constructed by two codewords, which will

increase the probability of the re syncs appear.

These results can be used in an online multiple transmission system in

ignorance of client bandwidth, where the server transmits video data on

demands to more than one clients. The transmission schedule can be calcu-

lated dynamicly as the numbers of the clients changed. The synchronization

marker can be used in error resilience when transmission error occurs.

There remains a problem on how to transmit multiple video streams if

the clients’ bandwidth is limited. One possible solution is to incorporate a

bit-rate transcoder [35] in our proposed system. This transmission system

will be done in our future work.

Also, the algorithm to find out SSs of an RVLC C is left to be our future

work.

95

Acknowledgments

First of all, I should like to express my sincere thanks to Professor Hiroyoshi

Morita for his precious guidance, invaluable encouragement and various sup-

port in my study and persional life. Without him, this dissertation would not

have been done. I would also wish to thank the committee of graduate studies

for the precious comments on my manuscript, including Associate Professor

Hiroshi Nagaoka, Professor Mamoru Hoshi, Professor Kazuyuki Suzuki and

Professor Hideki Koike.

I would also like to express my gratitude to Associate Mikihiko Nishiara

and Associate I Gusti Bagus Baskara Nugraha for their many many helps in

my research. And also thanks to all the members of Morita laboratory for

supporting me.

Also, I wish to acknowledge the finacial support given by Japanese Mon-

busho from April 2005 to March 2007.

My Final thanks are due to my wife Weifang Yu and my unborn child for

their emotional support and occasional assistance throughout the long, long

process.

96

References

[1] Internet Association Japan, http://www.iajapan.org/index-en.html

[2] http://www.chiariglione.org/mpeg/

[3] ISO/IEC 11172-2, 1993.

[4] ISO/IEC 13818-2, 1994.

[5] ISO/IEC 14496-2, third edition, 2004.

[6] H. Fujiwara, “Newest MPEG Text Book,” ascii, Tokyo, 1994.

[7] N. Ahmed, T. Natarajan, and K. R. Rao, “Discrete cosine transform,”

IEEE Transactions on Computers, vol. C-32, pp. 90-93, Jan. 1974.

[8] S. Lam, S. Chow, and D. Yau, “An algorithm for lossless smoothing

of MPEG video,” in Proceedings of ACM SIGCOMM ’94, pp.281–293,

London, England, August 1994.

[9] J. D. Salehi, Z.-L. Zhang, J. F. Kurose, and D. Towsley, “Support-

ing stored video: Reducing rate variability and end-to-end resource re-

quirements through optimal smoothing,” in Proc. ACM SIGMETRICS,

pp. 221–231, May 1996.

[10] S. Sen, D. Towsley, Z. -L. Zhang, and J. K. Dey, “Optimal multicast

smoothing of streaming video over an internetwork,” Tech. Report 98-

77, Department of Computer Science, Univ. Massachusetts, 1998.

97

[11] J. Rexford and D. Towsley, “Smoothing variable-bit-rate video in an

internetwork,” IEEE/ACM Trans. on Networking, Vol. 7, pp.202–215,

1999.

[12] J. K. -Y. Ng and S. Song, “A video smoothing algorithm for transmit-

ting MPEG video over limitted bandwidth,” in Proc. of the 4th inter.

workshop on real-time computing systems and applications, pp.229–236,

Oct. 1997.

[13] T. V. Lakshman, A. Ortega, and A. R. Reibman, “Variable bit-rate

(VBR) video: Tradeoffs and potentials,” Proc. of IEEE, vol.86, pp. 952–

973, May 1998.

[14] J. Rexford, S. Sen, J. Dey, W. Feng, J. Kurose, J. Stankovic, and

D. Towsely, “Online smoothing of live, variable-bit-rate video,” in Proc.

Workshop on Network and Operating System Support for Digital Audio

and Video, pp. 249–257, May 1997.

[15] S. Sen, J. Rexford, J. Dey, J. Kurose, and D. Towsley, “Online smooth-

ing of variable-bit-rate streaming video,” Tech. Rep. 98-75, Univ. Mas-

sachusetts, Comput. Sci. Dept., 1998.

[16] S. Sen, J. Rexford, J. Dey, J. Kurose, and D. Towsley, “Online Smooth-

ing of Variable-Bit-Rate Streaming,” IEEE Transactions on Multimedia,

pp. 37–48, March 2000.

[17] A. W. Marshell and I. Olkin, “Inequalities: Theory of Majorization and

its Applications,” Academic Press, New York, 1979.

[18] T. J. Ferguson and J. H. Rabinowitz, “Self-synchronizing Huffman

codes,” IEEE Transactions on Information Theory, vol.30, No.4,

pp.687–693, July 1984.

98

[19] B. L. Montgomery and J. Abrahams, “Synchronization of binary

source codes,” IEEE Transactions on Information Theory, vol.32, No.6,

pp.849–854, November 1986.

[20] R. M. Capocelli, L. Gargano, and U. Vaccaro, “On the characterization

of statistically synchronizable variable-length codes”, IEEE Transac-

tions on Information Theory, vol.34, No.4, pp.817–825, July 1988.

[21] R. M. Capocelli, A. A. De Santis, L. Gargano, and U. Vaccaro, “On the

construction of statistically synchronizable codes,” IEEE Transactions

on Information Theory, vol.38, No.2, pp.407–414, March 1992.

[22] C. F. Freiling, D. S. Jungreis, F. Theberge, and K. Zeger, “Self-

Synchronization of Huffman Codes,” ISIT 2003, Yokohama, Japan, June

29 – July 4, 2003.

[23] C. F. Freiling, D. S. Jungreis, F. Theberge, and K. Zeger, ”Almost all

complete binary prefix codes have a self-synchronizing string,” IEEE

Trans. Inform. Theory, vol.49, No.9, pp.2219-2225, September 2003.

[24] Ksenija Lakovic and John Villasenor, “An algorithm for Construction

of Efficient Fix-Free Codes,” IEEE COMMUNICATIONS LETTERS,

vol.7, No.8, pp.391–393, August 2003.

[25] Y. Takishima, M. Wada, and H. Murakami, “Reversible variable length

codes,” IEEE Transactions on Communications, vol.43, pp.158–162,

February–April 1995.

[26] C. W. Tsai and J. L. Wu, “On constructing the Huffman-code based re-

versible variable length codes,” IEEE Transactions on Communications,

vol.49, pp.1506–1509, September 2001.

99

[27] C. Ye and R. W. Yeung, “Some basic properties of fix-free codes,” IEEE

Trans. Inform. Theory, vol.47, pp.72–87, January 2001.

[28] M. Crochemore, F. Mignosi, A. Restivo, and S. Salemi, “Data com-

pression using antidictionaries,” Proceedings of the IEEE, vol.88, No.11,

pp.1756–1768, 2000.

[29] T. Ota and H. Morita, ”One-Pass ECG Lossless Compression Using

Antidictionaries,” IEICE TRANSACTIONS, vol.J87-A, no.9, pp.1187–

1195, 2004(in Japanese).

[30] H. Morita and T. Ota, “A tight upper bound on the size of the an-

tidictionary of a binary string,” 2005 International Conference on the

Analysis of Algorithms(AofA’05), Discrete Mathematics and Theoretical

Computer Science Proceedings, AD, pp.393–398, 2005.

[31] T. Ota and H. Morita, “Linear complexity construction of antidictionar-

ies,” SITA2005, vol.1, pp.407–410, December, 2005.

[32] R. Sedgewick and P. Flajolet, “An Introduction to the Analysis of Al-

gorithms,” Addison-Wesley Pub (Sd), November, 1995

[33] R. G. Gallager, “Information Theory and Reliable Communication,”

John Wiley & Sons, Inc., 1968.

[34] N. G. de Bruijn, “A Combinatorial Problem,” Proc. Nederl. Akad.

Wetensch. 49, pp.758-764, 1946.

[35] H. Sun, T. Chiang and X. Chen, “Digital Video Transcoding for Trans-

mission and Storage,” CRC, May 2004.

100

Appendix

Experiment Results for MPEG4

Details of results of synchronous RVLC for MPEG4 shown in Table 6.2 is

given in Tabel A.2, where the meaning of Last, Run and Level are given in

Table A.1. The column re sync in Table A.2 indicates whether the codeword

is a re sync in the proposed RVLC.

Last “0”: there are more nonzero coefficients in this block“1”: this is the last nonzero coefficient in this block

Run the number of successive zeros preceding the coded coefficientLevel the non-zero value of the coded coefficient

Table A.1: Meaning of Last, Run and Level in Table A.2

Table A.2: Details of results of synchronous RVLC forMPEG4 shown in Table 6.2

Last Run Level VLC in [5] RVLC in [24] Proposed RVLC re sync

0 0 1 10 00 0100 0 2 110 010 01100 1 1 1110 0110 10111 0 1 0111 1011 11010 0 3 1111 1101 0111 00 0 5 0110 0 0111 0 1001 10 0 4 0110 1 1001 1 1010 10 2 1 0101 1 1010 1 0111 10

101

0 0 7 0100 11 0111 10 0111 110 0 6 0101 01 0111 11 1000 010 4 1 0100 00 1000 01 1000 110 0 8 0100 10 1000 11 1001 010 3 1 0100 01 1001 01 1010 010 1 2 0101 00 1010 01 1100 011 0 2 0011 00 1100 01 1110 011 1 1 0011 11 1110 01 1111 101 2 1 0011 10 1111 10 1111 110 5 1 0011 01 1111 11 1000 001

Escape 0000 011 1000 001 1000 1011 4 1 0010 000 1000 101 1001 0010 6 1 0010 010 1001 001 1010 0010 7 1 0010 100 1010 001 1100 1110 2 2 0010 101 1100 111 1110 1110 1 3 0010 110 1110 111 1000 00011 5 1 0010 011 1000 0001 1000 10010 0 9 0010 111 1000 1001 1001 00010 8 1 0001 1001 1001 0001 1100 00111 3 1 0010 0011 1100 0011 1000 0000 1 Yes1 9 1 0001 1010 1000 0000 1 1000 1000 1 Yes0 0 11 0001 1110 1000 1000 1 1010 0001 10 1 4 0001 1100 1010 0001 1 1100 0001 10 3 2 0001 1011 1100 0001 1 1100 0010 10 9 1 0001 1000 1100 0010 1 1100 1011 11 7 1 0001 0100 1100 1011 1 1100 1100 11 8 1 0001 0011 1100 1100 1 1110 0011 10 0 10 0001 1111 1110 0011 1 1110 1011 10 10 1 0001 0111 1110 1011 1 1110 1100 11 0 3 0001 0110 1110 1100 1 1111 0111 11 6 1 0001 0101 1111 0111 1 1000 0000 01 Yes0 0 15 0010 0011 1000 0000 01 1001 0000 110 0 12 0001 1101 1001 0000 11 1010 0000 110 7 2 0000 1101 0 1010 0000 11 1010 0001 011 10 1 0000 1010 1 1010 0001 01 1100 0000 111 1 2 0000 1011 0 1100 0000 11 1100 0001 011 13 1 0000 1001 0 1100 0001 01 1100 0010 01 Yes1 12 1 0000 1001 1 1100 0010 01 1100 1001 11

102

1 11 1 0000 1010 0 1100 1001 11 1100 1101 110 4 2 0001 0001 0 1100 1101 11 1110 0001 110 0 13 0001 0010 1 1110 0001 11 1110 1001 110 0 14 0001 0010 0 1110 1001 11 1110 1101 110 11 1 0000 1100 1 1110 1101 11 1111 0011 111 0 4 0000 1011 1 1111 0011 11 1000 0000 001 Yes0 12 1 0000 1100 0 1000 0000 001 1000 1000 011 Yes0 1 6 0000 1111 1 1000 1000 011 1001 0000 0110 1 5 0001 0000 0 1001 0000 011 1001 0000 1010 0 16 0001 0000 1 1001 0000 101 1010 0000 0111 14 1 0000 1000 1 1010 0000 011 1010 0000 1010 6 2 0000 1101 1 1010 0000 101 1010 0001 001 Yes0 5 2 0000 1110 0 1010 0001 001 1100 0000 0110 2 3 0000 1111 0 1100 0000 011 1100 0000 1010 3 3 0000 1110 1 1100 0000 101 1100 0001 001 Yes0 13 1 0000 0001 11 1100 0001 001 1100 0010 001 Yes0 3 4 0000 0010 11 1100 0010 001 1100 1000 1111 2 2 0000 0001 00 1100 1000 111 1100 1010 1110 1 7 0000 0011 01 1100 1010 111 1100 1011 0011 0 5 0000 0001 10 1100 1011 001 1110 0000 1111 1 3 0000 0001 01 1110 0000 111 1110 0010 1110 2 4 0000 0011 00 1110 0010 111 1110 0011 0010 0 20 0000 0011 10 1110 0011 001 1110 1000 1110 4 3 0000 0010 10 1110 1000 111 1110 1010 1110 8 2 0000 0010 01 1110 1010 111 1110 1011 0010 0 19 0000 0011 11 1110 1011 001 1111 0001 1110 5 3 0000 0010 00 1111 0001 111 1111 0101 1110 0 17 0000 1000 01 1111 0101 111 1000 0000 0001 Yes0 0 18 0000 1000 00 1000 0000 0001 1000 1000 0011 Yes0 0 24 0000 0100 001 1000 1000 0011 1000 1000 01010 0 21 0000 0000 111 1000 1000 0101 1001 0000 00110 1 8 0000 0100 010 1001 0000 0011 1001 0000 01010 9 2 0000 0100 011 1001 0000 0101 1001 0000 1001 Yes1 16 1 0000 0100 111 1001 0000 1001 1010 0000 00111 15 1 0000 0100 110 1010 0000 0011 1010 0000 01011 4 2 0000 0100 101 1010 0000 0101 1010 0000 1001 Yes1 3 2 0000 0100 100 1010 0000 1001 1010 0001 0001 Yes1 0 7 0000 0000 100 1010 0001 0001 1100 0000 0011

103

1 0 6 0000 0000 101 1100 0000 0011 1100 0000 01010 0 23 0000 0100 000 1100 0000 0101 1100 0000 1001 Yes0 0 22 0000 0000 110 1100 0000 1001 1100 0001 0001 Yes0 7 3 0000 0101 011 1100 0001 0001 1100 1000 01110 6 3 0000 0101 0100 1100 1000 0111 1100 1001 01111 5 2 0000 0101 1010 1100 1001 0111 1100 1001 10011 6 2 0000 0101 1011 1100 1001 1001 1100 1010 01111 17 1 0000 0101 1100 1100 1010 0111 1100 1011 01111 20 1 0000 0101 1111 1100 1011 0111 1100 1100 01110 1 9 0000 0101 0011 1100 1100 0111 1100 1101 01111 18 1 0000 0101 1101 1100 1101 0111 1100 1101 10011 19 1 0000 0101 1110 1100 1101 1001 1110 0001 10010 0 25 0000 0101 0000 1110 0001 1001 1110 1001 10010 0 26 0000 0101 0001 1110 1001 1001 1110 1101 10010 2 5 0000 0101 0110 1110 1101 1001 1111 0000 11111 0 8 0000 0101 1001 1111 0000 1111 1111 0010 11110 14 1 0000 0101 1000 1111 0010 1111 1111 0100 11110 0 27 0000 0101 0010 1111 0100 1111 1111 0110 11110 1 10 0000 0101 0101 1111 0110 1111 0000 1011 1110 0100 Yes

104

List of Publications Related tothis dissertation

Journal Paper

Dongzhao SUN, Mikihiko NISHIARA, Hiroyoshi MORITA, ”On Multiple

Smoothed Transmission of MPEG Video Streams” IEICE TRANSACTIONS,

Vol. E88-A, No.10, pp.2844-2851,2005. (Related to Chapter 3)

International Conference

Dongzhao SUN, Hiroyoshi MORITA and Mikihiko NISHIARA, “On Con-

struction of Reversible Variable-Length Code Including Resynchronization

Markers as Codewords,” ISITA2006, Paper No. 28, Korea, October 2006.

(Related to Chapter 4 and Chapter 6)

105