RAMZAN LAYOUT
2/3/11
7:13 PM
Page 2
FUTURE MEDIA INTERNET
Peer-to-Peer Streaming of Scalable Video in Future Internet Applications Naeem Ramzan, Queen Mary University of London Emanuele Quacchio, STMicroelectronics Toni Zgaljic and Stefano Asioli, Queen Mary University of London Luca Celetto, STMicroelectronics Ebroul Izquierdo, Queen Mary University of London Fabrizio Rovati, STMicroelectronics
ABSTRACT Scalable video delivery over peer-to-peer networks appears to be key for efficient streaming in emerging and future Internet applications. Contrasting the conventional server-client approach, here, video is delivered to a user in a fully distributed fashion. This is, for instance, beneficial in cases where a high demand for a particular video content is imposed, as different users can receive the same data from different peers. Furthermore, due to the heterogeneous nature of Internet connectivity, the content needs to be delivered to a user through networks with highly varying bandwidths. Moreover, content needs to be displayed on a variety of devices featuring different sizes, resolutions, and computational capabilities. If video is encoded in a scalable way, it can be adapted to any required spatio-temporal resolution and quality in the compressed domain, according to a peer bandwidth and user context requirements. This enables efficient low-complexity content adaptation and interoperability for improved peer-topeer streaming in future Internet applications. An efficient piece picking and peer selection policy enables high quality of service in such a streaming system.
INTRODUCTION Multimedia applications over Internet are becoming popular due to the widespread deployment of broadband access. In conventional streaming architectures the client-server model and the usage of content distribution networks (CDNs) along with IP multicast were the most desirable approaches for many years. The client/server architecture, however, severely limits the number of simultaneous users in video streaming. The reason is the bandwidth bottleneck at the server side, since usually many clients request the content from the server. A CDN overcomes the same bottleneck problem by introducing dedicated servers at geographically
2
0163-6804/11/$25.00 © 2011 IEEE
different locations, resulting in expensive deployment and maintenance. Compared to conventional approaches, a major advantage of peer-to-peer (P2P) streaming protocols is that each peer involved in content delivery contributes its own resources to the streaming session. Administration, maintenance, and responsibility for operations are therefore distributed among the users instead of handled by a single entity. As a consequence there is an increase in the amount of overall resources in the network, and the usual bottleneck problem of the client-server model can be overcome. Therefore, a P2P architecture extends exceptionally well with large user bases, and provides a scalable and cost-effective alternative to conventional media delivery services. The main advantage of P2P systems is their ability to self-organize, bandwidth scalability, and network path redundancy. These are indeed attractive features for effective delivery of media streams. Nevertheless, several problems are still open and need to be addressed in order to achieve high quality of service and user experience. In particular, the bandwidth capacity of a P2P system is extremely varying, as it relies on heterogeneous peer connection speeds, and directly depends on the number of connected peers. To cope with varying bandwidth capacities inherent to P2P systems, the underlying video coding/transmission technology needs to support bit-rate adaptation according to available bandwidth. Moreover, displaying devices at the user side may range from small handsets (e.g., mobile phones) to large HD displays (e.g., LCD televisions). Therefore, video streams need to be transmitted at a suitable spatio-temporal (ST) resolution supported by the user’s display device. If conventional video coding technologies are used, the above mentioned issues cannot be solved efficiently. Scalable video coding (SVC) techniques [1, 2] address these problems, as they allow “encoding a sequence once and decoding it in many different versions.” Thus, scalable coded bitstreams can efficiently adapt to the
IEEE Communications Magazine • March 2011
RAMZAN LAYOUT
2/3/11
7:13 PM
Page 3
application requirements. The adaptation is performed fully in the compressed domain, by directly removing parts of the bitstream. The SVC encoded bitstream can be truncated to lower resolution, frame rate, or quality. In P2P environments such real-time low-complexity adaptation results in a graceful degradation of received video quality, avoiding the interruption of the streaming service in case of congestion or bandwidth narrowing. Recently, P2P scalable video streaming has attracted significant attention from researchers. Liu et al. [3] employ layered video to accommodate asynchronous requests from users of heterogeneous bandwidths. Baccichet et al. [4] develop a mathematical framework to quantify the advantage of using a scalable codec for treebased overlays, particularly during network congestion. Ding et al. [5, 6] present a P2P video on demand (VoD) system that utilizes SVC for delay minimization and to deal with heterogeneous user capabilities as well as dynamic endto-end resource availability. The possibility to exploit the flexibility given by scalable bitstreams within P2P overlays has also been an important topic in large cooperative projects. Among others, P2P-Next [7] and SEA [8] aim to build the software infrastructure enabling high-quality and reliable P2P-based TV services over the Internet. In the following sections we explain the fundamentals of video streaming techniques used in some of these projects.
SCALABLE VIDEO CODING In general, a scalable video sequence can be adapted in three dimensions: temporal (frame rate reduction), spatial (resolution reduction), and quality (quality reduction), by simple parsing and dropping specific parts of the encoded representation. Thus, the complexity of adaptation is very low, in contrast to the adaptation complexity of non-scalable bitstreams. The SVC scheme gives flexibility and adaptability to video transmission over resource-constrained networks in such a way that, by adjusting one or more of the scalability parameters, it selects a layer containing an appropriate ST resolution and quality according to current network conditions. Figure 1 shows an example of video distribution through links supporting different transmission speeds and display devices. At each point where video quality/resolution needs to be adjusted, an adaptation is performed. Since the adaptation complexity is very low, the video can be efficiently streamed in such an environment. The latest video coding standard, H.264/ MPEG-4 AVC, provides a fully scalable extension, SVC 1 [1]. It reuses key features of H.264/AVC, and also uses some other techniques to provide scalability and improve coding efficiency. The scalable bitstream is organized into a base layer and one or several enhancement layers. SVC provides temporal, spatial, and quality scalability with a low increase of bit rate relative to the single-layer H.264/AVC. The SVC standard is based on a hybrid technology. In principle, it uses a combination of spatial transform based on discrete cosine transform and temporal differential pulse code modu-
IEEE Communications Magazine • March 2011
Scalable video encoder Cinema projector
Stored video Adaptation
Adaptation High definition TV
Adaptation
PC connected to office network Laptop connected to phone line
Personal digital Assistant
Figure 1. Streaming of scalable video.
lation. An alternative approach is to use wavelets for both temporal and spatial decorrelation. This approach is commonly referred to as waveletbased SVC (W-SVC). Several recent W-SVC systems [2] have shown exemplary performance in different types of application scenarios, especially when fine-grained scalability is required. Observe that fine-grained scalability is not supported by the current SVC standard.
STREAMING OF SCALABLE VIDEO OVER P2P NETWORKS P2P protocols have been widely deployed for sharing files over the Internet. One of the most commonly used P2P protocols is BitTorrent [9]. However, BitTorrent is not suitable for streaming applications since segments of the video file are generally not received in sequential order. Thus, substantial research has been conducted recently to extend the BitTorrent protocol and make it suitable for streaming. An example of such an extended protocol is Tribler [10]. A generic P2P streaming architecture using SVC is depicted in Fig. 2. At the sender side, the video is compressed by a scalable encoder. The compressed bitstream may optionally be further processed to make it more suitable for transmission or add additional data into the stream. The processing stage may consist of separating the scalable bitstream into files, each carrying an individual scalable layer, or multiplexing the audio and video streams. The corresponding bitstream description is created during either the encoding or processing phase. The description
1
In the remainder of this article, the acronym SVC is used interchangeably to denote both the standard and the concept of scalable video coding.
3
RAMZAN LAYOUT
2/3/11
7:13 PM
To ensure
Page 4
Input video sequence
continuous video
Audio
playback, chunks
P2P Network
Content producer side
close to the playback position need to be
User
received on time, at least for the base layer of scalable video. To ensure this,
SVC encoder
Scalable bit-stream
User Torrent file
neighboring peers need to be carefully
User
User User
Bit-stream description
selected.
Consumer side Adaptation SVC decoder
Chunk picking
Peer selection
Figure 2. P2P streaming of scalable video.
1
In the remainder of the article the acronym SVC will be used interchangeably to denote both the standard and the concept of scalable video coding itself.
4
may contain information about the organization of the video into scalable layers, the resolution and quality of each layer, and so on. Finally, the torrent file is produced, which, among other information, describes the mapping of the stored video into chunks. A chunk represents the smallest unit of data that will be transmitted over the P2P network. Sometimes, the term piece is used to denote a chunk. In this article both terms (chunk and piece) are used interchangeably. At the consumer side, the peer downloads the torrent file and requests the video. Here, conventional P2P protocols used for file sharing require modifications. In BitTorrent, file chunks are downloaded in rarest-first fashion. This is an efficient strategy in file sharing applications since the availability of rare chunks is eventually increased, and higher downloads rates can be achieved for these chunks. However, in video streaming this can result in an interruption of the video playback since chunks are not received sequentially. Therefore, special care needs to be given to those chunks that are close to the playback position. An example of an algorithm that takes into account these considerations is Giveto-Get (G2G) [11], implemented in Tribler [10]. In this algorithm chunks of compressed video are classified into three priority categories: high, medium, and low. This classification depends on the current playback position. Chunks close to the playback positions are marked as high-priority chunks; they are downloaded first and in sequential order. Medium- and low-priority chunks are downloaded according to the standard BitTorrent strategy: rarest-first. Given a scalable encoded video unit, a peer can initially decide to recover all or just a subset of available layers, depending on its capabilities. For instance, a mobile device can decide to
retrieve the base layer providing CIF (352 × 288) resolution, while a set-top box can retrieve the 4CIF (704 × 576) enhancement. Besides, in such a static selection, a peer can dynamically retrieve just a subset of layers in order to react to a temporary narrowing of the bandwidth. Such dynamic adaptation can be achieved through a carefully designed piece-picking policy. For this purpose the G2G algorithm can be modified to take into account not only the playback position, but also different layers in the scalable bitstream. To ensure continuous video playback, chunks close to the playback position need to be received on time, at least for the base layer of scalable video. To ensure this, neighboring peers need to be carefully selected. Ideally, these peers should be able to deliver video pieces before they are requested by the video player. In the following subsections we explain three recent state-of-the-art P2P scalable video streaming systems based on the principles described above.
THE MMV PLATFORM The system proposed in [12] is based on Tribler. The main modifications are in the G2G algorithm and peer selection policy. The video sequence is compressed by the W-SVC encoder [2]. The compressed sequence consists of groups of pictures (GOPs) and scalable layers. The number of frames within a GOP and the number of layers are set during encoding and are constant throughout the sequence. Along with the bitstream, the description file is generated, which contains information on mapping of GOPs and layers into chunks and vice versa. The description file is transmitted with the video sequence. It has the highest priority and therefore should be downloaded before the bitstream.
IEEE Communications Magazine • March 2011
RAMZAN LAYOUT
2/3/11
7:13 PM
GOP 1
GOP 2
GOP 3
GOP 4
GOP 5
Video quality
GOP 0
Page 5
The size of a chunk Enhancement layers Base layer
has been set to 32 Kbytes; however, other sizes are
Sliding window
supported as well.
Playback position
If the size of a GOP GOP 1
GOP 2
GOP 3
GOP 4
GOP 5
Video quality
GOP 0
in MMV platform
in bytes is not an Enhancement layers Base layer
integer multiple of the chunk size, padding bytes are added at the end of
Playback position GOP 0
the GOP. In this way GOP 1
GOP 2
GOP 3
GOP 4
each GOP consists of
GOP 5
Video quality
chunks that are Enhancement layers
independent from
Base layer
other GOPs.
Playback position GOP 1
GOP 2
GOP 3
Video quality
GOP 0
GOP 4
GOP 5 Enhancement layers Base layer
Playback position Time
Figure 3. Sliding window operations. First row: prebuffering phase start; second row: prebuffering phase end; third row: the window shifts the first time; fourth row: the window shifts the second time.
The size of a chunk in the MMV platform has been set to 32 kbytes; however, other sizes are supported as well. If the size of a GOP in bytes is not an integer multiple of the chunk size, padding bytes are added at the end of the GOP. In this way each GOP consists of chunks that are independent from other GOPs. Piece Picking Strategy — At the beginning of the streaming session, information about GOPs and layers is extracted from the bitstream description file. At this point, a sliding window is defined, made of several GOPs (typically three to four), and the prebuffering phase starts. Chunks are picked only from those inside the window unless all of them have already been downloaded. In the latter case, the piece picking policy will be rarest-first. Inside the window, chunks have different priorities, following the idea from the original G2G algorithm. First, a peer will try to download the base layer (BL), then the first enhancement layer (EL1), and so on. Pieces from the BL are downloaded in sequential order, while all other pieces are
IEEE Communications Magazine • March 2011
downloaded rarest-first (within the same layer). The window shifts every t GOP s, where t GOP represents GOP duration in seconds. An exception is given in the first shift, which is performed after prebuffering. The duration of the prebuffering stage corresponds to the length of the sliding window in seconds. Every time the window shifts, two operations are made. First, downloaded pieces are checked to evaluate which layers have been completely downloaded. Second, pending requests concerning pieces of the GOP located just before the window are dropped. Fully downloaded layers from that GOP are sent to a video player for playback. Note that the window shifts only if at least the BL has been received; otherwise, the system auto-pauses. Figure 3 shows the behavior of the system with a window three GOPs wide. An early stage of the prebuffering phase is shown in Fig. 3, first row. The peer is downloading pieces from BL in a sequential way. In Fig. 3, second row, the first two layers have been downloaded, and chunks are being picked from EL2 according to the rarest-first policy. These pieces
5
RAMZAN LAYOUT
2/3/11
7:13 PM
Page 6
1400
Video download rate Received video bit rate
Download rate (kb/s)
1200
THE NEXTSHARE PLATFORM
1000
800
600
400
200
0 0
40
80
120
160
200
240
280
320
Time (s)
Figure 4. Received download rate and received video bit-rate for Crew CIF sequence. can belong to any GOP within the window. In Fig. 3, third row, the window has shifted, although not all pieces from EL2 in GOP 0 have been received. This layer is discarded from GOP 0. Inside the window, before downloading any other pieces from GOP 1 or 2, the system will pick chunks from GOP 3 until the quality of received layers is the same. In other words, before picking any chunks belonging to EL2, chunks belonging to the BL of GOP 3 and EL1 of GOP 3 will be picked. In Fig. 3, fourth row, all GOPs within the window have the same number of completed layers, and pieces are picked from EL3. Peer Selection Strategy — Occasionally, slow peers in the swarm may delay the receiving of a BitTorrent piece even if the download bandwidth is high. This problem is critical if the requested piece belongs to the BL, as it might force the playback to pause. Therefore, these pieces should be requested from good neighbors. Good neighbors are those peers that own the piece with the highest download rates, which alone could provide the current peer with a transfer rate that is above a certain threshold. Each time the window shifts, download rates of all the neighbors are evaluated, and the peers are sorted in descending order. The pieces are then requested from peers providing download rates above a certain threshold. The performance of this framework is shown in Fig. 4. Here, the download rate is not high enough to allow the transfer of all layers. Moreover, the download rate is not constant; therefore, the received video bit rate needs to match the behavior of the download speed. It can be seen that the video is received at a higher bit rate immediately after the prebuffering phase and at the end of the sequence. The higher quality after the prebuffering phase results from the fact that the first couple of GOPs are in the window for a slightly longer period than other
6
GOPs. At the end of the sequence, when the window cannot be shifted anymore, the window is shrinking. Therefore, more enhancement layers can be downloaded for GOPs at the end of the sequence. Based on the Tribler P2P protocol, the NextShare platform has been designed and is being implemented in the framework of the P2PNext project [7]. The NextShare platform supports delivery over the P2P overlay of compressed video contents conforming to the specifications of the SVC standard [1]. At the sender side, first, the SVC bitstream is divided into several files, each carrying a single scalable layer. Only the BL is encapsulated with audio in MPEG-TS transport format. Within the torrent file layers are indexed as independent files, leaving the user free to select the one to be downloaded. Additional metadata is included in the torrent to provide a description of the scalable bitstream in terms of resolutions and bit rates supported. SVC layers are downloaded in the form of data segments from different files and composed by the NextShare P2P engine at the consumer side. Once a target resolution is composed, the corresponding data is forwarded to a media player. Adaptation Strategy — In NextShare the maximum target layer is selected and provided to the piece picking algorithm by matching context information and available scalable resolutions extracted from the torrent. To react to a temporary narrowing of the bandwidth, the adaptation decision is made periodically by checking the status of the input buffer, playback position, and pieces availability. Adaptation actions occur in correspondence to a synchronization point; for a compressed SVC bitstream this corresponds to an instantaneous decoding refresh (IDR) frame. IDR represents a special intra picture, which cuts off all inter-picture dependencies from previously decoded frames. The stream is therefore divided in units of constant temporal duration called time slots; each time slot corresponds to a period of frames between two consecutive IDRs. The size of a NextShare chunk has been set to 56,400 bytes in order to have multiple MPEGTS packets in each chunk, while preserving a reasonable chunk size for efficient transmission. Here, the size of each MPEG TS packet is 188 bytes. Each scalable layer is encoded at a constant bit rate (CBR), and hence is represented by a constant amount of bits in each time slot. Since CBR is used, it is possible to predict the number of chunks in a time slot of each layer. For example, for an SVC layer encoded at 512 kb/s and 25 frames/s, there will be a time slot of 64 frames (2.56 s), and the size of the corresponding block of frames will be approximately 164 kbytes, which corresponds approximately to three NextShare chunks. A bit overhead is considered in piece mapping for each scalable layer, in order to compensate for the drift from the target bit rate always present in CBR algorithms. Piece Picking Strategy — The procedure
IEEE Communications Magazine • March 2011
RAMZAN LAYOUT
2/3/11
7:13 PM
Page 7
Time slot
The size of
Video quality
NextShare chunk has EL2
High priority H2
been set to 56400
Low priority L2
bytes in order to have a multiple
Quality switch
number of MPEG-TS EL1
High priority H1
Low priority L1
packets in each chunk, while preserv-
Quality switch
ing a reasonable size BL
High priority H0
Low priority L0
of a chunk for efficient transmis-
t
t+x
sion. Here, the size Time
Playback position
of each MPEG TS packet is 188 bytes.
Figure 5. Layered priorities in NextShare.
implemented in NextShare to download scalable data chunks is an extension of the G2G algorithm. Priorities are defined as in G2G and extended to the multiple files, as depicted in Fig. 5. In the high-priority set pieces are downloaded sequentially, while in the low-priority set pieces are downloaded in a rarest-first fashion. Each block in the figure represents a time slot. In Fig. 5 at time instance t (playback position), the algorithm has to decide which block to download for time point (t + x). Here, the algorithm might decide to start downloading pieces inside EL1 at time t + 1 in order to improve the quality for the near future or may decide to continue downloading blocks for BL to ensure that the playback will not stop even if network conditions become worse. Periodically the algorithm makes such a decision depending on the current status of the download, pieces lost, and playback position. The controller implemented in NextShare tries to switch to a higher quality as soon as there is enough saved buffer for the current quality. Therefore, a safe buffer of chunks downloaded and not yet delivered to the player is defined; the size of this buffer is a function of the parameter x depicted in Fig. 5. The minimal value for x corresponds to five time slots, and can vary depending on network performance. When enough segments for the BL have been downloaded, the quality is increased, and the download of the next layer is selected. In this case the high-priority set is redefined, and high priorities are assigned to blocks belonging to the upper layers (the sequence of high priorities will follow layer dependencies H0 → H1 → H2). In order to guarantee a safe time alignment, for each increase in quality the initial time slots to download are ahead in time with respect to previous layers. An offset of one time slot is added at the beginning of each enhancement layer as depicted in Fig. 5. When not enough pieces are available for a certain resolution, the controller switches back to a safer position by interrupting the download of the correspondent file and reassigning priorities to lower layers.
IEEE Communications Magazine • March 2011
Peer Selection Strategy — The peer selection strategy is inherited from the approach implemented in Tribler. For each layer, pieces with an early deadline are downloaded from good (i.e., fast) peers. Badly behaving peers (i.e., peers that missed a given deadline for a particular piece) are moved from the high-priority set to a lowpriority one starting from the BL. A bad performance counter is incremented each time a piece download fails. As a consequence, peers with a positive bad performance counter are only allowed to pick low-priority pieces.
SEACAST PLATFORM In the framework of the SEA project [8], a different P2P architecture to support scalable video streaming has been implemented. While the NextShare and MMV platforms were both based on full mesh P2P topology, in SEA the scalable content is delivered over a multitree overlay. P2P platforms developed in SEA are based on the VidTorrent protocol [13], which creates an overlay forest of independent trees, each one carrying a different part of the stream. A central entity (tracker/broker) is used for creating and managing the overlay. Nodes of a tree structure have well defined parent-child relationships. Such an approach is typically push-based, that is, when a node receives a data packet, it also forwards copies of the packet to each of its children. If peers do not change too often, tree-based systems require little overhead, since packets are forwarded from node to node without the need for extra messages. However, with respect to mesh topologies in high churn environments, the tree must be continuously destroyed and rebuilt, which requires considerable control message overhead. Furthermore, nodes must buffer data for at least the time required to repair the tree in order to avoid packet loss. In the SEA project two different platforms have been developed. The first platform (SEABone) targets code optimization focusing on cross-platform development for set-top boxes. The second platform (SEACast) aims at adding
7
RAMZAN LAYOUT
2/3/11
7:13 PM
Page 8
By parsing the SDP
SDP (Session and scalability information) Data packets BL Data packets EL
the peer knows available resolutions and dependencies among the layers for the selected video. By matching this
Video producer and publisher
SEAcast root node
Broker
information with local capabilities and local bandwidth,
SEAcast leaf node
it selects a target
SEAcast leaf node
resolution. Low-end smartphones SEAcast leaf node
SEAcast leaf node
SEAcast leaf node
High-end STB and laptop
Figure 6. SEAcast architecture. support for layered and multiple-descriptive coding schemes [14]. SVC Support in SEACast — The structure of the P2P tree generated with the SEACast application is depicted in Fig. 6. The content is injected in the tree overlay by a root node that informs the broker about the published content. In case of layered video, the root node also generates a file containing information about the content structure, in terms of supported resolutions and dependencies among the layers. Such information is formatted in a socalled Session Description Protocol (SDP) message [15]. The original VidTorrent protocol was modified to deliver layered contents over multitree overlays. That is, for an SVC video, each layer is delivered over a different tree. The granularity introduced by splitting the content into multiple layers allows peers with limited upload bandwidth to contribute to the swarm by uploading data relative to a reduced version of the scalable bitstream. Intrinsic robustness to node failures is added, as the loss of connections carrying an enhancement layer will cause temporary degradation of the overall quality. Clearly, in case of failure or congestion of a connection carrying the BL, there is no possibility to easily recover the quality even if enhancement layers are received. In such a situation, the performance may be improved by assigning priorities to each different tree according to the importance of the SVC layer carried, and injecting and forwarding the BL over the most reliable path. Data Transport in SEACast — In SEACast
8
data packets are simply forwarded from parent to children nodes. As shown in Fig. 6, the publisher is connected to the SEACast root node by means of a different Real-Time Transport Protocol (RTP) connection for each scalable layer. RTP connections act also as interfaces between client nodes and the media player. SVC data are encapsulated by the publisher in RTP payload according to [15]. In the SEACast root node, RTP packets are directly pushed over a different tree according to the correspondent layer. Each SEACast client keeps a buffer of a few seconds for each tree in which it participates; RTP packets are extracted from the client buffer and again delivered to the media player over different sessions. The SVC stream is finally reconstructed inside the media player by aggregating the sub-bitstream, and synchronization among sessions is kept by using timestamp information contained in packet headers. Peer Selection and Adaptation Strategy in SEACast — When a peer wants to join the swarm, it first contacts the broker to receive the list of neighboring nodes that already have the video. The SDP message is also transmitted by the broker. By parsing the SDP, the peer knows available resolutions and dependencies among the layers for the selected video. By matching this information with local capabilities and local bandwidth, it selects a target resolution. According to the layers hierarchy, the peer pings its potential parent nodes, starting from the BL and repeating the operation for ELs. Each SVC layer is therefore retrieved from a different node. A local probe technique is used to select the best parent. In particular, a combination of round-
IEEE Communications Magazine • March 2011
RAMZAN LAYOUT
2/3/11
7:13 PM
Page 9
trip time, available bandwidth, and the number of already active connections is used. Once the parent node is selected for each layer, connections are established. Periodically, available bandwidth is checked, and in case of congestion or connection failure, the peer contacts the broker again to rebuild the tree.
CONCLUSIONS In P2P networks video is streamed to the user in a fully distributed fashion. Network resources are distributed among users instead of handled by a single entity. However, due to the diversity of users’ displaying devices and available bandwidth levels in the Internet, the underlying coding and transmission technology needs to be highly flexible. Such flexibility can easily be achieved by SVC, where bitstreams can be adapted in the compressed domain according to available bandwidth or user preferences. When using SVC in P2P streaming, special care needs to be given to handling different bitstream layers according to the current playback position. Since it is highly important that pieces close to playback position arrive on time, these need to be downloaded from good behaving peers. In this article we have presented several advanced P2P systems supporting streaming of scalable video and designed to support future Internet applications. Considering the flexibility given by scalable bitstreams within P2P overlays, it is clear that P2P streaming systems supporting SVC technology will play an important role in the Internet of the future.
ACKNOWLEDGMENT The authors wish to thank Simone Zezza from the Department of Electronics, Politecnico di Torino, for his help with revising this manuscript. This research has been partially funded by the European Commission under contract FP7247688 3DLife, FP7-248474 SARACEN, and FP7-248036 COAST.
REFERENCES [1] H. Schwarz, D. Marpe, and T. Wiegand, “Overview of the Scalable Video Coding Extension of the H.264/AVC Standard,” IEEE Trans. Circuits Sys. Video Tech., vol. 17, no. 9, Sept. 2007, pp. 1103–20. [2] M. Mrak et al., “Performance Evidence of Software Proposal for Wavelet Video Coding Exploration Group,” Tech. Rep., ISO/IEC JTC1/SC29/WG11/MPEG2006/ M13146, 2006. [3] Z. Liu, Y. Shen, and K. Ross, “LayerP2P: Using Layered Video Chunks in P2P Live Streaming,” IEEE Trans. Multimedia, vol. 11, no. 7, 2009. [4] P. Baccichet et al., “Low-Delay Peer-to-Peer Streaming Using Scalable Video Coding,” Proc. Packet Video ‘07, 2007, Lausanne, Switzerland, pp. 173–81. [5] Y. Ding et al., “Peer-to-Peer Video-on-Demand with Scalable Video Coding,” Comp. Commun., 2010. [6] PetaMedia Project; http://www.petamedia.eu. [7] P2PNext Project; http://www.p2pnext.org. [8] SEA Project; http://www.ist-sea.eu. [9] B. Cohen, “Incentives Build Robustness in BitTorrent,” Proc. 1st Wksp. Economics Peer-to-Peer Sys., 2003. [10] J. A. Pouwelse et al., “Tribler: A Social-Based Peer-toPeer System,” 5th Int’l. Wksp. Peer-to-Peer Sys., Feb. 2006; http://citeseerx.ist.psu.edu/viewdoc/summary? doi=10.1.1.60.8696. [11] J. J. D. Mol et al., “Give-to-Get: Free-Riding-Resilient Video-on-Demand in P2P Systems,” Proc. SPIE Multimedia Comp. Net., vol. 6818, San Jose, CA. [12] S. Asioli, N. Ramzan, and E. Izquierdo, “A Novel Tech-
IEEE Communications Magazine • March 2011
nique for Efficient Peer-To-Peer Scalable Video Transmission,” Proc. Euro. Sig. Process. Conf., Aalborg, Denmark, Aug. 23–27, 2010. [13] VidTorrent Protocol; http://web.media.mit.edu/~vyzo/ vidtorrent/index.html. [14] S. Zezza et al., “SEACAST: A Protocol for P2P Video Streaming Supporting Multiple Description Coding,” Proc. IEEE Int’l. Conf. Multimedia Expo, New York, NY, 2009. [15] T. Schierl and S. Wenger, “Signaling Media Decoding Dependency in the Session Description Protocol (SDP),” IETF RFC 5583, July 2009; http://tools.ietf.org/html/rfc5583.
BIOGRAPHIES NAEEM RAMZAN (
[email protected]) is a postdoctoral researcher at the Multimedia and Vision Group, Queen Mary University of London. His research activities focus around multimedia search and retrieval, image and video coding, scalable video coding, surveillance-centric coding, multimedia transmission over wireless, and P2P networks. Currently, he is a senior researcher and core member of the technical coordination team in the EU funded projects PetaMedia and SARACEN. He is the author or co-author of more than 40 research publications.
Considering the flexibility given by scalable bitstreams within P2P overlays, it is clear that P2P streaming systems supporting SVC technology will play an important role in the Internet of the future.
EMANUELE QUACCHIO (
[email protected]) received an M.S. degree in electronic engineering from the Polytechnic University of Turin, Italy, in 2003. He worked two years as a researcher in the Department of Electronics of the same university and joined STMicroelectronics in 2006. His activities are focused on embedded software development for STB/mobile platforms and multimedia communication. He has published several papers in the principal journals of engineering and conferences. Since 2006 he has participated in a number of EU funded projects. TONI ZGALJIC (
[email protected]) received a Ph.D. degree from Queen Mary University of London in 2008. He is currently a research assistant in the Multimedia and Vision Group in the School of Electronic Engineering and Computer Science at the same university. His research interests include scalable video coding and transmission, universal multimedia access, surveillance-centric coding, and video transcoding. He has published more than 20 technical papers in these areas, including chapters in books. STEFANO ASIOLI (
[email protected]) received an M.Sc. degree in telecommunications engineering from the Department of Information Engineering and Computer Science (DISI), University of Trento, Italy, in 2009. He is currently pursuing a Ph.D. degree in electronic engineering at the Multimedia & Vision Group, Queen Mary University of London. His research interests include peer-to-peer networks and scalable video coding. L UCA C ELETTO (
[email protected]) received a Master’s degree in electronic engineering from the University of Padova, Italy, in 1998. He joined STMicroelectronics in 1999, where he contributed to research projects in video compression and streaming. He has published and co-authored several papers in the principal journals of engineering and conferences, and has been granted several patents on video technologies. As an MPEG committee member, he participated in the standardization of the H.264 specifications. He has collaborated on EU-funded projects. E BROUL I ZQUIERDO (
[email protected]) is Chair of Multimedia and Computer Vision and head of the Multimedia and Vision Group in the School of Electronic Engineering and Computer Science at Queen Mary University of London. He received a Ph.D. from Humboldt University, Berlin, Germany. He has been a senior researcher at the Heinrich-Hertz Institute for Communication Technology, Berlin, and the Department of Electronic Systems Engineering of the University of Essex. He holds several patents in multimedia signal processing and has published over 400 technical papers, including chapters in books. FABRIZIO SIMONE ROVATI (
[email protected]) received his electronic engineering degree from Politecnico of Milano in 1996. In 1995 he joined STMicroelectronics in the AST System R&D group working on digital video processing algorithms and architectures. He currently leads the corporate R&D group in the field of networked multimedia. During his career he has authored or co-authored 15 British, European, and U.S. granted patents, and 10 publications in conferences or technical journals.
9
