Scalable Video Distribution in Peer-to-Peer Architecture Roberto Pontes Nunes
Rui Santos Cruz, M´ario Serafim Nunes
Instituto Superior T´ecnico Lisbon, Portugal Email:
[email protected]
Instituto Superior T´ecnico/INESC-ID/INOV Lisbon, Portugal Email:
[email protected],
[email protected]
Abstract—The combination of Scalable Video Coding and Peerto-Peer networks is a potential area of innovation in terms of video streaming on the Internet. Applications for sharing files, such as BitTorrent, have been broadly developed and nowadays they cater for the majority of the Internet traffic, adding the need for the exploration of real-time streaming services based on these networks. Several Peer-to-Peer streaming techniques have been deployed, but very few explore bandwidth adaptation, support of diverse terminal and computational setups, adequate incentives for contributing in a multi-source streaming environment or maintenance of a stable perceived video quality. This paper presents the design and implementation of a Scalable Video Coding and Peer-to-Peer Player prototype that uses a novel adaptive algorithm, the Prioritized Sliding Window, that addresses all these related issues in terms of maintaining a stable QoS/QoE. The evaluation of the prototype shows that it achieves a robust real-time streaming service, supports several terminal setups, adapts bandwidth to various access networks and discourages free-riders in the network. Index Terms—BitTorrent, Scalable Video, Peer-to-Peer, Adaptive Streaming
I. I NTRODUCTION Currently, most of the Peer-to-Peer (P2P) traffic in the Internet is used to distribute video files [1]. A user has to download the video file before being able to watch it, suffering from a long start-up time. But users are often interested in streaming the video for online viewing rather than for delayed playback, and this requires average streaming rates, typically between 300 Kbps and 1 Mbps. Managing and assuring a certain service quality for all users within a P2P network becomes a more challenging task than with other architectures, as the requirements and the conditions differ extensively among peers in regard to both their system resources (i.e., processing power or screen size) and the available network bandwidth (i.e., uplink or downlink bitrates). The constraints associated with the available network bandwidth are mainly connected to the relatively low uplink bandwidth of the access networks (due to the asymmetric characteristics of Asymmetric Digital Subscriber Line (ADSL) or cable networks), making it hard to stream audio visual contents. And that asymmetry is the main reason for the adoption of downloading methods instead of streaming by the most common P2P systems. And here is where Scalable Video Coding (SVC) techniques come of help by allowing users with variable bandwidth
resources to watch the video as it is being downloaded, due to special methods for encoding videos into layers with nested dependencies, i.e., higher layers refine the video in lower layers. To decode and playback the video, the base layer (i.e., the first layer) is required, corresponding to a low definition, acceptable quality video with a low bitrate. However, if higher layers can also be received then the decoding will produce a higher quality/definition video. Offering end users in a P2P network quality video streaming adapted to network conditions, together with the ability to manage the streams in almost “real-time” either in terms of space (i.e., image resolution), time (i.e., frame rate) or Signal-toNoise Ratio, are the challenges behind the development of the prototype solution1 described in this paper (focused on the Peer application component). For the P2P architecture of the solution, the option fall on the BitTorrent protocol [3], but modified in order to comply with the key requirements for distributed video streaming: • Real-Time streaming: Lost packets in enhancements layers neither affect the assembly nor the decoding of lower layers. The proposed Chunk-Layer requesting and scheduling algorithms give higher priority to more important layers. • Real-Time adaptation: maximizes the end-user perceived quality by adapting the video streaming to the terminal capabilities and the available bandwidth. • Upload Policies: incentive method for peers as the more they contribute, the more they receive video with better quality. In this paper, Section II present the State of the Art in related technologies, Section III gives an overview of the Scalable Video Coding P2P Player architecture and features, Section IV presents the evaluation results, Section V concludes the paper. II. S TATE OF THE A RT The scalable extension of H.264 Advanced Video Coding (AVC) [4], denoted as H.264 SVC or simply SVC, includes a sparse number of quality layers. The scalability property of SVC supports the partitioning of a valid bit stream into several other valid sub-streams by simply cutting parts of 1 The SVC P2P prototype solution described in this paper was developed within the scope of the European project SARACEN [2].
CRC'2010 - 10ª Conferência sobre Redes de Computadores, pp. 95-100, Universidade do Minho, Braga, Portugal, 2010. ISBN: 978-989-96929-1-6
96
Roberto Nunes, Rui Cruz, Mário Nunes
its data, and due to its simplicity, it may be performed in intermediate network elements without requiring high loaded computational work (like video transcoding). Additionally the base layer of an encoded H.264 SVC bit stream is by definition an H.264 AVC stream, enabling backward compatibility with legacy equipments. SVC offers three types of scalable dimensions [5], [6]: • spatial (i.e., number of encoded pixels per image); • temporal (i.e., pictures per second); • quality (or Signal-to-Noise Ratio). In a bit stream, each Network Abstraction Layer (NAL) unit (NAL units are packets that start with a one-byte header and have an integer number of bytes) is associated with a given level of spatial, temporal and quality fidelities. All of the three scalability dimensions can be combined with each other. However, the most important classification refers to the spatial layers of the SVC video stream, as within one spatial layer there can reside one or more temporal and quality layers. Many Peer-to-Peer Television (P2PTV) solutions are already available on the Internet ether commercial (e.g., TVUPlayer [7], PPLive [8] or CoolStreaming [9]) or open-source (e.g., Tribler [10] and BitLet [11]) offering video streaming capabilities (but without the functionality for scalable video). Most of them rely on similar concepts (professional TV shows, private contents, advertisement business model) but the advantage for linear TV broadcasters with this new concept is the possibility to make their programs available worldwide (apart from contents rights restrictions issues), shifting the costs of broadcasting to the users. Although Scalable Video Coding and Peer-to-Peer networks have attracted enormous attention from the research community, the amount of scientific publications focusing their interaction is rather small. The authors in [12] employ SVC to guarantee smooth delivery of video content among the peers in the network. The system described in [13] also uses SVC in a P2P environment. The theoretical analysis concentrates on quantifying the advantage of SVC with respect to single layer video coding. The research project P2P-Next [14], is also conducting the study and deployment of an advanced version of Tribler to use SVC encoding, but oriented to a fully distributed web platform, named NextShare [15].
files, called Layers, for the transmission. The only Layer that is required to reproduce the video, without dependencies, is the first Layer, called the Base Layer. The remaining Layer files will consume more download time, but if the Peer manages to download them, they will enhance the quality of the final assembled video.This scheme has the following advantages: • Increases time stamp and video bitrate adaptation granularity (very good for live streaming, and time seeking purposes); • Decreases the timeline delay for the streaming peers that are watching a live event. The network is composed by “Seeders” and “Leechers”. Seeders hold the complete video contents (i.e., the container with all file pieces), and all the Chunks and Layer files. The Leecher downloads the content within the BitTorrent network, but may also act as re-Seeder once in possession of some part or the full content (see Figure 1).
Figure 1.
File Data Process and Distribution
Once a Peer starts the bootstrap procedure (not the original seeder of the video) to initiate streaming it first contacts the Tracker to announce itself and to ask for information on other Peers sharing the desired content. After a Peer succeeds with the transfer of some or all Layers of a certain Chunk, these can be assembled into a playable video (with 2 seconds of duration), with variable quality depending on the number of Layer files used, that is then put in the SVC Player buffer for play-out. The P2P network behaves therefore as a distributed file system (or a multi-source streaming system) for video chunked layered files.
III. A RCHITECTURE OVERVIEW AND F EATURES The SVC P2P prototype solution is basically composed by several Peers (i.e., Clients) and one or more Trackers (i.e., Control Servers). Unlike what happens with a Client-Server model, the Trackers of this solution do not relay video content but instead provide information about the Peers on the network (i.e., contact information, streamed data status, etc.). A. Architecture Design The technique used for the operation of the system relies on a chunk transfer scheme, whereby the original video file data is chopped into small video Chunks with a duration of 2 (two) seconds. Each Chunk of video is then partitioned into various
B. Adaptation System and Peer Selection Strategy Unlike common BiTorrent protocols, the SVC P2P prototype does not use equally sized data blocks nor extracts pieces from the peers in the network in a random, rarest-first style order (see Figure 2), as these strategies would not be suitable for streaming since all video data in a timeline interval must be available, and in ordered sequence, for play-out. The strategy developed, named “Priority Sliding Window (PSW)” is an adaptation algorithm that chooses the adequate pieces already stored at each peer, in a download time period of 2 seconds, and sets a Chunk download window of size 3 (i.e., 6 seconds of video) that prioritizes the base layer
Scalable Video Distribution in Peer-to-Peer Architecture 97
Figure 2.
Standard BitTorrent Piece Download Strategy
and also to the Internet. The Web server system was based on Microsoft’s Internet Information Services (IIS) 7.0 [16]. The first scenario uses three different access networks (Figure 4): • A campus High-Speed LAN • A campus High-Speed Wireless Local Area Network (WLAN) • A 3rd Generation (3G)/Universal Mobile Telecommunications System (UMTS) Network
files. In the Chunk download window the number of Layers can increase or decrease, depending on several measured conditions (e.g., available bandwidth, latency, CPU load, etc.). As the Chunk download window slides every 2 seconds, priority assignments can be given to higher enhancement layer for next Chunks, if conditions are favorable. Figure 3 illustrates the file priority assignment as the video rendering is being processed by the Player. The Chunk priority is represented from top to bottom (i.e., base layer to last enhancement layer).
Figure 4.
Figure 3.
Priority Sliding Window Piece Download Strategy
The Peer selection strategy follows closely the neighboring algorithms of BitTorrent but with a slight modification to take into account the geographical location of Peers, giving higher priority on requests to closest Peers, due to the following reasons: • ISP Traffic Cost – Minimize traffic cost to international Internet Service Providers (ISPs). • Latency – Minimized if requests are made to local peers, or peers in the same ISP network. • Traffic Shaping – To avoid ISPs throttling, that limits bandwidth in P2P connections to external Peers. IV. E NVIRONMENT AND E VALUATION R ESULTS For the evaluation of the prototype behavior, as well as its functionalities and scalability of the whole solution, two scenarios were considered, the first to cover almost all functional requirements and the second to evaluate the prototype scalability and incentive properties. The Tracker and superseeder for both scenarios were installed in a Web server located in a controlled network environment, on a University campus premises, providing services to an internal high-speed 100 Mbps Local Area Network (LAN), a Wireless LAN (802.11g)
Local test scenario
The functional test set included the evaluation of the behavior over heterogeneous networks, the performance with live streaming and also terminal capabilities support. The end user device used for the majority of the tests possessed an Intel Core2Duo 2.26 GHz Central Processing Unit (CPU), with 3 GB DDR2 of RAM, running Windows 7 operating system. Another system with an Intel Pentium III 750 MHz, 512 MB of memory Random-Access Memory (RAM) and running Windows XP operating system was also used for the terminal capabilities tests. The second scenario deployed a set of peers (launching various computer instances) using Amazon’s Elastic Compute Cloud system [17]. Each set of peers was distributed over four world regions: US East (Virginia), US West (N. California), EU West (Ireland) and Asia (Singapore). Each region contained 4 peers, for a total overlay network of 12 active peers. Each instance corresponded to an Intel Xeon 2.6 GHz CPU, with 2 GB DDR3 of RAM, running Windows Server 2008 Datacenter Edition, with 5 Mbps symmetric Internet connections. Remote functionalities were inserted into the prototype in order to control the start/stop of streaming. The tests are performed following the same methodology in order to evaluate the prototype scalability, upload incentives and overall performance. A. Network Behavior Results The main objective of the tests was to evaluate if the Prioritized Sliding Window (PSW) algorithm would outperform standard piece picking policies of BiTorrent protocols (that request pieces using a chain of random and rarest-first piece
98
Roberto Nunes, Rui Cruz, Mário Nunes
picking) or of a simple sequential policy that requests pieces in order without waiting. For consistency of the evaluation process, the tests were performed using the same 250 seconds duration movie, encoded using 10 transmission Layers in both Double Common Intermediate Format (DCIF) and Common Intermediate Format (CIF) resolutions and frame rates between 1.875 fps to 30 fps, starting streaming at the beginning of the video. In Figure 5, Figure 6 and Figure 7 the percentage of received video Layers as a function of the maximum number of Layers per Chunk was plotted, for usage on a LAN, a WLAN and a 3G, respectively, with a single seeder in the swarm. Three distinct piece policies were compared in this scenario: the PSW, the Original BitTorrent Policy and the Sequential Policy. The results for all the situations show that the original BitTorrent policy achieves the highest startup delay (nearly 20 seconds). In Figure 5, the PSW policy bears the lowest startup delay, although slower to achieve the best movie quality than the sequential policy at the initial phase. This is due to the incremental number of Layers that the PSW algorithm orders from Peers.
Figure 5.
Received Chunk-Layer Ratio on LAN
Figure 7.
Received Chunk-Layer Ratio on 3G
B. Live Performance To test live video behavior and performance, a web camera with Hypertext Transfer Protocol (HTTP) support was attached to the Tracker and Super-Seed server in order to capture live video frames. These frames were assembled by ffmpeg [18] to produce H.264 AVC Chunks with 2 seconds of video. Since live encoding of H.264/SVC is still not possible with the available hardware, this solution seemed to be the closest approach to a live scenario. The “live” torrents were created with a 5 minutes timeline each. Each video Chunk file had a constant size of 96 KB, and the first 2 bytes of the file included the original file size. The overhead introduced was of about 5-10 KB per file, transferred as ”garbage”. The live performance tests were performed on the LAN scenario in order to evaluate real-time playback delays. Figure 8 shows the Cumulative Distribution Function (CDF) of the playback delays for a real-time capture. Delays fall between 8 and 13 seconds, with more than 50% probability between 10 and 13 seconds.
In Figure 6, for a WLAN access network, the PSW algorithm achieves a higher playback rate than the simple sequential policy.
Figure 8.
CDF of the Live Playback Delay from Real-Time Capture
C. Terminal Capabilities Figure 6.
Received Chunk-Layer Ratio on WLAN
Figure 7 clearly shows that the PSW algorithm outperforms all other policies, maintaining a stable stream without buffering. The other policies buffer most of the time and achieve very low streaming bitrates.
Two simple tests were performed in order to demonstrate the terminal capabilities adaptation, one for video screen size and the other for terminal CPU load. For the first case, Figure 9 represents the Chunk Layer ratio variation along time. At timestamp 1:05 min the Player video window was resized to a approximately a thumbnail size.
Scalable Video Distribution in Peer-to-Peer Architecture 99
It can be observed that the Chunk Layer ratio decreased the download/render of the number of Layers to 50%, i.e., to a half of the maximum number of Layers available. This behavior is due to the spatial scalability feature of SVC, as the video used for the tests had the first five Layers with a Common Intermediate Format resolution and the remaining higher layers with a Double Common Intermediate Format resolution. After some time the Player video window was resized to the previous normal size, and the PSW repeats the incremental Layer processing.
Figure 9.
algorithm was geographically distributed. These tests used the same methodology as in [19](tested with a non BitTorrent application), for scenarios with freeriders (15% of the peers) and without free-riders in the network, comparing also the effect of the Tit-for-Tat strategy in terms of incentives. Each terminal was initially launched and stayed in idle state until a signal to start the video streaming was received. The start signal was triggered at different timestamps in order to evaluate the server load efficiency in the network. Figure 11(a) and Figure 11(b) represent the CDF of the average download and upload rates, respectively, without freeriders. In Figure 11(a) at least in 50% of time time the playback rate was less than 750 Kbps, eventually reaching 1 Mbps.
Chunk Layer Ratio on LAN with Screen Resize
(a) Download Rate
Figure 10.
Chunk Layer Ratio on LAN with CPU Load
Using a less capable computer as end user terminal (Intel Pentium III 750 MHz), with just a small number of enhancement Layers the player achieved the same CPU load as a dualcore system rendering all Layers. Figure 10 shows the results of video Chunk Layer Ratio with the CPU Load heuristic. As soon as the Player reaches 50% of the available Layers (resolution at CIF), the CPU Load is around 25% and no more Layers are requested from Peers. As soon as the CPU Load falls, the Player tries to increment the number of Layers. Several increments were (forced) tested reaching a maximum of 60% of Layers (a DCIF resolution) but for a very short time, as the CPU load limiter was almost immediately fired, demonstrating that the CPU load heuristic manages to maintain a fluid video stream and performance on any terminal setup. D. Scalability, Incentives and Performance To evaluate the scalability, the performance and the behavior with or without incentives, a group of peers using the PSW
(b) Upload Rate Figure 11. riders
CDF of the Average Download and Upload Rate without free
It is also noticeable that with the Tit-for-Tat policy the bitrates reached, for the same probability distribution, are typically lower. Figure 11(b) shows that the upload rate may reach high values in a initial time window when all peers start streaming the video. As the peers have buffers to fill, and as no one has proven to be a good uploader yet, hight upload rates are achieved. As pieces are not needed to be sent in order, and are requested by any peer and in an random order, the average upload rate (approx. 1 Mbps) is much higher than the download rate. With this test, the average server load dropped from 100% to a 30%. Figure 12(a) represents the CDF of the average download rate when there are 2 or 3 free-riders in the network. The free-
100
Roberto Nunes, Rui Cruz, Mário Nunes
rider peers are clearly prejudiced by the Tit-for-Tat strategy as without it they receive as much video as they can, but put in danger the availability of pieces in the network. With Tit-forTat the highest download rates are reached earlier after some initial reviews of peers than without the strategy.
ACKNOWLEDGMENT The research leading to these results has received funding from the European Union’s Seventh Framework Programme ([FP7/2007-2013] ) under grant agreement n◦ ICT-248474. The authors would like to thank all SARACEN [2] project partners for their support. The authors would also like to thank Jˆanio Monteiro for all his support and expertise in the Scalable Video area. R EFERENCES
(a) Download Rate
(b) Upload Rate Figure 12. CDF of the Average Download and Upload Rate with free riders
Figure 12(b) demonstrates that the average upload rate is maintained at a higher rate when the Tit-for-Tat strategy is applied, even with 15% of peers (free-riders) contributing with 0 Kbps, while without the policy the the network is significantly affected. V. C ONCLUSION AND F UTURE W ORK This paper describes the architecture and the evaluation of a Scalable Video Coding and Peer-to-Peer Player prototype, compatible with various terminal hardware setups, with adaptive video streaming capabilities for heterogeneous access networks, using a novel algorithm, the Prioritized Sliding Window, to maintain a stable QoS/QoE. The solution showed to be stable, achieving a robust real-time streaming service in P2P environments and discouraging free-riders. Future work, already under development, includes the integration of the whole peer and media player engines in the form of a Web Browser plug-in and with HTTP multi-source transport support. Other enhancements are also forecasted, to address some limitations (related to Quality Of Experience (QoE) deterioration) with the SVC decoder/encoder used, to replace the incentive policy with one based on a Give-To-Get [20] approach, and to support for full NAT traversal mechanisms with an adaptation from Mono.Nat [21].
[1] A. Parker, “Addressing the cost and performance challenges of digital media content delivery,” P2P MEDIA SUMMIT LA, DCIA Conference & Exposition, Oct. 2006, p2P Media Summit, Los Angeles. [Online]. Available: http://www.dcia.info/activities/p2pmsla2006/ [2] SARACEN Consortium, “SARACEN: Socially Aware, collaboRative, scAlable Coding mEdia distributioN project Home Page,” SARACEN Consortium, 2010. [Online]. Available: http://www.saracen-p2p.eu/ [3] B. Cohen, “BitTorrent Protocol Specification,” BitTorrent.org, BitTorrent Enhancement Proposals BEP 3, Feb. 2008. [Online]. Available: http://www.bittorrent.org/beps/bep 0003.html [4] S. Rimac-Drlje, O. Nemcic, and M. Vranjes, “Scalable Video Coding extension of the H.264/AVC standard,” in Proceedings of the 50th International Symposium, ELMAR 2008, vol. 1, Sep. 2008, pp. 9 –12. [5] J. Rieckh, “Scalable Video for Peer-to-Peer Streaming,” Master’s thesis, Technical University of Vienna, Summer 2008. [6] J. F. Monteiro, “Quality Assurance Solutions for Multipoint Scalable Video Distribution over Wireless IP Networks,” Ph.D. dissertation, Instituto Superior T´ecnico - Universidade T´ecnica de Lisboa, Dec. 2009. [7] “TVUnetworks: P2PTV Application,” 2010. [Online]. Available: http://www.tvunetworks.com/ [8] “PPLive: P2PTV Application,” 2010. [Online]. Available: http: //www.pptv.com/en/ [9] S. Xie, B. Li, G. Y. Keung, and X. Zhang, “Coolstreaming: Design, Theory, and Practice,” IEEE Transactions on Multimedia, vol. 9, no. 8, pp. 1661–1671, Dec. 2007. [10] J. A. Pouwelse, P. Garbacki, J. Wang, A. Bakker, J. Yang, A. Iosup, D. H. J. Epema, M. Reinders, M. R. V. Steen, and H. J. Sips, “Tribler: A social-based peer-to-peer system,” in Proceedings of the 5th International Workshop on Peer-to-Peer Systems (IPTPS06), 2006. [11] BitLet.org, “The BitTorrent Applet Home Page,” BitLet.org, 2010. [Online]. Available: http://www.bitlet.org/ [12] M. Mushtaq and T. Ahmed, “Smooth Video Delivery for SVC Based Media Streaming Over P2P Networks,” in Proceedings of the 5th IEEE Consumer Communications and Networking Conference, CCNC 2008, Jan. 2008, pp. 447 –451. [13] P. Baccichet, T. Schierl, T. Wiegand, and B. Girod, “Low-Delay Peer-toPeer Streaming Using Scalable Video Coding,” in Proceedings of Packet Video 2007, Nov. 2007, pp. 173–181. [14] “P2P-Next: Next generation Peer-to-Peer (P2P) content delivery platform,” 2010. [Online]. Available: http://www.p2p-next.org/ [15] “NextShare streaming service,” 2010. [Online]. Available: http: //www.livinglab.eu/ [16] A. Zambelli, “IIS Smooth Streaming Technical Overview,” Microsoft Corporation, March 2009. [17] J. Dejun and G. P. C. hung Chi, “EC2 Performance Analysis for Resource Provisioning of Service-Oriented Applications,” 2008. [18] “FFmpeg: Complete, cross-platform solution to record, convert and stream audio and video,” 2010. [Online]. Available: http://ffmpeg.org/ [19] Z. Liu, Y. Shen, K. W. Ross, S. S. Panwar, and Y. Wang, “LayerP2P: Using Layered Video Chunks in P2P Live Streaming,” IEEE Transactions on Multimedia, vol. 11, no. 7, pp. 1340 –1352, Nov. 2009. [20] J. J. D. Mol, J. A. Pouwelse, M. Meulpolder, D. H. J. Epema, and H. J. Sips, “Give-to-Get: Free-riding-resilient Video-on-Demand in P2P Systems,” in Proceedings of the 15th Multimedia Computing and Networking Conference, MCNC ’08, vol. 6818, Jan. 2008. [21] “Mono.Nat: A library which allows you to easily forward ports on any uPnP capable router,” 2010. [Online]. Available: http: //projects.qnetp.net/projects/show/mono-nat
