This thesis explores possible solutions to replace Adobe Flash Player by using tools already built into modern web browsers, and explores the tradeoffs between bitrate, quality, and delay when using an adaptive bitrate for live streamed video. Using an adaptive bitrate for streamed video was found to reduce stalls in playback for the client by adapting to the available bandwidth. A newer codec can further compress the video file size while maintaining the same video quality. This can improve the viewing experience for clients on a restricted or a congested network. The tests conducted in this thesis show that producing an adaptive bitrate stream and changing codecs is a very CPU intensive process.

This thesis explores possible solutions to replace Adobe Flash Player by using toolsalready built into modern web browsers, and explores the tradeoffs between bitrate, qual-ity, and delay when using an adaptive bitrate for live streamed video. Using an adaptivebitrate for streamed video was found to reduce stalls in playback for the client by adapt-ing to the available bandwidth. A newer codec can further compress the video file sizewhile maintaining the same video quality. This can improve the viewing experience forclients on a restricted or a congested network. The tests conducted in this thesis showthat producing an adaptive bitrate stream and changing codecs is a very CPU intensiveprocess.

Severe weather impacts life and in this dire condition, people rely on communication, to organize relief and stay in touch with their loved ones. In such situations, cellular network infrastructure\footnote{We refer to cellular network infrastructure as infrastructure for the entirety of this document} might be affected due to power outage, link failures, etc. This urges us to look at Ad-hoc mode of communication, to offload major traffic partially or fully from the infrastructure, depending on the status of it. We look into threefold approach, ranging from the case where the infrastructure is completely unavailable, to where it has been replaced by make shift low capacity mobile cellular base station. First, we look into communication without infrastructure and timely, dissemination of weather alerts specific to geographical areas. We look into the specific case of floods as they affect significant number of people. Due to the nature of the problem we can utilize the properties of Information Centric Networking (ICN) in this context, namely: i) Flexibility and high failure resistance: Any node in the network that has the information can satisfy the query ii) Robust: Only sensor and car need to communicate iii) Fine grained geo-location specific information dissemination. We analyze how message forwarding using ICN on top of Ad hoc network, approach compares to the one based on infrastructure, that is less resilient in the case of disaster. In addition, we compare the performance of different message forwarding strategies in VANETs (Vehicular Adhoc Networks) using ICN. Our results show that ICN strategy outperforms the infrastructure-based approach as it is 100 times faster for 63\% of total messages delivered. Then we look into the case where we have the cellular network infrastructure, but it is being pressured due to rapid increase in volume of network traffic (as seen during a major event) or it has been replaced by low capacity mobile tower. In this case we look at offloading as much traffic as possible from the infrastructure to device-to-device communication. However, the host-oriented model of the TCP/IP-based Internet poses challenges to this communication pattern. A scheme that uses an ICN model to fetch content from nearby peers, increases the resiliency of the network in cases of outages and disasters. We collected content popularity statistics from social media to create a content request pattern and evaluate our approach through the simulation of realistic urban scenarios. Additionally, we analyze the scenario of large crowds in sports venues. Our simulation results show that we can offload traffic from the backhaul network by up to 51.7\%, suggesting an advantageous path to support the surge in traffic while keeping complexity and cost for the network operator at manageable levels. Finally, we look at adaptive bit-rate streaming (ABR) streaming, which has contributed significantly to the reduction of video playout stalling, mainly in highly variable bandwidth conditions. ABR clients continue to suffer from the variation of bit rate qualities over the duration of a streaming session. Similar to stalling, these variations in bit rate quality have a negative impact on the users’ Quality of Experience (QoE). We use a trace from a large-scale CDN to show that such quality changes occur in a significant amount of streaming sessions and investigate an ABR video segment retransmission approach to reduce the number of such quality changes. As the new HTTP/2 standard is becoming increasingly popular, we also see an increase in the usage of HTTP/2 as an alternative protocol for the transmission of web traffic including video streaming. Using various network conditions, we conduct a systematic comparison of existing transport layer approaches for HTTP/2 that is best suited for ABR segment retransmissions. Since it is well known that both protocols provide a series of improvements over HTTP/1.1, we perform experiments both in controlled environments and over transcontinental links in the Internet and find that these benefits also “trickle up” into the application layer when it comes to ABR video streaming where HTTP/2 retransmissions can significantly improve the average quality bitrate while simultaneously minimizing bit rate variations over the duration of a streaming session. Taking inspiration from the first two approaches, we take into account the resiliency of a multi-path approach and further look at a multi-path and multi-stream approach to ABR streaming and demonstrate that losses on one path have very little impact on the other from the same multi-path connection and this increases throughput and resiliency of communication.

Användningen av strömmande video ökar snabbt just nu. Ett populärt konceptär adaptive bitrate streaming som går ut på att en video kodas i flera olikabithastigheter. Dessa videor tas sedan och delas upp i små filer och görstillgänglig via internet. När du vill spela upp en sådan video laddar du först hemen fil som beskriver vart filerna finns och i vilka bithastigheter de är kodade i.Mediaspelaren kan där efter börja ladda hem filerna och spela upp dom. Om defysiska förutsättningarna, som exempelvis nedladdningshastighet eller CPUbelastning,ändras under uppspelningen kan mediaspelaren enkelt byta kvalitépå videon genom att börja ladda filer av en annan bithastighet och slippa attvideon laggar. Denna rapport tar därför en närmare titt på fyra tekniker inomadaptive bitrate streaming. De som undersöks är HTTP Live Streaming,Dynamic Adaptive Streaming over HTTP, HTTP Dynamic Streaming ochSmooth Streaming med avseende på vilka protokoll som dom använder.Rapporten undersöker även hur Apple och FFmpeg har implementerat HTTPLive streaming med avseende på hur mycket data som behövs läsas i en filinnan videon kan börja spelas upp. Rapporten visar att det inte är så storaskillnader mellan de fyra teknikerna. Dock sticker Dynamic AdaptiveStreaming over HTTP ut lite genom att vara helt oberoende av vilket ljud ellervideoprotokoll som används. Rapporten visar också på en brist i specificeringenav HTTP Live Streaming då det inte är specificerat att första komplettabildrutan i videoströmmen bör ligga i början av filen. I Apples implementationbehövs upp till 30 kB data läsas innan uppspelning kan påbörjas medan iFFmpegs implementation är det ca 600 byte. / The use of streaming video is growing rapidly at the moment. A popular conceptis adaptive bitrate streaming, which is when a video gets encoded in severaldifferent bit rates. These videos are then split into small files and made availablevia the internet. When you want to play such a video, you first download afile that describes where the files are located and in what bitrates they are encodedin. The media player then begin downloading the files and play them. Ifthe physical conditions, such as the download speed or CPU load, changes duringplayback, the media player can easily change the quality of the video bystarting to downloading files of a different bit rate and avoid that the video lags.This report will take a closer look at four techniques in adaptive bitrate streaming.They examined techniques are HTTP Live Streaming, Dynamic AdaptiveStreaming over HTTP, HTTP Dynamic Streaming and Smooth Streaming andwhich protocols they use. The report also examines how Apple and FFmpeg hasimplemented HTTP Live Streaming with respect to how much data is needed toread a file before the video can begin to be played. The report shows that thereare no large differences between the four techniques. However, Dynamic AdaptiveStreaming over HTTP stood out a bit by being completely independent ofany audio or video protocols. The report also shows a shortcoming in the specificationof HTTP Live Streaming as it is not specified that the first completeframe of the video stream should be at the beginning of the file. In Apple's implementationits needed to read up to 30 KB of data before playback can bestarted while in FFmpeg's implementation its about 600 bytes.

Virtualization on top of high-performance servers has enabled the virtualization of network functions like caching, deep packet inspection, etc. Such Network Function Virtualization (NFV) is used to dynamically adapt to changes in network traffic and application popularity. We demonstrate how the combination of Software Defined Networking (SDN) and NFV can support the parallel operation of different Internet architectures on top of the same physical hardware. We introduce our architecture for this approach in an actual test setup, using CloudLab resources. We start of our evaluation in a small setup where we evaluate the feasibility of the SDN and NFV architecture and incrementally increase the complexity of the setup to run a live video streaming application. We use two vastly different protocol stacks, namely TCP/IP and NDN to demonstrate the capability of our approach. The evaluation of our approach shows that it introduces a new level of flexibility when it comes to operation of different Internet architectures on top of the same physical network and with this flexibility provides the ability to switch between the two protocol stacks depending on the application.