DEGREE PROJECT IN COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2018
Towards network based media processing using cloud technologies
ROBERTO RAMOS CHAVEZ
KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE
Abstract
Media delivery based on HTTP adaptive bitrate streaming protocol has become one of the most popular methods for streaming video and audio over the Internet. These services are commonly built on top of centralized infrastructures that rely on network conditions or computing resources, which may reduce performance applications on the client side. Massive increases in cloud technologies, such as infrastructure as a service (IaaS), container as a service (CaaS), and new deployment paradigms like function as a service (FaaS) provide accessible deployment of virtual functions in multiple locations, which reduces various streaming performance constraints. However, there is no clear understanding of whether all cloud deployments are suitable for media delivery. This thesis develops a proof of concept for the deployment of media processing functions in the cloud. Three media processing use cases and a media streaming prototype for video on- demand (VOD) ad insertion are designed, implemented, and evaluated. Each of the three media processing use cases is evaluated in a specific deployment architecture to obtain key performance indicators (KPIs) for use in future networks, such as 5G and network-based media processing (NBMP). Acknowledgment
First, I would like to express my enormous gratitude towards my supervisor Dr. Rufael Mekuria at Unified Streaming. For his guidance and strong patience during this work. I would also like to thank Dirk Gri oen and Mark Ogle for our endless discussions and support during the past six months. I have learned a lot from them, my perception as a researcher, technology, and teamwork has changed dramatically. Their extensive knowledge in the field of media delivery inspired me every day that I was present at Unified Streaming. I would also like to stretch my thanks to Prof. Markus Flierl, for his continuous advice during his academic courses and the thesis. But mostly I would like to thank my parents and family for supporting me through the years.
Amsterdam, October 10th, 2018 Sammanfattning
Medieleverans baserad p HTTP-adaptivt bitrate-streamingprotokoll har blivit en av de mest populra metoderna fr streaming av video och ljud ver Internet. Dessa tjnster r vanligtvis byggda utver centraliserad infrastruktur som bygger p ntverksfrhllanden eller datafrbrukning, vilket kan minska prestandatillmpningar p kundsidan. Massiva kningar i moln teknik, ssom infrastruktur som en tjnst (IaaS), behllare som en tjnst (CAA) och nya distributions paradigm som fungerar som en tjnst (FAAS) tillhandahlla lttillgnglig utbyggnaden av virtuella funktioner p flera platser, som du minskar flera streaming prestanda begrnsningar. Det finns emellertid ingen klar frstelse fr huruvida molnutlggningar r lmpliga fr medialeverans. Denna avhandling utvecklar ett bevis p konceptet fr distribuering av mediabehandlingsfunk- tioner i molnet. bearbetning anvndningsfall och en prototyp fr media streaming video on-demand (VOD) ad insttning r utformade, genomfrs och utvrderas tre medierna. Var och en av de tre me- diebearbetningsanvndningsfall utvrderas i ett visst utplacering arkitektur Ska↵a nyckeltal (KPI) fr anvndning i framtida ntverk, och 5G: ssom ntverksbaserad media bearbetning (NBMP). Contents
1 Introduction 1 1.1 Background Information ...... 1 1.2 ResearchPurpose...... 1 1.3 Motivation ...... 1 1.4 Challenges...... 2 1.5 Researchquestions ...... 2 1.6 Thesisoutline...... 3
2 Technical Background and Related Work 4 2.1 Media Delivery ...... 4 2.1.1 HTTP adaptive bitrate streaming ...... 4 2.1.2 Live and on-demand streaming models ...... 4 2.1.3 Multimedia container formats and media descriptor languages ...... 5 2.1.4 Mediaprocessingsoftware...... 7 2.2 Cloud Computing ...... 8 2.2.1 Computing Virtualization ...... 8 2.2.2 Network Virtualization ...... 9 2.2.3 Container orchestration engine ...... 9 2.2.4 Functionasaservice...... 10 2.2.5 Edge computing ...... 11 2.3 Related Work ...... 12 2.3.1 Media processing operations in the network ...... 12 2.3.2 Clouddeploymentarchitectures...... 14 2.3.3 Mediaprocessingfunctions ...... 14 2.4 Our Contribution ...... 15
3 Media processing Function Use cases 16 3.1 Content packaging ...... 16 3.2 VideoTranscoding ...... 18 3.3 ContentAdInsertion...... 19
4MediaProcessingDeploymentDesign 20 4.1 Software Components ...... 21 4.2 Cloud Technology Components ...... 22 4.2.1 Hypervisor-based virtualization deployment technology ...... 22 4.2.2 Container orchestration deployment technology ...... 23 4.2.3 Serverless deployment technology ...... 25 4.3 DesignDecisions ...... 26 4.3.1 Cloud deployment technology decisions ...... 27 4.3.2 Ad insertion prototype design using Container Orchestration ...... 29
5 MediaProcessingDeploymentImplementation 32 5.1 Introduction...... 32 5.2 VMDeploymentImplementation ...... 34 5.2.1 Mediaprocessingimplementationprocedure ...... 34 5.3 Container Orchestration Deployment Implementation ...... 35 5.3.1 MediaprocessingImplementationprocedure...... 35 5.4 ServerlessDeploymentImplementation ...... 36 5.4.1 Serverless cloud provider implementation overview ...... 36 5.4.2 MediaprocessingImplementationprocedure...... 36 5.5 Ad Insertion Prototype Deployment Implementation ...... 38 5.5.1 Mediaprocessingimplementationprocedure ...... 38
6 Media Processing Deployment Evaluation 40 6.1 Load Generator Tools and Measurement Specifications ...... 40 6.1.1 MediaprocessingwithCGIexecution ...... 41 6.2 Use case (A) : Content packaging results ...... 43 6.2.1 VMs in content packaging ...... 43 6.2.2 Serverless in content packaging ...... 44 6.3 Use case (B) VideoTranscodingresults ...... 47 6.3.1 VMs in Video Transcoding ...... 47 6.3.2 ServerlessinVideoTranscoding...... 48 6.4 Use case (C) Contentstitchingresults ...... 48 6.4.1 VMincontentstitching ...... 50 6.4.2 Serverlessincontentstitching...... 51 6.5 Use case (D):ContentAdInsertionresults ...... 53 6.5.1 Container orchestration setups ...... 53 6.5.2 Measurement procedure for Ad insertion prototype ...... 54 6.5.3 Container orchestration for Ad insertion results ...... 54
7 Conclusion and Future work 58 7.1 Conclusions...... 58 7.2 Limitations and Future work ...... 59 7.2.1 Implementation constraints ...... 59 7.2.2 Futurework...... 59
Appendices 65
A Serverless Cloud Provider Evaluation 66 A.0.1 Serverless provider performance evaluation ...... 66 A.0.2 Serverlessproviderperformanceresults...... 67
i Chapter 1
Introduction
1.1 Background Information
This project was carried out at Unified Streaming, which is a leading company in streaming services located in the Netherlands. Unified Streaming provides streaming software for o✏ine and on-the-fly packaging content video and audio. Its software is based on C/C++ module and also possible to use on most common web server plugins.
1.2 Research Purpose
We are in a new era of media entertainment which o↵ers viewers endless choices for media consumption, from watching our favorite TV shows, to live streaming sporting events, to following camera feeds on social media in real-time. Consequently, the increase of data tra c through the networks has escalated dramatically, and network operators and service providers are struggling to serve the fast-growing media tra c over existing infrastructure. By 2020 Video tra c is expected to increase up to 80% from all Internet tra c [23]. HTTP Adaptive Bitrate Streaming (ABS) has converged as the primary transport protocol for delivering video over the Internet. The Cloud Services have evolved exponentially by providing ease of access to powerful computing resources in multiple locations. They have developed other novel technologies to improve the provisioning of resources such as Function as a Service(FaaS) and microservices based technologies. These allow to develop, run, and deploy code with specific functionality without controlling the back-end infrastructure. This thesis looks into the performance evaluation of di↵erent cloud technologies available to deploy media processing functions, which can help to achieve target KPI’s for 5G networks and improve the e ciency of media distribution. Cloud technologies such as hypervisor virtu- alization, containers, micro-service, and cloud functions will be used in this research. Chosen media processing functions are based on a di↵erent level of computing complexity in streaming services: content packaging, video transcoding, and content stitching.
1.3 Motivation
There are several motivations to carry out this work. First, the Future networks such as 5G, which can provide distributed cloud computing at the edge. For media delivery, it is attractive because it allows to run specific media processing functions at any point of the network.
1 For instance, a late-transmuxing seen in [46], provides higher performance than a CDN when delivering content, and a server-side ad insertion, which increases level of user personalization. This last one can be achieved by the deployment at strategic geo-locations/edges.
1.4 Challenges
The bottom line of this work it is to embed media processing in cloud-native networks envisioned in 5G. The cloud technologies are not explicitly developed for media processing. Therefore, certain adaptations into the design and implementation will take into account to achieve media processing functions with low latency, handling high volumes of data, and within a large number of users. Virtual Machine(VM), container, microservice, and cloud function, hence this study needs to look at the performance of deployment in di↵erent use cases.
1.5 Research questions
1. Q: ”Are cloud technologies suitable for the deployment and processing of media functions at the edge of the network” This thesis will investigate novel cloud technologies such as VMs, containers, and serverless by the assessment evaluation of media processing functions KPIs. It presents specific media functions used in streaming architectures with a distinct level of computational complexity.
(a) Q: ”What is the state of the art to support media processing functions in the cloud?” Our second research question aims to explore related work to find out what kind of media processing technologies and infrastructure systems have been developed in the past, and which technologies are available for the next generation of 5G Networks in Advanced Streaming services. (b) Q: ”What are the di culties and considerations for the design and deploy- ment of media processing functions using cloud technologies?” Our third question relies on the technologies available, the decisions made for using each of the deployment architectures. It relates to the supported features of each cloud provider, and the ease of deployment for the di↵erent use cases of content packaging, video transcoding, and content ad insertion. (c) Q: ”Which challenges are presented when implementing di↵erent use cases of media processing functions within cloud deployment technologies?” Our fourth question is based on how well our experimental setups of media processing function can be deployed using cloud technologies. This question will able to be answered by carrying out the di↵erent experimental setups. Consequently, it will provide a baseline to chose the most suitable deployment architecture for a (Video on demand)VOD Ad Insertion prototype. (d) Q: ”What is the performance evaluation of the chosen cloud deployment technologies?” Our final question relies on the results and experimental findings from each deployment architectures and media processing use case. It aims to provide critical KPIs from the di↵erent cloud setups and identify if cloud technologies are a suitable method for advanced streaming services.
2 1.6 Thesis outline
Chapter 2 presents related work and technical background based on the evolution of Cloud computing media distribution. Chapter 3 describes the chosen use cases of the selected media processing functions use cases. Chapter 4 and 5 introduce the design and implementation re- spectively, for each media processing function. Chapter 6 presents the evaluation of the di↵erent experimental setups and the evaluation results. Finally, chapter 7 concludes this thesis and outlines future research directions.
3 Chapter 2
Technical Background and Related Work
This chapter is divided into six sections. First, it introduces key concepts for media deliv- ery. Second, it presents a cloud computing background that we will use throughout this work. Third, it introduces the background of future networks like 5G networks and useful virtualization technologies. Fifth, we present the related work to this thesis. Finally, we present a summary of the contribution to this thesis.
2.1 Media Delivery
Video streaming enables clients to play back video while the content is downloaded, in comparison to a normal file, where the user must download the entire file before making use of it.
2.1.1 HTTP adaptive bitrate streaming Video streaming on the Internet has concentrated on delivery using HTTP as the primary transport protocol. In addition, HTTP provides keys benefits, like the re-use of the existing In- ternet infrastructure, such as caching and application servers. Additionally, the HTTP protocol is stateless. If an HTTP client requests data, the servers reply by sending the data, and the trans- action is terminated. To address this problem, ABS over HTTP can subdivide a large-source video into small media segments. These smaller media containers can be downloaded and de- coded independently by the client-side player. Furthermore, this approach allows quality/bitrate switching for each of the segments on the client side relying upon the network conditions [63]. Most popular streaming transport protocols for ABS have been developed in the past decade by di↵erent companies and standardization groups, for instance Apples HTTP Live Streaming (HLS) [15], Microsofts HTTP Smooth Streaming (HSS) [48], Adobes HTTP Dynamic Streaming (HDS) [14], and MPEGs Dynamic Adaptive Streaming over HTTP (MPEG-DASH) [51].
2.1.2 Live and on-demand streaming models Figure 2.1 shows the two most common end-to-end video streaming models: live streaming and VOD. The live streaming model uses a live encoder as a media source, which compresses
4 and encodes the media ingest in real time. The streaming server/compute node packages the media data to di↵erent streaming protocols and supplies the videos to the client. The VOD model uses stored multimedia files that are normally already encoded and packaged in multiple format specifications. However, the compute node is still capable of just-in-time configuration, serving the media files based on the users device requirements. Over-the-top media services use CDNs to distribute the content on a large scale. The CDN uses the best possible server based on the geographical proximity to the client. The CDN reduces latencies by caching the requested content from the client device. On the client side, the device renders the video on display.
Figure 2.1: Live and on-demand streaming models using a compute node.
2.1.3 Multimedia container formats and media descriptor languages Multimedia data streams are based on container formats. The information inside the con- tainer is divided into two type of information: the physical data and the metadata. For instance, metadata is needed when the client device uses information such as subtitles, compression stan- dards, and bitrates, among others. In video streaming, there are two main multimedia formats: MPEG-2 transport streams (MPEG-2 TS) [24] (extensions: .ts, .tsv, and .tsa) and Interna- tional Organization for Standardization (ISO) base media file formats (ISOBMFF) [39] (MP4, fragmented MP4, and data reference (dref) MP4). Apple adopted this standard in their HLS protocol, becoming an important standard for the video streaming industry. The MPEG-2 TS is based on multiplexing together audio, video tracks, and metadata. The MP4, fragmented MP4 (fMP4), and dref MP4 containers are part of the MPEG-4 Part 12 standard, which covers the ISOBMFF. The MP4 container became a widely adopted format.
ISO base media file format container specifications An MP4 media container is formed of a file type box (ftyp ), which provides the compatible brands and specifications of the file. The movie box (moov) represents the container box that contains metadata (e.g., title, tags, descriptions, time, etc.) for the media presentation. The movie fragement box(moof) contains the information about sample locations and sample sizes. The box type (stbl) refers to the table that contains all the time and data indexing of the media samples in a track. The media data box (mdat) is the container box, which holds the actual media data for the presentation. Figure 2.2b shows the fMP4 container, which has interleaving moov and moof boxes in comparison to only one moov type box from the MP4 container shown in Figure 2.2a. The dref MP4 container is a data reference box specified in the ISOBMFF [39]. It is defined as a data reference object. It contains a table of data references as URL locations
5 of the actual media data used within the presentation. Figure 2.2c shows an example of five referenced video tracks.
(a) MP4 Container (b) fragemented MP4 container (c) dref MP4 container
Figure 2.2: ISO base media file format container types.ISO base media file format container types.
Synchronized Multimedia Integration Language media files Synchronization Multimedia Integration Language (SMIL) 2.01 is a markup language that describes multimedia representations. It allows handling parameters, such as time, layout, ani- mation, visual transitions, and other multimedia specifications. It provides a simple method to read di↵erent video content sources that must be stitched together. Compared to other media formats, the SMIL file was a convenient choice that fit the use-case requirements for content ad insertion. Figure 2.3 shows a SMIL example file with a pre-roll example, showing a five-minute video of Tears of Steal content, plus five seconds of content from an advertisement.
1https://www.w3.org/TR/2005/REC-SMIL2-20050107/
6 1 2
Figure 2.3: SMIL File example
2.1.4 Media processing software To meet the multiple device requirements, such as transport protocols, container format, and video compression standards, among others in a streaming pipeline, there must be media pro- cessing functions that can process the data into the required format. This subsection introduces some of the most popular software modules for media processing in streaming services.
Unified Packager Unified Packager is a software program developed by Unified Streaming, which uses MPEG- 4 files to produce segmented output in the most common formats, such as HLS, MPEG-DASH, HDS, and MSS, among other formats [19]. It supports advanced features for adding multiple audio codecs and provides tools for encrypting content through Digital Rights Management (DRM) [20].
FFmpeg FFmpeg is a leading multimedia framework. It is capable of decoding, encoding, transcod- ing, multiplexing, and demultiplexing, among other media processing features. It is an open- source software-based compatible framework across multiple operative system platforms [31]. We will use FFmpeg due to its accessibility as an open-source software.
Unifed Remix Unified Remix is a C/C++ module developed by Unified Streaming, which mixes multiple video clips into a single stream, so players do not see any discontinuity. Unified Remix software matches the best bitrate track and resolves time challenges in case video or audio tracks are not synchronized [21]. This procedure is carried out in two steps: stitching sequences of video into a final dref MP4 file and requesting the stitched content by an Origin server.
7 2.2 Cloud Computing
Cloud computing has emerged as a cost-e↵ective alternative to having reliable computing resources without owning any of the infrastructure [60]. It combines servers with data centers to provide computing resources that can be accessed through the Internet. Consequently, customers can request resource variants such as CPU, memory, storage, bandwidth, among others. These services are commonly provided in three di↵erent models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service(SaaS). However, cloud providers have been able to combine this three models into services that can attract other business needs. Container as a Service (CaaS), Function as a Service (FaaS) and Backend as a Service (Baas) are the product of the three first models. CaaS, FaaS, BaaS, and aim to provide ease of deployment and reduction of costs. Consequently, financial models such as pay-as-you-go or on-demand help to manage these services. In figure 2.4 it shows the most common computing services o↵ered by cloud providers. From left to right it shows the high to low level of control.
Figure 2.4: Cloud services resource control
2.2.1 Computing Virtualization A virtual machine (VM) is the process of emulating a computer system. It is based on com- puter architectures that supply functionality like a physical computer. Each VM have their own virtual hardware and guest OS. Computing virtualization is divided into two main virtualization types: Hypervisor-based virtualization and Operating-system-level virtualization. Hypervisor-based virtualization allows running di↵erent operating systems as virtual ma- chines. This is achieved through the use of a hypervisor, which controls each of the virtual
8 machines that run on top of the host. The hypervisor creates the communication between the host and the virtual machines for resource allocation. Virtual machines o↵er isolation regarding disk, memory space and operating system. However, virtual machines can still share a network interface with the host machine leading to a possible bottleneck [25]. Operating-system-level virtualization method creates multiple virtual instances. However, they do not run its own guest operating system or kernel in comparison to hypervisor-based virtualization. They can only be run with the same operating system as the host. A container is an example of operating-system-level virtualization.
2.2.2 Network Virtualization Network virutalization aims to provide virtual resources on top of computing hardware.This type of virtualization it is mostly focused on telecommunication companies that are looking to deploy in cloud computing infrastructure all their services that normally are based on legacy hardware.
Network function virtualization Network Function Virtualization (NFV) is a term in the modern network architecture, which allows the virtualization of network nodes functions through di↵erent technologies into building blocks [4, 29]. NFV has gained great popularity by pushing the technology a network standard by the European Telecommunications Standards Institute(ETSI) [5]. NFV focuses on the virtualization of a software-based network node with security and resilience profile, as the firewalls and intrusion detection [49]. Complementary to the NFV, Software Defined Network (SDN) separates the control plane from the data plane in networking operations, thereby granting superior visibility, dynamic resource provisioning, and flexible service deployments [45]. NFV and SDN are two technologies with great promise perspective of high visibility, agility, and flexibility to enable innovative architectures for multimedia distribution, potentially trans- forming the entire delivery chain of multimedia contents. For example, recent research proposed by Sahhaf and Tavernier [58] explore the use of NFV for dynamic composition of service chains of connected services (e.g., firewall, network address translation (NAT), intrusion protection, load balancers) and the SDN for their fine-grained analytics collection (e.g., entries on ingress nodes, reporting of microflow packet counts), and interaction with the Cloud and NFV [22]. Finally, NFVs and SDNs are both network virtualized services capable of replacing networking devices by the ease of deployment on top of VMs or any computing IaaS.
Multi-access edge computing Multi-access Edge Computing (MEC) is a new architecture technology started in Septem- ber 2014 by the European Telecommunications Standards Institute (ETSI) [29]. This technology aims to provide mobile user devices with ultra-low latencies (below 10ms) by bringing the com- puting resources as close as possible to end-user devices. MEC base architecture is composed of four elements: MEC host, MEC app, and remarkable e cient network, and service delivery within the Radio Access Network (RAN).
2.2.3 Container orchestration engine This section represents the main components of a production-grade container orchestration engine. It describes their specifications and software modules. However, due to the great exten-
9 sion of this area, it will only be described the modules used in this work. For further information about Kubernetes software, please refer to the o cial documentation2.
Container A container is operating system-level virtualization capable of running in a determined host. Containers are base on operating-system-level virtualization. They have been a virtualization method for many of today applications with a server-oriented repackaging of a Unix-style process [16]. Container technologies such as Oracle [12], Windows [13], or the most well known Docker [3] enables developers to immediately spin up new services without slow provisioning, and run-time up above virtual machines.
Kubernetes: container orchestration engine Kubernetes [9] is an open-source software orchestrator for container environment. The software was born from Google’s Borg system cluster management that ran thousands of di↵erent applications, across many clusters with up to tens of thousands of machines[62]. Initially, the software was designed to run on bare-metal machines and virtual machines, but later on, cloud providers developed their own containerized cluster management based on Kubernetes core- software.
2.2.4 Function as a service Functions as a Service (FaaS) computing is a modern paradigm that looks to transform how we build, deploy, and manage online applications and services [35]. Serverless architectures are application designs that incorporate third-party BaaS, and/or that include custom code run in managed, ephemeral containers on FaaS platform [57]. Consequently, serverless Computation attracts developers by reducing the high costs of buying and maintaining large numbers of ma- chines, and given the fact that some these servers were underutilized, thereby it opens an excellent perspective for virtualization of systems [18]. Virtualization allows astounding consolidation of services on top of servers, which consequently reduces cost and improves manageability. Figure 2.5 shows a comparison between cloud services with high speed of initialization against of cloud services where the server-aware its characterized by longer running time process. Existing implementations about FaaS computing model has developed by certain Cloud providers o↵ering the concept of Serverless computing. Most popular serverless computing platforms such as Lambada[1], Google Functions [7], Azure functions [10], among others.
2https://kubernetes.io/docs/home/
10 Figure 2.5: Esase of scaling VS Average time-to-live [17]
2.2.5 Edge computing Edge computing is a term used in Cloud services for placing computational resources, power and communication capabilities at the edge of the networks as shown in figure 2.6. Edge comput- ing can use the virtualization technologies like VM, container, microservice, serverless, among others. The di↵erence from other cloud computing systems is the geographical distribution of nodes close to the end-user location [43]. Allowing a higher application performance, thanks to the ultra-low latency and high throughput between the user device and the requested application server. Compared to traditional CDN, edge computing allows to achieve processing at the edge, and use the available CPU. Consequently, this work aims to investigate how to enable and deploy virtualization technologies for edge/network-based media processing.
11 Figure 2.6: Central, Regional, and Edge cloud distribution
2.3 Related Work 2.3.1 Media processing operations in the network Due to the nature of streaming services with multi-protocol formats, the creation of dis- tributed warehouses with numerous versions of the same content distributed through the CDN leads to redundant CDN caching and transport of media data. In addition to this constraint, streaming services models, such as VOD rely on the consistent access to backend storage. This creates a bottleneck in the backend tra c from the media processing entity to the media source. To address some of these problems and challenges for emerging network environments, MPEG has proposed a cloud-native media processing standard: NBMP [50]. The primary goal of NBMP is to define the reference frameworks and interfaces between the media sources and media processing functions in the cloud or the network. Moreover, NBMP describes the composition of NBMP functions using application programming interfaces (APIs) to control and use NBMP services. The NBMP framework will define external interfaces between the media sources/media sink and media processing entities. Figure 2.7 shows the NBMP framework. It describes a media processing entity that retrieves from the media source and processes the media through processing functions, and then it services the media sink of the user device. Figure 2.8 shows the NBMP framework based on central cloud and edge cloud computing for each of the media processing entities. This form allows retrieval of the multimedia content from the media source and interaction with di↵erent deployed media processing functions at the edge of the network. The NBMP has a great potential to handle many of the problems of video streaming. Additionally, previous work, such as late-transmuxing [46] and the backend storage caching scheme [41], prove that moving a media processing node in the edge can address some
12 Figure 2.7: Network-based media processing system framework. of the current limitations.
Figure 2.8: Network-based media processing vision for the central edge of the network.
13 2.3.2 Cloud deployment architectures In media delivery, VMs are one of the most commonly used resources in IaaS. They allow controlling applications, data, runtime, middleware, and OSs, by providing powerful computing to run media processing services, such as an Origin server for video streaming, video encoders, or even transcoder modules. Nevertheless, the primary concern of streaming platforms and broad- casters is to ensure their services can scale from one user to thousands of users in a short period with fast instantiation on their VMs. Broadcasters most natural solution is to over-provision VMs for the client-server demands, but this might bring capital expenditure and operational expense. Our objective in designing media processing functions using VMs is to obtain initial baseline metrics on how the VM can escalate and perform during VOD streaming with separate ad-insertion media functions. Docker containers have emerged as the preferred technology for most developers and the industry for the distribution of web applications. They can run on top of guest host OSs with ease of deployment procedures, allowing portability, reliability, and continuous development over its applications. The use of containers in streaming platforms has rapidly transitioned from deploying on bare-metal servers to the deployment of containers on top of VMs. In [25], nearly identical performance is obtained for containers and bare-metal setups, and no overhead was present in contrast to VMs. It shows containers are a powerful tool for media processing functions with ease of deployment and high performance. Di↵erent performance analyses were explored by Padala et al. [55], comparing OpenVZ containers, Xen VMs, and base Linux setups. These results are encouraging by observing a high- performance container compared to hypervisor virtualization. However, they do not provide a performance assessment for media delivery as ABS, comparing more than one deployment architecture. In [25], the performance of hypervisor-based virtualization was demonstrated to have a relative higher overhead when using streaming media processing functions compared to bare-metal machines and Docker containers. The term ”serverless has not only obtained significance among the distributed and man- agement systems but also from developers that can focus directly on the coding scheme rather than infrastructure management [42]. As observed by McGrath and Brenner [44], serverless per- formance can be improved by the handling of network latency, clocking considerations, language runtimes, and function code size. Moreover, it must consider the di↵erence between event types and CPU allocation scaling.
2.3.3 Media processing functions In [40, 64], di↵erent methods are explored for transcoding in the cloud. First, [40] explored the tradeo↵strategy for cost-e cient transcoding, which reduces the total IaaS cost in the cloud. This is achieved by using a VM deployment method in a dynamic cluster creation. Nevertheless, this approach provides cost-e ciency after a 15-day period. This clearly shows a disadvantage for short periods of transcoding demand. Second, [64] introduced a video segmentation approach and proposed a segment-based storage. This system design approach decides which versions of segments are stored or transcoded to minimize the total IaaS costs. However, it only takes into consideration continuous transcoding load during a 1-9 period week, which is a disadvantage of variable demand in transcoding. In video delivery, these two last procedures might create multiple copies of the same content in di↵erent compression formats, increasing the backhaul tra c and cache storage. To reduce this overhead, other techniques for running media functions at smart edges, as seen in [46], can improve the overall performance in media delivery.
14 This thesis examines the design and implementation of di↵erent cloud deployment tech- nologies. The primary objective is to ascertain whether cloud technologies, such as hypervisor virtualization, container orchestration, and serverless functions, are viable means for using edge media streaming processing functions.
2.4 Our Contribution
1. Design and implementation of media processing functions for content packaging, video transcoding, and content stitching using cloud technologies. 2. Performance evaluation assessment for media processing functions using hypervisor virtu- alization, container orchestration, and serverless functions. 3. Assessment performance evaluation for serverless functions based on di↵erent cloud providers. 4. Design, implementation, and evaluation of a VOD Ad insertion prototype using container orchestration deployment.
15 Chapter 3
Media processing Function Use cases
This chapter represents the three chosen media processing functions of content packaging, video transcoding, and content ad insertion. It provides a description for each of the media processing functions and the requirements in a media delivery architecture.
3.1 Content packaging
Packaging content is the operation of enclosing metadata and video material in one specific format and/or transport protocol. Content packaging is a powerful processing function in media delivery. The procedure allows using the metadata and the actual data from the multimedia content to provide multiple services: first, to serve multi-protocol streams for di↵erent brand devices, providing video delivery interoperability between the media source and the clients device and, second, in the case in which companies that manufacture devices (e.g., Apple and Microsoft) decide to update OS devices, hitting device playout requirements. By using content packaging, it is possible to downgrade or upgrade media streams to fit the correct version of the player device without all of the content. Another example of the importance of content packaging is the use of encryption for content protection. Through on-the-fly content packaging, it allows encrypting, changing the security level, adding multiple keys, or changing the DRM vendor for the content while the content is streamed.
Figure 3.1: Packaging content example.
16 Table 3.1: Adaptive Bitrate Streaming especifications
Most common media streaming formats Developed Protocol Media Manifest Video Segment by container file codec length DASH MPEG-2 TS XML/MPD H.264,H.265 1-10 sec MPEG DASH fMPEG-4 XML/MPD H.264,H.265 1-10 sec HLS MPEG-2TS M3U8 H.264,H.265 10 sec Apple HLS fMPEG-4 M3U8 H.264,H.265 10 sec Microsoft HSS PIFF* XML/ISM/SMIL H.264,VC-1 2sec Adobe HDS F4V* XML H.264,VP6 4sec
In practice, video delivery using multiple protocols is needed to support the full range of clients in the digital media ecosystem. However, there is a definite disadvantage for streaming platforms, such as Internet TV broadcasters, who are encountering problems when caching and distributing almost duplicate segments requested for each protocol through the CDN. Therefore, one approach is to reduce backhaul tra c and cache storage and to move the media processing function to the edge of the network. This method has proven to work in [46] by moving the multi-protocol conversion node to the edge, providing higher performance compared to common CDNs. Nevertheless, there has not been a further exploration using other deployment methods other than hypervisor virtualizations, raising questions regarding the cost and performance that can be obtained using other cloud technologies for content packaging at the edge. Table 3.1 shows the most popular streaming formats with the most common specifications. How- ever, due to the vast extent of the di↵erent formats, protocols, updates, and other specifications, content packaging has become a vital media processing function in media delivery.
17 3.2 Video Transcoding
Transcoding is a media process based on the conversion from the code description type into di↵erent code representations. The procedure is known for its high demand on hardware resources (CPU). Video transcoding can be used when the client-side device does not meet specific requirements for the video content format. For example, when the client side does not meet the exact bandwidth requirements, then reducing the bitrate of the content through transcoding is widely useful. Additionally, transcoding can be used when the client device does not meet the supported compression standard, such as high-e ciency video coding (HEVC)/H.265.
Figure 3.2: Example: Transcoding video content form HEVC to AVC.
The current methods of Internet video delivery, such as HTTP adaptive streaming, require either abundant amounts of storage capacity where full encodings of the content are conserved at all times, or extensive computing resources to generate content on demand. In our second use case for video transcoding, we aim to first obtain a comparative evaluation of performance from di↵erent deployment methods and understand its viability for transcoding at the edge of the network.
18 3.3 Content Ad Insertion
Ad insertion is the action of stitching video content from one or multiple video clips into one content stream. The procedure of dynamic ad insertion is carried out by selecting specific time markers to create one-clip content based on media descriptor languages, such as SMIL files or by exploiting splice points such as SCTE35 [26]. It indicates the video sources to mix, like the starting and stopping points of the newly created clip. For example, broadcasters might use dynamic ad insertion based on live streams, such as football highlights, on which a bumper is inserted at the desired point of the stream without any discontinuity on the client side. This example is shown in Figure 3.3.
Figure 3.3: Use case 2: Ad insertion process overview [34]
Media services, such as Internet video streaming, are becoming highly prominent, especially ABS protocols, such as MPEG-DASH [51] or Apple HLS [15], that use the HTTP protocol for content distribution. Therefore, inserting content, such as advertisements or personalized or edited content, is an important monetizing method for content owners or other service providers. One of the advantages for content ad insertion from Internet media broadcasters to traditional broadcasters is the full content personalization that can be given to each of the Internet connec- tions (instead of a broadcaster stream of one to many). However, online video streaming can also encounter complications when inserting video content. First, there is less control over the software running at the client side and over obstacles, such as ad-blocking software, di↵erent player implementations, and manifest manipulation, as proposed in [28], which does not fully satisfy the advertisement insertion procedure. A second solution based on the server side re-encodes all content and stores multiple media representations. However, this can bring high costs to the infrastructure, storage, and compu- tation resources. A third approach, also on the server side, is based on a microservice container architecture for media processing functions, seen in [63]. This solution is based on standardized technologies, such as MPEG-4 ISOBMFF, and descriptor multimedia languages, like SMIL files. This last solution successfully overcomes the two previous cases.
19 Chapter 4
Media Processing Deployment Design
Designing three use cases for media processing functions in the cloud with three di↵erent deployment architectures is quite challenging. Each deployment technology has a di↵erent ar- chitecture and deployment procedure, making it a complex task to interact with each of the technologies. However, certain decisions have to be made. Most of the next decisions are based on the available deployment technologies and supported features. This chapter describes the technology advantages and disadvantages in making these de- cisions. First, we introduce the software components used for the deployment of our media processing functions. Second, we provide an overview of the supported features of each cloud technology. Third, we provide the decisions for the design of using the chosen deployment tech- nologies. Finally, we present an ad insertion design prototype based on container orchestration.
Figure 4.1: Media processing design and deployment model.
Figure 4.1 shows the high-level design of the software components acting as the media processing functions and the deployment technology inside the cloud provider region.
20 4.1 Software Components
This section represents the software components used for the deployment of media processing functions. The purpose and some specifications of each software component are explained.
Unified Packager software The mp4split is a C/C++ software module that allows packaging multimedia content from standard media containers, such as MPEG-4 and fragmented MPEG-4 to ABS formats, such as MPEG-DASH, HLS, HDS, and HSS, among others. The mp4split software is used as a command-line software in multiple OSs.
Ffmpeg module software The FFmpeg module software is a popular multimedia processing open-source software based on C/Assembly. It is a command-line and software-based processor and is widely used for video format transcoding, basic editing, and video scaling, among other functions. Its architec- ture depends on other libraries, such as libavcodec [32], which makes it a powerful tool for media functions that test and develop.
Unified Remix software Unified Remix is also a C/C++ software module that allows the creation of a reference MP4 (ISOBMFF) based on SMIL files through its command-line interface. This software provides a lower level of computing complexity compared to content packaging and video transcoding.
Apache & Nginx software Apache [54] and Nginx [37] are two of the web servers that dispatch multiple requests on the client side. The main di↵erence between these two servers is the way to handle HTTP client requests. For Nginx, it works using an event loop system to handle multiple requests in one process. On the other hand, the Apache web server dispatches HTTP requests by releasing numerous threads to handle a higher number of requests. Nginx can process more concurrent requests than Apache if we compared them with the same computing resources. In this work, the Apache web server fits better as an application server by the dynamic load of modules through configuration files. This type of method has made Apache a good and popular web server.
21 4.2 Cloud Technology Components 4.2.1 Hypervisor-based virtualization deployment technology Hypervisor-based virtualization has become one of the most popular technologies in any cloud infrastructure by providing VMs for almost any type of need or purpose. Most of the VMs that cloud providers o↵er are based on common factors, like vCPUs, storage, memory, or bandwidth. Additionally, cloud OSs like OpenStack [11] allow monitoring and managing a large cluster of VMs from the cloud provider infrastructure. For instance, the Superfluidity project [59] uses OpenStack for the dynamic deployment of VMs in a streaming architecture. However, in this research, we focus on stand-alone VM to obtain a baseline on the di↵erent use cases of media processing functions.
VM instances Table 4.1 shows three di↵erent instance types from the selected Azure Cloud provider. Each instance is ordered by the Azure Compute Unit (ACU), which allows the comparison of compute (CPU) performance across all Azure VM1 instance families. In contrast to the memory-optimized instance, it provides the caching memory size instead of the ACU.
Table 4.1: Azure VMs instance selection.
Type Model ACU vCPU Memory: Temp Bandwidth family (GiB) storage(GiB) (Mbps) D2s v3 160-190 2 8 50 1000 General DS1 v2 210-250 1 3.5 7 750 Purpose DS2 v2 210-250 2 7 14 1500 DS3 v2 210-250 4 14 28 3000 Compute F16s v2 195-210 16 32 128 7000 Optimized Memory E2s v3 (50GiB cache) 2 16 32 1000 Optimized
1https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes
22 4.2.2 Container orchestration deployment technology Kubernetes is a container orchestration engine and open-source software that can be in- stalled and deployed in di↵erent computing environments. In this research, we focus on the deployment of media processing functions in the cloud using microservice container architecture. There are multiple ways to deploy the Kubernetes orchestration engine [9]. The three most com- mon methods for installing the software are the following: on a local machine, hosted in a cloud service, or in a bare-metal server installation. For experimental purposes, we focus on the second option of hosted services, which is a CaaS. The most popular providers who o↵er Kubernetes Management Service are the following: Azure Kubernetes Service 2 by Microsoft Azure, Google Kubernetes Engine 3 by Google Cloud Platform, and Amazon Elastic Kubernetes Service 4 by Amazon Web Services (AWS) . Nevertheless, there are a few advantages and disadvantages for each of the cloud providers that will be explained in the following sections. Table 4.2 summarizes the most important considerations between the cloud providers.
Auto-scale Kubernetes software is distinguished for its high deployment control in containers and its scalability procedure. A significant advantage for using Kubernetes Cluster Management in a hosted provider compared to bare-metal installation is the increase of instances (nodes) at a horizontal level. The automatic scaling mode of cloud providers aggregates nodes based on the CPU usage threshold. For the case of Azure and AWS, this method can be controlled manually. It means that we can increase the number of computing instances from the infrastructure gradually without the need to set up a threshold.
Ingress controller and load balancer Each cloud provider o↵ers a load balancer service, which interacts with the computing nodes of the managed Kubernetes cluster based on inbound and outbound requests. This service has a cost for used time, and unfortunately, it has a few limitations, such as monitoring each of the container services. However, it can be configured as an ingress controller to manage the load balancer. This can provide basic monitoring for each of the containerized media functions.
YAML scripts Through the use of data serialization languages, such as YAML, files allow the ease of deploy- ment of containers in its configurations. It facilitates configuring before deployment parameters, such as the container image to download, number of nodes, number replications, number of pods, number of deployments, size of the cluster, and network configuration, such as exposed ports. This type of script is quite useful when deploying multiple Kubernetes clusters with a specific configuration.
Network policy Each of the cloud providers supplies security rules for the communication between the nodes of the cluster and load balancer, providing several configuration rules like a firewall and exposed ports. The AKS from Azure does this process in automatic form without the need to create any
2https://azure.microsoft.com/en-gb/services/kubernetes-service/ 3https://cloud.google.com/kubernetes-engine/ 4https://aws.amazon.com/eks/
23 security rules in the deployment configuration file. This may be an advantage in case there is no needed security layer in our deployment testbed.
Command-line management The command-line interface (CLI) management tool is o↵ered by Azure and Google Cloud, but not fully for AWS. The advantage of using a full local CLI is to provide continuous develop- ment and an easier method of deployment of a cluster without the external remote connection to the cloud provider website.
Table 4.2: Kubernetes Cluster Management provider comparison.
Kuberentes management provider comparison Feature Azure (AKS) Google (GKE) AWS(EKS) Auto-scale Manual Automatic Manual Network policy Automatic Manual Manual Load Balancer Yes Yes Yes Upgrades On-demand Auto/On-demand Auto Mangement by CLI Full Full Partial Kubernetes verison 1.9.1-gke 1.8.12-gke.2 1.10-gke
24 4.2.3 Serverless deployment technology This subsection represents the third deployment technology of serverless computing. The motivations for this research using serverless deployment technology is to first understand its performance in media processing functions and, second, to analyze its viability for streaming architectures on specific media processing use cases. Most of the decisions taken were based on the o↵ered features from each of the providers. Some of these features are shown in Table 4.3.
Max execution duration Azure and IBM Cloud stand out for the maximum function execution time of 10 minutes compared to the AWS provider, which in contrast has the lowest execution duration time of 5 minutes. Therefore, choosing the maximum execution time may provide better results in case the media processing function needs more time to execute.
Scalability From all the providers, Azure Functions can be configured on a manual and automatic form. The manual configuration allows assigning some computing resources (CPU and memory) on a monthly plan. This will provide more computing resources in case the media processing function needs to scale. On the other hand, the automatic scalability (consumption plan) is based on an automatic scheme by providing specified CPUs from the cloud provider.
Continuous deployment The Azure function platform has the most deployment procedures, allowing di↵erent source controls for deploying code in contrast to AWS and OpenWhisk, which use only three or two methods.
Supported operating system The supported OS is one of the most important elements for the selection of a serverless computing platform. In the case of the Azure platform and IBM Cloud, both support Docker containers, which consequently is a great advantage among the other providers to build one image with all dependencies in a development or production environment. However, Azure only supports its own specific Docker image, and OpenWhisk from Apache have customizable Docker images.
25 4.3 Design Decisions
Common HTTP gateway design Each cloud deployment technology has variants in architecture and access tools. However, our primary objective is to assess the performance of each of the deployment technologies using the respective media processing software component. Above all the deployment technologies, serverless computing architecture provides a built-in HTTP interface to trigger the software component in contrast to VMs and container orchestration, which need to build an HTTP interface to trigger each of them. This type of design allows evaluation through a similar HTTP interface in all deployment architectures.
Software decisions For the first use case of content packaging, we use the mp4split software module due to its portability on Windows and Linux systems. However, we are aware that Unified Packager uses shared libraries in Linux kernels, which makes the Windows x64 build a favorable OS for the ease of implementation in all cloud deployment technologies. On the other hand, we have selected FFmpeg as our media processing software tool for our second use case of video transcoding. First, it is open-source software. Second, it can be run on di↵erent OSs compared to [33, 38]. Finally, FFmpeg supports video codec standards, such as H.264/AVC1 and H.265/HEVC, which we will need for the implementation stage. The final use case of content ad insertion, we have selected the Unified Remix software
Table 4.3: Serverless cloud provider specifications from 20 August 2018.
Serverless provider comparison Azure Google AWS IBM: Feature Functions Functions Lambda OpenWhisk Max. execution 10min 9min 5min 10 min duration Manual Automatic Automatic Automatic Scalability Automatic OneDrive ZIP Upload ZIP Upload Browser Editor Continuous Local CLI Cloud storage Cloud9 Editor Local CLI deployment GitHub Cloud repository Local CLI Bitbucket Local CLI Dropbox Env. App Settings Beta* Yes No variables ConnectionStrings (Since July 2018)* C#, NodeJS Node.js Node.js, C# Node.js Runtime F#, Python Python* Python,Java Python,Java language Batch, PHP (Since July 2018)* GO lang Swift PowerShell PHP,GO Supported Windows NA Linux Docker OS Linux Docker
26 module: first, due to it is accessibility to obtain the software and, second, because of its capa- bility to use media description languages, such as SMIL files. Additionally, we have selected an Apache web server as an application web server in the final ad insertion prototype, which allows loading the software modules through configuration files. This is quite helpful for the ease of implementation in di↵erent deployment architectures, such as VMs, containers, and FaaS cloud services.
4.3.1 Cloud deployment technology decisions Hpervisor-based virtualization The Azure Cloud was selected as the computing platform. It has a variety of VMs based on size, vCPU, storage, and bandwidth, among other elements. However, in this work, we focus on VM instances that best fit the media processing functions: general purpose instances,memory and storage optimized instances, and compute-optimized instances. For example, the general- purpose instance can provide a metric baseline by measuring the performance and cost of each of the selected media processing functions. Memory-optimized instances may be more suitable for smart-caching systems seen in [47]. Third, compute-optimized instances may be appropriate for media processing functions like video transcoding, which requires a specific number of threads and cores based on the compression standard applied (e.g., H.264 or H.265). Consequently, in our final design, we have selected the compute optimized instance F16s v2 shown in Table 4.1.
Container orchestration We have chosen Kubernetes Cluster Management as the container orchestration service, which is as a CaaS cloud computing. It o↵ers in a packaged method with all the software mod- ules needed to run Kubernetes on top of the cloud infrastructure. This method is an excellent alternative to reduce provisioning time, instead of installing Kubernetes software and building the computing infrastructure from scratch. Additionally, Kubernetes Cluster Management ser- vice brings flexible deployment, fast resource allocation, ease of scalability procedure, and an alternative to use the same cloud infrastructure where other services like content storage are located. The decisions for choosing a specific provider for CaaS are based on several reasons. First, AKS by Azure has an automatic security configuration compared to AWS and Google Cloud. In this work, the security of deployment is out of the scope, which allows focusing only on the implementation and evaluation of the testbed. Second, AKS can be used by the deployment of containers through the local CLI using YAML files. Using CLI has a significant advantage in continuous development, testing, and deployment of services. Finally, AKS allows manual horizontal scaling compared to the other providers. Manual scaling grants a gradual increase in the number of compute instances, which brings higher control to measure cloud media functions from a low to high number of instances during the evaluation phase.
Serverless deployment Most of the decision for choosing a serverless platform is based on the supported features showing on Table 4.3. However, before making a final decision, we have created an experimental setup to evaluate KPIs, such as requests per second and response time from each of the providers through a simple HelloWorld function. Through this evaluation, we obtained higher performance from AWS Lambda and Azure Cloud functions compared to the other two providers of serverless functions. Further information about this performance evaluation can be found in Appendix A.
27 Based on previous performance evaluation and supported features, we have selected the Azure Cloud Functions for our deployment testbed compared to the other providers for the following reasons: ease of deployment, highest execution time, manual and automatic scalability, continuous deployment by local CLI, highest number of supported runtime languages, and OS support for Windows, Linux, and Docker containers. We are aware that serverless computing is a new deployment paradigm, and it may not be a suitable technology for intensive workloads for long periods of time. However, its scalability component and fast provisioning attract the attention to implement modest streaming processing functions. Table 4.4 summarizes the software components that will be used in each testbed use case. It presents the media processing use cases side by side and the di↵erent cloud deployment archi- tectures to be implemented.
Table 4.4: Side-by-side use cases and cloud deployment technology.
Software components in di↵ereent deployment. Use case Hypervisor Container Serverless case virtualization orchestration function Packaging (USP mp4split) (USP mp4split) (USP mp4split) Transcoding (FFmpeg) (FFmpeg) (FFmpeg) Content (USP Remix) (USP Remix) (USP Remix) stitching
28 4.3.2 Ad insertion prototype design using Container Orchestration This subsection represents the last experimental testbed of an ad insertion prototype. In comparison to the previous design (Section 4.3.1), where each binary software module was wrapped in cloud technology and triggered to process one specific media task , here we design a prototype, which is close to a real-case scenario for a streaming platform. The ad insertion prototype is based on a microservice architecture using container orchestration. The idea behind this prototype design is to use the most mature cloud deployment technology of Kubernetes from the three used in Section 4.3.1.
Pods and nodes Kubernetes software does not run containers directly. Instead, it wraps one or more con- tainers into the main unit called a pod, which represents a higher-level structure. A pod is analogous to a VM but is not exactly the same, with a group of containers sharing networking and storage from the node. Figure 4.2 shows an example of one pod within a node. The example pod contains three containers sharing the same network interface and storage A and B, which belong to the node.
Figure 4.2: Kuberentes pod architecture [6]
Cluster and ingress Cluster is the concept of building groups of nodes that communicate with each other through an ingress controller. On the other hand, an ingress controller is the door from the Internet to web applications. It gives access to the cluster and can provide a set of rules for the incoming tra c. The ingress controller can also be set up as a load balancer, which improves the performance of pod web applications. Figure 4.3 shows an example of two nodes within the Kubernetes cluster.
Pod replication As mentioned previously, a pod is the main unit of Kubernetes in its replication process. At any time in which a container is highly consumed by users, Kubernetes software will create a replica of the pod with the same number of containers and deploy a new copy of the pod. This Kubernetes procedure allows the load balancing and failure resistance in production systems. Finally, the number of replication pods will be decided by the Kubernetes cluster, which will be introduced in the next subsections.
29 Figure 4.3: Kuberentes Cluster.
(a) Deployment type (b) DaemonSet type
Figure 4.4: Kubernetes pod launch type.
Deployment and DaemonSet Pods are managed by a layer of abstraction called deployment. Its objective is to declare how many copies of a pod will be running on the cluster. In the case in which a pod dies, the replication mode will take the information from the deployment configuration and will create a new instance of the pod. Then, the new replica of the pod is added to the cluster monitoring. Daemonset is another layer of abstraction similar to the deployment. However, DaemonSet is designed to have a single-pod-per-node model. It automatically scales to new nodes, when the nodes join the cluster, whereas deployment pods are only scheduled on new nodes if required [2].
Ad insertion prototype decisions Kubernetes Cluster Management is chosen for this ad insertion prototype due to the ease of deployment using Docker containers. Each Docker container will have a media microservice function for each media processing task interacting with each other. For example, container A will have an Origin server, which will stream video segments, and container B will stitch content
30 from di↵erent sources stored in container C. Docker containers were chosen in our testbed design for the capability to distribute software images [36] through the Docker hub [27] distribution system. Therefore, this option is quite handy when deploying containers in Kubernetes Cluster Management compared to other container technologies, such as [12, 56]. Additionally, we have chosen an Alpine Linux image OS to run inside each container. The Alpine Linux is a lightweight version of Linux kernels, allowing a lightweight and rapid initialization when deploying the media functions. On the other hand, we have selected the open-source Traefik ingress controller [2], which works as a reverse proxy/load balancer. This decision was taken because it o↵ers more flexibility, control, and monitoring of all our media microservices (media container functions) compared to other ingress controllers like [53], or the same load balancer as Azure. The implementation of this software might be quite challenging if the network configuration from the providers does not allow it. Therefore, this choice will be decided based on some experimental tests during the implementation phase.
Table 4.5: Ad insertion prototype.
Ad insertion prototype software. Use case Hypervisor Container Serverless case virtualization orchestration function Ad (Apache Web Server insertion &USP Remix)
31 Chapter 5
Media Processing Deployment Implementation
This chapter presents our di↵erent use cases of media processing functions: content packag- ing, video transcoding, and content ad insertion. It describes the steps taken for the deployment procedure and its configurations. Each of our three di↵erent setups will be deployed on di↵erent technologies from a high to low level of control over the stack of implementation: VM, container orchestration, and serverless computing.
5.1 Introduction
To correctly implement our three di↵erent use cases of media processing functions, we introduce each of the procedures in the order shown in Table 5.1. First, we implemented each of the media processing functions using the common gateway interface (CGI), which allows wrapping a command-line module into the di↵erent deployment architectures. Second, after obtaining an evaluation, we created an ad insertion prototype using the deployment architecture that had the best performance from all the selected cloud technologies.
Table 5.1: Side-by-side use cases and deployment technology.
CGI Implementation Use case Hypervisor Container Serverless case virtualization orchestration function Packaging 5.2 5.3 5.4 Transcoding 5.2 5.3 5.4 Content 5.2 5.3 5.4 stitching
32 Common gateway interface implementation Common gateway interface (CGI) is a simple interface for running external programs, soft- ware, or gateways under an information server in a platform-independent manner [8]. The CGI is a computer programming process based on standard input (stdin) and standard output (stdout) streams. It allows the execution of command-line software using the respective dependencies and arguments in an OS. In this research, we created a CGI script acting as a wrapper for a C/C++ command-line based code to Node.js JavaScript language. Figure 5.1 shows the CGI implementation pipeline. The HTTP request first triggers the function. Then, the web appli- cation looks into the paths provided in the HTTP request to the application global variables. Then a child process1 is created with an asynchronous spawn. This spawning method uses only one thread to run the command-line software and save the output file in local storage. Figure A.3 shows a snippet of code of the main four steps of the CGI implementation. This last procedure was carried out in tall the three deployment platforms, which enables consistent performance evaluation.
Figure 5.1: CGI implementation process.
node.js Server To be able to execute the media functions from outside the VM and a container, there was a need to build an HTTP interface. Therefore, we created an HTTP endpoint using the node.js server. It allows requesting through an HTTP GET and executing the command-line function
1 var child process = require( ’child process ’); 2 var spawn = child process .spawn; 3 var arguments = [ ’ license key=’+ license , ’ o’, outputFile,inputFile] 4 var exeSpawn = spawn( ’ mp4split ’ , arguments );/ Asynchronous process / ⇤ ⇤
Figure 5.2: NodeJS wrapper based on a CGI implementation for content packaging(mp4split)
1https://nodejs.org/api/child_process.html
33 1 localhost:8080/values?input=big buck bunny 4000k . ismv&output=outputFile .mp4
Figure 5.3: Example HTTP GET for content packaging using the NodeJS server from our CGI implementation
for the respective media function. The HTTP GET URL contains the key and value parameters. For example, key values are presented as ’input’ and ’output’, and values from these keys are the respective names and extensions of the media containers. The example HTTP GET for content packaging is shown in Figure 5.3.
5.2 VM Deployment Implementation
The VMs have the highest control over the resources compared to other deployment tech- nologies like container orchestration and serverless computing. It means that we can modify more parameters within the limits of the OS, such as networking throughput and memory al- location for each of the media functions. As it was designed in the previous section (Section 4), our configuration will be based on the Azure Cloud using two di↵erent VM families: the general-purpose VMs and compute-optimized VMs.
5.2.1 Media processing implementation procedure Each of the software modules that were used is command-line software wrapped up with our Node.js code in the CGI form as shown in Section 5.1. However, all the dependencies of mp4split, FFmpeg, and Unified Remix will be installed on the VM separately using their binary sources and environmental variables for an Ubuntu 16.04 system.
Implemetation steps:
1. Chose Hypervisor-based virtualization: F16s v2 2. Resource group creation in West Europe. Chose F16s v2: 16vCPU, 32GB RAM, 128GB SSD, Ubuntu 16.04 OS. Then launch the instance and access through SSH client.
3. Install software dependencies through repository manager: npm module (Node.JS). 4. Add executable processing files software into the app folder: mp4split, FFmpeg, and Unified Remix. 5. Create a CGI wrapper based on Node.js with an HTTP server with the objective to trigger the function.
6. Deploy App through node module: node run
Figure 5.4 it shows the design using Hypervisor-based to stream the multimedia files for the three di↵erent use cases. Each of the functions was installed in the same virtual environment.
34 Figure 5.4: Virtual machine media deployment implementation overview
5.3 Container Orchestration Deployment Implementation
This second section presents the use of container orchestration for media processing func- tions. In comparison to the VM deployment, we created a Docker image for each of the software modules: mp4split for content packaging, FFmpeg for video transcoding, and Unified Remix for content stitching. By this means, we built a container web application with a Node.js HTTP server for each of the media processing functions. In comparison with the VM software instal- lation procedure, we used an Alpine Linux system on each of our Docker images and with their respective modules of the packager, transcoder, and content stitching [30, 61]. Kubernetes container orchestration allows replication of pods, creating more than one copy of a pod inside the same node (VM) instance. However, to provide a similar approach compared to the other cloud technologies, we only used one replica for the pod configuration. This means that each node contains only one pod, and each pod contains one copy of the Docker image containers.
5.3.1 Media processing Implementation procedure Implementation steps 1. Create a cluster manager through the CLI Azure console manager. 2. Indicate the machine-size of the nodes(VM instances) DS1 v2. Additionally, Azure requires homogeneous sizes nodes in comparison to GKE. 3. Connect to the Cluster manager from the local CLI. 4. Write the YAML configuration script: number of replicas: 1, images to deploy, ingress controller, and ports exposed: Traefik 80 with ingress controller of DaemonSet type. 5. Deploy the YAML files through the local CLI using: kubectl create f
35 5.4 Serverless Deployment Implementation
Our third deployment technology is based on serverless computing. This implementation has the objective to compare its performance to previous deployment technologies of VM and container orchestration. First, we implement and evaluate the performance of the most common serverless providers with a simple request procedure. Second, we implement and evaluate the performance of serverless computing using the CGI approach, as it was done in the previous two cloud technologies of VMs and container orchestration.
Figure 5.5: Functions as a service deployment implementation.
5.4.1 Serverless cloud provider implementation overview Before selecting a serverless cloud provider for our final implementation, we carried out an overview performance assessment for four di↵erent cloud function providers: AWS, Google, Azure, and IBM Cloud. The preliminary test performance was based on a HelloWorld function with an execution duration of 50 ms. This assessment brought a baseline for important parame- ters, such as time per request, request per second, and average speed based on bytes per second. Further information of this evaluation is shown in Appendix A.
5.4.2 Media processing Implementation procedure In comparison to the other deployment methods of VMs and container orchestration. Server- less functions such as Azure functions provide multiple options to trigger the function. We used the HTTP trigger because it comes with an HTTP built-in interface when we first created the serverless app function. Therefore, there is no need to create a Node.js server to trigger the function, but we still used the CGI implementation needed for the execution of the binary files.
36 Implementation steps 1. Selection of Windows as the preferred OS for its convenience of not using shared libraries as Linux kernels. Only one dependency is needed for the case of mp4split, Unified Remix, and FFmpeg.
2. Creation of a serverless app: select region West Europe, select scaling type: Automatic (consumption plan). 3. Create local CGI wrapper based on JavaScript within the app folder and the respective execution files and paths.
4. Upload/deploy source code and executable files to the App Cloud through the local CLI. 5. Trigger type: HTTP request. 6. Obtain the processing time of the function through an HTTP 200 response.
37 (a) Container orchestration CGI imple- (b) Container orchestration as a media mentation. micro-service architecture.
Figure 5.6: Container orchestration CGI VS container orchestration using multiple containers.
5.5 Ad Insertion Prototype Deployment Implementation
The ad insertion prototype is the last implementation from this work. Based on the per- formance from the three di↵erent deployment procedures using a CGI implementation, we have selected container orchestration as the preferred cloud technology for media processing functions. The decision is based on the performance compared to the other two deployment technologies, VM and serverless computing.
5.5.1 Media processing implementation procedure Azure container orchestration The ad insertion implementation procedure is similar to the implementation procedure seen in Section 5.3.1. However, the main di↵erence between the CGI implementation in this ad in- sertion prototype is the use of other image containers that interact with each other, acting as a microservice architecture. Additionally, we used an Apache web server on each of the containers that interact with each other through HTTP requests. A visual explanation of a Kubernetes pod for the ad insertion prototype is shown in Figure 5.6b.
Implementation steps First, the Azure local CLI allows the deployment and modification of services. Therefore, we used the local CLI to first to deploy the Kubernetes cluster using the node-base size of the Standard VM DS1 v2 instance. Second, we used the same procedure for the deployment as seen in Section 5.3.1. However, the di↵erent configuration was based on the YAML files. The YAML configuration file provided the media processing function containers, and the Traefik ingress controller, which was set up as a DaemonSet type. Traefik allowed access to only one ingress controller pod. Figure 5.7 presents a diagram on how a Kubernetes cluster was deployed in the cloud. From right to left, it shows the procedure of a client requesting the manifest and a video segment through an HTTP request. We emphasize that we did not use a CDN during our implementation prototype.
38 Figure 5.7: Container orchestration implementation overview.
Table 5.2: Container orchestration experimental setup.
Cloud Provider Nodes Size Number of nodes ASK(Azure) VM1 1,3,5 VM1 3,5,7 GKE(Google) VM2 3,5,7 VM3 3,5,7
39 Chapter 6
Media Processing Deployment Evaluation
This chapter presents the results obtained from the experimental testbeds of CGI imple- mentation functions and the ad insertion prototype. The chapter is divided as follows. First, we present the load generator tools for each experimental deployment setup. Second, we present the results for each media processing use case using a CGI implementation. Third, we introduce the evaluation results for the ad insertion prototype.
6.1 Load Generator Tools and Measurement Specifications
Software load generators simulate numerous HTTP client requests. Most popular load generator software allows multiple and concurrent requests for specific periods. The idea behind a load generator in this research is to find out the performance and bottlenecks of the presented experimental testbeds. The experimentation will be carried by multiple shell scripts using cURL command line tool and Apache Bench. Since we are evaluating di↵erent deployment technologies in the same cloud region, the network latencies are not considered in this work.
Sequential scripts using cURL cURL1 is a Linux command tool capable of receive and transfer data from one server to another. It supports di↵erent transport protocols such as HTTP, FTP, POP3, RTMP, among others. The command is designed to work by the creation of shell scripts and run them in Linux kernel servers. In our first metric evaluation, we will use cURL command to create HTTP sequential(one after another) requests.
Load generator Apache Benchmark Apache Benchmark (AB) is an HTTP server benchmarking tool that allows a high number of concurrent connections to one requested URL source. It stresses the evaluated server within the first seconds the response rate of the server. Additionally, AB provides Key Performance Indicators(KPIs) such as request per second, time per request, an overall timer per request, which will help to evaluate each of the experimental setups. Apache Benchmark will be used for more
1https://curl.haxx.se/
40 complex concurrent requests in the di↵erent experimental setups. Finally, the load generator will be running on top of a VM instance F16s v2 with 16vCPUs and 32GB of RAM with 7Gbps of bandwidth.
6.1.1 Media processing with CGI execution Content Packaging: generating fragment MPEG-4 content (A) The first use cases of content Packaging will take input MPEG-4 files from Tears of Steal content material. Each of the content will have five videos with bitrates of 600, 1200, 2000, 3000, and 4000 kbps, encoded with the compression standard of AVC1/H.264[52] and two di↵erent lengths. The content material specifications for content packaging is shown on table 6.1.
1 mp4split otears of steel 600k .mp4 tears of steel 600k .ismv
Video Transcoding: Transcoding to H.265 (B) Transcoding will use the FFmpeg module locally to pre-process our content from our origi- nal compression standard H.264 to H.265. In the box below it shows an example of the FFmpeg module command converting one video of 5 seconds with a bitrate of 600kbps to H.265 compres- sion standard.
1 ffmpeg itearsof steel 1min .mp4 c:v \ 2 libx265 tears of steel 1min h265 .mp4
Content stitching: Generating MPEG-4 dref file (C) Content stitching module of unified remix creates a dref MPEG-4 (ISOMBFF) based on the SMIL file given. The first code below represents a content stitching creation by command-line software, and second SMIL example file used in content stitching.
1 unified remix odrefmp4 output .mp4 tears of steal .smil
Video Resolution Bitrate(kbps) Tears of steal(20-min) 420p,720p 600,1200,2000,3000,4000 Tears of steal(1-min) 420p,720p 600,1200,2000,3000,4000
Table 6.1: Video content for Packaging use case
41 1 2
42 6.2 Use case (A) : Content packaging results
This subsection explains the media processing function of content packaging using virtual machine and serverless computing.
6.2.1 VMs in content packaging Figure 6.1 shows the time per request for packaging 1-minute content from one concurrent user. It converts MPEG-4 containers to fragment MPEG-4 containers. From left to right it presents from the low to high-quality bitrate content. The results show an average of one request per second for the lowest bitrate of 600kbps. In comparison to the highest bitrates of 3000kbps and 400kbps that obtained 2x higher request per second than the 600kbps content. However, there is a similar performance of request per second of the 3000kbps and 4000kbps. On the other hand, on figure 6.2 it shows the time that took to process one concurrent request. For 600kbps content bitrate it was obtained an average of one second. In contrast with the video content of 4000kbps that obtained a time per request of 1.8 seconds. Therefore, the 4000kbps obtained 2x more time to package the content than the 600kbps bitrate content.
Figure 6.1: Request per second from 1-min content in VM deployment
43 Figure 6.2: Time per request from 1-min content in VM deployment
6.2.2 Serverless in content packaging Figure 6.3 shows the time per request for content packaging from MPEG-4 to fragmented MPEG-4 using serverless computing. The results shows 2.2 seconds of average processing time for 600kbps content bitrate. In comparison, to the average processing time of 4.5 seconds for the highest bitrate of 4Mbps. This shows almost 2.04x higher processing time for the 4Mbps compared to the 600kbps of 1-minute length. On the other hand, Figure 6.4 shows a 20-minute content length using serverless computing. The processing time for 600kbps bitrate content obtained 15 seconds average time. In contrast to the highest bitrate content, which obtained 72 seconds average processing time. This results showed almost 4.8x higher processing time for the 4000kbps bitrate content than for the 600kbps bitrate content.
44 Figure 6.3: Time per request from 1-min content using serverless deployment
Figure 6.4: Time per request from 20-min content in serverless deployment
45 Experimental findings The chosen serverless cloud provider allows a maximum execution time of 10 minutes (600 seconds). The setup for serverless content packaging obtained an average processing time of 4.5- seconds for 1-min content length and 72 seconds for the 20-min content length for the highest bitrate content. Therefore, the 72 seconds processing time only used 12% of the maximum execu- tion time available of 10 minutes. On the other hand, if we consider a heuristic approach by divid- ing the total processing time per minute content-length: 72sec/20min =3.6sec/1 min length we obtained 3.6-seconds processing time for each minute content length. This information reveals that serverless computing increases its performance over-time by reducing the time per request of 4.5 seconds to 3.6 seconds processing time of the 1-minute content.
Figure 6.5 shows the comparison of content packaging for both deployment technologies, VMs and serverless computing. Serverless deployment obtained a processing time of 2x higher than VMs for 600kbps bitrate content and 2.4x higher than VMs for 4000kbps bitrate content.
Figure 6.5: VM vs Serverless 1-min content packaging
46 6.3 Use case (B) Video Transcoding results
The second media processing function provides findings for transcoding video content from H.264 to H.265 compression standard. Video transcoding is well known for the high demand of computing resources (CPU) compared to the other two media processing use cases. In this sec- tion, we compare the performance of video transcoding using compute-optimized VMs instances F16s v2 and the consumption plan from Azure serverless functions.
6.3.1 VMs in Video Transcoding Figure 6.6 shows the time per request results for transcoding video content of 1-min content length using a VM. The experimental results show an average processing time of 3.8 seconds for the lowest bitrate of 600kbps, and 18 seconds processing time for 4000kbps bitrate. This experimental finding shows that transcoding a video with a higher bitrate of 2000kbps, the processing time increases dramatically. This high increase of processing time might have caused by memory allocation of the VM transcoding the content.
Figure 6.6: Transcoding deploying on a F16s v2 VM instance
47 6.3.2 Serverless in Video Transcoding Figure 6.7 shows the results of video transcoding using the serverless computing deployment. In comparison to the deployment of VM, serverless computing was capable of processing without errors video content equal to or lower than 2000kbps bitrate. Transcoding video of the 600kbps and 1200kbps obtained an average processing time of 35 seconds. On the other hand, the highest bitrate content of 2000kbps obtained a processing time of 130 seconds.
Figure 6.7: Serverless Azure transcoding average time per request
Experimental findings Figure 6.8 shows the comparison of time per request between VM and serverless deployment for video transcoding seen previous sections. The time per request of video transcoding from the two di↵erent deployments was highly contrasting. However, it is important to mention that the VM used was a compute-optimized instance, which provides higher computing performance than a standard VM. On figure 6.8 it shows that serverless computing deployment had 9.77x higher processing time for the content of 600kbps bitrate. For 2000kbps bitrate content, server- less computing deployment obtained 20.5x higher processing time than the VM deployment.
Figure 6.9 shows a time per request comparison between the use case of content packaging and video transcoding of 600kbps bitrate. The high di↵erence between the two di↵erent use cases evidences the high compute complexity for transcoding using serverless deployment.
6.4 Use case (C) Content stitching results
Content stitching is part of the pipeline of the Ad insertion use case. It is carried out by creating a dref MPEG-4 from two or more video content sources. In the next two subsections,
48 Figure 6.8: VM deployment V.S. Serverless computing deployment of time per request for video transcoding.
49 Figure 6.9: Serverless time per request comparison overview. it is presented the obtained results for content stitching by deploying on VMs and serverless computing.
6.4.1 VM in content stitching For the second use case of content stitching using VM deployment, it was observed in figure 6.10 the histogram of time per request. This result reveals that for 106 requests took 2.5 to 2.6 seconds to stitch(create dref MPEG-4) two di↵erent contents of 20m-in and 5-sec length. This result shows that the creation of the dref file does not need a high number of computing resources compared to the other two use cases.
Figure 6.10: Content stitching using F16s v2 instance
50 6.4.2 Serverless in content stitching In figure 6.11(a) it shows the behavior of our experimental serverless function for 1000 HTTP requests, producing one MPEG-4 dref file for each request. It can be observed that the first HTTP request has the highest response time of 5.5 seconds. The first high peak was provoked by ’cold start’ of the function.
(a) Content stitching HTTP behavior for 1-min content
(b) Content stitching time per request of 1-min and 20-min content length
Figure 6.11: Content stitching behavior using serverless deployment.
On the other hand in 6.11(b) it can be observed the average time per request of two di↵erent content lengths by the serverless experimental setup. The di↵erence of average time per request of 1.2-seconds and 1.3-seconds(almost real-time) show that specific media processing functions like content stitching can perform well with serverless deployment. This deployment might reduce the cost of over-provision of VMs but also giving other applications as advertisement personalization based on client location.
51 Figure 6.12: FaaS Azure content stitching time per request histogram
Figure 6.13: Time per request serverless media function comparison
52 6.5 Use case (D): Content Ad Insertion results
Our last results are based on an Ad insertion prototype. It is based on the container orchestration deployment using Kuberentes cluster management. In figure 6.14 it is shown the most common pipeline for content add insertion at the server-side. However, we emphasize that in this research we omit the use of a CDN.
Figure 6.14: Server-side Ad insertion pipeline
6.5.1 Container orchestration setups The Ad insertion prototype is evaluated by using an AB load generator running in a compute optimized instance F16s v2. The prototype is divided in three di↵erent experimental setups shown in figure 6.15. Setup 1 has one node in the Kubernetes cluster, setup 2 has three nodes, and finally, setup 3 has five nodes. Besides, to the three di↵erent setups with a di↵erent number of nodes, the AB load generator server simulates concurrent connections of 10, 100, and 1000. Each concurrency case requests 1000 HTTP requests.
Figure 6.15: Ad insertion prototype evaluation with container orchestration
53 6.5.2 Measurement procedure for Ad insertion prototype As it shows in 6.15, the load generator simulates concurrent HTTP client requests to the cloud ingress controller. As it was designed in chapter 4, each node contains one pod with multiple containers acting as media processing functions(e.g., Origin, content stitching module, SMIL playlist creator). The evaluation procedure is based on three di↵erent HTTP requests: the manifest(.mpd) file for MPEG-DASH, video segments of low bitrate of 405kbps(420p resolution), and video segments of higher bitrate of 3Mbps(720p resolution). The results for each of the three figures are organized as follows. For each case of concur- rency, there is a figure containing three graphs: request per second handled, time per request, and the throughput. Visually, the graph at the top left of each figure represents the requests per second that the Origin server dispatched to the clients. The graph located in the right top corner of the figures represents the time it took to process the HTTP query from the moment it was requested until the moment it was delivered to the client. Finally, the image on the bottom for the three di↵erent cases of concurrency represents the throughput of kbytes/sec.
6.5.3 Container orchestration for Ad insertion results Using 10 concurrent clients
(a) Request per second (b) Time per request
(c) Throughput
Figure 6.16: 10 concurrent setup
On the first case of 10 concurrent clients shown in figure 6.16a it illustrates the highest
54 number of request per second for the manifest file with one node setup, in comparison to three or five nodes setups. However, with the setup of five nodes, the segment of 420p had a higher number of responses compared to the setup of one node. This last result is quite interesting, showing that container orchestration improves the performance of request per second and time per request for the video segments, but not for the manifest file when the fifth node is added. It is important to realize that the file size of the manifest is smaller than the segments with low and high bitrate. For the case of throughput, the figure 6.16c show similar data transfer with one and three nodes, but in the fifth node, the throughput of the 720p segment only increases 5MB/s.
Using 100 concurrent clients
(a) Request per second (b) Time per request
(c) Throughput
Figure 6.17: 100 concurrent client setup
The results obtained for 100 concurrent clients have similar behavior to the ten concurrent clients regarding request per second and time per request. However, the time per request in figure 6.17b decreases in a 14% for a segment with high bitrate(720p) from three to five node setup. This increase of time per request is shown when moving from one node setup to three and five node setup. On figure 6.17c, the throughput of 100 concurrent clients from three nodes and five nodes arrive at the limit of 40Mb/s. This shows that using 100 concurrent clients can arrive to a limit of five nodes.
55 10 and 100 concurrent users: 1. When increasing more than one node, the performance of the manifest file starts decreasing. This might be caused by each node having their own caching, which might produce multiple copies of the same content in a di↵erent pod. 2. The request of segments of low and high bitrate obtained the best performance when the number of nodes is increased. 3. The limit throughput for requesting the highest bitrate content was of 40Mb/s. This is the case for three and five nodes. The maximum increase obtained was of 14%.
Using 1000 concurrent clients Our final experimental scenario is based on the simulation of 1000 requests within 1000 concurrent users. During this experimental scenario, it also applied the three di↵erent setups when increasing the number of nodes from one to three nodes using the
(a) Request per second (b) Time per request
(c) Throughput
Figure 6.18: 1000 concurrent client setup
By using 1000 concurrent clients with 1000 requests shows maximum load generation setup for one, three and five nodes. As it shows figure 6.18a, the request per second of the manifest is of 300 requests per second. This value seems to be the maximum value for all the experimental setups and concurrency tests. However, the performance for time per request and throughput for three and five nodes decreases drastically to almost 50% compared to only one node. Therefore,
56 there a few reasons that this might have happened: first, that the ingress controller from the Kubernetes management tool is missing a configuration component in order to deliver the load into the di↵erent nodes. Second, the low performance could be caused to the Cloud provider network throughput to each of the nodes(three and five node setups) have limited bandwidth based on the compute instance family. Third, the cluster of nodes was saturated in short periods and the measurements carried out by using Apache Bench(AB) could not be shown the right behavior. As it shows the figure 6.17c the throughput of two and three nodes is almost the same with 40MBps. However, if we compare this information against the throughput from the 1000 concurrent clients, we observe that the escalation using three and five nodes is worst than the one with one node, which in theory the value should be the opposite as it was seen with the test of 100 concurrent clients.
57 Chapter 7
Conclusion and Future work
This chapter provides the summary of this work. It emphasizes the results and experimental findings from the evaluation chapter. Furthermore, it provides the constraints during this work and the possible directions of this research in the future.
7.1 Conclusions
This work has presented several experimental results for media processing functions using cloud technologies, in particular those that can be deployed in the cloud and/or network edges. We chose three useful media processing use cases in streaming platforms: content packaging, video transcoding, and content ad insertion. The three chosen use cases were designed and implemented for media processing using cloud deployments: hypervisor virtualization (VM), microservice/container orchestration, and serverless functions. We evaluated each of the exper- imental setups using a load generator, which simulated a real-case scenario from HTTP client requests. Finally, based on the previous performance evaluation of media processing functions, we implemented and evaluated a VOD ad insertion prototype using container orchestration. The results showed that VMs could provide good performance of 2 seconds compared to serverless functions which obtained 4.5 seconds for content packaging for the highest bitrate of 4Mbps and 1-minute length. Serverless results obtained a processing time of 2x higher for the lowest bitrate content, and 3x higher for the highest bitrate content. On the second use case of video transcoding, VMs were compared to serverless deployment by processing video from H.265 to H.264. The results demonstrated that video transcoding using serverless deployment arrived at a processing content-size limit of 2Mbps bitrate and 1 minute content length. This constraint might be caused by the memory capacity of the serverless function and its limit on automatic scaling. On the third use case, the generation of dref files (ISOBMFF) for content stitching, as expected, demonstrated great performance (less than 1.2 seconds) compared to previous use cases. The average time per request of 1 minute content compared to 12 minute content had a small increase of 15.4%. Overall, serverless functions had lower performance than a high-performance VM type. However, serverless deployment is still an attractive technology in case the function does not need to be called continuously, or delay requirements of the process allow a specified delay. Finally, we carried out an Ad insertion prototype using container orchestration in the Azure Cloud. This showed that using container orchestration as a microservice approach can be used in advanced media applications. It is based on low delays and a high number of requests compared to a VM or a serverless function. However, the throughput of 10 concurrent users that we observed
58 from one to five nodes only increased to a maximum of 10.5% when requesting a high bitrate segment(3Mbps). Moreover, for the second current setup using 100 concurrent users, there was no increase in throughput from three to five nodes. This small increase of throughput shown that using Kubernetes Cluster Management might not be the most suitable deployment in comparison to bare-metal servers using Kubernetes software. However, in this work we used the default machine-size(DS1 v2) as nodes with 750Mbps bandwidth each. Furthermore, our experimental findings showed that the maximum requests per second on our setup for the manifest (.mpd) file arrived up to 300 request per second compared to the serverless function provider metrics, which can arrive at 150 request per seconds for a HelloWorld return message string. This reflects that Kubernetes Cluster Management handles the concurrency of clients pretty well for a low bitrate (600 kbps), but the data transfer throughput slightly improved from one to five nodes.
7.2 Limitations and Future work 7.2.1 Implementation constraints During the implementation phase, a few barriers were encountered for the deployment of media processing functions using cloud technologies. For example, the novel technology of serverless functions does not support environmental variables and Docker containers for OSs in all cloud providers. Therefore, we used the CGI (stdin/stdout wrapper) implementation for its ease of employment, and its compatibility with Windows and Linux systems. On the other hand, the implementation for Kubernetes Cluster Management had limitations on the configuration of the load balancer, such as the ingress controller throughput. On the Azure Cloud, the load balancer had a total throughput of the sum of each of the nodes bandwidth. For example, if each of the nodes has an expected bandwidth of 750 Mbps, then the use of three nodes should have been 2250 Mbps. However, the final results showed that the maximum throughput obtained for requesting a segment of high bitrate (x > 3 Mbps) arrived at a limit of 360 Mbps. This last result indicates that the cloud load balancer using the Traefik ingress controller did not improve the throughput dramatically by increasing the number of nodes. The configuration of the ingress controller thought the DaemonSet might cause this as well as the limitations of the cloud load balancer.
7.2.2 Future work Central-edge tradeo↵model: The deployment of computing resources at the edge of the • network allows processing media functions rapidly. However, there is no clear understand- ing of which media functions should be ran on the central or at the edge of the cloud. Consequently, there is a need for a tradeo↵model in media processing functions, which can provide KPIs central-edge cloud. This model aims to provide advantages and disadvantages regarding costs and performance for each of the setups. Cloud provider: In this work, we used the Azure Cloud for the design and implementation. • However, it is essential to use other cloud providers to observe other performance variants. Divide in smaller pieces: Splitting content into smaller pieces (segments) or chunks with • serverless architectures could be done for massively parallel computing of media processing functions. Additionally, function chaining between the media functions could be created to perform di↵erent media processing tasks.
59 Serverless Origin server: The Apache server module in a Docker container could be used • with a serverless open-source software, such as OpenWhisk, which runs any OS in a Docker container.
60 Bibliography
[1] Aws lambda. https://aws.amazon.com/lambda/. Accessed: 2018-07-20.
[2] Deployment or daemonset, traefik. https://docs.traefik.io/user-guide/kubernetes/. Accessed: 2018-07-20. [3] Docker containers. https://www.docker.com/. Accessed: 2018-07-20. [4] Etsi nfv. https://www.etsi.org/technologies-clusters/technologies/nfv. Accessed: 2018-07-20.
[5] European telecommunications standards institute. https://www.etsi.org/. Accessed: 2018-07-20. [6] Getting started with google kubernetes engine, google cloud. https://www.coursera.org/ learn/google-kubernetes-engine/. Accessed: 2018-07-20.
[7] Google cloud functions. https://cloud.google.com/functions/docs/. Accessed: 2018- 07-20. [8] Ietf org. https://www.ietf.org/rfc/rfc3875.txt. Accessed: 2018-08-20. [9] Kubernetes. https://kubernetes.io/docs/setup/pick-right-solution/. Accessed: 2018-07-20. [10] Microsoft azure functions. https://azure.microsoft.com/en-us/services/functions/. Accessed: 2018-07-20. [11] Openstack. https://www.openstack.org/software/. Accessed: 2018-07-20.
[12] Oracle solaris containers. http://www.oracle.com/technetwork/server-storage/ solaris/containers-169727.html. Accessed: 2018-07-20. [13] Windows containers. https://docs.microsoft.com/en-us/virtualization/ windowscontainers/index. Accessed: 2018-07-20. [14] Adobe. HTTP Dynamic Streaming.[Online]. URL: https://www.adobe.com/products/ hds-dynamic-streaming.html. [15] Apple. HTTP Live Streaming.[Online]. URL: https://developer.apple.com/ streaming/. [16] Remzi H Arpaci-Dusseau and Andrea C Arpaci-Dusseau. Operating systems: Three easy pieces, volume 151. Arpaci-Dusseau Books Wisconsin, 2014.
61 [17] Ioana Baldini, Paul Castro, Kerry Chang, Perry Cheng, Stephen Fink, Vatche Ishakian, Nick Mitchell, Vinod Muthusamy, Rodric Rabbah, Aleksander Slominski, et al. Serverless computing: Current trends and open problems. In Research Advances in Cloud Computing, pages 1–20. Springer, 2017. [18] Edouard Bugnion, Scott Devine, Kinshuk Govil, and Mendel Rosenblum. Disco: Running commodity operating systems on scalable multiprocessors. ACM Transactions on Computer Systems (TOCS), 15(4):412–447, 1997. [19] ”Unified Streaming BV”. ”Factsheet.”. URL: "http://docs.unified-streaming.com/ faqs/factsheet.html#supported-drm-systems". [20] ”Unified Streaming BV”. ”Unified packager.”. URL: "http://docs.unified-streaming. com/documentation/package/index.html". [21] ”Unified Streaming BV”. ”Unified Remix.”. URL: "http://docs.unified-streaming. com/documentation/remix/index.html". [22] Giuseppe Carella, Marius Corici, Paolo Crosta, Paolo Comi, Thomas Michael Bohnert, An- dreea Ancuta Corici, Dragos Vingarzan, and Thomas Magedanz. Cloudified ip multimedia subsystem (ims) for network function virtualization (nfv)-based architectures. In Computers and Communication (ISCC), 2014 IEEE Symposium on, pages 1–6. IEEE, 2014. [23] Cisco. Cisco Global Cloud Index: Forecast and Methodology. 20152020.[On- line]. URL: http://www.iotjournaal.nl/wp-content/uploads/2017/02/ white-paper-c11-738085.pdf. [24] Generic coding of moving pictures and associated audio information. Iso/iec 13818-1: art 12: Iso base media file format. International Organization for Standardization, 2007. [25] Mark Croes. Performance analysis of virtualized video streaming service. In Bachelor Thesis in Informatica, pages 1–46. UvA, 07-2017. [26] Digital Program Insertion Cueing Message for Cable. Society of Cable and Telecommuni- cation Engineers. 35, 2016. [27] ”Docker”. ”Docker hub.”. URL: "https://hub.docker.com/". [28] Ran Dubin, Amit Dvir, Ofer Hadar, Tomer Frid, and Alex Vesker. Novel ad insertion tech- nique for mpeg-dash. In Consumer Communications and Networking Conference (CCNC), 2015 12th Annual IEEE, pages 582–587. IEEE, 2015. [29] GSNFV ETSI. 001:” network functions virtualisation (nfv). Architectural framework, 2014. [30] ”↵mpeg org”. ”Alpine ↵mpeg 2.8.11-r0.”. URL: "https://pkgs.alpinelinux.org/ package/v3.3/main/x86/ffmpeg". [31] ”FFmpeg.org”. ”FFmpeg.”. URL: "https://www.ffmpeg.org/about.html". [32] ”FFmpeg.org”. ”Libavcode.”. URL: "https://www.ffmpeg.org/libavcodec.html". [33] ”DVD Flick”. ”DVD Flick.”. URL: "http://www.dvdflick.net/features.php". [34] Anvato Frank Beacham. Hearst television rolls out anvatos digital ad insertion technol- ogy for live streaming, 2014. URL: http://www.tvnewscheck.com/playout/2014/04/ hearst-television-rolls-out-anvatos-digital-ad-insertion-technology-for-live-streaming/.
62 [35] Scott Hendrickson, Stephen Sturdevant, Tyler Harter, Venkateshwaran Venkataramani, An- drea C Arpaci-Dusseau, and Remzi H Arpaci-Dusseau. Serverless computation with open- lambda. Elastic, 60:80, 2016. [36] Docker Inc. Docker images. Documentation, Accesed: 2018-08-20. URL: https://docs. docker.com/engine/reference/commandline/images/.
[37] ”Nginx Inc.”. ”Nginx web server.”. URL: "https://www.nginx.com/". [38] ”Ingex”. ”BBC RD labs.”. URL: "http://ingex.sourceforge.net/". [39] ISOBMFF. ISO base media file format. URL: "http://standards.iso.org/ittf/ PubliclyAvailableStandards/c068960_ISO_IEC_14496-12_2015.zip".
[40] Fareed Jokhio, Adnan Ashraf, S´ebastien Lafond, and Johan Lilius. A computation and storage trade-o↵strategy for cost-e cient video transcoding in the cloud. In 2013 39th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA), pages 365–372. IEEE, 2013.
[41] Christina Kylili. Improving the video streaming backend with on-the-fly format conversion and cloud storage. 2018. [42] C Lowery. Emerging technology analysis: Serverless computing and function platform as a service. Gartner, Tech. Rep., 2016. [43] Yuyi Mao, Changsheng You, Jun Zhang, Kaibin Huang, and Khaled B Letaief. Mobile edge computing: Survey and research outlook. arXiv preprint arXiv:1701.01090, 2017. [44] Garrett McGrath and Paul R Brenner. Serverless computing: Design, implementation, and performance. In Distributed Computing Systems Workshops (ICDCSW), 2017 IEEE 37th International Conference on, pages 405–410. IEEE, 2017.
[45] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner. Openflow: enabling innovation in campus networks. ACM SIGCOMM Computer Communication Review, 38(2):69–74, 2008. [46] Rufael Mekuria, Jelte Fennema, and Dirk Gri oen. Multi-protocol video delivery with late trans-muxing. In Proceedings of the 2016 ACM on Multimedia Conference, pages 92–96. ACM, 2016. [47] Rufael Mekuria, Christina Kylili, Arjen Wagenaar, and Dirk Gri oen. Performance assess- ment and improvement of the video streaming backend with cloud storage and on-the-fly format conversion. In Proceedings of the 23rd Packet Video Workshop, pages 31–36. ACM, 2018.
[48] Microsoft. Smooth Streaming Protocol.[MS-SSTR]-v2015063. URL: https://www. microsoft.com/silverlight/smoothstreaming/. [49] Rashid Mijumbi, Joan Serrat, Juan-Luis Gorricho, Niels Bouten, Filip De Turck, and Raouf Boutaba. Network function virtualization: State-of-the-art and research challenges. IEEE Communications Surveys & Tutorials, 18(1):236–262, 2016.
[50] MPEG. Additional use case and requirement for network distributed video coding: multi- client interacting. Hobart, Australia.
63 [51] ISO/IEC JCT1/SC29 MPEG. Dynamic adaptive streaming over HTTP (DASH) 2014. URL: "https://dashif.org/". [52] MPEG-4. H.264/14496-10. AVC Reference Software Manua (revised for JM 19.0).[Online]. URL: https://developer.apple.com/streaming/.
[53] Nginx. Nginx ingress controller. Ingress controller, Accesed: 2018-08-20. URL: https: //www.nginx.com/products/nginx/kubernetes-ingress-controller/. [54] ”Apache Org”. ”apache server”. ”Http Server”, ”Accesed 2018-08-25”. URL: "https: //httpd.apache.org/". [55] Pradeep Padala, Xiaoyun Zhu, Zhikui Wang, Sharad Singhal, Kang G Shin, et al. Per- formance evaluation of virtualization technologies for server consolidation. HP Labs Tec. Report, 137, 2007. [56] rkt. ”CoreOS.”. URL: "https://coreos.com/rkt/". [57] Mike Roberts. Serverless architectures. ], : https://martinfowler. com/articles/serverless. html, 4, 2016. [58] Sahel Sahhaf, Wouter Tavernier, Didier Colle, and Mario Pickavet. Network service chain- ing with e cient network function mapping based on service decompositions. In Network Softwarization (NetSoft), 2015 1st IEEE Conference on, pages 1–5. IEEE, 2015. [59] Stefano Salsano, Luca Chiaraviglio, Nicola Blefari-Melazzi, Carlos Parada, Francisco Fontes, Rufael Mekuria, and Dirk Gri oen. Toward superfluid deployment of virtual functions: Exploiting mobile edge computing for video streaming. In Teletra c Congress (ITC 29), 2017 29th International, volume 2, pages 48–53. IEEE, 2017. [60] S Srinivasan. Cloud computing evolution. In Cloud Computing Basics, pages 1–16. Springer, 2014.
[61] ”USP”. ”Alpine USP packager.”. URL: "https://github.com/unifiedstreaming/ packager". [62] Abhishek Verma, Luis Pedrosa, Madhukar Korupolu, David Oppenheimer, Eric Tune, and John Wilkes. Large-scale cluster management at google with borg. In Proceedings of the Tenth European Conference on Computer Systems, page 18. ACM, 2015. [63] Arjen Wagenaar, Dirk Gri oen, and Rufael Mekuria. Unified remix: a server side solution for adaptive bit-rate streaming with inserted and edited media content. In Proceedings of the 8th ACM on Multimedia Systems Conference, pages 221–224. ACM, 2017. [64] Hui Zhao, Qinghua Zheng, Weizhan Zhang, Biao Du, and Haifei Li. A segment-based storage and transcoding trade-o↵strategy for multi-version vod systems in the cloud. IEEE Trans. Multimedia, 19(1):149–159, 2017.
64 Appendices
65 Appendix A
Serverless Cloud Provider Evaluation
This section presents the initial evaluation for di↵erent serverless computing functions. It provides an assessment for the cloud providers that o↵er serverless computing. This part aims to analyze di↵erent cloud providers and o↵ers a baseline overview of their performance.
A.0.1 Serverless provider performance evaluation Our initial assessment of serverless functions is carried out by a separate performance assess- ment of each cloud provider. It is based on a request and response from a console message string with an execution duration of 50 ms (example shown below). For equality testing purposes, we created a VM instance acting as a load generator in the same region that the serverless function is deployed. For example, the Azure function and VM are located in the Azure West Europe region. The AWS Lambda and its VM are in London. The Google function is in St. Ghislain (Belgium), and the IBM OpenWhisk is in the London region. On our experimental setup, we are not considering the network latency within the same region.
Figure A.1: Serverless experimental setup overview.
66 A.0.2 Serverless provider performance results Initially, we thought that the Azure serverless provider would have the best performance compared to other providers. Nevertheless, Figure A.2(blue bars) illustrates that AWS Lambda obtained the lowest time per request with 112 ms, compared to the highest time per request from the Google functions provider with 180 ms. In the same experimental finding, we corroborate with [44], finding a high variance of time per request from Azure Functions. This variance indicates that Azure has di↵erent infrastructure scalation and dynamic allocation of resources compared to the other three providers. This variance of resource allocations seems to have a dynamic threshold by the provision of resources.
Figure A.2: FaaS provider evaluation setup
In the same figure, Figure A.2 (green bars), we found that the AWS Lambda provider had the best throughput of eight requests per second where the variance of most of the providers did not change dramatically, as seen in the time per request for Azure Functions. Therefore, the small variance in throughput from all providers correlates with the number of concurrent requests that the character the FaaS provider. Finally, the most outstanding value of average transfer speed was obtained by the open- source OpenWhisk with the highest speed of 400 bps among all providers. The extremely low speed and apparent lack of correlation compared to the other providers were possibly attributed to the HTTP authentication message that IBM needs to handle on each of its requests. In contrast to AWS Lambda, Azure and Google functions were not needed for an HTTP handshake as they were for IBM OpenWhisk.
67 Table A.1: Serverless Azure pricing.
Meter Provider Price Free grant(Per month) Execution time Azure 0.000014/GB-s 400,000 GB-s Total Executions Azure 0.169 per million executions 1 million executions
Performance analysis Serverless functions are charged based in their time of execution. They do not depend on how many computing power CPU, resources, or memory was allocated during the execution process. t ExecutionDuration = Tduration(seconds)dt (A.1) Z0 Memory usage calculation: #ofexecutionunits Execution timeGb s = (A.2) 1, 024, 000
68 1 / ⇤⇤ 2 The function Unified Remix i s based on the smil p l a y l i s t . ⇤ 3 It creates a mixed content ⇤ 4 as an dref .mp4.. ⇤ 5 / ⇤ 6 7 8 9 var child process = require( ’child process ’); 10 var spawn = child process .spawn; 11 12 const argsRemix = ””; 13 var response = ’ ’ ; 14 // Starts the function 15 module . exports = function (context, req) { 16 context . log(’ UNIFIED REMIX ’); ⇤⇤⇤⇤⇤⇤⇤⇤⇤⇤⇤ ⇤⇤⇤⇤⇤⇤⇤⇤⇤⇤ 17 context . log(’ Starting ... ’); 18 19 if(GetEnvironmentVariable(’USP LICENSE KEY2 ’ , c o n t e x t)==u nde f i n ed ) { 20 console . log(”Plase provide your USP LICENSE KEY in order to continue ”); 21 context . log(”Plase provide your USP LICENSE KEY in order to continue”); 22 context . res = status : 202, body: ”Insert USP LICENSE KEY” ; { } 23 } 24 else { 25 //The SMIL file comes in the req.body 26 if ((req.query.inputname req.query.externalinput) || 27 && req.query.outputname) { 28 29 try { 30 var usp license = GetEnvironmentVariable(’USP LICENSE KEY2 ’ ) ; 31 console . log(”Ths USP LICENSE : ”+ u s p license ); 32 var localUrlPath = req.originalUrl; 33 var functionName = localUrlPath.substring(localUrlPath.lastIndexOf(’/’)+1, 34 localUrlPath . lastIndexOf ( ’? ’)); 35 var exeFilePath = getExePath( ’ unified remix ’); 36 var finalUrl = localUrlPath.substring(0, localUrlPath.lastIndexOf(’?’)) 37 38 39 //Request names and input file name 40 var inputName = req . query .inputname; 41 var outputName = req . query .outputname; 42 //Indicate the names of the input and ouputs of the cmmd 43 var IOPaths = setInputOutputFilePaths(outputName , inputName); 44 var finalOuputPath = IOPaths [0]; 45 var finalInputPath = ””; 46 47 finalInputPath = IOPaths [1]; 48 if(req.query.externalinput!=undefined) { 49 console . log(” EXTERNAL SOURCE :”+req.query.externalinput); ⇤⇤⇤ ⇤⇤⇤ 50 finalInputPath = req.query. externalinput ; 51 } 52 var remixResponse=unifiedRemix(exeFilePath69 , usp license ,finalOuputPath , 53 finalInputPath , argsRemix , context , finalUrl ) 54 if(remixResponse!=’0’) { 55 console . log(”Output file path: ” + finalOuputPath ); 56 response = ”” + finalOuputPath ; 57 } 58 else { 59 //context.log(”Exe error: ” + remixResponse); 60 console . log(”Exe error : ” + remixResponse); 61 62 response = remixResponse; 63 } 64 context . res = { 65 66 body : response 67 ; } 68 catch ( error ) } { 69 console . log(”ERROR:” + error ); 70 response = ”ERROR: ” + error ; 71 context . res= { 72 status : 503, 73 body : response 74 } 75 context .done (); 76 } 77 78 } 79 else { 80 context . res = { 81 status : 400, 82 body : ”Please give a name on the query string for ’inputname ’ and ’outputname ’” 83 ; } 84 context .done (); 85 } 86 87 } 88 ; } 89 90 function GetEnvironmentVariable(name, context ) 91 { 92 try { 93 return process .env[name]; 94 catch ( error ) } { 95 console . log(”Your .env file does not have: ” + name); 96 context . log(”Your .env file does not have: ” + name); 97 //return context.done(); 98 } 99 } 100 101 //This function needs to run with the main host 102 function getExePath( fileName ) { 103 var currentDir = getCurrentDirectory(); 104 var path = currentDir + ” bin ”+fileName+ ”.exe”; \\ \\ 105 return path; 106 } 107 108 function getCurrentDirectory () { 109 var fullPath = dirname ; 110 var path = fullPath . split (”/”); 111 var cwd = path [ path . length 1] 112 return cwd; 113 } 114 115 //TODO: tmp path file 116 function setInputOutputFilePaths(outputNameFile , inputNameFile) { 117 var currentDirectory = getCurrentDirectory(); 118 var inputFilePath = currentDirectory + ” input ”+inputNameFile \\ \\ 119 var ouputFilePath = currentDirectory + ” output ”+outputNameFile; \\ \\ 120 121 //TODO: It should automatically select the desired folder or to be temp file 122 return IOParams = [ ouputFilePath , inputFilePath ]; 123 } 124 125 126 function unifiedRemix(exeFilepPath , license , ouputMp4Path, inputSmilPath , args , context , finalUrl ) { 127 var infoResponse = ””; 128 try { 129 130 var args = [’ license key=’+ license , ’ o’, ouputMp4Path, inputSmilPath] 131 var exeSpawn = spawn(exeFilepPath , args); 132 console . log (’Spaning EXE FILE! ’ + args . join (’ ’)); 133 134 exeSpawn . stderr .on( ’ data ’ , function ( data ) { 135 if(data!=null) { 136 console . log (’STD: ’ + data ); 137 //context.log(’STD: ’ + data); 138 infoResponse = data ; 139 } 140 141 ); } 142 exeSpawn . on( ’ close ’ , function(code) { 143 console . log(”Close with code: ” + code); 144 if(code==’404’) { 145 context . res = status : 400, body: ”Error in the packager with code: ”+ code ; { } 146 infoResponse = ”0”; 147 context .done (); 148 return infoResponse ; 149 } 150 //Code 200 FMP4 OK m p 4 s p l i t 151 if(code==’0’) { 152 //context.log(”Success with code: ”+ code); 153 context . res = status : 200, body: ”Success with code: ”+ code + ” & LOCALPATHOUTPUT: ” + ouputMp4Path ; { } 154 infoResponse = ’200 ’ ; 155 context .done (); 156 return infoResponse ; 157 } 158 ); } 159 context . res = { 160 status : 200, 161 body : ( finalUrl + ” SPAWN ”+ouputMp4Path) ⇤⇤⇤⇤⇤⇤ ⇤⇤⇤⇤ 162 ; } 163 } 164 catch(e) { 165 console . log(”Catching the error SPAWN” + e); 166 context . res = status : 503, body: ”Error using mp4split: ” + e ; { } 167 infoResponse = ”0”; 168 context .done (); 169 } 170 return infoResponse ; 171 }
Figure A.3: NodeJS command-line software execution on a CGI level for content pack- ager(mp4split) TRITA EECS-EX-2018:550
www.kth.se