Dynamic Scheduling on Video Transcoding for MPEGDASH in the Cloud Environment

He Ma1,2, Beomjoo Seo1, Roger Zimmermann1

1School of Computing, National University of Singapore, Singapore 1174172National University of Singapore (Suzhou) Research Institute, 377 Lin Quan Street, Suzhou Industrial Park, Jiang

Su, People’s Republic of China, 215123{mahe,seobj,rogerz}@comp.nus.edu.sg

ABSTRACT

The Dynamic Adaptive Streaming over HTTP (referred asMPEG DASH) standard is designed to provide high qualityof media content over the Internet delivered from conven-tional HTTP web servers. The visual content, divided intoa sequence of segments, is made available at a number ofdifferent bitrates so that an MPEG DASH client can au-tomatically select the next segment to download and playback based on current network conditions. The task oftranscoding media content to different qualities and bitratesis computationally expensive, especially in the context oflarge-scale video hosting systems. Therefore, it is preferablyexecuted in a powerful cloud environment, rather than onthe source computer (which may be a mobile device withlimited memory, CPU speed and battery life). In order tosupport the live distribution of media events and to pro-vide a satisfactory user experience, the overall processingdelay of videos should be kept to a minimum. In this pa-per, we propose a novel dynamic scheduling methodologyon video transcoding for MPEG DASH in a cloud environ-ment, which can be adapted to different applications. Thedesigned scheduler monitors the workload on each processorin the cloud environment and selects the fastest processors torun high-priority jobs. It also adjusts the video transcodingmode (V TM) according to the system load. Experimentalresults show that the proposed scheduler performs well interms of the video completion time, system load balance,and video playback smoothness.

Categories and Subject Descriptors

G.1.0 [General]: Parallel algorithms; G.3 [Probabilityand Statistics]: Statistical computing; I.2.8 [ProblemSolving, Control Methods, and Search]: Scheduling

General Terms

Algorithms, Measurement, Performance

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.MMSys ’14, March 19 - 21, 2014, Singapore, SingaporeCopyright 2014 ACM 978-1-4503-2705-3/14/03 $15.00.

Keywords

DASH, Video transcoding, Scheduling, Cloud computing

1. INTRODUCTIONRecently, Over-The-Top (OTT) streaming, i.e., delivering

video and audio content through the public Internet infras-tructure rather than proprietary infrastructures such as ca-ble networks, has become an active topic in the broadcastingand content delivery communities. OTT in particular refersto content that arrives from a third party, such as Netflixand Hulu, and is delivered to an end-user device, leaving theInternet provider responsible only for transporting packets.The final link to end-users is usually handled with HTTPstreaming, or other proprietary technologies. Consumerscan access OTT content through various Internet-connecteddevices such as desktops, laptops, tablets, smartphones, TVsand gaming consoles (e.g., Xbox 360, PlayStation, Wii).The variety of devices requires the video hosting servicesto provide different bitrates of the original videos.

Moreover, the wide-spread availability of smartphones (andincreasingly tablets) and the rapid improvement of wirelessnetworks (3G/4G, or WiFi) have enabled the possibility ofdaily video streaming through mobile devices. A study fromCisco [8] has indicated that the overall mobile data trafficreached 885 petabytes per month at the end of 2012, 51percent of which is mobile video. Forecasts predict that mo-bile video will grow at a Compound Annual Growth Rate(CAGR) of 75 percent between 2012 and 2017 and reach oneexabyte per month by 2017. An important consideration isthat the bandwidth for mobile devices varies depending onlocation and time. The changes in bandwidth influence thequality of video streaming. For example, assume that allavailable bandwidth of a mobile client is used to watch avideo. When the bandwidth increases, it has the capacityto watch a higher quality video. Conversely, when the band-width decreases, the playback would be interrupted due toinsufficient bandwidth for the current bitrate. Therefore,to guarantee smooth playback and enable streaming of thehighest possible quality, it is essential that media stream-ing can adapt to the current network bandwidth and con-ditions. Dynamic Adaptive Streaming over HTTP (DASH)is designed to provide high quality streaming of media con-tent over the Internet delivered from conventional HTTPweb servers. Figure 1 illustrates the architecture of DASH.Media content is encapsulated into a parallel sequence of seg-ments with a number of different bitrates so that an MPEGDASH client can automatically and seamlessly select thenext segment to download and play back based on current

Figure 1: A general architecture of DASH.

network conditions.YouTube [20] statistics show that over four billion hours

of videos are watched each month and 72 hours of video areuploaded every minute. The popularity of video streaminghas highlighted video transcoding as a challenging problem.In recent years, cloud computing has become an effectiveparadigm for many applications. It is a technology aimed atsharing resources and providing various computing and stor-age services flexibly over the Internet. For multimedia ap-plications and services, there are strong demands for cloudhosting because of the significant amount of computationrequired for serving millions of Internet and mobile userssimultaneously [23]. The complex nature of video transcod-ing (e.g., CPU-intensity) and the high demand requirementsof streaming have enabled cloud computing to be uniquelysuitable for video transcoding, especially in the context oflarge-scale video hosting systems. Therefore, transcoding ispreferably executed in a powerful cloud environment, ratherthan on the source computer (which may be a mobile devicewith limited memory, CPU speed and battery life).In order to support live streaming of media events and

to provide a satisfactory user experience, the overall videotranscoding completion time should be minimized. In therest of the paper we refer to this simply as the video com-pletion time or the completion time. Minimizing the videocompletion time is desirable for several reasons. Obviouslyit is crucial not to exceed the waiting tolerance of clients.Because of the high computational complexity, schedulingvideo transcoding jobs in a cloud environment to minimizethe processing latency and satisfy users’ expectations is achallenging problem. Furthermore, it is important to bal-ance the workloads among all the processing nodes in thecloud. In this paper we propose a dynamic scheduling al-gorithm for DASH video transcoding designed for cloud en-vironments. The scheduler makes use of the estimation of

the video transcoding time (V TT ). Jobs are distributed tofree processors when they are not urgent, but to the fastestprocessors if video watching requests are pending. Exper-imental results show that the scheduler performs very wellin executing video transcoding jobs and balancing the work-load among all the processors. The main contributions ofour method are summarized as follows:

• We introduce a video transcoding time (V TT ) esti-mation, with respect to video segment duration andtargeted bitrates, that is modeled based on measuredstatistics and probabilistic theory.

• We incorportate a job distribution mechanism amongprocessors that achieves load balancing among the pro-cessing resources.

• The scheduler includes workload and status monitor-ing for each processor, and dynamically selects thefastest processors to run high-priority jobs when videoshave pending viewing requests.

• The scheduler dynamically optimizes the video transcod-ing mode (V TM) when the number of processors isinsufficient to support all video watching requests, sothat the processors prioritize transcoding of the re-quested bitrates and leave other bitrates to be pro-cessed later.

The rest of this manuscript is organized as follows. Sec-tion 2 introduces the fundamentals of HTTP and DASHstreaming, as well as cloud video transcoding services andscheduling strategies on parallel video transcoding. Sec-tion 3 models the V TT estimation methodology consideringthe video duration. The scheduling algorithm and evalua-tion metrics are detailed in Section 4. Section 5 presentsthe experimental results and analysis. Finally, Section 6concludes the paper and investigates the future work.

2. BACKGROUND AND RELATED WORK

2.1 HTTP Streaming FundamentalsWith the development of content delivery networks (CDN),

Hypertext Transfer Protocol (HTTP) streaming has emergedas the de-facto streaming standard, replacing the conven-tional streaming with the Real-Time Transport Protocol(RTP) and Real-Time Streaming Protocol (RTSP). Undertypical HTTP streaming, once an client sends a request andestablishes a connection between the server and itself, a pro-gressive media download is activated until the streaming isterminated [19]. Disadvantages of a progressive downloadinclude: (a) unstable conditions of the network, especiallya wireless connection for mobile clients, may cause band-width waste due to reconnection or rebuffering events, (b)it does not support live streaming (e.g., concert or foot-ball match), and (c) it does not support adaptive bitratestreaming. In recent years, streaming platforms such as Mi-crosoft’s Smooth Streaming (MSS) [14], Apple’s HTTP LiveStreaming (HLS) [16], and Adobe’s HTTP Dynamic Stream-ing (HDS) [4], all use HTTP streaming as their underlyingdelivery method and support adaptive streaming as well.The commonalities [18] of these techniques are: (1) split-ting an original encoded video file into small pieces of self-contained media segments, (2) separating the media descrip-tion into a single playlist file, and (3) delivering segmentsover HTTP. Among each other, these techniques differ in thefollowing way: (i) MSS is a compact and efficient method for

the real-time delivery of MP4 files from Microsoft’s IIS webserver, using a fragmented, MP4-inspired ISO Base MediaFile Format (ISOBMFF), (ii) HLS uses an MPEG-2 Trans-port Stream (TS) as its delivery container format and uti-lizes a higher segment duration than MSS, and (iii) HDSis based on Adobe’s MP4 fragment format (F4F) and itscorresponding XML-based proprietary manifest file (F4M).Published in April 2012, DASH [2] addresses the above

weaknesses of simple, progressive HTTP streaming. A videofile is broken into a sequence of small playable HTTP-basedsegments and these segments are uploaded to the standardHTTP server sequentially. The visual content is then en-coded at a variety of different bitrates and the HTTP-clientcan automatically select the next segment from the alterna-tives to download and play back based on current networkconditions. The client selects the segment with the high-est possible bit rate that can be downloaded in time forsmooth and seamless playback, without causing rebufferingevents. DASH standardizes the two most important compo-nents: the Media Presentation Description (MPD) and thesegment formats.

2.2 Video Transcoding Services in the CloudThere exist several cloud services that offer video transcod-

ing. Amazon released their Elastic Transcoder [7] in Jan-uary of 2013. It executes transcoding jobs using Amazon’sElastic Compute Cloud (Amazon EC2 [5]) and stores thevideo content in Amazon’s Simple Storage Service (AmazonS3 [6]). Amazon’s Elastic Transcoder manages all aspectsof the transcoding process transparently and automatically.It also enables customers to process multiple files in paral-lel and organize their transcoding workflow using a featurecalled transcoding pipelines. Zencoder [22] provides videotranscoding services as well. In addition to providing typicalvideo transcoding services in the cloud, it also supports livecloud video transcoding. EncoderCloud [9] also provides thesame web-based “pay-as-you-go” service and helps to buildapplications on top of other service providers (e.g., Ama-zon EC2 and RackSpaceCloud [17]), but offers a differentpricing policy – charging by the volume of the total amountof source video transfered in and encoded video transferedout. These services provide the capability of video transcod-ing in the cloud, but the transcoding scheduling mechanismis transparent to end-users.

2.3 Scheduling StrategiesCloud computing provides tremendous computing resources

for applications but there is no universal “best” schedulingalgorithm. Instead, they are usually optimized for certainapplications. One study [12] introduces a parameter-tuningframework by combining the bitrate and encoding speed asencoding cost and provides a cost optimization method forvideo cloud transcoding. Li et al. [11] proposed a parallelvideo encoding strategy considering a load balance factor.By considering the granularity of the load partitions andthe associated overheads caused, they utilized the divisibleload theory paradigm to distribute the video frames amongprocessors. Zaharia et al. [21] presented a fair job schedulingfor Hadoop to minimize the job response time. Li et al. [13]developed a cloud transcoder that takes the utilization ofCPU into account to help to predict video transcoding tasks.Kllapi et al. [10] presented an optimization of schedulingdataflows on these three aspects: minimizing completion

time, minimizing the monetary cost given a deadline, andfinding the trade-off between completion time and monetarycost. However, these approaches investigate neither the spe-cific properties of DASH (e.g., correlation between segments,alternative bitrates of uploaded segments) nor the interac-tion between the service hosts and the end-users. To the bestof our knowledge, although existing scheduling strategies canbe applied, there exists no specific work on scheduling videoDASH transcoding for cloud environments, especially whileuntranscoded segments already have pending video watch-ing requests.

3. TRANSCODING TIME ESTIMATIONWe first introduce our approach of estimating the video

transcoding time (V TT ) from the original stream to otherqualities, i.e., different bitrates. For DASH, the server needsto prepare multiple bitrates and multiple formats of the orig-inally uploaded videos. Since the time for the video trans-formatting jobs (i.e., transformatting .mp4 files to .ts files)is only a few milliseconds, we focus on scheduling the videotranscoding jobs in this study. Furthermore, preparing theMPD, including the playable file name and its HTTP link,not affecting the performance of the scheduler, is also ig-nored in this paper. Without loss of generality, we considertwo reduced quality streams, namely encoding the originalvideo segments at a medium bitrate (768 kbps with reso-lution of 480×360) and low bitrate (256 kbps with resolu-tion 360×240), respectively. The scheduling algorithm isalso applicable to a larger number of targeted bitrates. Thescheduler will hence distribute video transcoding jobs (V TJ)based on the estimation of V TT . The V TT includes the sumof the following two parts: the time for the file transfer be-tween the storage repository and the processing nodes, andthe time for the actual transcoding procedure. In order tomodel the estimation of V TT given the video duration, wemeasure the actual V TT (denoted as V TTmea) for statisticson a set of video segments in the shared cloud environment,which is also used to run experiments with the syntheticdataset.

3.1 Configuration of the Cloud Environmentand Description of Dataset

The shared cloud environment includes one master nodeand 25 processing nodes. All the nodes are running Cen-tOS 5.5 and can access a shared storage system. The mas-ter node is used to run the scheduler with two quad coreIntelR© XeonR© E5440 2.83 GHz CPUs and 16 GB of mem-ory. The processor nodes used to run V TJs consist of twoquad core IntelR© XeonR© E5620 2.4 GHz CPUs and 24 GBmemory. The dataset includes 11, 194 video segments from339 videos which we collected with Android phones and arecoded in MPEG-4 (2 Mbps with resolution of 720×480).These videos are segmented at the mobile clients and up-loaded to remote servers [18]. For smooth and seamless ren-dering of the segments, each contains an integral number ofGroup-Of-Pictures (GOP). In the configuration of the mo-bile application, the segment durations were chosen as 3, 4or 5 seconds, and the duration of the last segment of eachvideo varies accordingly from about 0.2 second to 6.5 sec-onds. On the remote servers, all the segments are transcodedand transformatted with the open source platform FFm-peg [1].

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

0 1 2 3 4 5 6 7

Vid

eo

tra

nsco

din

g t

ime

(s)

Video duration (s)

low bitratemedium bitrate

low bitrate fitting curvemedium bitrate fitting curve

Figure 2: V TT statistics and the fitting curves todifferent bitrates with respect to video duration.

3.2 VTT Estimation MethodologyIn order to avoid the effect of caching on the V TJs, we

deployed the V TJ for low and medium bitrates on differentprocessors, which could be fully utilized without being oc-cupied by other jobs. To minimize the runtime bias (e.g.,the variability of the connection speed between processorsand the storage repository, and individual processing time)on V TJs, we ran these jobs 10 times across different pro-cessors and calculated the mean values of V TT . Figure 2presents the measured V TT to low and medium bitrates,respectively, as well as the corresponding fitting curves (de-noted as V TTcal), with respect to the video segment du-ration. Compared among all the fitting curves, the powerfitting curve achieves the minimum sum of square. There-fore, tfhe fitting curves can be calculated as formulated inEqn. 1.

V TTcal (dur(VBk) ) = a · (dur(VBk

) )b (1)

where dur(VBk) indicates the video duration, and a and b

are the fitting coefficients. In our current configuration ofthe cloud environment, the values of a and b are shown inEqn. 2:

[a b] =

{[0.796 0.621 ] (low)[1.152 0.700 ] (medium)

(2)

As shown in Figure 2, the actual V TT s are always differ-ent from the value calculated by the fitting curve for mostof the time. In order to match the V TT estimation with themeasurements, we calculate the bias of the measured V TTwith respect to the calculated V TT . The normalized errorfor each V TT is calculated as shown in Eqn. 3:

Terr =V TTmea − V TTcal

V TTcal

(3)

The distributions of the value of Terr follow a Gamma dis-tribution (shown in Eqn. 4):

Prob(Terr) ∼1

θk·

1

Γ(k)· Terr

k−1· e−

Terr

θ (4)

where Terr = round(Terr·100). Overall, we calculate Prob(Terr)over the whole dataset for each individual V TT and com-pute the value of k and θ (Table 1):

k θlow bitrate 8 2.4

medium bitrate 5.8 3.4

Table 1: The coefficients of Gamma distributionused in the shared cloud environment.

Based on this, the estimated V TT can be calculated as:

V TTest = V TTcal + V TTerr = V TTcal(1 + Terr) (5)

Figures 3(a) and 3(b) illustrate the distribution of Terr tolow and medium bitrates, respectively.

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

-15 -10 -5 0 5 10 15

pro

ba

bili

ty

round(Terr*100)

actual distribution

gamma !tting curve

(a) Low bitrate.

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

-15 -10 -5 0 5 10 15

pro

ba

bili

ty

round(Terr*100)

actual distribution

gamma !tting curve

(b) Medium bitrate.

Figure 3: The distribution of Terr in the shard cloudconfiguration.

Ideally, when a processor is not running other jobs, theV TT of a given segment follows the calculation in Eqn. 5.However, due to various reasons (e.g., shared usage of CPUand/or memory, as well as the congestion of the network),the actual V TT might be significantly different from theestimated value. This would affect the performance of thescheduler, especially when processing videos with viewing re-quests. Practically, the scheduler compares the actual V TTwith the estimated value and treats the difference as feedbackfrom the processor that ran the V TJ . The scheduler willthus distribute V TJs, also considering the feedback fromeach of the processors. The detailed scheduling algorithm ispresented in the next section.

4. SCHEDULING ALGORITHMThis section introduces the dynamic scheduling algorithm

for video transcoding with DASH in a cloud environment.Figure 4 shows the overall architecture of the framework.When a video is uploaded to the front-end web server clus-ters (referred to as a job), the server load balancer acceptsthis job and assigns it to a HTTP server for processing withthe consideration of balancing the workload. The HTTPserver then forwards the job of the video transcoding re-quest to the job scheduler and stores the uploaded videoin the video storage repository. The job scheduler assignsjobs once any of the processors is available according to itsscheduling strategy. When a client sends the video retrievalrequest (i.e., for viewing) to the web server, the request willbe forwarded to the specific server for video retrieving. Ifthe required video segment is available, an HTTP connectionis set up between the mobile client and the storage reposi-tory for streaming. Otherwise, the request is converted toa high-priority job for the targeted video and the schedulerimmediately searches for the fastest processor to answer therequest.

4.1 Evaluation MetricsIn the experiment configuration, the HTTP client is also

set up in the same LAN with the cloud, the transmissiondelay between the client and the server is thus assumed tobe zero. The performance of the scheduler can be then eval-uated by the following evaluation metrics, considering theplayback on the client side.

Startup latency (Ls): This metric measures the time in-terval from when the video segment is started to be transcodeduntil the video is available for playback.

Number of quality switches (NQS): The playback willswitch to other bitrates if the subsequent segment of thecurrent bitrate is not available, or the network conditionschange.

Number of rebuffering events (NRE): The video clienthas to pause the playback of both audio and video duringrebuffering if there exists no lower bitrate to switch to.

Mean rebuffering time (Tmr): During rebuffering, thevideo is paused until the video can be restarted. The du-ration of the rebuffering period varies. The longer the re-buffering period is, the worse the video streaming performs.

Mean Opinion Score (MOS): We apply the calcula-tion from Mok et al. [15] to express users’ quality of expe-rience (QoE). The metric is based on a regression analysisto acquire the relationship between QoE and the applica-tion quality of service (QoS). The MOS can be calculated asshown in Eqn. 6:

MOS = 4.23− 0.0672Ls − 0.742(NQS +NRE)− 0.106Tmr

(6)

Load Balance Factor (LBF): This measures the bal-ance among different processors. We use the standard devi-ation of the overall V TT of all the processors normalized bythe average total V TT to estimate the load balance factor.

LBF =

√√√√ 1

N

N−1∑

i=0

(Tpro(i) −

1

N

N−1∑

i=0

Tpro(i)

)2

/

(1

N

N−1∑

i=0

Tpro(i)

)

(7)

where N denotes the number of processors in the cloud en-vironment and Tpro(i) indicates the overall running time ofprocesser i.

4.2 SchedulerIn the backend cloud environment, the job scheduler main-

tains two queues: one queue keeps all the normally uploadedjobs (referred as NQueue), while the other one maintainsthe jobs with high-priority (referred as PQueue). All jobsare initially inserted into NQueue, and jobs are migratedto PQueue only if the corresponding videos are requestedfor watching. Figure 5 illustrates the switching of jobs be-tween NQueue and PQueue. Figure 5(a) shows an exampleof the initial state of NQueue and PQueue at time t. Ini-tially, Videos A to D are uploaded to the server and arewaiting to be transcoded. Utilizing the methods introducedin Section 3, jobs in NQueue are sorted according to theirestimated V TT ascendingly (shown in Algorithm 1). Oncenew video segments are uploaded to the server, the sched-uler calculates the estimated job completion time and in-serts the related job into NQueue at the correct location.In our current approach, we publish the video to be avail-able for watching when the beginning Lva seconds of a videoare transcoded. As shown in the example of Figure 5, onceSegment VB1

is under request, all of its subsequential seg-ments from Video B (VB) are assigned to be high-priorityand transferred to PQueue (shown in Figure 5(b) and lines10-14 of Algorithm 2). Note that the jobs in PQueue aresorted by the their deadlines ascendingly. When one ofthe subsequent segments (e.g., VBm+1

) is required by an-other client, itself and the subsequent jobs are reinsertedinto PQueue according to the updated deadlines (shown inFigure 5(c) and lines 15-18 of Algorithm 2).

...

(a) Initial state.

...

(b) VB1is under request.

...

...

(c) Another video retrieval request on VBm+1

Figure 5: Illustration of inserting jobs into theNQueue and PQueue.

Definition 1 The deadline of a job.When a video segment is requested to be watched by end-users, its corresponding and subsequent jobs are selectedas a high-priority jobs. To guarantee smooth playback forvideo streaming, the V TJ needs to be accomplished beforeits previous segment is played to the end. The predictedtime for its previous segment to be played to the end isdefined as the deadline of a job (referred as JobDL). Aspresented in the above paragraph, we publish a video asavailable for watching after the beginning Lva seconds of

Figure 4: The architecture of scheduling on video transcoding for DASH in the cloud environment.

the video are transcoded. Therefore, JobDL equals to thecumulative video duration of all its previous segments plusLva. Considering the example of Figure 5(b), Eqn. 8 showsthe calculation of JobDL given a required job on video seg-ment VB1 and all its subsequent segments

JobBi

DL = Lva +i−1∑k=1

(dur(VBk) (i > 1) (8)

where dur(VBk) is the duration of VBk

.

Algorithm 1: videoUpload()

Input: An uploaded video segment VI j

1 JID = assignID(VIj); // assign job ID to VI j

2 test = timeEst(duration of VI j); // transcoding time

estimation

3 insert2NQ(JID, test); // insert into NQueue

according to time by SJF

Algorithm 3 presents the proposed scheduling strategy.The basic idea is to transcode the jobs in both NQueue andPQueue simultaneously, guaranteeing the smooth playbackfor videos under request. A segment can be transcoded withfive different modes (denoted as V TM): trancoding to lowand medium bitrates simultaneously (0); transcoding to lowbitrate first and then medium (1); transcoding to mediumbitrate first followed by low (2); only transcoding to low bi-trate (3); and only transcoding to medium bitrate (4). If

there exist no video viewing requests, then all the proces-sors are assigned to run jobs of NQueue. Jobs in NQueue aretranscoded with V TM setting as 0. The number of proces-sors necessary to run a high-priority job needs to satisfy thefollowing condition: the V TT of the next segment shouldbe smaller or equal to the playback time (i.e., video dura-tion) of its previous segment. To minimize the bias on V TTestimation, we assign one extra processor to run each high-priority job. For example, when one video VB1

is underrequest, the scheduler calculates the number of processors(referred to as Npr) needed in order to ensure smooth play-back (shown in Eqn. 9) and decides to follow V TM (chosenfrom 1 or 2) according to which bitrate of video is under re-quest. Only when not enough processors are available to runhigh-priority jobs will the scheduler switch the V TM (1 →3, 2 → 4 accordingly) to minimize the V TM , prepare for therequired bitrate first and leave the other bitrates afterwardswhen the system is under a lighter workload.

Npr =

⌈timeEst(dur(VBk

))

dur(VBk−1)

⌉+ 1 (k > 1) (9)

The scheduler will then assign this number of processors torun jobs in PQueue when they are available. The sched-uler keeps monitoring the work status of all the processors,as well as the jobs in NQueue and PQueue, and adjusts theprocessors to run jobs in either NQueue or PQueue accordingto the current workload. For practical purposes, the sched-uler also monitors the system load (e.g., CPU and memory

Algorithm 2: videoUnderRequest()

Input: Video segment VI j is under request,The request bitrate is Breq

1 for j ≤ j ≤ m do2 JID = getID(VI j); // get the job ID

3 if JID is accomplished then4 send the link to the HTTP-client;5 end6 else if JID is being processed then7 wait until JID is accomplished;8 send the link to the HTTP-client;

9 end10 else if JID is in NQueue then11 tdl = calDL(JID); // calculate the deadline

of JID

12 insert2PQ(JID, Breq, tdl); // move JID to

PQueue

13 removeNQ(JID); // remove JID from NQueue

14 end15 else

/* JID is in PQueue */

16 tdl = calDL(JID);17 updatePQ(JID, Breq, tdl); // reinsert JID

into PQueue and remove the old entry

18 end

19 end

usage) of each processor and finds the fastest processor torun jobs in PQueue.

5. EXPERIMENTAL EVALUATIONIn order to test the performance of the scheduler under

critical conditions, all the experiments are conducted un-der the cloud environment with limited (instead of elastic)computational resources. Two different datasets are appliedin the experiments: a real-world dataset and a syntheticdataset.

5.1 Experiment with a Real-World DatasetWe compare the proposed scheduling algorithm with the

FIFO policy utilizing a real-world dataset in a private cloudenvironment where all the computing resources can be fullyutilized by the scheduler.

5.1.1 Experimental Configuration

We set up a cloud environment with ten commodity PCsconnected with a high speed gigabit network, where one PCwas the master node and the others are the processing nodes.Each PC contains an IntelR© Quad CoreR© 2.66 GHZ CPU,4 GB memory and is running under CentOS Linux 5.6. Thetesting real-world dataset was collected in collaboration withthe Columbia College of Chicago, where journalism studentsrecorded the events that happened in the streets of Chicagoduring the NATO Summit in May 2012. Overall, the datasetincludes nine uploaders submitting a total of 259 videos,which consist of 4, 899 video segments. The length of thesevideo segments varies from 0 to 10 seconds and the over-all duration of the segments is around 6.8 hours. Most ofthe segments are five seconds long, while about 2% of thesegments have a longer duration (e.g., 10 seconds), and 4%

Algorithm 3: scheduler()

Input: Processor lists: ListPQ{}, ListNQ{}job queues: NQueue{}, PQueue{}

1 for all available processors do2 ListNQ.insert(PID); // assign all processors

to run jobs in NQueue

3 end4 num job = # of requested jobs;5 num pro = cal pro(num job, V TM); // calculate

the number of processors reserved to run

high-priority jobs for smoothly playback

6 i = 0;/* reserve num_pro processors to run

high-priority jobs */

7 while i ≤ num pro do8 find the fastest PID;9 if PID in NQueue is available then

10 ListPQ.insert(PID);11 ListNQ.delete(PID);

12 end13 i++;

14 end15 if not enough number of PID then16 switch V TM according to the required bitrate;17 num pro = cal pro(num job, V TM);

18 end19 while !NQueue.isEmpty() || !PQueue.isEmpty() do20 if ∃PID in ListNQ is available then21 assign(PID, NQueue.pop());22 end23 if ∃PID in ListPQ is available then24 assign(PID, PQueue.pop());25 end

26 end

have a shorter duration.

5.1.2 Performance Evaluation

Following the method introduced in Section 3.2, using thesame dataset (introduced in Section 3.1) but using a differentcloud configuration, the coefficients of the fitting curves andthe Gamma distributions of the private cloud configurationare summarized in Table 2.

low bitrate medium bitratea 0.006173 0.01263b 0.5655 0.518k 7.8 2.5θ 5.5 3.5

Table 2: The coefficients of the fitting curves andthe Gamma distributions used in private cloud en-vironment.

We study the efficiency of the proposed algorithm com-pared with standard FIFO policy with a real-world video up-loading stream set. In this experiment, there exist only videouploading streams but no video viewing requests. There-fore, the video segments are transcoded to both low bitrateand medium bitrate simultaneously (VTM = 0). Figure 6(a)shows the number of segments received at the server side per

second, which during some periods of time exceeds the max-imum capacity of the system. Figures 6(b) and 6(c) presentthe comparison of the cumulative segment queueing time(CSQT for short) and completion time (CSCT) between theproposed algorithm and the FIFO algorithm, respectively.Overall, the differences between CSQT and CSCT for bothof the algorithms are not significant. The proposed algo-rithm presents a slight improvement on both the CSQT andCSCT. The reason is that we only have a small uploadingdataset with a light workload and most of the video segmentsare of the same length. The transcoding sequences for bothalgorithms are almost the same. When the workload ex-ceeds the system capacity, the scheduler starts to distributethe predicted faster jobs to other processors and hence theCSQT and CSCT decrease. Moreover, since a processingnode can finish most VTJs with around 1.5 to 2 seconds,the difference on the CSQT is always small.At the beginning of the uploading procedure (i.e., for the

first 200 segments), the workload never reaches the maxi-mum capacity of the system. The cumulative segment queue-ing time is almost zero and there exists no difference betweenthe two algorithms. When the workload starts to exceedthe system capacity (e.g., at the 240th segment) and thequeue grows, the values of CSQT and CSCT increase and asmall gap begins to exist between the two algorithms. Whilethe system works under overload (i.e., uploading segmentswith IDs around 2,500 to 4,000), the CSQT has a largerincreasing rate and both the gaps in CSQT and CSCT in-crease. From the above analysis, it can be inferred that theproposed scheduler can improve the video transcoding per-formance, especially when the system is overloaded with aheavy workload.

5.2 Experiment with a Synthetic DatasetWe report on the performance of the scheduler with re-

spect to segment completion time, MOS, load balance andplayback smoothness when the system keeps working underheavy workload with a synthetic dataset.

5.2.1 Experimental Configuration

To test the functionality whether the scheduler can dy-namically identify the fastest processor to run urgent jobs,all the experiments were conducted in another shared cloudenvironment. The used processors could also be accessed byother users and used to run other CPU or memory intensivejobs. The configuration of the master node and processorswere earlier presented in Section 3.1, and the coefficients ofthe fitting curves and the Gamma distributions are statedin Eqn. 2 and Table 1 respectively. All the video watchingrequests are generated from a VLC Media Player [3]. Totest the performance of the proposed scheduling algorithm,we used a testing dataset with 400 videos, which consistedof overall 20, 000 video segments. The number of segmentsin each individual video varies from 10 to 197, which meansthat the video lengths varies from around 30 seconds to 16minutes.

5.2.2 Performance Evaluation

In the following experiments, we use two scenarios whichcommonly happen among video hosting services: (1) thevideos (e.g., historical videos) are only uploaded to the serverand none of them is being watched before all alternative bi-trates are transcoded; and (2) the videos (usually news clips

and live sports events) are watched shortly after being up-loaded and not all required bitrates are prepared yet. Ta-ble 3 summarizes the parameters used in the experimentswith the synthetic dataset.

Parameters ConfigurationsStream 1 (uploading) MPEG-4 video, AAC audio

Number of uploaders (M1) 6Uploading frequecy (∆t) 1 segment per second

Stream 2 (uploading) MPEG-4 video, AAC audioNumber of uploaders (M2) 7Uploading frequecy (∆t) 1 segment per second

Stream 3 (uploading) MPEG-4 video, AAC audioNumber of uploaders (M3) 8Uploading frequecy (∆t) 1 segment per second

Mean inter-arrival time (λ) 50 seconds0: low and medium together1: first low then medium

Video Trans. Manner (V TM) 2: first medium then low3: only low4: only medium

Video available latency (Lva) 5, 10, 15 secondsTargeted video bitrates (Bitr)

Medium bitrate 480×360, 768 kbpsLow bitrate 360×240, 256 kbps

Request arrival rate (Nwr) 5 per second

Table 3: Parameters used in the experiments to an-alyze the system capacity.

Scenario 1: No video watching requests. In thisscenario, we tested the performance of the scheduler onthe process of the videos being uploaded to the cloud andnone of them being requested for watching by end-users.Since no video watching requests arrived, all the segmentsare transcoded to medium and low bitrates simultaneously,which means that each segment needs to be transferred be-tween the storage repository and the processors once. Thevideo uploading streams are generated by Mi video upload-ers and each of them submits one segment every ∆t secondsuntil all the segments are uploaded to the server. The ar-rival time of the first uploaded segment from each uploaderfollows a Poisson distribution with mean inter-arrival timeof λ = 50 seconds.

We first analyze the system capacity by comparing thelatencies of uploading Streams 1 to 3. Figures 7(a), 7(c),and 7(e) show the number of segments received at the serverside per second, and for each stream, the server works at themaximum workload for a period of time. Figures 7(b), 7(d),and 7(f) show the latency (both the queueing time and thecompletion time) of each uploaded segment for Streams 1to 3, respectively. When the maximum arrival rate of seg-ments is 6 (Figure 7(b)), the queueing time of each segmentis fairly small and the completion time also remains less than10 seconds during the first 50 minutes. We can conclude thatreceiving six segments per second is within the capacity ofthe current system, and the scheduler can support near-livestreaming because of the small segment completion latency.Figure 7(d) shows that when the maximum arrival rate in-crease to 7, both the queuing time and the completion timefor the segments grow. This indicates that the workload inStream 2 exceeds the system capacity. The uploaded seg-ments start to queue up and the queue size grows as timeelapses. Compared with the latency when the arrival rateis 7, Stream 3 (Figure 7(f)) overloads the system more asthe growth rate of the latency is larger than that of Stream

0

2

4

6

8

10

0 200 400 600 800 1000

# o

f segm

ents

receiv

ed p

er

second

Segment uploading time (s)

# of segments received per second

(a) Uploading stream.

0

2000

4000

6000

8000

10000

12000

0 500 1000 1500 2000 2500 3000 3500 4000 4500

Cum

ula

tive s

egm

ent queuein

g tim

e (

s)

Segment ID

FIFOThe proposed algorithm

(b) Cumulative segment queueing time.

0

5000

10000

15000

20000

0 500 1000 1500 2000 2500 3000 3500 4000 4500

Cum

ula

tive s

egm

ent queuein

g tim

e (

s)

Segment ID

FIFOThe proposed algorithm

(c) Cumulative segment completion time.

Figure 6: Comparison on the segment queueing time and completion between the proposed algorithm andFIFO algorithm.

2. The latency decreases as soon as the workload is smallerthan 7. One important observation is that there exist twosituations of completion time increase: (a) the completiontime increases with the same pattern as the queueing time(shown in Figures 7(d) and 7(f)), and (b) the completiontime increases while the queueing time remains a small andrelatively constant value (illustrated in the last minutes ofFigures 7(b), 7(d), and 7(f)). Situation (a) is due to thegrowing queue size as the segment uploading rate is largerthan the system capacity and hence it represents an accu-mulation of the previous transcoded segments. On the otherhand, situation (b) is due to the long duration of V TT forspecific segments. For all these three streams, V TT of thelast segments are almost the same. Consequently, the sys-tem capacity is sensitive to the V TT of each segment. Thescheduler needs to be smart enough to find the fastest pro-cessors to run urgent jobs.

Stream LBFStream 1 0.0199Stream 2 0.0036Stream 3 0.0132

Table 4: Statistics on LBF for each stream.

We next present the load balancing results of the system.Table 5 illustrates the statistics of all processors to transcodevideos in Stream 2 as an example. From the table, we ob-serve that although the number of jobs completed by eachprocessor varies from 550 to 946, the overall V TT for eachprocessor only differs little. Some processors execute morejobs and transcode a higher duration of videos than oth-ers. The same situation occurs when uploading Stream 1and Stream 3. We can conclude that the scheduler performswell with respect to load balancing. Table 4 summarizes thevalue of LBF for processing Streams 1 to 3. When compar-ing the LBF of these three streams, the scheduler achievesthe best load balance when transcoding Stream 2. It is in-ferred that the scheduler works well when the system reachesits full capacity, and the performance decreases by a smallpercentage when the system is less or more loaded.

Scenario 2: Videos are requested for watching whilethey are being uploaded to the server. In this scenario,we study the performance of the scheduler while some of thevideos are requested for watching before all the segmentsare transcoded. One assumption is that the clients do not

interact with the videos during playback, such as pausingand forward/backward seeking. This means that each videois watched from the beginning to the end. Note that theprocessors in Scenario 2 are working under different work-loads during the experiments, indicating that the V TT forthe same video segment might vary on different processors.Therefore, the scheduler needs to search for the fastest pro-cessors to transcode videos that are being watched.

Client ID Lva Ls NQS NRE Tmr MOS5 4.26 1 1 3.54 2.08

1 10 8.51 0 0 0 3.6615 13.11 0 0 0 3.355 4.78 1 8 3.14 -3.10

2 10 9.05 1 3 2.05 0.4415 16.08 1 2 3.41 0.565 6.96 1 3 1.24 0.66

3 10 11.44 1 1 2.6 1.7015 14.99 1 1 2.17 1.515 7.15 1 1 3.16 1.93

4 10 10.69 1 0 0 2.7715 14.32 0 0 0 3.275 6.82 0 0 0 3.77

5 10 8.47 0 0 0 3.6615 13.15 0 0 0 3.35

Table 6: Measured values for the evaluation metricson varying Lva.

We first tested the extreme condition that videos are re-quested to be watched as soon as they are available. Inthis case, we used Stream 2 to upload videos and generatedfive clients to send video watching requests when the sys-tem reached its maximum capacity. The requests are sentto the server as soon as the initial Lva seconds of video aretranscoded, and we keep Bitr as the medium bitrate. Thevalue of Bitr changes to the low bitrate only when the re-quired medium rate is not available and it will never changeback again. Table 6 summarizes the values of the evaluationmetrics of each client when Lva changes. Figure 8 showsthe V TT normalized by segment duration for all the clientsand the average among processors running jobs in NQueueat the time interval since Stream 2 starts to upload videos.When comparing Clients 1 to 5, a small Lva always causesquality switches during the playback for the subsequent seg-ments. The other outlier is for Client 5 whose requests are

0

1

2

3

4

5

6

7

0 500 1000 1500 2000 2500 3000 3500 4000

# o

f segm

ents

receiv

ed p

er

second

Segment uploading time (s)

# of segments received per second

(a) Stream 1.

0

5

10

15

20

25

30

35

40

45

0 500 1000 1500 2000 2500 3000 3500 4000

Late

ncy (

s)

Segment uploading time (s)

Queueing timeCompletion time

(b) Latency for Stream 1.

0

1

2

3

4

5

6

7

8

0 500 1000 1500 2000 2500 3000 3500

# o

f segm

ents

receiv

ed p

er

second

Segment uploading time (s)

# of segments received per second

(c) Stream 2.

0

20

40

60

80

100

120

0 500 1000 1500 2000 2500 3000 3500

Late

ncy (

s)

Segment uploading time (s)

Queueing timeCompletion time

(d) Latency for Stream 2.

0

1

2

3

4

5

6

7

8

9

0 500 1000 1500 2000 2500 3000 3500 4000 4500

# o

f segm

ents

receiv

ed p

er

second

Segment uploading time (s)

# of segments received per second

(e) Stream 3.

0

50

100

150

200

250

0 500 1000 1500 2000 2500 3000 3500 4000 4500

Late

ncy (

s)

Segment uploading time (s)

Queueing timeCompletion time

(f) Latency for Stream 3.

Figure 7: Experimental results for uploading Streams 1 to 3 with Scenario 1.

received last. The reason is the scheduling algorithm carriedout by the server. Since the scheduler always searches for thefastest CPU and reserves enough processors to run jobs inPQueue, the processing speed of processors that transcodefor Clients 1 to 4 are faster than or at least equal to that forClient 5. Therefore, transcoding segments for Client 5 onany processors causes no quality switch. On the other hand,when segments requested by other clients are transcoded bythe processors joined due to Client 5 sending a video watch-ing request, the playback might be interrupted due to theslower speed of the these processors. For example, thereexist jitters with the normalized V TT for Clients 2 to 4,which indicates that the video transcoding speed varies sig-

nificantly during the playback. This situation hence causesquality switches and rebuffering events on Clients 2 to 4.When comparing the values of MOS, there are no best pa-rameters. Small values of Lva enable end-users to access thevideo shortly after it is uploaded, while a large Lva supportssmooth playback better. Consequently, we need to considerthe trade-off among these parameters and adjust them basedon the target application. In the following experiments, weset Lva to 10 seconds as it neither delays the playback toolong nor causes too many interrupts.

We next show that the proposed scheduler distributes ur-gent jobs to the fastest processors. Figure 8 compares thenormalized V TT among processors transcoding segments for

Node ID # of jobs Overall V TT (s) Mean normalized V TT (s) Median normalized V TT (s) Overall duration (s)1 810 2963.9 0.889 0.811 3628.22 832 2965.2 0.857 0.788 3737.43 718 2973.4 1.016 0.913 3183.24 860 2957.9 0.832 0.745 3874.65 946 2954.4 0.745 0.682 4278.36 797 2968.1 0.927 0.823 3543.27 777 2967.5 0.917 0.830 3498.98 921 2951.6 0.797 0.701 4110.89 725 2958.0 0.993 0.898 3234.510 714 2957.7 1.003 0.910 3163.811 727 2964.9 1.005 0.894 3238.712 604 2973.3 1.181 1.101 2708.913 863 2948.2 0.819 0.739 3909.214 854 2944.4 0.815 0.753 3842.515 657 2965.7 1.078 0.980 2938.4.16 809 2950.8 0.887 0.798 3629.417 846 2945.6 0.835 0.773 3801.318 898 2948.9 0.797 0.720 4020.119 926 2948.7 0.794 0.703 4121.220 886 2958.2 0.810 0.731 3973.221 887 2952.1 0.812 0.728 3936.922 648 2971.3 1.106 1.028 2907.823 550 2988.2 1.283 1.193 2483.724 833 2960.3 0.845 0.777 3782.125 912 2943.9 0.775 0.701 4085.6

Table 5: Statistics on each processor for Stream 2. The similarity of the overall V TT shows that the workloadsamong processors are well balanced, while the normalized V TT and the overall duration differentiate theprocessing capacity of each individual processor.

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

200 300 400 500 600 700 800 900

No

rma

lize

d V

TT

(s)

Request arriving time (s)

Average VTT for NQueueVTT for Client 1VTT for Client 2VTT for Client 3VTT for Client 4VTT for Client 5

Figure 8: Comparison of the normalized videotranscoding time V TT (Lva = 10 seconds).

clients and those for normally uploaded segments. For mostof the time, the normalized V TT is smaller for Clients 1 to5 than that for NQueue, indicating that the fastest proces-sors are used to transcode video segments for the watchingclients. On the other hand, the average V TT for NQueueincreases when the server receives video watching requests.The reason is that only the slowest processors are assignedto run jobs in NQueue.Finally, we illustrate the benefits of the automatic VTM

switching functionality. Figure 9 shows the comparison be-tween the deadline and completion time of transcoding. At

the beginning, after the server receives the video watch-ing request from Client 2, the time difference between thetwo curves increases since faster processors transcoding forClient 1 can serve Client 2. After Clients 3 to 5 join, someslower processors also serve Client 2. The sharp V TT changeson Client 2 and the increasing V TT result in a quality switchwhen Segment #38 is finished transcoding. After the qual-ity switch, Client 2 changes its request from medium tolow bitrate and the scheduler only changes V TM from 2to 1. This strategy shortens the completion time for therequired bitrate for a single transcoding job but does nothelp subsequentially in transcoding since the overall V TTon the processor remains the same. The next three rebuffer-ing events also happen for the same reason. Conversely,when the scheduler switches V TM after encountering thefirst rebuffering event, the transcoding completion time isshortened significantly. This can improve the performanceof the scheduler and the system throughput, as well as im-prove end-users’ experiences. However, the drawback of au-tomatic V TM is that the system might suffer from frequentchanging of the required bitrates, which seldom happens.

6. CONCLUSIONS AND FUTURE WORKIn this study we proposed a dynamic scheduling algo-

rithm for video transcoding jobs designed to support Dy-namic Adaptive Streaming over HTTP in a cloud environ-ment. We first modeled the video transcoding time V TTestimation based on statistics from video segment durationsand the targeted bitrate. The scheduler then dynamicallydistributes video transcoding jobs V TJ according to V TTestimation and the system workload. Overall, the proposed

200

300

400

500

600

700

0 10 20 30 40 50 60 70 80 90

Tim

e (

s)

Segment ID

Quality switch

Rebuffering event 1

Rebuffering event 2

Rebuffering event 3

The deadline of preparing the segmentThe transcoding completion time (no VTM switch)

The transcoding completion time (VTM switch)

Figure 9: Comparison between the deadline andcompletion time for each video segment watched byClient 2 (Lva = 10 seconds).

scheduler can support near live streaming while balancingthe workload and provide smooth and seamless playback.Most importantly it can dynamically serve requests and ad-just the video transcoding mode V TM accordingly. Experi-mental results show that the scheduler can distribute urgentjobs to the fastest processors and shorten the transcodingcompletion time by using V TM switching. Multiple config-urations of the scheduler allow it to be adjusted accordingto the needs of different applications. In the future, we planto investigate a cost model for the scheduler, which wouldbe helpful for administrators to select appropriate cloud ser-vices while considering multiple parameters.

Acknowledgements

This research has been supported by the Singapore NationalResearch Foundation under its International Research Cen-tre @ Singapore Funding Initiative and administered by theIDM Programme Office. The authors would also like tothank Professor Junchang Xin, from Northeastern Univer-sity, China for his kindly support on providing the cloudcomputing resources.

7. REFERENCES[1] FFmpeg. URL:http://www.ffmpeg.org/.

[2] ISO/IEC 23009-1: 2012 Information technology –Dynamic adaptive streaming over HTTP (DASH) –Part 1: Media presentation description and segmentformats. URL:http://www.iso.org/iso/iso_catalogue/catalogue_tc/

catalogue_detail.htm?csnumber=57623.

[3] VLC Media Player.URL:http://www.videolan.org/vlc/.

[4] Adobe System Inc. HTTP Dynamic Streaming.URL:http://www.adobe.com/products/hds-dynamic-streaming.html.

[5] Amazon. Amazon Elastic Compute Cloud (AmazonEC2). URL: http://aws.amazon.com/ec2/.

[6] Amazon. Amazon Simple Storage Service (AmazonS3). URL: http://aws.amazon.com/s3/.

[7] Amazon. Amazon Elastic Transcoder, 2013. URL:http://aws.amazon.com/elastictranscoder/.

[8] Cisco. Cisco Visual Networking Index: Global MobileData Traffic Forecast Update, 2012-2017, 2013. URL:http://www.cisco.com/en/US/solutions/

collateral/ns341/ns525/ns537/ns705/ns827/

white_paper_c11-520862.pdf.

[9] EncoderCloud. URL:http://www.encodercloud.com/.

[10] H. Kllapi, E. Sitaridi, M. M. Tsangaris, andY. Ioannidis. Schedule Optimization for DataProcessing Flows on the Cloud. In 2011 sigmod, pages289–300. ACM, 2011.

[11] P. Li, B. Veeravalli, and A. A. Kassim. Design andImplementation of Parallel Video Encoding StrategiesUsing Divisible Load Analysis. Circuits and Systemsfor Video Technology, IEEE Transactions on,15(9):1098–1112, 2005.

[12] X. Li, Y. Cui, and Y. Xue. Towards an AutomaticParameter-Tuning Framework for Cost Optimizationon Video Encoding Cloud. International Journal ofDigital Multimedia Broadcasting, 2012, 2012.

[13] Z. Li, Y. Huang, G. Liu, F. Wang, Z.-L. Zhang, andY. Dai. Cloud Transcoder: Bridging the Format andResolution Gap between Iinternet Videos and MobileDevices. In Proceedings of the 22nd InternationalWorkshop on Network and Operating System Supportfor Digital Audio and Video, pages 33–38. ACM, 2012.

[14] Microsoft Corporation. Smooth Streaming ProtocolSpecification, 2012.URL:http://download.microsoft.com/download/9/5/E/95EF66AF-9026-4BB0-A41D-A4F81802D92C/

[MS-SSTR].pdf.

[15] R. K. P. Mok, E. W. W. Chan, and R. K. C. Chang.Measuring the Quality of Experience of HTTP VideoStreaming. In 12th IFIP/IEEE InternationalSymposium on Integrated Network Management, pages485–492, 2011.

[16] R. Pantos and E. W. May. HTTP Live Streaming,2012. URL:http://tools.ietf.org/pdf/draft-pantos-http-live-streaming-10.pdf.

[17] Rackspace. The Rackspace Cloud.URL:http://www.rackspace.com/cloud/.

[18] B. Seo, W. Cui, and R. Zimmermann. AnExperimental Study of Video Uploading from MobileDevices with HTTP Streaming. In ACM MultimediaSystems Conference, pages 215–225, 2012.

[19] T. Stockhammer. Dynamic Adaptive Streaming overHTTP - Standards and Design Principles. In ACMMultimedia Systems Conference, pages 133–144, 2011.

[20] YouTube. YouTube Press Statistics, 2013. URL:http://www.youtube.com/t/press_statistics.

[21] M. Zaharia, D. Borthakur, J. S. Sarma, K. Elmeleegy,S. Shenker, and I. Stoica. Job Scheduling forMulti-user Mapreduce Clusters. EECS Department,University of California, Berkeley, Tech. Rep.UCB/EECS-2009-55, 2009.

[22] Zencoder. Zencoder Cloud, 2010. URL:http://zencoder.com/en/cloud.

[23] W. Zhu, C. Luo, J. Wang, and S. Li. MultimediaCloud Computing. Signal Processing Magazine, IEEE,28(3):59–69, 2011.