FOS: A Funnel-Based Approach for Optimal Online
Traffic Smoothing of Live Video
Jeng-Wei Lin, Ray-I Chang, Member, IEEE, Jan-Ming Ho, Member, IEEE, and Feipei Lai, Senior Member, IEEE
Abstract—Traffic smoothing is an efficient means to reduce the bandwidth requirement for transmitting a variable-bit-rate video stream. Several traffic-smoothing algorithms have been presented to offline compute the transmission schedule for a prerecorded video. For live video applications, Sen et al. present a sliding-window algorithm, referred to as ( ), to online compute the transmission schedule on the fly. ( ) looks ahead video frames to compute the transmission schedule for the next frametimes, where . Note that is upper bounded by the initial delay of the transmission. The time
com-plexity of ( ) is ( ) for an frame live
video. In this paper, we present an ( ) online traffic-smoothing algorithm and two variants, denoted as , 1 and 2, respectively. Note that ( ) is a trivial lower bound of the time complexity of the traffic-smoothing problem. Thus, the proposed algorithm is optimal. We compare the performance of our al-gorithms with ( ) based on several benchmark video clips. Experiment results show that 2, which adopts the aggressive workahead heuristic, further reduces the bandwidth requirement and better utilizes the client buffer for real-time interactive applications in which the initial delays are small.
Index Terms—Live video, multimedia streaming, online delivery, traffic smoothing.
I. INTRODUCTION
T
HERE are a growing number of video applications such as digital libraries, video archives, newscasts, and distance learning that can be accessed on various networks. For contin-uous video playback, the client player must render a new frame after one frametime (the period of time between two succes-sive frames) has passed. In order to prevent the client player from starvation, the video server has to transmit the media data into the client buffer before it is going to be rendered. While the media data are retrieved from the disks or generated online, the video server can send a frame per frametime, as shown in Fig. 1(a). However, compressed video streams often exhibit sig-nificant burstiness of frame sizes (number of bits for each frame) on many time scales due to the encoding frame structure and Manuscript received March 30, 2004; revised October 26, 2005. The associate editor coordinating the review of this manuscript and approving it for publica-tion was Dr. Ton Kalker.J.-W. Lin is with the Department of Information Management, Tunghai Uni-versity, Taichung, Taiwan, R.O.C. (e-mail: [email protected]).
R.-I Chang is with the Department of Engineering Science and Ocean Engineering, National Taiwan University, Taipei, Taiwan, R.O.C. (e-mail: [email protected]).
J.-M. Ho is with the Institute of Information Science, Academia Sinica, Taipei, Taiwan, R.O.C. (e-mail: [email protected]).
F. Lai is with the Department of Computer Science and Information Engi-neering and Department of Electronic EngiEngi-neering, National Taiwan University, Taipei, Taiwan, R.O.C. (e-mail: [email protected]).
Digital Object Identifier 10.1109/TMM.2006.879868
Fig. 1. Bandwidth requirement for transmitting the first 1000 frames of Star Wars is reduced from 70 to 26 kB per frametime if the output of the encoder is smoothed.
their natural variations within and between scenes [15], [16]. This burstiness complicates the design of a multimedia system for high resource utilization, such as network bandwidth [19].
In a guarantee service model, the multimedia system has to al-locate enough network bandwidth for the burstiness. However, a lot of bandwidth is wasted when the effective transmission rate is much lower than the allocated bandwidth. In a best-ef-fort service model, when a burst suddenly jams into the net-work, the packets may be discarded, including those of other applications. It is necessary to design a mechanism to reduce the impact caused by the burstiness of variable-bit-rate (VBR) video streams. One approach is to smooth the burstiness. The video server can start the transmission of large frames earlier. By working ahead, it is shown that traffic smoothing is efficient at reducing the bandwidth requirement for VBR video transmis-sion [1]–[13], as shown in Fig. 1(b).
For a prerecorded video stream, the video server has com-plete knowledge of all the frame sizes. The server can use a traffic-smoothing algorithm that takes advantage of the knowledge of upcoming large frames and starts more data transmission in advance of the burst. Several traffic-smoothing algorithms have been presented to offline compute the transmis-sion schedule. For example, the Critical Bandwidth Allocation (CBA) algorithm [2] minimizes the total number of rate in-creases, the Minimum Change Bandwidth Allocation (MCBA) algorithm [9] minimizes the total number of rate changes, and the Minimum Variance Bandwidth Allocation (MVBA) algorithm [1] minimizes the variance of rate changes.
In live video applications, however, the video server only has limited knowledge of frame sizes at any time. Old media data is transmitted, while new media data is generated simultane-ously. In real-time interactive applications, such as video tele-conferencing, the tolerable response delay is small, so only a few frames can be buffered in the video server. In other live video ap-plications, like newscasts and distance learning, the clients may 1520-9210/$20.00 © 2006 IEEE
generated, recomputes the transmission schedule. For an frame live video, the time complexity of
is . Since the time-consuming usually
computes the transmission schedule of a small peak bandwidth requirement, there is a tradeoff between computing costs and performance.
In this paper, we present an traffic smoothing algo-rithm called Funnel-Based Optimal Online Traffic Smoothing (FOS) for live video applications. Note that is a trivial lower bound of the time complexity of the traffic-smoothing problem. Thus, the proposed algorithm is optimal. The video server can use to compute the transmission schedule for a live video. In a lookahead window, maintains the candidates for transmission schedules in a funnel. It considers each new frame iteratively and modifies the two chains of the funnel. If the two chains will cross each other, determin-istically generates a transmission schedule, or when no more frame size information is available, heuristically gener-ates a schedule at the minimal transmission rate in the funnel. While the video server executes the transmission schedule, new frames are generated, and after the transmission schedule has finished, computes the next one. In fact, computes the same transmission schedule as in linear time.
We observe that always uses the minimal transmis-sion rate in a lookahead window. It may lower the transmistransmis-sion rate unnecessarily and then raise the rate in the next window. This usually occurs if the initial delay of a video transmission is small. In such cases, it is likely that all frames in the server buffer are small, e.g., B/P-frames, due to the encoding frame structure. Therefore, lowers the transmission rate. When finds that a large frame, e.g., I-frame, is generated later, it has to raise the transmission rate. If a traffic-smoothing algo-rithm has aggressively transmitted more data to the client, there are less data buffered in the server. Therefore, it is likely that the algorithm can smooth the large frame in the next window.
We have used different heuristics to improve . By com-bining with frame size prediction [13], [17], [18] and ag-gressive workahead [12], we derived two variant algo-rithms called and , respectively. Experiment re-sults show that further reduces the peak bandwidth re-quirement and utilizes the client buffer more efficiently when the initial delay is small.
The remainder of this paper is organized as follows. A formal definition of the online traffic-smoothing problem for live video is illustrated in Section II. Section III presents our al-gorithm, its time complexity proof, and different heuristics. Section IV shows the experiment results. Finally, in Section V we give conclusions.
Fig. 2. Feasible transmission scheduleS should satisfy F (t) G(t) H(t), whereG(t) is a function of S.
II. ONLINETRAFFICSMOOTHING FORLIVEVIDEO
For an frame video , which uses
bits to encode the th frame and is the frametime, the continuous playback schedule can be represented as the step function
where
if
if .
At time , the client player will have played bits and will continue playing bits in the next frametime. Given a frametime playback delay, a video server can transmit media
data at the rate from time to according to a
transmission schedule .
The cumulative transmission function is defined as if
if .
To guarantee continuous playback at the client, should satisfy
However, the client player usually does not have unlimited buffer space. We assume the client player provides a -bit buffer. The cumulative buffer function is defined as
To avoid buffer overrun, should also satisfy
Fig. 3. Looking ahead in live video applications. (a) Online smoothing algo-rithm determines anL frametime transmission schedule S . (b) After L fram-etimes have passed, the algorithm determines the next transmission schedule
S .
Without loss of generality, we consider a discrete time model at the granularity of a frametime. Assuming , we sim-plify the definition of , and as follows.
Cumulative playback function if
if . (1)
Cumulative buffer function
(2) Cumulative transmission function
if
if . (3)
As is the total size of the video frames, a
traffic-smoothing algorithm should not plan to transmit more
than data. For a prerecorded video stream, a
traffic-smoothing algorithm knows each frame size and can offline compute the transmission schedule that satisfies
(4) For live video, however, a traffic-smoothing algorithm has limited knowledge of frame sizes at any time because frames after the time have not been generated. The
algorithm knows and has no idea about
. An frametime
transmission schedule is feasible
if satisfies
(5) as shown in Fig. 3(a). While the video server executes , new frames are generated. After frametimes have passed and
Fig. 4. (a) SLW IN(W ) has drawbacks when smoothing traffic across window boundaries. (b)SLW IN(k) incorporates new frame size information and therefore computes a better transmission schedule.
Fig. 5. SLW IN(k) unnecessarily lowers the transmission rate in the first three windows and raises the rate in the fourth window.
has therefore finished, new frames have been generated. The traffic-smoothing algorithm can incorporate new frame size in-formation to compute the next transmission schedule , as shown in Fig. 3(b).
Given a frametime initial delay and a slide length
, [10], [11] looks ahead a window of
frames and uses an algorithm ( [1]) to compute the transmission schedule for the
window. Note that fixes . After
frame-times have passed, computes the next transmission schedule. The total time complexity is times the com-plexity of smoothing a -frame window of the video stream.
Thus, the time complexity of is .
usually has a tradeoff in selecting the slide
length. If the maximum slide length is used ,
as shown in Fig. 4(a), the entire live video transmission is scheduled into continuous nonoverlapped transmission
sched-ules. has drawbacks when smoothing traffic
Fig. 6. F OS iteratively considers F (a) and H(a) for t + 1 a t + D to maintain the candidates for transmission schedules in the funnel, i.e., the shadowed area.
in Fig. 4(b), only the first frametime part of the transmission schedule is used and the rest of the schedule is discarded. Although using a smaller slide length requires more computing resources, it makes a better transmission schedule.
We observe that always generates the transmis-sion schedule for a window at the minimal rate. Note that at time , the transmission schedule that generates for the window is the shortest path from to
[11], [14]. may lower the transmission rate unnecessarily and raise the rate in the next window, as shown in Fig. 5. This usually occurs when has smoothed a window of small frames and a large frame is generated in the next window. If a traffic-smoothing algorithm has aggressively transmitted more data to the client in the previous windows, there are less data buffered in the server. Thus, it is likely the algorithm can smooth the large frame in the next window.
III. OURALGORITHMS ANDTIMECOMPLEXITYANALYSIS
A. Algorithm
Like , at time , our algorithm tries
to find the shortest path from to in
the window. However, generates transmission schedules in nonoverlapped and variant-length manners. It considers each frame only once and remembers useful computational results for the next window by maintaining a funnel.
As shown in Fig. 6(a), from the starting point , maintains the candidates for transmission schedules
within a convex upper chain and
a concave lower chain , where
, are points selected from the
function , and are points selected from the
function . is convex if and only if
(6) where is the slope of the line from to . is con-cave if and only if
(7) The two chains form a funnel.
Fig. 7. (a)F OS removes v ; v ; . . . ; v , appends x onto the funnel, and dis-covers that the resultant lower chain will cross the upper chain. (b)F OS deter-ministically generates the transmission schedule and reconstructs the funnel. (c) F OS removes u ; u ; . . . ; u , appends x onto the funnel, and discovers that the resultant upper chain will cross the lower chain. (d)F OS deterministically generates the transmission schedule and reconstructs the funnel. (e) When there is no more frame size information,F OS heuristically chooses a point x in the funnel. (f)F OS generates the transmission schedule and reconstructs the funnel.
We now describe how the chain points are selected. Initially,
, , and . In
a window, iteratively considers each unprocessed frame
and modifies and . For , appends
the points onto and onto , as
shown in Fig. 6(b) and (c). then removes some points so that the resultant and remain concave and convex, respec-tively, as shown in Fig. 6(c) and (d). By triangle inequality, we can prove that the shortest path is in the funnel. If the resultant and will cross each other, as shown in Fig. 7(a) and (c), deterministically generates the transmission schedule. When there is no more frame size information available, as
Fig. 8. Processingx. (a) F OS first scans the lower chain. If there is a point v such that V = fv ; . . . ; v ; xg is concave. (b) F OS modifies the funnel. In this case,F OS does not generate the transmission schedule. The figure is skewed for better visualization.
Fig. 9. Processingx. (cont.) (a) If F OS fails to find v , it scans the upper chain and finds a pointu so that the edge u x will not cross the upper chain. (b) F OS modifies the funnel. If j 6= 0, F OS generates the transmission schedule according tofu ; . . . ; u g. The figure is skewed for better visualization.
shown in Fig. 7(e), heuristically chooses a point in the funnel and generates the transmission schedule. The length of each transmission schedule is dynamic and after it is generated, reconstructs the funnel, as shown in Fig. 7(b), (d), and (f). When the transmission schedule has finished and at the same time new frames have been generated, computes the next transmission schedule. The detailed description of the funnel maintenance follows.
When the th frame is considered,
first tries to append the point onto . As shown in Fig. 8(a), along , tries to find a point
from to such that . If such
a point is found, removes from and adds
to the tail of . As shown in Fig. 8(b), the resultant chain is concave. and maintain the funnel. In this case, does not generate the transmission schedule. If there is no such point, as shown in Fig. 9(a), along ,
tries to find a point from to so that
edge will not cross , i.e., ;
otherwise, sets . As shown in Fig. 9(b),
replaces with . If , and maintain the
funnel and does not generate the transmission schedule. If , generates the transmission schedule according
to and then removes from . The
resultant chain remains convex. and
maintain the funnel again.
Fig. 10. Processingx . (a) After F OS heuristically chooses a point x in the funnel, it findsv and u on the lower chain and the upper chain, respec-tively, so thatfx ; v ; v ; . . . ; v g is concave and fx ; u ; u ; . . . ; u g is convex. (b)F OS reconstructs the funnel and computes the transmission schedule according tofs; x g. The figure is skewed for better visualization.
After appending onto , then appends the point onto . The processing of is similar to the
pro-cessing of . tries to find a point from to so
that is convex. If such a point is found,
and maintain the funnel and does not generate the transmission schedule. If there is no such point, then finds
a point from to so that and
maintain the funnel. If , generates
the transmission schedule according to and then
removes from .
Saturation may occur if does not decide the transmis-sion schedule after the th frame is considered. Since there is no more frame size information available, heuristically selects a point in the funnel and generates the transmission schedule according to , as shown in Fig. 7(e). Note that
must satisfy (8) where (9) and (10) i.e., and are the minimal and maximal feasible trans-mission rates from the point . Many heuristics can be used. sets to incorporate new frame size information as early as possible, and uses the minimal feasible transmission
rate in the funnel. It selects the point .
then reconstructs the funnel. As shown in Fig. 10,
1) along , finds a point from
to such that
and thus is concave. 2) Along
We assume each edge that is added onto the funnel associates with a counter. The counter is initialized as zero and increases by one whenever the edge is scanned. The time complexity analysis of is based on the following claims.
Claim A: The counter of an edge that is added onto the funnel and removed later is read as two.
Claim B: The counter of an edge that remains on the funnel is read as one.
Proof:
1) Consider the process of appending onto . first starts scanning the edges on from the tail.
If there is a point such that
, the scan stops. The
edges on have been scanned and
their associated counters increased from one to two.
Then, are removed and is added to the
tail of . Note that the counter of the edge is initialized as zero. We can amortize the two counters
of the edges and so that each counter is
reset to one, as shown in Fig. 8. Thus, claims A and B hold. If there is no such point, starts scanning the edges on from the head. Applying similar amortized analyses, we can prove that claims A and B also hold after the scan stops, as shown in Fig. 9. Therefore, after completes the process of appending onto , claims A and B hold.
2) Similarly, we can prove that after completes the process of appending onto , claims A and B hold. 3) When there is no more frame size information
available, computes in constant time and
then reconstructs the funnel. As shown in Fig. 10, scans the edges on from the head. When
finds a point such that
, the scan stops. The
edges on have been scanned and their
associated counters increased from one to two. Then, are removed and is added to the head of . Note that the counter of the edge is initialized as zero. We can amortize the two counters of the edges and so that each counter is reset to one. Therefore, claims A and B hold. then scans the edges on from the head. Again by applying similar analyses, we can prove that after completes the reconstruction, claims A and B hold.
considers and once for .
Each time, adds one edge onto the funnel and may re-move some edges. Since the number of transmission schedules generated will be , at the most, reconstructs the funnel
cally, or heuristically, computes the transmission schedule. It is easy to see that computes the same transmission schedule as . As stated in the end of Section II, it is also true that may lower the transmission rate unnecessarily and then raise the rate in the next transmission schedule. Note that when there is no more frame size information available, heuristically chooses to transmit media data over a frametime at the rate . If a traffic-smoothing algorithm has aggressively transmitted more data to the client, there are less data buffered in the server. Therefore, it is likely the algorithm can smooth the upcoming large frame.
There exist different heuristics. For example, smoothing al-gorithms can predict the transmission rate in the near future [17], [18]. We have derived a variant algorithm called that considers the current transmission rate as a simple form of rate prediction. transmits media data over a frametime at the rate
(11)
where at time .
We have also derived another variant algorithm called that considers the current peak rate. will try to keep the client buffer full without raising the current peak rate. It trans-mits media data over a frametime at the rate
(12)
where at time .
By definition, and thus .
works ahead more aggressively than and .
The aggressive workahead has a significant impact on reducing the peak rate when the initial delay is small. In this case, there is not much time for traffic-smoothing algorithms to work ahead on the upcoming large frames. If has aggressively trans-mitted more data to the client, there is a high probability it will smooth the large frames.
IV. EXPERIMENTRESULTS
In this section, we examine the performance of the proposed online traffic-smoothing algorithms. The study focuses on net-work and client resources by measuring the peak rate and the client buffer occupancy. The peak rate of a smoothed video stream determines its worst-case bandwidth requirement across the path from the video server to the playback client. Hence, most traffic-smoothing algorithms attempt to minimize the peak rate to increase the likelihood that the video server, network and client player have sufficient resources to handle the stream.
TABLE I
SOMESTATISTICS OF THEFOURMPEG VIDEOCLIPS
Fig. 11. Peak bandwidth and client buffer utilization of transmission schedules for Star Wars as a function of the client buffer size for variant initial delays. Practically, media data may get lost in the network. However, if the client player can detect the data loss early enough, it can request a retransmission. A transmission schedule with a high percentage of client buffer occupancy usually implies that there is a high probability the client player will detect the data loss early.
We simulate the transmission of four 40 000-frame MPEG video clips [21]. Table I shows some statistics of these streams. First, we explore how the two metrics, the initial delay ( fram-etimes) and the client buffer size ( kB), change as a function. We then compare the performance of the proposed algorithms
to when the initial delay is small.
looks ahead frames to compute the transmission schedule, i.e. . We can see that indeed computes the same transmission schedule as . However, the time
com-plexity of is only of . In [10] and [11],
Sen et al. have shown that consistently outper-forms . To demonstrate the lower bound of the peak rate, the graph also plots the optimal transmission schedule ob-tained by the offline algorithm presented in [1].
A. Client Buffer Size and Initial Delay
Using Star Wars as the test video, Fig. 11 illustrates the performance of the three proposed algorithms ,
and . Generally speaking, the client buffer size limits the maximum data that can be workahead transmitted to the client. If the client buffer is small, smoothing algorithms cannot transmit media data in advance of the burst. As the client buffer is enlarged and more data can be transmitted in advance, the transmission rate can be reduced. High client buffer occupancy shows that most media data arrives at the client much earlier than its playback time. However, enlarging the client buffer beyond a certain value does not help smoothing algorithms to reduce the peak rate. When the client buffer is comparatively huge with the initial delay, the client buffer occupancy also starts falling.
When the initial delay is small, there are few frames in the server buffer. Consequently, the benefit from a large client buffer is not significant. As shown in Fig. 11, when the initial delay is smaller than 72 frametimes, using a client buffer larger than 512 kB does not help the three algorithms to further reduce the peak rate. Since there is little data to be buffered, the client buffer oc-cupancy falls rapidly as the client buffer is enlarged. Heuristics play an important role when the initial delay is small. We will discuss this in more detail in the next subsection.
As the initial delay increases, the benefit from a large client buffer becomes apparent. A large initial delay gives the video server more time to transmit any frame, and thus the peak rate is reduced. In such cases, there is a high probability that , , and will deterministically compute the trans-mission schedule at any time. Heuristics, therefore, have little impact on reducing the peak rate. For example, when the ini-tial delay is 360 or 720 frametimes, the peak rate computed by , and is almost the same for variant client buffer sizes. Even so, aggressive workahead utilizes the client buffer more efficiently. utilizes 60% to 80% of the client buffer. However, only achieves 40% to 60% while achieves 40% only when client buffer is smaller than 1024 kB.
When the initial delay is comparatively large with the client buffer size, the three algorithms always deterministically com-pute the transmission schedule. Heuristics are, therefore, never used. The three algorithms compute the same transmission schedule, for example, when the initial delay is 3600 or 7200 frametimes and the client buffer is smaller than 2048 kB.
B. Heuristics and Initial Delay
In this subsection, we further compare the performance of on-line traffic-smoothing algorithms when the initial delay is small. In such cases, online traffic-smoothing algorithms lack the in-formation to deterministically compute a transmission schedule most of the time. Heuristics play an important role. Since large client buffers do not have significant impacts, we choose two client buffer sizes that are slightly larger than the double and triple of the maximal frame size. In real applications, the system
Fig. 13. Peak bandwidth and client buffer utilization of transmission schedules for Star Wars when initial delays are small.(B = 384 kB).
may determine this value according to experiential rules, such as the desired quality of the video. Note that com-putes the same transmission schedule as . Their perfor-mance curves are overlapped in Fig. 12 and 13.
As shown in Fig. 12 and Fig. 13, online traffic-smoothing al-gorithms hardly reduce the peak rate for transmitting Star Wars by enlarging the client buffer from 256 to 384 kB. con-stantly performs better than and in reducing the peak rate and utilizing the client buffer. dramatically re-duces the peak rate when the initial delay is within 12 to 48 frametimes. It reduces the peak rate to 32 kB per frametime when the initial delay is 16 frametimes. Analyzing the frame sizes of Star Wars, there are two bursts close to one another. The second is slightly longer and burstier than the first. If the ini-tial delay is smaller than 48 frametimes, cannot smooth the first burst. It therefore raises the peak rate. Since ag-gressively works ahead and there are less data buffered in the server, it can smooth the second burst. If the initial delay is larger than 48 frametimes, is able to smooth the first burst with a smaller rate. This time, however, cannot smooth the second burst and therefore the peak rate increases.
Experiments on the other video clips show similar trends. Table II gives a brief summary of the improvement of on in rate reduction when the initial delay is small. The results show that the aggressive workahead heuristic sig-nificantly improves the performance of smoothing algorithms, especially for real-time interactive applications.
V. CONCLUSION
In this paper, we first present an efficient traffic-smoothing al-gorithm for live video transmission. Given a client buffer and a playback delay, maintains the candidates for trans-mission schedules in a funnel. Whenever the two chains of the funnel will cross each other, deterministically generates
the transmission schedule. When there is no more frame size in-formation available, heuristically generates the transmis-sion schedule at the minimal rate for the next frametime. The
total time complexity of is . In fact,
gener-ates the same transmission schedule as .
We observe that may lower the transmission rate unnecessarily and then raise the rate in the next transmission schedule. We have used different heuristics to improve .
considers the current transmission rate and aggressively considers the current peak rate. When the initial delay is small, heuristics play an important role. Experiment results show that further reduces the peak bandwidth requirement and better utilizes the client buffer for real-time interactive applications in which the initial delay is small.
In the best-effort service model, media data transmitted across the Internet are normally subject to delay jitter, out-of-order delivery, and packet loss. The working of smoothing algorithms will be seriously impaired if there are errors in the transmission medium. Many error recovery techniques for multimedia streaming have been proposed, such as automatic repeat request (ARQ), forward error correction (FEC), etc. [20]. Since usually generates the transmis-sion schedule with high client buffer occupancy, the media data should arrive at the client much earlier before its playback time. If there is an error, the client can detect the error early and request a retransmission. In such cases, the server may retransmit the data and recompute the funnel. We will further study this problem in the future.
REFERENCES
[1] J. D. Salehi, Z.-L. Zhang, J. Kurose, and D. Towsley, “Supporting stored video: Reducing rate variability and end-to-end resource re-quirement through optimal smoothing,” IEEE/ACM Trans. Network., vol. 6, no. 4, pp. 397–410, Aug. 1998.
[2] W. Feng and S. Sechrest, “Critical bandwidth allocation for delivery of compressed video,” Comput. Commun., pp. 709–717, Oct. 1995. [3] W. Feng, F. Jahaian, and S. Sechrest, “Optimal buffering for the
de-livery of compressed video,” in IS&T/SPIE Multimedia Computing and
Networking (MMCN), San Jose, CA, 1995, pp. 234–242.
[4] R. I. Chang, M. Chen, M. T. Ko, and J. M. Ho, “Optimization of stored VBR video transmission on CBR channel,” in SPIE Voice, Video, and
Data Communications (VVDC) Symp., 1997, pp. 382–392.
[5] R. I. Chang, M. Chen, M. T. Ko, and J. M. Ho, “Designing the on-off CBR transmission schedule for jitter-free VBR media playback in real-time networks,” in Proc. IEEE Real-Time Computinmg Systems and
Applications (RTCSA) Conf., 1997, pp. 1–9.
[6] J. M. McManus and K. W. Ross, “Video on demand over ATM: con-stant-rate transmission and transport,” in Proc. IEEE INFOCOM, San Francisco, CA, Mar. 1996.
[7] J. M. McManus and K. W. Ross, “Dynamic programming methodology for managing prerecorded VBR sources in packet-switched networks,” in SPIE Voice, Video, and Data Communications (VVDC) Symp., Univ. Pennsylvania, 1997.
[8] M. Grossglauser, S. Keshav, and D. Tse, “RCBA: a simple and efficient service for multiple time-scale traffic,” in Proc. ACM SIGCOMM, Aug. 1995, pp. 219–230.
[9] W. Feng and J. Rexford, “A comparison of bandwidth smoothing tech-niques for the transmission of prerecorded compressed video,” in Proc.
IEEE INFOCOM, Apr. 1999, pp. 58–66.
[10] J. Rexford, S. Sen, J. Dey, W. Feng, J. Kurose, J. Stankovic, and D. Towsley, “Online smoothing of live, variable-bit-rate video,” in Proc.
International Workshop on Network and Operating Systems Support for Digital Audio and Video, May 1997, pp. 249–257.
[11] S. Sen, J. L. Rexford, J. K. Dey, J. F. Kurose, and D. F. Towsley, “On-line smoothing of variable-bit-rate streaming video,” IEEE Trans.
Mul-timedia, vol. 2, no. 1, pp. 37–48, Mar. 2000.
[12] R. I. Chang, M. C. Chen, J. M. Ho, and M. T. Ko, “An effective and efficient traffic smoothing scheme for delivery of online VBR media streams,” in Proc. IEEE INFOCOM, Mar. 1999, pp. 447–454. [13] G. Cao, W. Feng, and W. Singhal, “Online VBR video traffic
smoothing,” in Proc. 8th IEEE Int. Conf. Computer and
Communica-tion and Networks, Oct. 1999, pp. 502–507.
[14] D. T. Lee and F. P. Preparata, “Euclidean shortest path in the presence of rectilinear barriers,” Networks, vol. 14, pp. 393–410, 1984. [15] M. Garrett and W. Willinger, “Analysis, modeling and generation of
self-similar VBR video traffic,” in Proc. ACM SIGCOMM, London, U.K., Sep. 1994.
[16] M. Krunz and S. K. Tripathi, “On the characteristics of VBR MPEG streams,” in Proc. ACM SIGMETRICS, Jun. 1997, pp. 192–202. [17] A. Ads, “Supporting real-time VBR video using dynamic reservation
based on linear prediction,” in Proc. IEEE INFOCOM, Mar. 1996, pp. 1476–1483.
[18] S. Crosby, M. Huggard, I. Leslie, J. Lewis, B. McGurk, and R. Russell, “Predicting bandwidth requirement of ATM and ethernet traffic,” in
Proc. IEE UK Teletraffic Symp., Manchester, U.K., Mar. 1996.
[19] E. Amir, S. McCanne, and H. Zhang, “An application level video gateway,” in Proc. ACM Multimedia, San Francisco, CA, Nov. 1995. [20] G. Carle and E. W. Biersack, “Survey of error recovery techniques for
IP-based audio-visual multicast applications,” IEEE Network, vol. 11, no. 6, pp. 24–36, Nov./Dec. 1997.
[21] [Online]. Available: http://www3.informatik.uni-wuerzburg.de/ MPEG/traces/
Jeng-Wei Lin received the B.S. degree in computer
information science from National Chiao-Tung Uni-versity, Hsinchu, Taiwan, R.O.C., in 1994, and the M.S. and Ph.D. degrees in computer science and in-formation engineering from National Taiwan Univer-sity, Taipei, Taiwan, in 1996 and 2005, respectively.
He joined the Department of Information Man-agement, Tunghai University, Taichung, Taiwan, in 2005. From 1996 to 2005, he was a Research Assistant with the Institute of Information Science, Academia Sinica, Taipei, and was then promoted to Postdoctoral Researcher. His research interests include multimedia systems, traffic management, and other areas in networking.
Ray-I Chang (M’96) received the Ph.D. degree in
electrical engineering and computer science from National Chiao-Tung University, Hsinchu, Taiwan, R.O.C., in 1996.
He then joined the Computer Systems and Communications (CSCL) Laboratory, Institute of Information Science, Academia Sinica. In 2003, he joined the Department of Engineering Science, National Taiwan University, Taipei.
Jan-Ming Ho (M’90) received the Ph.D. degree in
electrical engineering and computer science from Northwestern University, Evanston, IL, in 1989 and the B.S. degree in electrical engineering from National Cheng-Kung University, Tainan, Taiwan, R.O.C., in 1978, and the M.S. degree from the Insti-tute of Electronics, National Chiao-Tung University, Hsinchu, Taiwan, in 1980.
He joined the Institute of Information Science, Academia Sinica, Taipei, Taiwan, as an Associate Research Fellow in 1989, and was promoted to Research Fellow in 1994. He visited IBM T. J. Watson Research Center, Yorktown Heights, NY, in the summers of 1987 and 1988, the Leonardo Fibonacci Institute for the Foundations of Computer Science, Trento, Italy, in the summer of 1992, and the Dagstuhl-Seminar on “Combinatorial Methods for Integrated Circuit Design”, IBFI-Geschäftsstelle, Schloß Dagstuhl, Fach-bereich Informatik, Universität des Saarlandes, Germany, in October 1993. He is currently Director General, Division of Planning and Evaluation, National Science Council, Taiwan. His research interests include web mining, video streaming, and combinatorial optimization.
Feipei Lai (SM’92) received the B.S.E.E. degree
from National Taiwan University (NTU), Taipei, Taiwan, R.O.C., in 1980, and the M.S. and Ph.D. degrees in computer science from the University of Illinois at Urbana-Champaign in 1984 and 1987, respectively.
He is a Professor in the Department of Electrical Engineering and in the Department of Computer Science and Information Engineering, NTU. He is also the Director of the Computer and Information Network Center at NTU, and the Vice Superinten-dent of NTU Hospital. His current research interests are low-power circuit design, high-performance microprocessor chip design, computer architecture, optimizing compilers, VLSI design, MPEG4 design, and cryptography.
Dr. Lai is included in Who’s Who in Science and Engineering and Who’s Who
