QoS-aware Video Transcoding Service Composition Process in a Distributed Cloud Environment
International Journal of Innovative Research in Computer and Communication Engineering
In this paper, we address the problem of selecting and composing video transcoding services in a distributed cloud environment. One of the challenging issues for video transcoding service composition is how to find the best transcoding path to route the data flow through while satisfying the viewer requirements and specifications. In a cloud environment, video transcoding service providers provide different video transcoding services that have similar functionality (i.e., format conversion),
... mat conversion), but with different Quality of Services (QoS) specifications. Since the combination of the QoS specifications, such as frame size, frame rate, video bit rate, and transcoding delay might affect the end user's experience in non-intuitive and subjective way and also might affect the delivering of a high quality video content over any type of network, we propose a QoS-aware model to select and compose the best video transcoding services to satisfy hard constraints on the input and output video formats and comes as close as possible to satisfying soft constraints on the QoS. This model uses an aggregate function to evaluate the QoS for each transcoding service and for each viewer request to explore the best composition path. In this paper, we adapt the Simulated Annealing (SA) algorithm and the Genetic Algorithm (GA) as candidate solutions to help in the composition process. The SA/GA algorithms provide multi-constraints QoS assurance for video transcoding service composition. They also support directed acyclic graph composition topology. We have implemented a prototype of the proposed algorithms and conducted experiments using small-, medium-, and large-scale graphs of video transcoders and sample viewer requests to measure the performance and the quality of the results. The experimental results show that the SA outperforms the GA in terms of performance and success ratio for small-scale graph, while GA outperforms the SA algorithm in terms of performance for medium-and large-scale graphs. The success ratio for the SA and GA algorithms are close to each other for medium-and large-scale graphs. At the end, we provide several directions and suggestions for future work. 3727 limitations, device-specific requirements, and end-user preferences. Video transcoding services are components within a delivery system that transform or convert video content from one format to another (e.g., from MPEG-2 to H.264). This transcoding process may also involve frame-size conversion, bit-rate conversion, or frame-rate conversion. These conversions are based on the end-user preference values. The transcoding process is usually done in cases where a target device (or playback software) does not support the original video's format or has limited storage capacity, or in order to convert incompatible or obsolete data to a better-supported or modern format . Fig. 1 depicts the general video transcoding process. When an end-user wants to watch a cloud-based video through a viewer (i.e., video playback software), the viewer needs to request a stream for that video. That request includes: a) the required video-coding format, also called the video-compression format, and b) a desired QoS that specifies a hoped-for video quality and a tolerable delay. A video coding format defines the structure of the video's image and audio data. Some popular formats are H.264/MPEG-4, MJPEG (Motion JPEG), WMV, and DivX, but there are over 20 in common use today  . A codec is a piece of software that can encode video data into a particular format or decode a video from that format. A codec's name is often used as a synonym for the format with which it works. In general, frame size, frame rate, video bit rate, and audio sampling rate characterize the quality of a video and part of QoS specifications  . However, since the audio portion of the video accounts for only a small portion of the data, it is often not considered in QoS-related decisions. When dealing with streaming, a desired QoS may also include a constraint on the amount of delay that the viewer is willing to tolerate in the stream. Even though the delay does not directly characterize a video's quality, it does characterize a video stream and it affects the end user's experience. So, in this paper, we limit the QoS properties to: frame size, frame rate, video bit rate, and the average transcoding delay. A viewer's desired QoS will be determined based on user preferences, viewer's window size, device capabilities, power-savings setting, network bandwidth, and other device-specific factors. For example, a 78.0" Diagonal UHD display device requires around 80Mbps video bitrate  while a 5.5" iPhone 6 plus requires around 18Mbps video bitrate  . Optimal utilization of the overall video delivery system resources comes from successfully calculating the desired QoS values for a specific device, playback software, or network connection. These resources are either devicespecific resources, such as the computational power and the internal buffers, or network-specific resources, such as network bandwidth. Incorrect calculation of these values might negatively impact the end-user's subjective perception of the video. For example, asking for higher video bitrate for a device that has low computational power or low network bandwidth might make the device much slower than usual and the video might look jerky. In contrast, asking for low video bitrate while the device has a high computational power and network bandwidth may generate low video quality and negatively affect the user experience. Therefore, calculating the right QoS for a video will entirely change the user experience regarding video quality. How a viewer computes a desired QoS is an interesting human-factors and device-management problem, but it is outside the scope of this paper. 3728 due to unavailability of video frames while video startup time is the interval between the moment when the user selects the link and the moment when the video starts playing. The delay in start-up time is due to a delay in transcoding, streaming, or playing. In this paper, we focus on satisfying the requested QoS level while performing the transcoding process, which in turn helps in enhancing all the other factors. 3729 with a limited number of transcoders, c) the computations could be distributed among different processing units, d) improved the client QoS level while properly scaling with number of clients, e) provide a clear separation between video contents and the transcoded ones, and f) generate more powerful applications with more complex functionalities because the functionality offered by individual services is limited  . Manual composition of services is time consuming, error prone, generally hard and not scalable. Therefore, many fully or partially automatic service composition approaches have been investigated  . Service composition involves creating composite services by combining different services to provide a new value-added service  . It does not only improve reusability of service components, but also enables rapid development of new complex applications and requirements  . Composing the best transcoders is an open problem to date; there are similar composition problems in other domains, like web-services, that have been heavily investigated  . Section II reviews this related work and categorize them into five different groups. feasibility of the new neighboring path by adding the source and the destination nodes to it. Therefore, the new neighboring path satisfies the viewer request's hard constraints. E. The acceptance probability After generating the neighboring path, we use the acceptance probability function to calculate the acceptance probability based on the combination of the currentCost, newCost, userCost, and the . This function compares the cost of the two paths with respect to the userCost. We described above how we calculate these costs. The acceptance probability function helps the SA algorithm to intelligently accept worse solutions and escape from the local optima that are worse than the global one  . The acceptance probability is a non-negative real number between 0 and 1. Function 5 describes the acceptance probability function. A. Parameters configuration In this part, we configure the parameters of the GA algorithm, mainly, the population size and the number of iterations. These parameters are user defined and their values depend on the problem domain and size. Function 6 describes this configuration process.