Keywords

1 Introduction

Currently, to support high quality live streaming on different users’ devices, video publishers must create multiple versions (i.e. different formats) of this video at their service providers. However, this method faces from hardware limitations and network bandwidth. In addition, this approach is not aware of the demands of viewers. This means that it can produce versions not requested by viewers. Thus, this approach has remained costly and ineffective [1]. Another approach is on-demand streaming video streaming, in this approach; the publisher creates only one copy of the video at its end. Live video can be broadcast to viewers as long as the devices are compatible with streaming format. Live video streaming is performed on demand when a new viewer joins in a compatible device format [2].

The provision and improvement of the live video streaming’s infrastructure basically is required to meet the increasing global demands for video streaming but it is costly effective [3]. Therefore, the use of cloud services has become a common solution among all Internet service providers. As video streaming providers use cloud computing to host their services, they face challenges by assessing the quality of experience and designing unified strategies in this complex environment.

Live video viewers request to receive video without any delay. So we need to specify the display time as the last time (i.e. deadline) that the transcoding process can be completed for the video stream without any interruption. There is no value in converting the format of the video after its display time. This means that each transcoding task has an individual hard time limit. Consequently, for stable live video streaming, transcoding tasks that can’t finish its processing must be dropped. In this research, we also need to specify a drop rate as a percentage of transcoded tasks because transcoding can’t be completed during viewing times. To have maximal QoE (i.e. viewer satisfaction), we inquiry to minimize the drop rate of the video playback.

Previous work such as [4] shows that more than 40% of viewers watch only a few seconds of video streaming. So they assess the quality of the service provider depending on the initial delay that happens at the starting of the video streaming. So we need to determine the delay acquired by the user at the beginning of the stream as a startup delay. Under these situations, to have maximal QoE (i.e. viewer satisfaction), we inquiry to minimize the startup delay in video playback.

In this work, we will consider our objective problem is to maximize QoE of end users (i.e. viewers’ satisfactions) with supposed constraints: minimizing the startup delay and the drop rate. Therefore, the challenge in this research is how to assign (i.e., management) transcoding tasks on cloud resources to satisfy the QoE requirements of live streams viewers without considering another cost to the video service provider.

So that our work is constituted from two stages: Firstly, we proposed a new QoE management scheme that will be useful for service providers to optimal usage of cloud resource without any additional cost. Our proposed scheme differs from previous works by using transcoding process for real time streaming using cloud resources to submit high video quality for many different video players. Secondly, this proposed scheme is experienced under three effective indicators (startup delay, deadline time and bit rate level variations), which it is also consider a new approach of monitoring and reviewing the user experience for live video streaming.

The work of this paper is organized as follows: Sect. 2 describes the main related works to our research approach, while Sect. 3 submits the detailed description of the proposed scheme architecture for QoE management of live video streaming. Section 4 will define and derive the three suggested QoE performance indicators of our proposed scheme. Section 5 shows the simulation results that will be drawn from our experiments to describe our proposed scheme. Finally, Sect. 6 will give the main conclusions are gained with this work.

2 Related Work

Video transcoding process consumes very large data storage and long time, so it requires big data storage and computing infrastructures for implementation. Accordingly, the use of cloud computing is becoming a common practice solution for streaming service providers. As a result, researchers have faced many challenges in leveraging cloud services.

The way in which videos are segmented plays an important role in transmitting and transcoding processes of video streaming. Authors of [5] describe how video segmentation technique can impact on the transcoding time seriously. While our work, the video is splitting into segments that contain a group of pictures (GOPs), and we will treat each GOP separately, so we can control and monitor transcoding time to improve the segmentation process. Authors of [6] suggested a scheduling and provision method with video on demand (VOD) approach in cloud, the purpose of this work was to ensure quality of service which is claimed by video viewers while minimizing the required cost of using cloud services. Our work is different from [6] by two main concepts: Firstly, we basically use live video streaming approach instead of VOD approach which means the transcoding time is definitely unknown. Secondly, at live video streaming, the GOP tasks will be dropped if they miss their final deadline times while at VOD must be completed even if they miss their final deadline times. This difference increases uncertainty in live video streams and makes their management a more challenging problem.

The provision and management of QoE in a cloud is currently an important research topic. Authors of [7] proposed a system to improve the provision and management of QoE using cloud resources, They studied the problem of cloud resource optimization based on quality indicators and proposed a multidimensional architecture where agents residing within the cloud used to monitor QoE. After that, these indicators can be used to update and manage the cloud resources. The current work is similar with [7] by the idea of monitoring QoE within the cloud but our work differs by the suggested modules that form our proposed scheme for QoE management as it will be shown in details in in Sect. 3 of this paper. Another work [8] deals with QoE assessment of cloud service providers. The authors of this work proposed a hierarchical model based on cloud provisioning subsets, output bandwidth, response time and latency, the use of the probability that the service could be successfully provided (i.e. the service is available and latency requirements are not violated) and the average time of service completion as QoE indicators. In our work we consider different QoE indicators for video quality assessment since we will present and derive three important performance indicators of QoE to reflect the live video streaming experience at viewer’s side.

3 Proposed Scheme Description

We propose a new scheme of QoE management for live streaming using cloud services. An overview of this scheme architecture is presented in Fig. 1. The proposed scheme architecture shows the sequence of actions taken place when viewers request videos from a live streaming service provider. This proposed scheme architecture includes three main components, namely client, delivery network and server. The client side consists from the following key components:

Fig. 1.
figure 1

Proposed scheme architecture

Full size image

  • Player buffer: This buffer is used to store the received video frames from the server hosted in cloud.

  • Decoder: It is used to decode the received video frames from the player buffer.

  • Buffer regulator: It is used to control the player buffer length so it can avoid buffer underflow/overflow situations.

  • Bandwidth estimator: It is used to estimate the available network bandwidth and requests the suitable segment to the server.

In the other side, the service provider side (Server) consists from the following main components and the cooperation of these components leads to cost-efficient and achieving QoS requirements for live streams within the cloud:

  • Video Selection: The video selection is the process that the user may choose the video. This module may give all information about the video file. For example (video name, video format, video path and video size). At this module the user may select any video it does not affect with the video size.

  • Video Segmentation: Live video is split into several groups of pictures (GOP) depending on coming video frames, which can then be independently transcoded. Each GOP has a specified deadline on the basis of the time of the first frame in that group.

  • Transcoding Execution: At live video streaming, the execution time (transcoding process) of coming video frames (i.e. GOP tasks) can’t be predicated. It is worth mentioning that this is a big difference of live streaming with the video on demand (VOD) where the video stream is processed several times. Thus, the execution time of each GOP task can be estimated based on previous implementation information.

  • GOP Assignment: This module is responsible for assigning GOP functions to transcoding servers. The goal of this module is to meet the quality of service requirements for customers (in terms of minimum start delay and GOP drop rate for video streams) without additional cost is charged to video streaming provider.

  • Transcoding Virtual Machines (VMs): VMs are assigned by the cloud service provider to handle GOP transcoding tasks. In this work, we assume that the default custom VMs are homogeneous. Each VM has a local queue where the required data is preloaded to GOPs before execution. When a free patch appears through the local queue of the virtual machine, a scheduler is assigned to set the GOP to the VM.

  • Video Merging: The function of this merger is to put already transcoded GOPs in the right order and form live streams. Then, this video merger sends these live streams to corresponding viewers.

  • Video Repository: This temporally pool to store the video after merging and to be served according to HTTP request. And this module can monitor the operation of the transcoding VMs in the streaming video structure directly, changing the size of the VM cluster to meet customer service quality requirements and reduce the cost incurred for the video service provider.

4 QoE Indicators of the Proposed Scheme

In this work, we propose the video segment duration is a fixed number of seconds, and if the client requests the high video rate, then it contains larger segment size (in bytes). When high video rate segment R(t) is requested by the client and available bandwidth B(t) is lower than the request video rate then the buffer is filled at the rate B(t)/R(t) < 1, and as the result the buffer decreases. If client continuously requests high video quality at a rate greater than network bandwidth, the buffer might be depleted as shown in Fig. 2. As a consequence, playback will freeze, and re-buffering event will occur, thus decreasing the client’s QoE. However, if network bandwidth is always higher than the requested video rate, then client will never observe re-buffering events i.e. B(t)/R(t) > 1.

Fig. 2.
figure 2

Video playback buffer

Full size image

In live video streaming approach, the video is encoded into various bitrates. So, the player buffer length q(t) can be modeled by using the following formula:

$$ q\left( t \right) = \frac{B\left( t \right)}{R\left( t \right)} - d\left( t \right) $$
(1)

where d(t) is the buffer draining rate, that can be expressed as given below:

$$ d\left( t \right) = \left\{ {\begin{array}{*{20}l} 1 \hfill & {playing} \hfill \\ 0 \hfill & {paused} \hfill \\ \end{array} } \right. $$
(2)

where B(t) represents the available network rate and R(t) represents the received video level. The player buffer filling rate represents the number of seconds video are stored in the buffer per second. The term d(t) is the draining rate which describes the number of seconds video are played per second.

In this work, we propose a scheme to manage QoE for live video streaming, generally there are many main quality influenced indicators for QoE performance. So that our proposed scheme for managing reviewers’ QoE will consider three indication factors into account. These three indicators are startup delay, deadline time (including null time number and total duration) and bit rate level variation (the video quality and its fluctuation). However any QoE’s model is a static and posterior model, which means it cannot be used for on-line and real-time service. While in our work, we derive this model into an iterative way for real-time QoE evaluation. This modification makes the QoE followed rate enhanced for on-line service possible.

First indication parameter is the startup delay which impacts directly to the QoE; this parameter is denoted by ISD. According to [9], the factor α is defined as a threshold exists for viewers’ impatience which is computed by linear regression. Before the segment i is requested, the already accumulating startup delay is I SD(i − 1) , if level j is selected for i, the startup delay will increase by B i,j /R(i). We modify the impact of startup delay in an iterative form as:

$$ I_{{SD\left( {i,j} \right)}} = \alpha \left( {I_{{SD\left( {i - 1} \right)}} + \frac{{B_{i,j} }}{R\left( i \right)}} \right),\quad q < q_{min} $$
(3)

The second indication parameter is the deadline time I DT which it is the combination of the null time duration N DT and null time numbers S DT . If the client is in re-buffering state, requesting segment i will not introduce new null event but adding the null duration by B i,j /R(i). In order to evaluate the deadline indicators, we introduce a warning threshold \( \acute{q}_{min} = \gamma q_{min} + \left( {1 - \gamma } \right)q_{max} ,\;\gamma \in \left( {0,1} \right) \) which is larger than q min to indicate the upcoming deadline event. After download the segment i, then the buffer length becomes q + τ − B i,j /R(i). And if the buffer length drops below q min , a null event is assumed to occur, that increase S DT by 1, and the N DT is increased by the time cost to re-fill the buffer to q min again. In such a situation, the client needs to download q min /τ segments to resume palyback. Thus deadline threshold of current buffer length is:

$$ T_{DT} = \acute{q}_{min} + \frac{{B_{i,j} }}{R\left( i \right)} - \tau $$
(4)

Combining the derivation above, the null number S DT (i, j) and null duration N DT (i, j) for the upcoming segment i with level j is:

$$ S_{DT} \left( {i,j} \right) = \left\{ {\begin{array}{*{20}l} {S_{DT} \left( {i - 1} \right) + 1,\quad \;q_{min} < q < T_{DT} } \hfill \\ {S_{DT} \left( {i - 1} \right),\quad \quad \quad \quad otherwise} \hfill \\ \end{array} } \right. $$
(5)
$$ N_{DT} \left( {i,j} \right) = \left\{ {\begin{array}{*{20}c} {N_{DT} \left( {i - 1} \right) + \frac{{B_{i,j} }}{R\left( i \right)},\,\,} & {q < q_{min} } \\ {N_{DT} \left( {i - 1} \right) + \sum\nolimits_{i + 1}^{{i + q_{min} /\tau }} {\frac{{B_{i,j} }}{R\left( i \right)}} ,} & {q_{min} < q < T_{DT} } \\ {N_{DT} \left( {i - 1} \right),\quad \quad \quad } & {otherwise} \\ \end{array} } \right. $$
(6)

And according the relationship between the I DT , N DT and S DT in [9], the influencing from deadline time can be obtained in expression (7) below:

$$ I_{DT} \left( {i,j} \right) = aN_{DT} \left( {i,j} \right) + bS_{DT} \left( {i,j} \right) - c\sqrt {N_{DT} \left( {i,j} \right)S_{DT} \left( {i,j} \right)} $$
(7)

The cross-term in expression above is used to compensate the simultaneous effects of null duration and null time number, and the values of coefficients a,b and c in expression (7) are derived by linear regression [9].

The third indication parameter is level variation I LV (i, j). It is determined by quality factor I quality (i, j) as well as the switch factor I switch (i, j). Video Quality Metric (VQM) is described in details for frames quality assessment [10], while the value of VQM ranges in (0, 1). The frames with the higher VQM are of the poorer qualities and definitions. The annoyance of the viewer increases exponentially as the streaming persistently stays at low quality level. So the quality factor is influenced by the distortion as expressed in the following equation:

$$ I_{quality} = \sum\nolimits_{i = 1}^{M} {VQM_{l\left( i \right)} e^{0.02\tau X\left( i \right)} /M} $$
(8)

I quality is the weighted mean of the VQM of the M segments. The weight of each segment is given by the e 0.02τX(i). The X(i) stands for the number of continuous segments before i whose VQM is close to i’s VQM, indicating that if the video remains in low quality, the QoE will be damaged exponentially. As for quality switch, facts are that viewers are much more sensitive to the switch-down than switch-up, so only the switch-down case is taken into consideration by a sign function:

$$ I_{switch} = \frac{1}{M}\sum\nolimits_{i = 1}^{M} {\left[ {\left( {VQM_{i} - VQM_{i + 1} } \right)^{2} sign\left( {VQM_{i + 1} - VQM_{i} } \right)} \right]} $$
(9)

However, the I quality and I switch are calculated posteriorly in [9], in order to evaluate the QoE during the streaming service in real-time, the equations are modified into an iterative form for on-line service:

$$ I_{quality} \left( {i,j} \right) = \left[ {\left( {i - 1} \right)I_{quality} + VQM_{j} e^{{k\tau X_{i} }} } \right]/i $$
(10)
$$ I_{switch} \left( {i,j} \right) = \left[ {\left( {i - 1} \right)I_{Switch} \left( {i - 1} \right) + \left( {VQM_{j} - VQM_{{l\left( {i - 1} \right)}} } \right)^{2} sign\left( {VQM_{j} - VQM_{{l\left( {i - 1} \right)}} } \right)} \right]/i $$
(11)

And the total influence due to level variation is the weighted sum of I quality and I switch according to the coefficients in [9]:

$$ I_{LV} \left( {i,j} \right) = B_{1} I_{quality} \left( {i,j} \right) + B_{2} I_{switch} \left( {i,j} \right) $$
(12)

Where B 1 and B 2 coefficients are derived using linear regression technique.

The overall QoE metric is Q, which is a hundred-marked score, can be calculated from I LV , I SD and I DT :

$$ Q\left( {i,j} \right) = 100 - I_{SD} \left( {i,j} \right) - I_{DT} \left( {i,j} \right) - I_{LV} \left( {i,j} \right) + 0.17I_{SD} \left( {i,j} \right)\sqrt {I_{DT} \left( {i,j} \right) + I_{LV} \left( {i,j} \right)} + 0.31\sqrt {I_{ST} \left( {i,j} \right)I_{LV} \left( {i,j} \right)} $$
(13)

The coefficients and terms in expression (13) come from the regression of subjective test in [9]. We have developed a real-time QoE model; furthermore, it will be used as the guidance to select the bit-rate level.

5 Simulation Results

In this work, we studied the perceived video quality using DASH technology. We investigate three indication factors which impact on user perceived video quality (i.e. QoE): startup delay, null time (frame freezing), and bit rate level variations (frame quality fluctuations). Moreover, for each factor, we explore multiple dimensions that can have different effects on perceived quality. For example, in the case of the deadline time factor, while most previous research have studied how null duration correlates with user perceived quality, we also consider when the null times happen and how the nulls are distributed, since we believe they may also impact user experience. We design and conduct extensive subjective tests to study the impairments of the different dimensions of the three factors on user perceived video quality. We will describe the methodology to design the subjective tests, and present the results of the subjective tests. Based on the subjective tests, we derive impairment functions which can quantitatively measure the impairment of each factor on the user experience of any DASH video and also provides validation results.

The experiments for our simulation are done by using JAVA language, Net Beans 6.9.1 IDE and MySQL for database. Figure 3 below shows the follow diagram for the implementation of our proposed system which including main five modules (Video Selection, Video Splitting, DASH Streaming Process, QoE Evaluation and Video Viewing Process). The video selection is the process that the user may choose the video; this module may give all information about the video file (i.e. video name, video format, video path and video size). In this module, the user may select any video it does not care about the video size. This process is a source process that the user may select the video and transmit the video. The video splitting process may split at based on video size and video duration, while the video may splitting at same frames the size does not vary, then the complete video may chunks at small components. The DASH streaming technique introduces an additional level of complexity for measuring perceived video quality (i.e. viewer’s QoE), as it varies the video bit rate and quality. We investigate three factors which impact user perceived video quality (viewer’s QoE): startup delay, null duration time (frame freezing), and bit rate level variations (frame quality fluctuations). Moreover, for each factor, we explore multiple dimensions that can have different effects on perceived quality. Finally, the Video viewing process shows the video merging process, the completed video may store into a destination folder that the user can view this video.

Fig. 3.
figure 3

Flow diagram of simulation implementation

Full size image

Our experiments begin with testing 16 videos for different cases of simulation above. Firstly, we test videos number 1 to 5 by adding various length of startup delay in the beginning of streaming videos. Figure 4 below shows the relationship between the impairment subject and the startup delay for our tested videos from 1 to 5. So we can prove that this relationship between the average impairment subject and startup delay is linear as shown in figure below.

Fig. 4.
figure 4

Startup delay impairment effect

Full size image

In second experiment, we test the videos from 6 to 16 to evaluate the second influenced parameter that it is the deadline time which is the combination of the null time duration and null time numbers. Figures 5 and 6 respectively show the average impairment values for tested videos (6–16), where null duration and null number are varied. From these two figures, we can note that when the null number is fixed, the subjective impairment value will increase consequently with null duration. While when the null duration is fixed, the subjective impairment value will not increase consequently with null number. However, we can observe that the impairment value is highest with the highest null number, which indicates that frequent nulls will cause big impairment on user experience.

Fig. 5.
figure 5

Null duration in each tested videos

Full size image
Fig. 6.
figure 6

Null time number in each tested videos

Full size image

In another side, we examine the effect of level variation impairment factor on viewer’s quality of experience, level variation impairment is the most complicated parameter to examine because it is difficult to describe and strip complex patterns of level fluctuations during each trace of the video session. As described in problem formulation section, there are three impact dimensions of this impairment parameter: average level of each video session, number of switches in each session, and average switch magnitude of each trace as shown in Figs. 7, 8 and 9 respectively. From these figures we can notice that the annoyance of the viewer increases exponentially as the streaming persistently stays at low quality level. We can also observe that the three impact dimensions will monotonically impact on user experience in a complicated way. Also we can notice that the annoyance of staying at a low level (low quality) will grow exponentially with the duration that the low level is maintained.

Fig. 7.
figure 7

Distribution of level variation in each session

Full size image
Fig. 8.
figure 8

Distribution of number of switches in each session

Full size image
Fig. 9.
figure 9

Distribution of average switch magnitude in each session

Full size image

6 Conclusions

In this work we submitted a proposed QoE management scheme in cloud environment, and then we test this model under some subjective experiments to evaluate the QoE for viewers using three indication parameters for different DASH streaming videos. Based on the results from these evaluations, we can monitor and control the caused impairment by each one of these three indicators (startup delay, deadline time and bit rate level variation). The simulation results show that the tested indication parameters do not need to access the service providers in order to monitor QoE of viewers and neither any need to insert these indicators into the video streaming client software to determine the user experience in real time (live video streaming). We believe they can serve as useful and light-weight tools for live video streaming service provider to monitor and control their quality of service. Also our results prove that the cloud resources can satisfy the QoE requirements of live stream streaming viewers without considering another cost to the video service providers.