Low Latency MPEG-DASH System over HTTP 2.0 and WebSocket

Transcription

1 Low Latency MPEG-DASH System over HTTP 2.0 and WebSocket Xiaona Wu 1,2, Cheng Zhao 1, Rong Xie 1,2, and Li Song 1,2 1 Institute of Image Communication and Network Engineering, Shanghai Jiao Tong University 2 Cooperative Medianet Innovation Center, Shanghai, China youli206@sjtu.edu.cn,zhaocheng100a@163.com, {rongxie,song_li}@sjtu.edu.cn Abstract. Dynamic Adaptive Streaming over HTTP (MPEG-DASH) is an adaptive bitrate streaming technique that breaks the video contents into some sequences of small HTTP-based file segments in different bitrates. With enough bandwidth now, live latency has become the most serious problem. MPEG has discussed two core experiments Server and Network-assisted DASH(SAND) and Full Duplex HTTP-compatible Protocols(FDH) to improve performance of video streaming. In this paper, we refer the two ideas and complete a low delay streaming system over HTTP 2.0 and WebSocket. Based on our experiments, we could adaptively choose which bitrate of segments to push according to the network condition. With the smaller header size, utilization of bandwidth has been improved and there is 40.22% start-up time saved and 57.96% transmission latency saved averagely in all situations. Keywords: MPEG-DASH, FDH, SAND, HTTP 2.0, WebSocket, live latency 1 Introduction Live video streaming has become more and more popular recently. Along with the increasing demand for better user experience, we need to solve problem of live latency in live situations. Compared with traditional protocols and transmission methods[1], MPEG-DASH standard supposed two core experiments FDH and SAND using HTTP 2.0 and WebSocket. MPEG-DASH was developed under MPEG(The Moving Picture Experts Group) which contains the manifest file Media Presentation Description File and video segments with data in different bitrates. Studies on DASH started in 2010 and DASH became a Draft International Standard in January 2011, and an International Standard in November The MPEG-DASH standard[2] was published in April, The media description file defines the media information including adaptation sets, representations and so on. Segments are defined based on two kinds of formats, ISO Base Media File Format[3] and MPEG-2 Transport Stream[4]. In 2014 DASH standard was updated to version 2 and proposed FDH[5] and SAND[6] in 2015.

2 2 Xiaona Wu et al. FDH defines full duplex HTTP-compatible protocols which both allows serverinitiated and client-initiated transactions. The idea can be applied over HTTP 2.0 and WebSocket. In a DASH session the client requests the MPD file first and then requests video segments with corresponding segment URL and a push strategy. Then the server responses with the requested segments following the given push strategy. PushDirective is used to signal the push strategy that the client wants the server to use, while PushAck is used to inform the client which strategy the server follows. The whole structure can reduce the transmission delay by decreasing the number of requests in live streaming. However, all the push strategies only support pushing segments from a single representation. SAND enables a bidirectional messaging plane between the clients and other DASH aware network elements(dane) to carry any kind of operational information and assistance information. SAND messages includes Parameters Enhancing Delivery(PED) messages exchanged between DANEs, Parameter Enhancing Reception(PER) messages sent from DANEs to DASH clients and Metrics and Status messages sent from clients to DANEs. These messages are delivered over HTTP via a URL in a HTTP header or a SAND channel(e.g. WebSocket). In this work, we implement a low latency DASH system over HTTP 2.0 and WebSocket[7]. HTTP 2.0 supports function of server push. While using the HTTP 2.0 protocol in adaptive streaming, another problem we need to solve is how to select the quality of segments pushed. Of course, we can push definite amount of segments and change the selection after receiving a new request. In this article, we implemented a system using WebSocket to feedback SAND messages from the client and make server determine which kind of content to be pushed. The remainder of the paper is organized as follows. In Section 2, we summarize the recent and related work on MPEG-DASH. Section 3 discusses our own system including the push scheme and implementation of WebSocket to send SAND messages to the server from the client. In Section 4, we describe the structure of our system and its corresponding open source tools. The results of experiments and comparison with traditional design are also shown. Section 5 concludes the paper. 2 Related Work MEPG-DASH is becoming the popular transmission protocol and many people research on it. Some use cases have been presented in [8] for hybrid broadcasting and it explained how the MPEG-DASH standard performed. Datasets composed of segments with different representations are provided in [9]. Comparisons of HTTP 1.1 and HTTP 2.0 are provided both in terms of functionalities and page download time in [10]. As to the researches on low latency, [11] conducted a number of practical experiments on latency for protocols of HTTP 1.1, SPDY and HTTP 2.0. [12] explored WebRTC in a streaming transport process to carry video data and observed its contribution in low delay streaming with fast channel switching.

3 Low Latency MPEG-DASH System over HTTP 2.0 and WebSocket 3 Fig. 1: Traditional MPEG-DASH streaming system One experiment demonstrated how a DASH client could use Quality of Server(QoS) information to achieve faster quality convergence at start up in [13]. The optimal quality is reached much faster when the DASH client is assisted in estimating the available bandwidth via SAND messages. In this paper, we not only consider push technology from FDH idea, but also explore how to control the quality switch in server side. We finally establish our SAND system based on HTTP 2.0 and WebSocket. 3 Low latency MPEG-DASH System In this section, we will introduce our system using push technology and Web- Socket in details. Fig. 2: Low latency MPEG-DASH streaming system

4 4 Xiaona Wu et al. As shown in Fig.1, media contents are composed of MPD files and DASH segments in kinds of qualities, which are stored in the web server after generated. Then client requests for the MPD file first, parses it, gets the path of target segments according to the network conditions and requests them one by one in traditional streaming system. In our system, we utilize the push idea in FDH over HTTP 2.0 and SAND messages to improve the performance. The server will push next several segments and switch to different bitrates adaptively according to SAND messages sent from the client as shown in Fig Push Strategy In our system, we use the HTTP 2.0 protocol to implement push function. The server will push the corresponding resources to the client before it sends its requests for needed certain segments, which can reduce the live and start-up delay. This method can also decrease the number of connections to server and the size of header sent by the client. In this section, we mainly talk about two methods for media push in our system. As we said before, push technology can reduce both live latency and start-up latency. For the first purpose, we need to push several media segments to the player not wasting time for the connection establishment between them again and again as shown in Fig.3(a). And for the start-up delay, we need to do some changes in the beginning of playback for a video as shown in Fig.3(b). (a) Case I (b) Case II Fig. 3: Two methods for reducing time delay. Case I in (a) shows that the server pushes n segments for each request and Case II in (b) shows the server pushes MPD file, initialization file and all the following segments to start playback more quickly.

5 Low Latency MPEG-DASH System over HTTP 2.0 and WebSocket 5 After receiving the manifest file, the client parses the file and requests for the segments in proper bitrates. The web server will push not only the requested one but also a certain number of following segments in the same quality. After reading from the buffer the client will repeat the request process. This can obviously reduce the Round Trip Time(RTT) in live streaming. Considering that push strategy will mostly be used in live streaming, users watch videos continuously. So there will be no data redundancy because all resources will be provided to users. For the purpose of decreasing start-up delay, we can just push resources after the server receives the request for MPD. Once web server detects the request, it pushes the initialization mp4 file and several video segments and the client can start to play video immediately. Although we may not play the segments in most appropriate quality to make full use of the bandwidth at first, we reduce the start-up latency to get better experience for users. 3.2 Messages Feedback over WebSocket Using pull technology the client would choose the required quality of segments according to the bandwidth calculated by the downloading bitrate. Then when we use the push technology, we need to consider the selection of the proper quality. We attempted several ways to transfer the bandwidth message from client to server. WebSocket has a high real-time performance so we choose it to transfer the SAND messages. Algorithm 1 Feedback SAND messages using WebSocket The client: Input: current downloading bitrate A, previous bitrate B while A B is more than 500bps do send SAND messages M (M=A) to server let B = A detect downloading bitrate and update A The server: Input: SAND messages M Pushing repa if M accepted then if server has repm then Push repm in new quality else Push highest quality segments else Push repa The basic idea is making the client to estimate the network conditions at all time. Algorithm 1 gives the detailed description. When there is a large enough

6 6 Xiaona Wu et al. change the client will send the current downloading bitrate to server. Then the server can judge the message and change to push segments in another bitrate to avoid the network choked or bandwidth wasted. Obviously this scheme proposed a more robust rate adaption method for live streaming. However, we did not take the sharp changing of network into consideration and we will discuss how to improve robustness of the system in the future. 4 Experiments and Comparisons We implement the low latency MPEG-DASH system based on HTTP 2.0 protocol and WebSocket. The datasets Big Buck Bunny[14] we use are from ITEC- Dynamic Adaptive Streaming over HTTP[15]. The corresponding parts with different segment durations we use are shown in Table 1. We choose Node.js[16] as the web server implementing our push strategy and open source project openssl to generate the key and certificate in the server to establish HTTPS connection for that is the need of HTTP 2.0 protocol. For the client side, dash.js[17], an opensource library, acts as the player developed by DASH Industry Forum and supported by many industry media companies. It also supports the push technology and we only need to add some marks to do our experiments. Table 1: Datasets with different durations Index Duration FrameWidth FrameHeight Bitrate(kbps) 1 1s s s s Adaptive Switch over WebSocket First, we test adaptive switches according to SAND messages over WebSocket. The 1s segments are used as MPEG-DASH video sources with bitrates of bps, bps, bps, bps, bps, bps, bps and bps shown in Table 2. Using SimpleHT T P Server module in Python to start a server for the dash.js player interface and node server for the video resources, we can get all the information of network transmission in the Chrome devtools[18]. A WebSocket connection is established between the server and client. When network condition is changed large enough, the client will send the current downloading bitrate message to media source server. Then the server judges the message and chooses segments to push. The results of adaptive switch are shown in Fig.4.

7 Low Latency MPEG-DASH System over HTTP 2.0 and WebSocket 7 Table 2: Datasets for adpative switch Name FrameWidth FrameHeight Bitrate(kbps) bunny bps bunny bps bunny bps bunny bps bunny bps bunny bps bunny bps bunny bps From the above figure, we can see that the bandwidth of network is changing along with time. For example, if the server finds out that the condition becomes worse, it will push lower bitrate segments to client to avoid the playback freezes due to the slow downloading speed of high quality resources. On the contrary, when network gets better, the server will choose higher bitrate segments to push in order to improve the bandwidth utilization. Fig. 4: Adaptive switches over WebSocket with SAND messages

8 8 Xiaona Wu et al. 4.2 Key Indicators In this part we test the performances of our own system. For the experiments, we mainly talk about three main indicators: header sizes of requests and responses, start-up delay and transmission latency. Header size First, we consider the difference of header sizes. Using the 1s segments we find that header size of requests is 514 and 446 bytes respectively and the response header size is 299 and 142 bytes for traditional and our systems. We get the new result of 259 and 80 bytes when we add the push technology in HTTP 2.0. Fig. 5: Comparison of header sizes of request and response The size is apparently reduced about 50 percent and it eventually saves the bandwidth resources. We get the same results when using 2 or 6 or 15 seconds segments. Fig.5 shows the comparison of request headers in the left and response headers another side intuitively. Start-up delay The start-up delay is another important indicator for video streaming. We test start-up delay using different segments and receive the following results in Fig.6. The line above represents the start-up delay in our system and the other is for the traditional transmission. As we can see, the player will playback video contents more quickly. The time saved for segments duration of 1, 2, 6 and 15 seconds is about 45.46%, 26.7%, 43.21% and 45.51%. Transmission latency The last indicator we need to consider is the transmission latency. When we are stuck in a bad network, it is pretty significant to keep downloading resources to avoid playback freezing. Under the consideration of the segments sizes, we compare the latency of same one in two systems each time. In the situation for 1s segments, the results are shown in Fig.7(a) and compared for each one.

9 Low Latency MPEG-DASH System over HTTP 2.0 and WebSocket 9 (a) 1s (b) 2s (c) 6s (d) 15s Fig. 6: Start-up delay for 1s, 2s, 6s and 15s segments. (a) 1s (b) 2s (c) 6s Fig. 7: Transmission delay for 1s, 2s and 6s segments.

10 10 Xiaona Wu et al. However, some sudden breaks may happen when downloading segments and we have to request again or change to the next one. If the length of one segment is too long, contents played will be dulplicate or missing. So we will ignore the 15s segment situation. The other results are shown in Fig.7(b) and (c). It is obvious that the larger segments are, the more advantages it will have in saving time. The time decreased are respectively 43.82%, 57.11% and 72.96%. 5 Conclusion In this paper, we use HTTP 2.0 and WebSocket to develop a low latency MPEG- DASH streaming system. HTTP 2.0 protocol is utilized for push technology, while WebSocket is used to transfer the SAND messages in order to adaptively choose the resources pushed. Also, we take some experiments to prove its advantages of smaller header sizes to save network bandwidth, lower start-up delay to give better user experience and lower transmission latency to save time in live streaming. To sum up, we observe that there is 40.22% start-up time saved and 57.96% live delay saved averagely in all situations. Obviously the start-up time and live delay are saved much and this scheme can be used in the live streaming. It can provide users a more comfortable experience for live broadcasting. 6 Acknowledgement This work was supported by NSFC ( and ), the 111 Project (B07022 and Sheitc No ) and the Shanghai Key Laboratory of Digital Media Processing and Transmissions. References 1. Stockhammer, T.: Dynamic adaptive streaming over http: standards and design principles. In: ACM Conference on Multimedia Systems, pp (2011) 2. ISO/IEC :2012, Information technology dynamic adaptive streaming over http(dash) part 1: Media presentation description and segment formats (2012) 3. ISO/IEC :2015, nformation technology Coding of audio-visual objects Part 12: ISO base media file format (2015) 4. ISO/IEC :2015, Information technology generic coding of moving pictures and associated audio information part 1: Systems (2015) 5. Information Technology Dynamic adaptive streaming over HTTP(DASH) Part 6: DASH over Full Duplex HTTP compatible Protocols(FDH) (2015) 6. ISO/IEC :2017, Information Technology Dynamic adaptive streaming over HTTP(DASH) Part 5: Server and network assisted DASH (SAND) (2017) 7. RFC 6455, The WebSocket protocol (2011) 8. Feuvre, J.L., Concolato, C.: Hybrid broadcast services using mpeg dash 9. Lederer, S., Timmerer, C.: Dynamic adaptive streaming over http dataset. In: ACM Sigmm Conference on Multimedia Systems, Mmsys 2012, Chapel Hill, Nc, Usa, February. pp (2012)

11 Low Latency MPEG-DASH System over HTTP 2.0 and WebSocket Corbel, R., Stephan, E., Omnes, N.: Http/1.1 pipelining vs http2 in the clear: Performance comparison. In: International Conference on New Technologies for Distributed Systems. pp. 1 6 (2016) 11. Naik, N., Jenkins, P.: Web protocols and challenges of web latency in the web of things. In: Eighth International Conference on Ubiquitous and Future Networks. pp (2016) 12. Zhao, S., Li, Z., Medhi, D.: Low delay mpeg dash streaming over the webrtc data channel. In: IEEE International Conference on Multimedia Expo Workshops. pp. 1 6 (2016) 13. Thomas, E., Deventer, M.O.V., Stockhammer, T., Begen, A.C.,Famaey, J.: Enhancing mpeg dash performance via server and network assistance. In: Ibc (2015) 14. BigBuckBunny, DASHDataset2014/BigBuckBunny/ 15. ITEC, 16. Node.js, Dash.js, Chrome DevTools,