7

Click here to load reader

HAVS: hybrid adaptive video streaming for mobile devices

  • Upload
    chuck

  • View
    218

  • Download
    3

Embed Size (px)

Citation preview

Page 1: HAVS: hybrid adaptive video streaming for mobile devices

210 IEEE Transactions on Consumer Electronics, Vol. 60, No. 2, May 2014

Contributed Paper Manuscript received 04/01/14 Current version published 06/23/14 Electronic version published 06/23/14. 0098 3063/14/$20.00 © 2014 IEEE

HAVS: Hybrid Adaptive Video Streaming For Mobile Devices

Jaehyun Hwang, Member, IEEE, Junghwan Lee, Nakjung Choi, Member, IEEE, and Chuck Yoo, Member, IEEE

Abstract — This paper presents a new Scalable Video

Codec (SVC)-based hybrid adaptive video streaming scheme, named HAVS, for mobile devices in wireless environments. The proposed approach takes two existing video streaming technologies, viz., progressive download and adaptive streaming, and switches them in a hybrid manner. To this end, HAVS employs the H.264/SVC encoding scheme, where each video chunk is encoded into one base layer and several enhancement layers. Since clients request the base layer every time a video is streamed, HAVS performs progressive download for the base layer and adaptive streaming for the enhancement layers. Through wireless test-bed experiments, it is demonstrated that the proposed scheme can be easily implemented on mobile devices without any server-side modification. This scheme effectively prevents video freeze thereby providing better quality video streaming than the existing non-hybrid streaming technologies1.

Index Terms — Hybrid Adaptive Video Streaming, Dynamic Adaptive Streaming, Progressive Download, Video Freeze

I. INTRODUCTION

Streaming video from Internet has been a key application in mobile CE devices. Its traffic continues to grow rapidly. According to [1], consumer Internet video traffic will constitute 69% of the entire consumer Internet traffic by 2017, up from 57% in 2012. This increase in Internet video traffic is mostly due to widespread use of mobile hand-held devices such as smart phones, tablets, etc. Therefore, it is important to design an efficient streaming method, especially for mobile devices.

Recently, the Hypertext Transfer Protocol (HTTP) [2]-based adaptive streaming has emerged as a state-of-the-art technology for video delivery. This technology dynamically adjusts the quality of a video stream to create richer user

1This work was supported by the Seoul R&BD Program (WR080951)

funded by the Seoul Metropolitan Government, and the National Research Foundation of Korea (NRF) grant funded by the Korea Government (MEST) (No.2010-0029180).

Jaehyun Hwang is with Bell Labs, Alcatel-Lucent, Seoul, Korea (e-mail: [email protected]).

Junghwan Lee is with the Department of Computer Science and Engineering, Korea University, Seoul, Korea (e-mail: [email protected]).

Nakjung Choi is with Bell Labs, Alcatel-Lucent, Seoul, Korea (e-mail: [email protected]).

Chuck Yoo is with the Department of Computer Science and Engineering, Korea University, Seoul, Korea (e-mail: [email protected]).

experience. The success of this HTTP-based adaptive streaming scheme is attributed to several interesting features. First, since the scheme uses HTTP, it is transparent to network address translation boxes and proxies, which guarantees high penetration. Second, it delivers smooth video playback to heterogeneous devices even in dynamic network conditions.

However, the existing video streaming technologies assume wired Internet environments whereas the mobile devices access Internet through wireless networks, such as Wireless LAN (WLAN) or cellular networks. Wireless channel contention can lead to frequent changes in the availability of wireless network bandwidth. Consequently, the mobile end-user’s experience can diminish due to adaptation failure or video freeze. To address these problems, this paper proposes a new Scalable Video Codec (SVC)-based Hybrid Adaptive Video Streaming scheme, named HAVS, for mobile devices. The basic idea of HAVS is to exploit two existing HTTP-based video streaming technologies, viz., progressive download and adaptive streaming. HAVS activates these technologies in a hybrid manner to derive maximum advantage of both the technologies. For this purpose, HAVS employs the H.264/SVC encoding scheme [3]-[5], where each video chunk is encoded into one base layer and several enhancement layers. Since clients request the base layer every time a video is streamed, HAVS performs progressive download for the base layer and adaptive streaming for the enhancement layers.

This study is an extended version of the previous work [6], which was based on a simple design and evaluated only by network simulations. This study makes following three contributions,

Previous studies related to recent adaptive streaming technologies are thoroughly examined and compared. The extended scheme is revised to include (i) two streaming modes, viz., Progressive-Download (PD) mode and Hybrid mode, and (ii) a novel mode selection algorithm to switch between the two modes. The proposed scheme has been implemented and evaluated on a wireless test-bed.

Through the wireless test-bed experiments, it is

demonstrated that the proposed scheme (i) is easily implemented on mobile devices without any server-side modification, (ii) effectively prevents video freeze, and (iii)

Page 2: HAVS: hybrid adaptive video streaming for mobile devices

J. Hwang et al.: HAVS: Hybrid Adaptive Video Streaming For Mobile Devices 211

provides better quality video streaming than the existing non-hybrid streaming technologies.

The rest of this paper is organized as follows. Section II reviews previous studies on current video streaming technologies and motivates our work. Then Section III describes the proposed video streaming scheme in detail. The experimental evaluation of the proposed scheme is provided in Section IV. Finally, Section V concludes this paper.

II. BACKGROUND AND MOTIVATION

This section initially describes a brief background on current video streaming technologies, including the two video delivery methods used in the proposed scheme, and then explains the motivation of this research.

A. Progressive Download and Adaptive Streaming

Based on the success of the HTTP, the recent video delivery technologies are categorized into two types: (i) progressive download and (ii) adaptive streaming. Many online content providers serve video content through the web so that the end-users download the content using HTTP. They also enable the end-users, i.e., consumers, to play the downloaded part immediately even when the entire file is not downloaded. This technique called progressive download is still widely used in many web sites. The disadvantage of this scheme is that the end-users have to select the video streaming quality, e.g., 200Kbps or 300Kbps or 500Kbps. Once the quality is selected, it is fixed for the entire playback. Clearly, this is not a novel approach since the current network bandwidth that determines the highest quality video that can be played seamlessly, is usually unavailable to the end-users. The available bandwidth may be larger than the selected quality, which will result in bandwidth under-utilization. On the other hand, if a user selects high quality then the requested bandwidth may not be available thereby leading to frequent video freeze.

This mismatch between the user quality selection and the network bandwidth leads to a new streaming technology, Dynamic Adaptive Streaming over HTTP (DASH) [7]. DASH adjusts the video quality to the most appropriate one on a moment-by-moment basis, based on the current network condition. More specifically, in the DASH framework, a video is encoded at multiple bitrates, i.e., quality levels. Typically a video is available in 7–10 different quality levels ranging from 150Kbps for mobile devices to 6Mbps for high definition. Each encoding is divided into several video chunks2, typically between 2–30 seconds duration. The information about available video streams, their encodings, chunk durations, etc. is described in a Media Presentation Description (MPD) file. This file is requested by the clients at the start of video streaming. Armed with this information, the client requests appropriate video chunks one by one using HTTP requests.

2 To decode each video chunk independently at the client, it usually starts

with a key frame and consists of one or more closed groups of pictures (GOPs).

Whenever each chunk is downloaded, the client measures the network bandwidth and runs a Rate Determination Algorithm (RDA), in order to determine the quality level of the next video chunk.

Since there is no standard for the RDA, many different RDAs have been proposed and developed. For example, Akhshabi et al [8] conducted an experimental evaluation of three adaptive streaming players to compare their RDAs. Famaey et al [9] explained a well-designed RDA, which is based on the network bandwidth and the status of client’s play-out buffer as shown in Fig. 1.

q = 0 state = BUFFERING On receiving a video chunk: if state == BUFFERING then q = calculate quality according to bandwidth if buffer ≥ U+L/2 then state = STEADY else if state == STEADY then if buffer starvation || buffer < P then q = 0 state = BUFFERING else if BufferSlowlyChanging then if buffer < L then q = q – 1 else if buffer > U then Attempt to increase quality else if BufferDecreasing && buffer < L then q = 0 state = BUFFERING else Attempt to increase quality Request the next chunk at quality q

Fig. 1. Example of RDA that is based on the network bandwidth and the status of the play-out buffer [9]. Three thresholds are used here: a lower threshold L, an upper threshold U, and a panic threshold P.

The main idea behind this RDA is that, when the buffer

occupancy level is low (i.e., BUFFERING state), the next bitrate is mostly determined by the network bandwidth. If the buffer eventually becomes high, above a certain threshold (i.e., STEADY state), the RDA may select a higher bitrate than the network bandwidth, playing back the video chunks from the buffer.

B. SVC-based Adaptive Streaming

Traditionally, the H.264/AVC (Advanced Video Coding) has been used for the encoding process in the DASH solution. However, it is known that this encoding scheme usually introduces significant amount of content redundancy across different quality levels, requiring a large size of storage [10]. To remove this redundancy, the SVC-based adaptive streaming has been proposed [10], [11]. In the SVC encoding scheme, each video chunk is encoded into one base layer and several enhancement layers as shown in Fig. 2. The base layer is mandatory for playback of the video chunk whereas the enhancement layers are optional. The quality of each video chunk increases as the enhancement layers are sequentially requested and stacked on top of the base layer. This fine-grained adaptation allows the client to react to bandwidth

Page 3: HAVS: hybrid adaptive video streaming for mobile devices

212 IEEE Transactions on Consumer Electronics, Vol. 60, No. 2, May 2014

oscillations quickly since the base layer, i.e., the lowest quality layer, is always requested first. Therefore, the SVC-based adaptive streaming is able to keep the buffer occupancy level very stable.

New adaptation algorithms have been proposed within the SVC-based adaptive streaming framework. Andelin et al [12] proposed a sloping-based SVC heuristic for the RDA. One advantage of the SVC-based approach is that the client can request any enhancement layers for the video chunks stored in the buffer. In other words, the client can either: (i) pre-fetch (download the base layer for future video chunks) or (ii) backfill (download the enhancement layer for the current video chunks). A sloping-based heuristic is defined for this purpose where more backfilling is performed if the slope is steeper, whereas more base layers of new video chunks are downloaded if the slope is flatter. However, this method assumes the rate (bandwidth) distribution is available in advance to determine the slope. Currently there is no dynamic slope adjustment scheme available.

Lee et al [13] proposed a SVC-based adaptation algorithm that effectively avoids video freeze. This algorithm introduces a drop timer so that the download of the enhancement layers of each video chunk can be stopped when the timer expires. In this manner, the algorithm prevents the client’s buffer from draining. However, this method is designed for in-network caching environments such as Content Delivery Networks (CDN) or Content-Centric Networking (CCN) [14], where the network bandwidth can be significantly over-estimated because of the cache effect.

Video Contents

Video chunk

1. Start with Q1 (the lowest bitrate)

2. Increase quality level (Q2)

3. Increase quality level (Q3)

4. Decrease quality level (Q2)

AVC

SVC

AVC

SVC

DASH-Server DASH-Client

(Kbps)BL

E1

E2

Q1

Q2

Q3

AVC SVC

1000

Q3

500

Q2

300

Q1

BLBL

E1

BL

E1

BL

E1

E2

Play TimeT+3T+2T+1T

1. Start with BL (the lowest bitrate)2. Increase quality level (BL and E1)3. Increase quality level (BL, E1, and E2)4. Decrease quality level (BL and E1)

Play TimeT+3T+2T+1T

500

300

1000(Kbps)

321 NN-1

BL

E1

E2

BL

E1

E2

BL

E1

E2

BL

E1

E2

BL

E1

E2

321 NN-1

500

300

1000

(Kbps)

Fig. 2. AVC vs. SVC: AVC-based encoding scheme generates several independent video files as many as the number of video quality level, whereas SVC-based approach can cover all video quality levels with one video encoding, generating one base layer (BL) and multiple enhancement layers (E1, E2, and so forth) for each video chunk.

C. Adaptive Streaming over Wireless Networks

Mobile hand-held devices are gaining popularity. Consequently, some studies have focused on video adaptation over wireless environments. Riiser et al [15] made a comparison of the existing adaptive video streaming solutions on a mobile 3G network. Their main finding was that the

quality of the scheduler has a large impact on the quality of experience. Previous solutions had different adaptation policies, so there was no RDA that can satisfy all of the important goals such as avoiding buffer under-runs and avoiding rapid oscillations in quality.

Vleeschauwer et al [16] proposed an Adaptive Guaranteed Bitrate (AGBR) algorithm, which optimizes the performance of the adaptive streaming at the base station. This algorithm calculates the target bitrate of each streaming flow by formulating a utility maximization problem. Following this, the calculated bitrates are passed on to the underlying minimum rate proportional fair scheduler that manages wireless channel resources across all the flows. This study showed that the AGBR algorithm achieves required fairness among the streaming flows and never starves the mobile clients. However, there can still be a deployment problem since the algorithm is required to be implemented on the infrastructure, i.e., base stations.

D. Motivation on Hybrid Streaming for Mobile Devices

Unlike the high-speed fixed networks, the availability of network bandwidth is rarely stable in mobile wireless networks. Because of the bandwidth oscillation, the RDA may fail to estimate the current network condition accurately, causing video freeze. However, it is not easy to develop an RDA that always works well in mobile wireless networks [15]. Therefore, a new streaming model that is less affected by the RDA performance is needed in such unstable mobile environments. Indeed, research is highly motivated by the insight that it is of outmost importance to first download the base quality of video chunks in the most efficient way and not the RDA itself. An effective way for achieving this goal is to utilize the progressive download, which requires only one request message while streaming. In addition, the download speed is not limited by the play-out buffer size because the streaming is regarded as an HTTP file download.

While the progressive download is extremely efficient and useful for downloading the base quality video chunks, the new scheme still needs to be adaptive. For this reason, this study takes a hybrid approach, which performs progressive download for the base layers and adaptive streaming for the enhancement layers using the SVC. In the following section, the design of the proposed scheme is explained in detail.

III. HAVS: HYBRID ADAPTIVE VIDEO STREAMING

In this section, first the overall architecture of the proposed hybrid scheme, HAVS, is described. Following this, the mode selection algorithm, a key component of HAVS, is explained.

A. Overall Architecture

As described in Section I, the proposed scheme employs H.264/SVC encoding to separate the base layer and the enhancement layers in each video chunk. It is assumed that the client initially downloads a MPD file from the media server to obtain complete information about the video stream.

Page 4: HAVS: hybrid adaptive video streaming for mobile devices

J. Hwang et al.: HAVS: Hybrid Adaptive Video Streaming For Mobile Devices 213

HAVS supports two streaming modes: (i) Progressive-Download mode and (ii) Hybrid mode. HAVS starts with the PD mode and then switches between the two modes depending on the network condition. The mode selection algorithm is explained in the following subsection.

In the PD mode, it should be possible to download all base layers by sending a single HTTP request. To this end, it is assumed that the base layers are all merged into a single file and stored on the server prior to streaming. This base quality video file is then progressively downloaded and stored onto secondary storage devices such as hard disks or flash memory cards. As there is no buffer limitation for the progressive download, the download can be performed independently of the status of the adaptive streaming buffer. Furthermore, since PD does not need to send a request message for every single video chunk download, the download time will be

significantly reduced—about as much as round-trip timeⅹ

total number of video chunks.

Enhancement layers

E3 E3E3 E3

E1E1E1 E1

BLBLBLBL

E2E2 E2E2

Base layers

Server side

E3

E1E1E1

BLBLBLBL

E2E2

Secondary storage

Client side

Streaming

buffer

Progressive download

Adaptive streaming

Fig. 3. Video streaming in the Hybrid mode: The base layer is progressively downloaded during the first request, and the enhancement layers are requested one by one through the Rate Determination Algorithm.

In the Hybrid mode, the client starts adaptive streaming by

sending multiple HTTP requests for enhancement layers while performing the progressive download in parallel, as shown in Fig. 3. In adaptive streaming mode, the basic behavior of the Hybrid mode scheme is identical to that of SVC-based DASH solution except that the first enhancement (E1) layer is considered as the base layer. In other words, the hybrid mode’s lowest quality level is E1 since the actual base layer (BL) is downloaded through progressive download. Therefore, even if the streaming buffer becomes empty, the playback of the current video chunk will not stop if the corresponding base layer is available from progressive download. This effectively avoids the problem of video freeze.

B. Mode Selection Algorithm

The mode selection algorithm decides when to switch between the two modes. The underlying design principle is that the streaming always starts in PD mode, and then switches to Hybrid mode when sufficient network bandwidth is available to download enhancement layers. For this purpose, two main variables are defined: play_chunk and target_chunk. The play_chunk indicates the video chunk that is currently being played back on the screen. The target_chunk is the

starting chunk for adaptive streaming, and is defined as play_chunk + 2. For example, if the play_chunk is 10, i.e., the client is playing back the 10th video chunk, and the streaming mode is switched to Hybrid, then the target_chunk is 12. The client activates the adaptation with the enhancement layers of the 12th video chunk.

Fig. 4 depicts the flow chart of the mode selection algorithm. As per the algorithm, first PD mode is explicitly turned on, which indicates that progressive download is now active. During the download, current Download Bandwidth (DBWpd) is measured for each video chunk. Although the base layer is downloaded as a file, the client can recognize the boundary of each chunk by counting the size of received data. This is possible because the size of each chunk in the base layer is available in advance through the MPD file. If DBWpd is at least as much as the bitrate of E1 then the mode is switched to Hybrid. There is another option to switch to Hybrid mode even if DBWpd is not enough. If a large number of base layer for future video chunks have already been downloaded through PD then the algorithm allows the client to switch to Hybrid mode. More specifically, if (received_chunk – play_chunk) is greater than the streaming buffer size in time (seconds), the mode will be switched, assuming that sufficient playback time is secured. Finally, if the received chunk is the last one, i.e., PD is complete, the algorithm switches to Hybrid mode by explicitly turning off PD mode. In this case, the algorithm does not need to switch back to the PD mode.

On receiving a video chunk

Measure DBWpd

DBWpd >= E1 of target_chunk

received_chunk– play_chunk >=

buffer sizeSwitch to Hybrid

Last chunk?

Yes

Yes

Yes

No

No

No

Request E1 oftarget_chunk

Buffer <= 0

Rate adaptationwith RDA

Is PD_mode on?

PD_mode = off

PD_mode = on

Yes

No

No

Switch to PD

Yes

<PD mode> <Hybrid mode>

Fig. 4. Mode selection algorithm: the client always starts in PD mode and switches between the two modes. In both modes, progressive download is always performed.

Hybrid mode begins by requesting E1 of the target chunk as

shown in the right side of Fig. 4. Following the download of the target_chunk, the rate adaptation is performed with RDA. This is done only for the enhancement layers. The primary condition to switch to PD mode is when the streaming buffer becomes empty, which indicates that the network bandwidth is

Page 5: HAVS: hybrid adaptive video streaming for mobile devices

214 IEEE Transactions on Consumer Electronics, Vol. 60, No. 2, May 2014

not enough for video quality enhancement. However, even though the buffer is empty, the mode is not switched if PD for the base layer is already completed, i.e., PD mode is off. In this case, the adaptation restarts with E1 of the target_chunk as the video is played back with the base layer of the play_chunk.

C. Rate Determination in Hybrid mode

In Hybrid mode, the quality level of video chunks is mainly determined by the available download bandwidth. Let Q = {q1, q2,···, qn} be a set of available video quality levels extracted from the MPD file, assuming q1 indicates the lowest bitrate, i.e., E1, and qn is the highest. For rate determination, the download bandwidth for the requested enhancement layers is measured for the ith chunk, DBWi, as follows,

/i i iDBW ChunkSize t (1)

where ChunkSizei is the size of data of all the requested enhancement layers of the ith video chunk (i = 1, 2, 3, …) and ti is its download time. Now, the quality level for the ith chunk, xi is obtained as follows,

1

1max :

, 1

1,iiy y Q y D

q i

iBWx

(2)

The RDA starts with q1 for the first target video chunk.

After that, the bitrate for the next video chunk is determined from the download bandwidth of the previous video chunk. For example, if Q = {221Kbps, 429Kbps, 683Kbps} and DBWi-1 is 500Kbps, then the next selected bitrate, xi, would be 429Kbps.

In addition to this basic RDA, this study adopts the buffer-based RDA [9] (Fig. 1), which considers the buffer occupancy level for rate determination, in order to encompass the case where the buffer occupancy level is sufficiently large. That is, there could be a room for increasing the video quality level even if the network bandwidth is not enough. Thus, this buffer-based RDA is a good complement to the proposed basic RDA.

IV. EXPERIMENTS

For evaluation, HAVS was implemented on mobile clients and compared with the AVC and SVC-based DASH schemes [7], [10]. For fair comparison, the same RDA was used in all schemes.

A. Test-bed Setup

The wireless test-bed for the experiments is shown in Fig. 5. Six mobile clients equipped with a WLAN interface are deployed on a network and attached to the same Access Point (AP). The maximum wireless link rate is 11Mbps. The available bandwidth between the AP and the media server is controlled via Dummynet [17]. All clients request the same video content stored in the media server.

Fig. 5. Wireless test-bed for the experiments.

The video content is encoded by JSVM (version 9.19.14) [18], an open source-based SVC encoder, and five quality levels are generated, which are 221Kbps, 429Kbps, 683Kbps, 1050Kbps, and 1503Kbps, i.e., there is one base layer and four enhancement layers. In HAVS, the base layer is downloaded through PD, and the four enhancement layers are requested by adaptive streaming in Hybrid mode. The length of each video chunk is two seconds and the number of video chunks is 248, i.e., the total playback time is 496 seconds. The streaming buffer size is 20 seconds, i.e., 10 chunks.

B. Behavior of HAVS

To examine the behavior of HAVS first, the variation of the requested bitrate is measured with a client as shown in Fig. 6. At the beginning, HAVS starts in PD mode and stays until chunk 41 since the available bandwidth is not enough to activate Hybrid mode during this period. Note that SVC-DASH experiences video freezes at chunks 14-29. The main reason is that SVC-DASH is not able to download more than the buffer size, which results in buffer underflow, where HAVS downloads the base-layered chunks as many as possible in PD mode. After the bandwidth becomes enough, HAVS switches to Hybrid mode and PD is done around chunk 45. At this point, HAVS performs only adaptive streaming for the enhancement layers and experiences no video freeze as all base layers are already downloaded. Thus it provides better video quality at chunks 63-100. SVC-DASH suffers from the video freeze again at chunks 79-90 as the available bandwidth is smaller than the lowest video quality.

0

500

1000

1500

2000

2500

1 11 21 31 41 51 61 71 81 91

Bit

rate

(Kb

ps)

Video chunk #

Available Bandwidth

SVC-DASH

HAVS

HAVS: PD_mode= Off

SVC-DASH: video freeze(chunk #: 79-90)

HAVS: PD mode

HAVS:Hybrid mode

SVC-DASH: video freeze

(chunk #:14-29)

Fig. 6. Behavior of HAVS: PD mode starts at chunk 1 and Hybrid mode is activated at chunk 41.

Page 6: HAVS: hybrid adaptive video streaming for mobile devices

J. Hwang et al.: HAVS: Hybrid Adaptive Video Streaming For Mobile Devices 215

C. Video Freeze

From now, video performance for three streaming schemes is measured, increasing the number of clients from 1 to 6. In addition, the available bandwidth is temporarily reduced to 400Kbps for 10 seconds every one minute, which emulates heavy network congestion.

The first performance metric is video freeze, which is directly related to user experience. In Table I, it is observed that the existing AVC and SVC-DASH schemes show poor performance in terms of the number of video freezes as the number of client increases. The total number of video freezes was 126 when the number of clients was 6. The reason why SVC-DASH is better than AVC-DASH is that SVC-DASH can play back video chunks as long as the base layer is downloaded whereas AVC-DASH has to download a complete video chunk for the requested quality level. On the other hand, HAVS achieves zero video freezes with 4 or less clients by efficiently downloading the base layers through PD. Even when there are 6 clients, the number of freezes was 53.

TABLE I

TOTAL NUMBER OF VIDEO FREEZES

Number of clients 1 2 3 4 5 6

AVC-DASH 0 0 10 47 145 126

SVC-DASH 0 5 2 4 24 126

HAVS 0 0 0 0 3 53

Fig. 7 shows the total video freeze time. In fact, the

duration of each video freeze is usually different, depending on the network condition. Generally, the video freeze time will increase if it takes a long time to download the next video chunk during the video freeze. In Fig. 7, it is observed that the total video freeze time of AVC and SVC-DASH schemes can increase up to 518 seconds and 450 seconds respectively. In contrast, HAVS downloads the base layers efficiently to avoid video freeze even when the number of clients is 6, thus it shows relatively short freeze time (about 104 seconds), compared to the existing non-hybrid streaming schemes.

0

100

200

300

400

500

600

1 2 3 4 5 6

Number of clients

Total video freeze time (s)

AVC-DASH

SVC-DASH

HAVS

Fig. 7. Total video freeze time. No freeze occurs with one client.

0

200

400

600

800

1000

1200

1400

1600

1 2 3 4 5 6

Nubmer of clients

Average requested bitrate (Kbps)

AVC-DASH

SVC-DASH

HAVS

Fig. 8. Average video quality (requested bitrate).

D. Average Video Quality

In addition to the video freeze, the average requested bitrate is also measured as shown in Fig. 8. In the figure, HAVS shows better average video quality than the existing adaptive streaming schemes when there is one client on the network. Even with multiple clients, it is observed that the average video quality of HAVS is similar to that of SVC-DASH and slightly better than that of AVC-DASH. That is, HAVS can achieve better quality video streaming by effectively avoiding video freeze.

E. Number of Mode Switching

For HAVS, the number of mode switching between the two modes is measured as shown in Fig. 9. Basically, it is expected that the mode switching will less happen if there is less number of clients, which means that the network bandwidth is less congested. Fig. 9 indicates that when there is one client, the mode is rarely switched while mostly staying in Hybrid mode. As the number of client increases, the client frequently changes the modes to efficiently utilize the available bandwidth.

0

5

10

15

20

25

1 2 3 4 5 6Number of clients

Number of mode switching

Fig. 9. Number of mode switching between the two modes in HAVS.

V. CONCLUSION

This paper proposes a new hybrid adaptive video streaming scheme for mobile devices. In the SVC-based video streaming, the base layer is requested by the clients every time whereas the enhancement layers are optional. In contrast, HAVS

Page 7: HAVS: hybrid adaptive video streaming for mobile devices

216 IEEE Transactions on Consumer Electronics, Vol. 60, No. 2, May 2014

performs progressive download for the base layer and adaptive streaming for the enhancement layers. More specifically, HAVS defines two streaming modes, Progressive-Download mode and Hybrid mode, and switches between the two modes based on the proposed mode selection algorithm.

Through the wireless test-bed experiments, it has been confirmed that HAVS effectively prevents video freeze while not losing overall video quality in wireless environments.

REFERENCES [1] Cisco Systems, Inc., “Cisco visual networking index: forecast and

methodology, 2012-2017,” Cisco White Paper, May 2013. [2] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T.

Berners-Lee, “Hypertext transfer protocol -- HTTP/1.1,” RFC 2616, IETF, Jun. 1999.

[3] H. Schwarz, D. Marpe, T. Wiegand, “Overview of the scalable video coding extension of the H. 264/AVC standard,” IEEE Trans. Circuits Syst. Video Technol., vol. 17, no. 9, pp. 1103-1120, Sep. 2007.

[4] J.-H. Lee and C. Yoo, “Scalable ROI algorithm for H.264/SVC-based video streaming,” IEEE Trans. Consumer Electronics, vol. 57, no. 2, pp. 882-887, May. 2011.

[5] Y.-M. Hsiao, C.-H. Chen, J.-F. Lee, and Y.-S. Chu, “Designing and implementing a scalable video-streaming system using an adaptive control scheme,” IEEE Trans. Consumer Electronics, vol. 58, no. 4, pp. 1314-1322, Nov. 2012.

[6] J. Hwang, N. Choi, J. Lee, and C. Yoo, “SVC-based hybrid video streaming in mobile CE devices,” in Proc. IEEE International Conference on Consumer Electronics, Las Vegas, USA, pp. 408-409, Jan. 2014.

[7] T. Stockhammer, “Dynamic adaptive streaming over HTTP –: standards and design principles,” in Proc. ACM Multimedia Systems Conference, San Jose, USA, pp. 133-144, 2011.

[8] S. Akhshabi, A. C. Begen, and C. Dovrolis, “An experimental evaluation of rate-adaptation algorithms in adaptive streaming over HTTP,” in Proc. ACM Multimedia Systems Conference, San Jose, USA, pp. 157-168, 2011.

[9] J. Famaey, S. Latre, N. Bouten, W. V. de Meerssche, B. D. Vleeschauwer, W. V. Leekwijck, and F. D. Turck, “On the merits of SVC-based HTTP adaptive streaming,” in Proc. IFIP/IEEE International Symposium on Integrated Network Management, Ghent, Belgium, pp. 419-426, 2013.

[10] R. Huysegems, B. De Vleeschauwer, T. Wu, and W. Van Leekwijck, “SVC-based HTTP adaptive streaming,” Bell Labs Technical Journal, vol. 16, no. 4, pp. 25-41, Mar. 2012.

[11] Y. Sánchez de la Fuente, T. Schierl, C. Hellge, T. Wiegand, D. Hong, D. De Vleeschauwer, W. Van Leekwijck, and Y. Le Louédec, “iDASH: improved dynamic adaptive streaming over HTTP using scalable video coding,” in Proc. ACM Multimedia Systems Conference, San Jose, USA, pp. 257-264, 2011.

[12] T. Andelin, V. Chetty, D. Harbaugh, S. Warnick, and D. Zappala, “Quality selection for dynamic adaptive streaming over HTTP with scalable video coding,” in Proc. ACM Multimedia Systems Conference, Chapel Hill, USA, pp. 149-154, 2012.

[13] J. Lee, J. Hwang, N. Choi, and C. Yoo, “SVC-based adaptive video streaming over content-centric networking,” KSII Transactions on Internet and Information Systems, vol. 7, no. 10, pp. 430-2447, Oct. 2013.

[14] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, R. L. Braynard, “Networking named content,” in Proc. ACM International Conference on emerging Networking Experiments and Technologies, Rome, Italy, pp. 1-12, 2009.

[15] H. Riiser, H. S. Bergsaker, P. Vigmostad, P. Halvorsen, and C. Griwodz, “A comparison of quality scheduling in commercial adaptive HTTP streaming solutions on a 3G network,” in Proc. ACM Workshop on Mobile Video, Chapel Hill, USA, pp. 25-30, 2012.

[16] D. De Vleeschauwer, H. Viswanathan, A. Beck, S. Benno, G. Li, R.

Miller, “Optimization of HTTP adaptive streaming over mobile cellular networks,” in Proc. IEEE International Conference on Computer Communications, Turin, Italy, pp. 898-997, 2013.

[17] M. Carbone and L. Rizzo, “Dummynet revisited,” ACM SIGCOMM Computer Communication Review, vol. 40, no. 2, pp. 12-20, Mar. 2010.

[18] J. Reichel, H. Schwarz, M. Wien, “Joint scalable video model 9 (JSVM-9),” IEC JTC1/SC29/WG11 and ITU-T SG16 Q.6, Doc. JVT-V202, 2007.

BIOGRAPHIES J. Hwang (M’10) received the B.S. degree in computer science from Catholic University of Korea, Seoul, Korea in 2003, and the M.S. and Ph.D. degrees in computer science from Korea University, Seoul, Korea in 2005 and 2010, respectively. Since September 2010, he has been with the networking research domain at Bell Labs, Alcatel-Lucent, Seoul, Korea as a Member of Technical Staff. His current

research interests include HTTP adaptive streaming, multipath TCP, data center networks, and software-defined networking.

J. Lee received the B.S. degree in computer science from Sungkyul University, Korea in 2007, and the M.S degree in computer science from Korea University, Seoul, Korea in 2009. He is currently the Ph.D. candidate in the Department of Computer Science and Engineering at Korea University, Seoul, Korea. His research interests include scalable video codec, content-centric networking, and HTTP adaptive video streaming.

N. Choi (S’02-M’10) received the B.S. and Ph.D. degrees in computer science and engineering from Seoul National University (SNU), Seoul, Korea, in 2002 and 2009, respectively. From September 2009 to April 2010, he was a postdoctoral research fellow in the Multimedia and Mobile Communications Laboratory, SNU. Since April 2010, he is a member of technical staff at Bell Labs, Alcatel-Lucent,

Korea. His research interests are mobile networks, software defined networking, information centric networking, and green networking.

C. Yoo (M’76) received the B.S. and M.S. degrees in electronic engineering from Seoul National University, Seoul, Korea, and the M.S. and Ph.D. degrees in computer science from University of Michigan, Ann Arbor, USA. He worked as a researcher in Sun Microsystems Laboratory from 1990 to 1995. He is a professor in the College of Information and Communications, Korea University, Seoul,

Korea since 1995. His research interests include operating systems, embedded systems, virtualization, and multimedia streaming.