SyncStream: Synchronized Media Streaming System in a Peer-to-Peer Environment Daeil Seo
Suhyun Kim
Gyuwon Song
Dept. of HCI and Robotics Imaging Media Center Dept. of HCI and Robotics University of Science and Technology Korea Institute of Science and Technology University of Science and Technology Seoul, Korea Seoul, Korea Seoul, Korea
[email protected] [email protected] [email protected]
Abstract—With recent advances in video encoding and network technology, media streaming services are getting popular. Media streaming system based on the traditional server/client or CDN architecture has a scalability problem, and peer-to-peer media streaming system using resources of peers in the system can provide better scalability. Previous media streaming services are suited to play stored contents such as dramas or movies, which are not live or real-time. However, if these services are used to provide live streaming such as broadcasting sports events, variation among play positions of peers in the service will be a problem. The users will demand simultaneity between viewers watching the same sports game through a real-time streaming service. To solve this problem, it is necessary to coordinate the behavior of peers participating in the service. In this paper, we propose SyncStream, a peer-to-peer media streaming system that synchronizes play positions of peers in the service. SyncStream provides synchronization in the same channel to help concurrent interaction among users. In our experiment, the difference in play positions of SyncStream nodes is 1 second at the maximum. This small gap among viewers will encourage group interaction and enrich user experience.
I. I NTRODUCTION With recent advances in video encoding and network technology, media streaming services are getting popular. Media streaming system based on the traditional server/client or CDN(Content Delivery Network) architecture has a scalability and cost problems, but peer-to-peer based system using resources of peers in the system can provide better scalability and cost efficiency. Media streaming system are (1) the traditional server/client, (2) CDN, and (3) peer-to-peer based system. The traditional server/client media streaming system is stored contents on the server. A client sends a request to the server, the server provides a content to the client. The server handles requests for contents, load of the server is increased. Because of this reason, the traditional server/client system has a scalability problem. The CDN architecture is designed to avoid the server bottleneck. In the CDN, computers are containing copies of contents and placed at various points in the network. The CDN can overcome of weakness of the server/client system; however, it is also demanded expensive cost when increasing This work was supported by the IT R&D program of MKE/KEIT. [KI002119, Development of New Virtual Machine Specification and Technology]
computers for better performance. The peer-to-peer based media streaming system provides better scalability and cost efficiency by using resources of peers. The previous media streaming services are appropriate contents such as dramas, movies. These contents are serviced by VoD(Video-on-Demand) systems; on the other hand, sports broadcast is required real-time live streaming. The users will demand simultaneity between viewers watching the same sports game through real-time streaming system. These contents are streamed by existing systems, users cannot watch contents in real-time. Existing systems have the gap between play positions of peers, group interaction with watching same view is difficult. In this paper, we propose SyncStream, a peer-to-peer media streaming system that synchronizes play positions of peers in the service. SyncStream provides synchronization in the same channel to help concurrent interaction among users. The rest of the paper is organized as follows. In the next section, we introduce related work on the peer-to-peer systems and view sharing. In section 3, we show problems of previous systems and present the basic design of SyncStream. We discuss the evaluation results of SyncStream in section 4 and conclude in section 5. II. R ELATED W ORK Recent main focus of the peer-to-peer researches is a file sharing. Nowadays, research on the peer-to-peer based media streaming becomes active. File sharing based on the peer-to-peer system is sharing resources owned by participants in systems. There are a lot of popular systems such as BitTorrent [1], eMule Project [2], and Tribler [3]. These systems store sharing files in distributed nodes and transfer files concurrently using resources of participants whenever a user wants. BitTorrent [1] is the most popular peer-to-peer file sharing system and a growing number of organizations are using it to distribute their contents. eMule Project [2] uses eDonkey and KAD protocols for file sharing. It brings in a reward system to encourage users to upload more files. Tribler [3] is based on BitTorrenent protocol and introduces a trust-based social group. Social group is an online community of similar taste for contents and boosts participation of users.
978-1-4244-7570-4/10/$26.00 ©2010 IEEE
Another research on the peer-to-peer system is media streaming systems. These systems are getting popular and consisted of VoD and live streaming systems. The peer-topeer VoD system has fewer synchronism when users share video contents. Huang et al. [4] proposed a general architecture for supporting VoD services based on PPLive. They present a number of results on user behavior, various system performance metrics and discuss what they observe based on the system design. P2Cast [5] is designed a VoD system to support asynchronous users and uses patching techniques, while only relying on unicast connections among peers. GridCast [6] improves to peer sharing through caching and replication. It has served videos to 23,000 unique users in peak months. J. Wang et al. [7] is Tribler based personalized television system. A user selects a channel and watches content by streaming from other users. However, this system cannot provide concurrent interaction among users watching same content because it does not serve real-time media streaming. These peer-to-peer VoD systems do not support synchronization of viewing position among peers. The peer-to-peer media streaming systems are deployed with high viewing quality but low server burden. GoalBit [10] is the first open source peer-to-peer streaming system and improves QoE(Quality of Experience), performance value of the system measured by peer. MyP2P [8] and PPLive [9] are commercial peer-to-peer streaming services. MyP2P [8] provides specialized services for sports. PPLive [9] is the largest chunk-driven multimedia streaming peer-to-peer overlay in the world. PPLive had over 200 distinct online channels, a daily average of 400,000 aggregated users, and average of 200,000 concurrent users in one channel. There are a lot of works on sharing view. Zync [11] is a synchronized video player that provides a social viewing experience for online videos. It provides a plug-in module for a popular instant messaging client to help foster conversations. People can share their opinions and experiences by adding comments or chatting. Cesar et al. [12] presents an architecture and implementation for media content selection, organization, and sharing within a user community. CollaboraTV [13] allows people to interact in synchronous, asynchronous, and mixed television-viewing situations. III. S YNCHRONIZED S TREAMING S YSTEM In this paper, we provide SyncStream, a peer-to-peer media streaming system that synchronizes play positions of peers in the service. Our system based on GoalBit [10], an open source peer-to-peer streaming network. However, it cannot be satisfied our purposes that synchronized view among peers to encourage group interaction and enrich user experience. In this section, we introduce problems of previous systems and propose a solution to solve them. A. Problems In general, the majority of media streaming systems focus on VoD. Typical system of this purpose is the CDN architecture that is efficient for streaming many of the individual users
to difference contents. Individual users can watch a targeting content rapidly; however, it is unsuitable for interaction among users watching live events such as sports games. These systems have a problem that cannot provide simultaneous play positions among users watching same content. It makes difficult to interact with others.
Fig. 1. System
Difference of Synchronized Real-time vs. VoD Media Streaming
Figure 1 shows the difference of synchronized real-time and VoD media streaming system. VoD system has computers are containing copies of contents and provides contents efficiently whenever the user wants. If the next frame was not delivery cause of network error, VoD system waits for that frame. After restoring network error, the player continues to play next frame. However, real-time media streaming has a different requirement. When users select a channel, the system sends a frame which is played instantly. After restoring network error, the player skips some frames during network error and plays a frame receiving in real-time. In peer-to-peer real-time media streaming, simultaneous play among peers is difficult. Peers make a lot of churns since continuously joining, leaving, and failing. Network errors in the peer-to-peer system are more occurred than the traditional server/client or CDN system. Peer-to-peer real-time media streaming ought to provide synchronization among peers. To solve this problem, we propose SyncStream, a peer-topeer media streaming system that provides synchronization of play positions among peers. SyncStream is based on GoalBit; however, GoalBit does not provide synchronized real-time media streaming. We introduce a protocol for synchronization of play positions in SyncStream. B. System Architecture For synchronizing view, media streaming system requires a component collecting play position of users. We call this information, ESI, the current piece ID played by the SyncStream player. We add a component ESI Control Sever, collecting ESI and sharing synchronized position. SyncStream nodes send the ESI information to ESI Control Server periodically.
Fig. 3.
Fig. 2.
Overview of SyncStream
ESI Control Server collects ESI from nodes and creates synchronization information, NEXT ESI, based on ESI. When ESI Control Server sends NEXT ESI to participated nodes, nodes compare and update current play position to NEXT ESI. Figure 2 is an overview of SyncStream. SyncStream is consisted of these components. Broadcaster receives the content from some source, divides the stream to piece for distribution, and sends pieces into the peer-topeer network. Super-peers are highly available and bandwidth peers. They get the stream from broadcaster and help to distribute contents. Peers are the final users and play the contents from the broadcaster and super-peers. Tracker manages the list of peer participating in media streaming system among channels. In SyncStream, the Tracker also takes a role ESI Control Server. ESI is the play index of current peer. Each peer adjusts a play position of media streaming. Table 1 is notations of SyncStream protocol. C. SyncStream Synchronized Protocol It is required a criterion for synchronization of play position in SyncStream. In SyncStream, we modify GoalBit protocol to share ESI information and NEXT ESI. Peers have an active buffer that stores pieces from the broadcaster or super-peers. After receiving pieces, SyncStream player plays a piece in the active buffer in sequence. Active buffer has ABI(Active Buffer Index) in GoalBit. We add ESI and NEXT ESI for SyncStream. ABI is the largest piece ID inside the active buffer. ESI is the current piece ID played by the player. NEXT ESI is the next piece ID to be consumed by the player. Peers send ESI information to ESI Control Server TABLE I N OTATIONS OF S YNC S TREAM PROTOCOL Name ABI ESI NEXT ESI
Description The largest piece ID inside the active buffer The current piece ID played by the player The next piece ID to be consumed by the player
SyncStream synchronized protocol
periodically for synchronization. ESI Control Server receives ESI from peers and executes the algorithm for generating NEXT ESI. ESI Control Server can select the lowest or height ESI value for NEXT ESI. If the lowest ESI is selected, all of peers are synchronize with position of a late playing node in the system. Some of the peers suffer from resources or network problems, peers in the system affected by these problems. When the height ESI is selected, position of peers is synchronized with fastest peer in the system. Some of the peers play late, it does not influence on others. For these reasons, ESI Control Server selects maximum ESI of collecting values in SyncStream. ESI Control Server chooses the maximum ESI on each channel and sends it to peers. This is NEXT ESI. After receiving NEXT ESI, a peer compares ESI of itself with NEXT ESI from the ESI Control Server. The peer selects a higher value between ESI and NEXT ESI. If the peer selects NEXT ESI, the peer sends a request for pieces which index is grater than NEXT ESI. Figure 3 is the synchronized protocol of SyncStream. IV. E VALUATION AND A NALYSIS In this section, we provide experiment results of SyncStream and GoalBit. We show performance of SyncStream providing synchronization of play position. A. SyncStream vs. GoalBit The major difference between SyncStream and GoalBit is synchronization of play position. We show the difference using ESI of peer and NEXT ESI from ESI Control Server. GoalBit originally does not use ESI and NEXT ESI. For comparison, we add the ESI and NEXT ESI field to GoalBit protocol. GoalBit receives ESI and NEXT ESI from ESI Control Server. GoalBit does not use this information for playing. In this experiment, we use a cycle of synchronization per 2 seconds and ESI value is increased 2 per second. Figure 4 is the comparison of ESI and NEXT ESI in SyncStream and GoalBit. We measure ESI and NEXT ESI during 1,700 seconds. The difference of NEXT ESI and ESI is the positioning difference of between the fastest and current peer. When the difference is larger, current peer has higher delays. The difference is 0, current peer has the same view with the fastest peer in the system. The average difference is 1.85 in SyncStream and 9.03 in GoalBit and the maximum difference
plays similar index of other peers in SyncStream. In GoalBit, a peer plays different index in the system. The gap of play position is determined by duration of network error.
Fig. 4.
Comparison of ESI in SyncStream vs. GoalBit
is 10 in SyncStream and 59 in GoalBit. In other words, the average difference of between the slowest and fastest peer is approximately 1 second in SyncStream and 5 second in GoalBit. The maximum difference of the slowest and fastest peer is approximately 5 seconds in SyncStream and 29 second in GoalBit.
Fig. 6. Comparison of ESI in SyncStream as synchronized frequency varies
In SyncStream, we use ESI and NEXT ESI to handle to time delays for synchronization. SyncStream has approximately 1 second delay between peers comparing with GoalBit has 5 seconds. In addition, SyncStream overcomes to delay occurring by network error. B. Synchronization Frequency
Fig. 5. Comparison of behavior after network error in SyncStream vs. GoalBit
Figure 5 is a comparison of behavior in SyncStream and GoalBit after network error. It shows difference behaviors between SyncStream and GoalBit through NEXT ESI and ESI. Peers make a lot of churns since continuously joining, leaving, and failing. This tendency makes temporal network errors frequently. We assume that all the peers play same position of content in the channel. In figure 5, network error is occurred at 18th slot and media streaming is restarted at 29th slot. Before network error, SyncStream and GoalBit show a similar tendency. However, after restoring network error, SyncStream and GoalBit act like different behavior. SyncStream updates ESI using NEXT ESI from ESI Control Server and GoalBit updates ESI to ESI + 1. These policies made a difference. A peer suffered network error, the peer
In this section, we discuss frequency of synchronization. Peers in SyncStream send ESI information to ESI Control Server periodically. When peers send ESI information frequently, the system spends more bandwidth. If the cycle of synchronization is infrequently, peers suffer from mismatch of ESI between peers. It is important to choose suitable ESI value. Figure 6 is the difference of ESI in SyncStream as synchronized frequency varies. Synchronization frequency is a tradeoff between bandwidth and gaps of play position. For tracking change of ESI, we measure ESI and NEXT ESI during 1,700 seconds and cycles of measurement are 1, 2, and 5 seconds. We denote a notation for cycles of measurement. Cycle per 1 second is C1 , cycle per 2 seconds is C2 , and cycle per 5 seconds is C5 . The average bandwidth for synchronization in C2 is 2 times more than C1 and C5 is 5 times more than C1 . The average difference of NEXT ESI and ESI is 1.65 in C1 , 1.85 in C2 , and 5.43 in C5 . This experiment shows that short synchronized time spends more bandwidth. However, the effect is not always good. Based on this experiment, we choose an appropriate synchronized frequency of ESI to 2 seconds. V. C ONCLUSION In this paper, we propose SyncStream, a peer-to-peer media streaming system that synchronizes play positions of peers in the service. SyncStream provides synchronization in the same channel to help concurrent interaction among users. SyncStream has approximately 1 second delay between peers
compared with GoalBit has 5 seconds. This small gap among viewers will encourage group interaction and enrich user experience. In addition, SyncStream has good behavior to overcome delays by network error. We hope that SyncStream can be relevant various real-time media streaming services. R EFERENCES [1] BitTorrent Homepage. http://www.bittorrent.com [2] eMule Project Homepage.. http://www.emule-project.net [3] J. Pouwelse, P. Garbacki, J. Wang, A. Bakker, J. Yang, A. Iosup, D. Epema, M. Reinders, M. van Steen, and H. Sips, “Tribler: A socialbased peer-to-peer system,” Concurrency and Computation: Practice and Experience, vol. 20, pp. 127–138, February 2008. [4] Y. Huang, T. Z. Fu, D.-M. Chiu, J. C. Lui, and C. Huang, “Challenges, design and analysis of a large-scale p2p-vod system,” in SIGCOMM ’08: Proceedings of the ACM SIGCOMM 2008 conference on Data communication, 2008, pp. 375–388. [5] Y. Guo, K. Suh, J. Kurose, and D. Towsley, “P2cast: peer-to-peer patching scheme for vod service,” in WWW ’03: Proceedings of the 12th international conference on World Wide Web, 2003, pp. 301–309. [6] B. Cheng, L. Stein, H. Jin, X. Liao, and Z. Zhang, “Gridcast: Improving peer sharing for p2p vod,” ACM Trans. Multimedia Comput. Commun. Appl., vol. 4, no. 4, pp. 1–31, 2008. [7] J. Wang, J. Pouwelse, J. Fokker, A. P. Vries, and M. J. Reinders, “Personalization on a peer-to-peer television system,” Multimedia Tools Appl., vol. 36, no. 1-2, pp. 89–113, 2008. [8] MyP2P Homepage. http://www.myp2p.eu [9] PPLive Homepage. http://www.pplive.com [10] M. E. Bertinat, D. D. Vera, D. Padula, F. Robledo, P. Rodr´ıguez-Bocca, P. Romero, and G. Rubino, “Goalbit: The first free and open source peer-to-peer streaming network,” in LANC ’09: Proceedings of the 5th international IFIP/ACM Latin American conference on Networking, 2009. [11] Y. Liu, P. Shafton, D. A. Shamma, and J. Yang, “Zync: the design of synchronized video sharing,” in DUX ’07: Proceedings of the 2007 conference on Designing for User eXperiences, 2007, pp. 1–8. [12] P. Cesar, D. C. Bulterman, D. Geerts, J. Jansen, H. Knoche, and W. Seager, “Enhancing social sharing of videos: fragment, annotate, enrich, and share,” in MM ’08: Proceeding of the 16th ACM international conference on Multimedia, 2008, pp. 11–20. [13] M. Nathan, C. Harrison, S. Yarosh, L. Terveen, L. Stead, and B. Amento, “Collaboratv: making television viewing social again,” in UXTV ’08: Proceeding of the 1st international conference on Designing interactive user experiences for TV and video, 2008, pp. 85–94.
