Seamless and Efficient Stream Switching of Multi- Perspective Videos

Transcription

1 Seamless and Efficient Stream Switching of Multi- Perspective Videos Hongchi Zhang, Anas Al-Nuaimi Technical University of Munich Munich, Germany Xiaoyu Gu, Michael Fahrmair DOCOMO Euro-Labs Munich, Germany {gu, Ryota Ishibashi NTT Service Integration Labs Tokyo, Japan Abstract According to a Cisco study, mobile video already makes up 50% of mobile data traffic and is expected to reach 66% in Nowadays, the video watching experience is being made more interactive to enhance the user experience. One way that users can enjoy better watching experience is to be able to switch between different perspectives in one video. Such multiperspective events require an efficient streaming scheme that is both cost-efficient and user-friendly. Based on three popular video streaming methods (RTP/RTSP, HTTP Progressive Download and DASH), we propose three different solutions for streaming multi-perspective videos. Architectures and principles of each solution are discussed and implemented on an Androidplatform-based smartphone. To compare the performance of our solutions, we design a framework for evaluation. The metrics we use to evaluate our solutions include bandwidth consumption and Quality of Service (QoS) parameters, such as switch delay and switch rendering. Our comparison shows that all three solutions can achieve acceptable performance for perspective switching. However, the DASH-based solution outperforms the remaining solutions as it provides shortest delay and seamless switching of perspectives for a given bandwidth. Keywords- H264/AVC; multi-perspective video; video stream switching; DASH; RTSP/RTP; HTTP Progressive Download I. INTRODUCTION Nowadays, 3G mobile networks with higher bandwidths and QoS support allow mobile devices and smart phones to stream videos. According to a recent study by Cisco, mobile video already made up 50% of mobile data traffic in 2011 and is expected to rise to 66% in 2015[13]. Multimedia services in the future are expected to be more personalized. Individuality and enhanced user experience are gaining in importance. Within the project CoopMedia (Cooperative Mobile Media) we investigate service enablers for allowing enhanced user experience, specifically for multiperspective events. Such events frequently occur in the context of user generated content (UGC). The multiple perspectives are hosted on the media servers and jointly processed such that they can be associated to video sets representing distinct events. The user can then enjoy the event from all perspectives. A user can switch the videos among different perspectives of the same event at any time such that he can choose the view he Visiting Researcher at DOCOMO Euro-Labs deems as most interesting at any instant (consider a goal shot in a football match). The service offers the user a more personalized experience that the user can choose not only the program he wants to watch but also the perspective he prefers. This kind of service can be popular in sports events, stage performances or cooperatively recorded and shared video clips of street performances and entertainment events. Streaming a multi-perspective event is a challenge. Video players, especially on mobile platforms, implement long buffering times (in the order of 7 seconds on the Android platform) when the file is not stored locally. Long switching delays caused by the large buffering totally degrade the user experience. In our tests we observed that the viewer could no longer tell that he was switching at synchronized instances due to the switching delays. Solving this by buffering different perspectives simultaneously is problematic: The bandwidth is usually limited in a mobile environment. Even if we disregard bandwidth considerations, mobile computing platforms such as Android-based ones may also have various limitations such as their limited capacity in terms of multi-tasking and multiprocess support. Users may switch among the videos of different perspectives frequently in the CoopMedia portal service. Therefore a solution of stream switching should be carefully designed. A mobile device is usually resource limited. Keeping a long battery standby time and using a portable mobile CPU means smartphones do not run as powerful as PCs. Thus the solution should be power-conserving and energy-conserving. Besides, since the access bandwidth of mobile devices is also often limited to the wireless network connections, the solution should be efficient in bandwidth. A mobile client that receives all streams of different perspectives at the same time is not an efficient one, because most of the time the user may just watch one of the streams and all the other traffic and processing is wasted. The ultimate goal of bandwidth cost when using the CoopMedia portal service should be as little as watching a normal single perspective video. On the other hand, the service should be user friendly, especially during the switching among the perspectives. Our goal is to achieve a low response delay of switching, and a seamless and smooth transition on user s mobile devices after switching between multiple perspectives. Research for similar purposes on the video coding level has been carried out. Multi-view Video Coding (MVC), which is an amendment of the H.264/MPEG-4 AVC video compression

2 standard, allows encoding of sequences captured simultaneously from multiple cameras using a single video stream [1]. However, MVC solutions are not applicable to this problem, since in this project, cameras are located randomly and views are encoded independently, while in MVC, the cameras are required to have linear arrangement to provide sufficient inter-view correlation. Furthermore, MVC is intended to be used in stereoscopic (two-view) video or 3D television. In [3], Hussain considered a different multicast scenario with similar purpose. He presented a different architecture and utilized the NICE protocol [4] for transmitting multi-view videos. His solution, nevertheless, is designed for the free viewpoint TV, which has different requirements from the mobile environment. In essence, this paper focuses on the practical issues encountered when utilizing standard protocols to develop an efficient and user-friendly multi-perspective streaming method. The rest of the paper is organized as follows. In Section II, we present three solutions based on RTP/RTSP Proxy, HTTP Progressive Download and DASH. In Section III, we show our implementation results for each solution. In Section IV, we give a comparison and analysis of the three solutions. Section V concludes. II. SOLUTION PROPOSALS A. RTP/RTSP Proxy Solution In the past decade, countless multimedia applications have been developed based on the Real-Time Streaming Protocol (RTSP) [5]. RTSP is used to control the streaming media servers. RTSP establishes TCP connections between the media server and the client. The client sends out the controlling commands such as PLAY, PAUSE, etc. to the media server to achieve real-time control of the playback of media files from the server. RTSP is a stateful protocol. This means the media server tracks the session and records the state transition. While the controlling commands are transmitted between the client and the media server using RTSP, the audio/video data is transmitted using the Real-Time Transport Protocol (RTP). The media data is packetized on the media server and transmitted from the media server to the client in UDP connections at the same rate as the video is played out. The client usually buffers the incoming media data and starts to play the audio/video out after a certain playback delay. To achieve a good user experience with continuous playback, the buffering size should be decided based on the scenario network conditions. In general, if a player client wants to switch between the two video streams in two RTSP sessions, it has to terminate the first session and establish the second session. If the connection of the second RTSP session is successfully established, the client sends the playing command to the media server and waits for the incoming RTP packets. The client starts to buffer the media data transmitted in the RTP packets. After a certain time interval of buffering, the client is able to play out the video. During this time interval, since the client has not finished loading its buffer, it will not start to play out the new video. Typically a black screen or frame freeze will occur. The playback delay accounts for the switching interval. The Android media player usually incurs a 7 seconds playback delay. If the client is implemented such that it can establish multiple RTSP connections with multiple videos of perspectives, receive RTP packets from multiple streams, and buffer the media data simultaneously, the switching of the perspectives can be done in a seamless manner. However, simultaneous transmission of these streams requires the bandwidth and data flow being multiple times of a case when there is just a single stream. Meanwhile, at any instant in time the user watches one of the streams only, and the others are simply wasted. We propose a stream switching solution based on a RTP/RTSP proxy. In this solution, a proxy server is introduced. We assume the proxy server is located at the edge of the network. That is, on one side, the proxy connects to the media server through high bandwidth in the network; on the other side, it is close to the smart phone and the delay between the proxy and the smartphones is relatively small. The proxy receives the multi-perspective streams and forwards one of the streams to the mobile client. The response time for the proxy to switch to a new perspective is short because it is at the network edge and close to the smart phone. The architecture of the solution is shown in Figure 1. Figure 1. RTP/RTSP Solution with a network edge proxy First, the mobile client initializes a RTSP SETUP request to the RTP/RTSP proxy server. The proxy parses the request and starts several RTSP requests in parallel to the media server; each represents a stream of one perspective of a video set. After the connections between the media server and the proxy have been setup, the proxy returns the smart phone client with an OK response corresponding to the initial SETUP request. At this point, the RTSP session between the client and the proxy server has been setup. If the client further sends the PLAY command in order to start playing the video, the proxy will also send PLAY command to the media server through each connected RTSP session. During the playback of the video, the proxy server receives several RTP streams in parallel but forwards only one of them to the mobile client. The forwarding is done at the packet level, which means no decoding or transcoding of media content is needed. If the client sends a command to the proxy server for switching to the neighboring perspective, the proxy server does not need to establish new RTSP or RTP session. Instead, it simply hands over the RTP stream from the old one to the new one. The proxy has to reset the header field of each packet, since different RTP streams use different Synchronization Source (SSRC) Identifiers to identify different streams. Also

3 the sequence number of different streams at the same time might be different. The proxy server resets the header field of each forwarded packets so that the client would not detect any switching according to the RTP header. The proxy server becomes transparent in the middle of the client and the media server. The client continuously receives the RTP packets, adds the media data into the buffer, and plays them out. B. HTTP Progressive Download Solution In HTTP messages, HTTP entities are represented as sequences of bytes [6]. HTTP/1.1 allows a client to request that only part (a range) of the requested entity be transferred. This method is called HTTP partial request. HTTP/1.1 client can specify the requested part using the range units in the Range header field. An entity can be broken into sub-ranges according various structural units [6] to reduce unnecessary network usage. The concept of range unit is meaningful for any HTTP entity. HTTP Progressive Download is based on a sequence of HTTP partial requests. The video file using HTTP Progressive Download is delivered in the same manner as an image, a PDF or any other file is downloaded. HTTP Progressive Download enables a client player to play the video while the video is still being delivered from a standard web server by requesting a different range at each request. This way, the client can download the video file progressively while the player is playing the media. It can also perform seek operation in the video by requesting a new range. Most Internet Video-ondemand services like YouTube are delivered through progressive download. In this solution, we prepare all the videos in the format of MPEG-4. MPEG-4 Part 14 defines the file format of ISO base media [7]. The file is structured as a sequence of objects called boxes. All data is encapsulated in boxes. All boxes start with a header which gives size and type. At the beginning of a media file, there are some important boxes, such as ftyp and moov. The moov box describes the metadata of the media like duration, rate of the video or preferred playback volume. The Media Data Box dat contains the media data e.g. frames in video tracks. The actual media data directly follows the type field; its structure is described by metadata in moov box (sample table, item location box etc) [7]. In our HTTP Progressive Download Solution, the client first tries to request the part in the file which contains the moov box. Based on the metadata and the network environment (bandwidth), the client will request an appropriate part of file by partial HTTP GET request. Each time the client will request a part (segment) in the file that covers 3-10s of the media [8]. The segment size should not be too long so the client can finish downloading and start playing quickly. The segment size should also not be too small in order to reduce the overall overhead the HTTP requests generate. Unlike RTP transmission, HTTP downloads the contents in a best-effort way. Therefore the response is fast and the buffering time can be short. While the client is playing each part in the media file, it keeps requesting the following part in the file in order to keep the media playback continuous. When the user wants to seek to a new part that has not been downloaded, the client calculates the range of the new part and starts a new partial request. We have implemented the client of this solution such that it downloads the video files which represent different perspectives to a local storage and changes the perspectives by switching among local files. This trick avoids the long buffering times the Android platform imposes by default for streaming over a data connection. In Summary, the client keeps making HTTP partial requests to download the video file. The client player does not have to wait for a whole video file to be downloaded before it starts to play. This solution is figuratively depicted in Figure 2 and Figure 3. First the client will create virtual video files of all perspectives locally. Then the client starts to request the header parts of the media file (i.e. the moov box) for each video file. Subsequently it calculates the range of bytes in one video file of the first several seconds. After this segment has been downloaded and written in the video file, the media player can start to play this video file from the beginning. As the player plays, the client continuously calculates the range of the following segments and requests them one after the other. The playback is continuous as long as one segment has been written in the file before the timeline reaches this segment. In the case of switching, the client calculates the range of bytes for a segment in the file to be switched to of the next few seconds and makes an HTTP partial request for this segment immediately. When the response is completed, the play out of the switched-to video file can proceed. Figure 2. File Container Header Downloading Figure 3. Segments Playback and Downloading

4 C. Dynamic Adaptive Streaming over HTTP Solution Another way of streaming a video through HTTP is to divide the overall stream into a sequence of small HTTP-based files (segments) and to change the download of part(s) of a large video file into the download of several small video segments. Each segment covers a short time in the video. The segments are independently encoded and can be independently decoded. Normally, the client downloads the segments in sequence and plays them out one after one continuously. As the stream is played out, the client may select from a number of different alternate streams containing the same content but encoded at a variety of data rates, allowing the streaming session to adapt to the available data rate. The latest streaming technology based on segments downloading is Dynamic Adaptive Streaming over HTTP (DASH) [9]. DASH enables delivery of media content from a standard HTTP server to HTTP clients and enables caching of content by standard HTTP caches. The ISO/IEC DIS [11] specifies two formats in DASH: the Media Presentation Description (MPD) which describes media presentation and the Segment Formats which specify the entity body (segment) of the response. The service provider server generates segments that contain different encoded versions of one or several of the media components of the media content. The segments are hosted on a media server along with the MPD. Based on the metadata in MPD, clients can find out the access URL of segments and then use HTTP GET or partial GET methods to fetch the segments sequentially. The client should manage the on-time request, the smooth playback of the sequence of segments, and the potential adjustment of bitrate [10]. The architecture of our DASH solution is shown in Figure 4. The media server provides an overall MPD for all perspectives: The information is provided either in one file, or in a hierarchical way (MPD for each perspective and an overall index of perspectives). For each segment, the MPD describes to which perspective the segment belongs, the time range and data rate of the segment. Therefore, for any time of any perspectives at any available bandwidth, the client knows which segment to request. Figure 4. DASH Solution Architecture If the user keeps watching one perspective, the client will keep one segment in the buffer at a time. The client starts to request the next segment in the sequence when it starts to play out one segment. The player plays segments continuously and the user would not realize the video has been divided into small segments. Once switching is initiated at the client side, it determines the appropriate segment in the new sequence, and from this segment it starts to download from the sequence of the perspective that should be switched to. Figure 5. Random Delay in DASH Solution As shown in Figure 5, using this method, the switching of perspectives happens only at the boundary of segments. The delay of switching is determined by the timing when the user makes the switching decision. If the user initiates the switching when a segment just starts to be played out, the delay will be the duration of one segment because the actual switching happens after the current segment finishes playing. If the user initiates the switching when a segment is about to finish, and if the client requests the segment from the new sequence in time, the delay of the switching might be very small. If we ignore the downloading time, the delay is a uniformly distributed between 0 and the pre-defined duration of a segment. Because the segments are downloaded via HTTP, the client can get the maximum transmission rate while downloading. Furthermore, the duration of each segment can be set to be small (1s-10s). In an ideal network environment, the segment downloading takes very little time (much shorter than the segment duration). Two properties of the network might affect segment downloading time: round trip time and bottle-neck bandwidth. If the bottle-neck bandwidth is too low and the transmission of a segment takes longer time than the playback time of a segment, then for the currently viewed perspective the client has to buffer a number of segments before the player can start playing the content. The user can only wait for the stream to start unless there is a stream at lower bitrate that the client can switch to. Similar consideration applies to the round trip delay. If it is larger than the segment duration, the client can still play the video continuously by buffering one or two more segments. Our implemented client player is able to switch between different sequences and plays frames continuously. In this solution a custom player is designed. This player can decode any segment sequence into a set of frames and show the frames at the desired framerate. The client can initiate switching requests, request segments accordingly and provides them to the player decoder. III. IMPLEMENTATION RESULTS A. RTP/RTSP Proxy Solution We utilize a media server supporting standard RTSP streaming at the server side. The mobile client is implemented based on the default media player on an Android phone.

5 After the client application on the smartphone is launched, it takes 6-7 seconds for the media player to set up the RTSP connection and to buffer the stream. We analyzed the packets transmitted in the network and found out that the delay was mainly caused by the media buffer length on the mobile phone. The switching delay of our solution is close to the time for a mobile player to open a normal RTP stream using RTSP. In terms of the video quality, the switching is seamless if we enforce switching only at intra coded frames. However, the switching delay is quite large since the player has to wait until such a switching opportunity occurs. Obviously this is dependent on the Group of Pictures (GOP) structure and can be fine-tuned. Once a switching is initiated by the user, the client keeps showing the video of the old perspective for 6-7 seconds before it is switched to the video of new perspective. This delay is mainly attributed to the media buffer length. The complexity of this solution is relatively high. The RTP/RTSP proxy server has multiple connections for each client and it has to be deployed at all access networks to be close enough to all mobile clients. B. HTTP Progressive Download Solution In our implementation of this solution, the HTTP server is an Apache server, while the mobile client is an Android smartphone. After launching the application on the client, it takes 5 seconds for the client to initialize. All headers of the video files are downloaded. The media content of the desired video is then progressively downloaded and played out. When the user initiates the switching between the perspectives, the video of the old perspective is stopped. After about 1.5 seconds of black screen the video of the new perspective starts playing out from where the old perspective is stopped. Using HTTP Progressive Download the response is much faster. This is mainly because the content is downloaded at the maximum possible speed so the data is readily available when switching occurs. Moreover the data is pre-stored on the local storage. Mobile platforms require much smaller buffering time when the data is played out locally. The media object is tricked to think that the data is being played out from the local storage. Another advantage of using HTTP is that all data is transmitted on top of TCP using the same well-known 80 port [12] while RTP and RTSP use separate ports on UDP. This solution does not require additional solutions for NAT or Firewall Traversal which means it is easier than RTP/RTSP Proxy Solution while being deployed. The video files can be hosted on any standard HTTP server and no other server is required. Hence the complexity of this solution is low. C. Dynamic Adaptive Streaming over HTTP Solution On the server side, an additional application for content preparation is developed. This server application takes in a set of videos and outputs a set of sequences of segments as well as a MPD file. The video contents are compressed into segments using H.264 format, each segment covers 2 seconds of video. The segments and the MPD file are hosted on an Apache Server. The client first downloads and analyzes the MPD file, and then starts to request the segments of a perspective. When the first one or several segment(s) in the sequence is ready, the player can start to play the stream automatically. The client application provides a seamless switching. There is no freezing or black screen during the switching. The response delay of the solution is random as we analyzed in the Section II. In our test environment, the delay is always shorter than two seconds and the average delay is about 1s. IV. COMPARISON & ANALYSIS We considered the resource limitation of the mobile phone and evaluated the bandwidth consumption and the complexity of deployment for each proposed and implemented solution. We also took the following quality of service parameters into consideration: the switch delay, which is the time interval between the user sending a switch command and when the client screen begins to show frames of new perspective at normal video quality; the switch rendering, which describes how the screen acts after the client stops showing the old perspective and before showing the new perspective (e.g. how to make the switch smoothing, how long is it when there is a black screen or freezing of the User Interface (UI) while the user is waiting for the new perspective). A. Bandwidth Consumption Since in the RTP/RTSP Proxy Solution, there is only one RTSP connection from the proxy to the client, the mobile phone would require no more bandwidth than a simple video stream. The client can save the data usage and processor power. In the experiment, the result agrees with our analysis: there is no difference on data transmission to the client in our solution and in a normal one-perspective video. But from the real media server to the proxy, the number of RTP streams is the same number of perspectives in the video set. So if the number of perspectives grows to 5 or more, large amounts of traffic are generated. In the HTTP Progressive Download Solution, the standard MP4 file is used and downloaded directly. For each MP4 file the client will first request the header (moov box etc) and then request media data in one of the files. Normally the header is small: the size of a standard 9 minutes 56 seconds sample MP4 is 37.3MB, and the header is only 332KB. The weight of the media header in the file also depends on the total size of the file: if we use a short video (1 or 2 minutes), the overhead by downloading all headers of file is of course larger than in the previous example. Each time the user switches the perspective, the client can finish downloading a segment of the new file in short time and starts playing the new file. But at the same time, in the old perspective file, there is a segment no shorter than the buffer length that has already been downloaded and buffered but wasted and becomes a fragment in the file. Each time the user switches the perspective, there might be a fragment generated. Therefore the bandwidth efficiency of the solution is influenced by the frequency of user s switching. This increases the overhead by about 20%-40% in our experiments. The overhead by the media headers in our experiments is approximately 10%. Therefore the total overhead is around 30%-50% of the size of the media content.

6 In the DASH Solution, because each segment can be independently decoded, each segment will introduce coding overhead. In the experiment we choose a segment duration of 2s. 30 segments of 2s video take up a space of 2.75MB while a 60s video of the same quality takes 2.5MB space. Hence, the encoding overhead is about 10% in this case. The HTTP header overhead makes up between 0.5-1% of the bandwidth consumption. The overall overhead is 11% in our experiment. B. Complexity of Deployment For the RTP/RTSP Proxy Solution, the media server and the client are simple, which are following the standard protocol. But the RTP/RTSP proxy server to be deployed on the network edge increases the complexity largely and loses the scalability. For the HTTP Progressive Download Solution, no additional server is required. A standard HTTP server and common media elements are used in the solution. This solution is the easiest one of the three. For the DASH Solution, a reuse of the current HTTP server is also possible. Since DASH is not supported by the default media players on most of the mobile platforms, the client player has to be a custom player that can switch among the segments of different perspectives seamlessly. C. Switch Delay Since we assume that the RTP/RTSP proxy server is close to the client, the round trip delay in this method is small. But usually the playback buffer of the media player is large for RTP streaming. Therefore the actual switching always happens after all frames of the old perspective are played out which takes around 7 seconds, which is the longest of the three. In the HTTP Progressive Download Solution, when the client decides to switch the perspective, it requests the corresponding part in the new perspective video file immediately. When the partial download is completed, the player changes the player source to the new file and starts playing from where it was playing in the old file. The delay equals sum of the request-download time and the buffer length for local playback. During our experiment, the delay is usually less than 2 seconds. For the DASH Solution, as we have analyzed, the delay is uniformly distributed between the download time and the sum of the download time and the duration of a segment. In the experiment, since the download time is small. The delay is random from 0 to 2s. D. Switch Rendering In RTP/RTSP Proxy Solution, although the delay is the longest, the player plays the old perspective continuously at full quality. The actual switching to the new perspective on the screen is seamless. In the HTTP Progressive Download Solution, when the client receives the switch command, it releases the old video file as resource and empties the buffer. While it waits the new perspective video file to be buffered, nothing will be shown on the screen. In the experiment the client gives a black screen during the switching. In the DASH Solution, during the switching, the client keeps playing the old perspective at full quality. The actual switch is seamless. Table I summarizes all preceding observations. TABLE I. Bandwidth SUMMARY OF COMPARISON OF EACH SOLUTION RTP/RTSP Proxy No overhead on mobile phone, multiple traffic in core network HTTP Progressive 30-50% overhead DASH About 10% overhead Complexity High Low Medium Delay 6-7s 1.5s 0-2s Rendering Keeps playing old perspective Black screen, blocked V. CONCLUSION Keeps playing old perspective In this paper, we studied and proposed three different streaming methods for multi-perspective video transmission on mobile platforms. The solutions enable the mobile user to seamlessly switch between different perspectives on a mobile platform, while conserving bandwidth consumption. We compared the three proposed solutions along three main criteria: incurred overhead, delay until switching happens, and switch rendering. The DASH-based solution gave best performance. It provides seamless switching with a delay of at most 2 seconds while only incurring 10% overhead. REFERENCES [1] Anthony Vetro, Sehoon Yea, Matthias Zwicker, Wojciech Matusik, and Hanspeter Pfister. Overview of multiview video coding and anti-aliasing for 3d displays, [2] P. Merkle, A. Smolic, K. Muller, and T. Wiegand. Efficient prediction structures for multiview video coding. Circuits and Systems for Video Technology, IEEE Transactions on, 17(11): , nov [3] Hussain Mudassar. Free viewpoint tv. Master s thesis, Linköpings universitet,2010. [4] Kurutepe Engin, Civanlar M. Reha and Tekalp A. Murat, Interactive transport of multi-view videos for 3DTV applications, School of Engineering, Koç University, Istanbul 34450, Turkey, Journal of Zhejiang University Science, ISSN (Print); ISSN (Online), [5] Henning Schulzrinne, A. Rao, and R. Lanphier. Rfc real time streaming protocol (rtsp), April [6] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. Rfc 2616, hypertext transfer protocol http/1.1, [7] Information technology coding of audio-visual objects part 14: Mp4 fileformat, [8] Nikolaus Farber, Stefan Dohla, and Jochen Issing. Adaptive progressive download based on the mpeg-4 file format. Journal of Zhejiang University-Science A, 7: , /jzus.2006.AS0106. [9] Information technology Dynamic adaptive streaming over HTTP (DASH) Part 1: Media presentation description and segment formats, ISO/IEC JTC 1/SC 29, 2011 [10] Thomas Stockhammer. Dynamic adaptive streaming over http : standards and design principles. In Proceedings of the second annual ACM conference on Multimedia systems, MMSys 11, pages , New York, NY, USA, ACM. [11] Thomas Stockhammer, Per Frodh, Iraj Sodagar, and Sungryeul Rhyu. Text of iso/iec : Dynamic adaptive streaming over http (dash), [12] Thernelius Fredrik. Sip, nat, and firewalls. Master s thesis, Royal Institute of Technology in Stockholm, [13] Cisco Systems Inc., Cisco Visual Networking Index: Forecast and Methodology, White Paper, 2011