Peer-to-peer streaming of scalable video in future Internet applications

IEEE Communications Magazine • March 2011128 0163-6804/11/$25.00 © 2011 IEEE

INTRODUCTION

Multimedia applications over the Internet arebecoming popular due to the widespread deploy-ment of broadband access. In conventionalstreaming architectures the client-server modeland the usage of content distribution networks(CDNs) along with IP multicast were the mostdesirable approaches for many years. Theclient/server architecture, however, severely lim-its the number of simultaneous users in videostreaming. The reason is the bandwidth bottle-neck at the server side, since usually many clientsrequest the content from the server. A CDNovercomes the same bottleneck problem byintroducing dedicated servers at geographically

different locations, resulting in expensive deploy-ment and maintenance.

Compared to conventional approaches, amajor advantage of peer-to-peer (P2P) stream-ing protocols is that each peer involved in con-tent delivery contributes its own resources to thestreaming session. Administration, maintenance,and responsibility for operations are thereforedistributed among the users instead of handledby a single entity. As a consequence there is anincrease in the amount of overall resources inthe network, and the usual bottleneck problemof the client-server model can be overcome.Therefore, a P2P architecture extends exception-ally well with large user bases, and provides ascalable and cost-effective alternative to conven-tional media delivery services. The main advan-tage of P2P systems is bandwidth scalability,network path redundancy, and the ability to self-organize. These are indeed attractive featuresfor effective delivery of media streams. Never-theless, several problems are still open and needto be addressed in order to achieve high qualityof service and user experience. In particular, thebandwidth capacity of a P2P system is extremelyvarying, as it relies on heterogeneous peer con-nection speeds, and directly depends on thenumber of connected peers.

To cope with varying bandwidth capacitiesinherent to P2P systems, the underlying videocoding/transmission technology needs to supportbit-rate adaptation according to available band-width. Moreover, displaying devices at the userside may range from small handsets (e.g., mobilephones) to large HD displays (e.g., LCD televi-sions). Therefore, video streams need to betransmitted at a suitable spatio-temporal (ST)resolution supported by the user’s display device.If conventional video coding technologies areused, the above mentioned issues cannot besolved efficiently. Scalable video coding (SVC)techniques [1, 2] address these problems, as theyallow “encoding a sequence once and decodingit in many different versions.” Thus, scalablecoded bitstreams can efficiently adapt to the

ABSTRACT

Scalable video delivery over peer-to-peer net-works appears to be key for efficient streamingin emerging and future Internet applications.Contrasting the conventional server-clientapproach, here, video is delivered to a user in afully distributed fashion. This is, for instance,beneficial in cases where a high demand for aparticular video content is imposed, as differentusers can receive the same data from differentpeers. Furthermore, due to the heterogeneousnature of Internet connectivity, the contentneeds to be delivered to a user through networkswith highly varying bandwidths. Moreover, con-tent needs to be displayed on a variety of devicesfeaturing different sizes, resolutions, and compu-tational capabilities. If video is encoded in ascalable way, it can be adapted to any requiredspatio-temporal resolution and quality in thecompressed domain, according to a peer band-width and other peers’ context requirements.This enables efficient low-complexity contentadaptation and interoperability for improvedpeer-to-peer streaming in future Internet appli-cations. An efficient piece picking and peerselection policy enables high quality of service insuch a streaming system.

FUTURE MEDIA INTERNET

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

Peer-to-Peer Streaming of ScalableVideo in Future Internet Applications

RAMZAN LAYOUT 2/18/11 3:11 PM Page 128

IEEE Communications Magazine • March 2011 129

application requirements. The adaptation is per-formed fully in the compressed domain, bydirectly removing parts of the bitstream. TheSVC encoded bitstream can be truncated tolower resolution, frame rate, or quality. In P2Penvironments such real-time low-complexityadaptation results in a graceful degradation ofreceived video quality, avoiding the interruptionof the streaming service in case of congestion orbandwidth narrowing.

Recently, P2P scalable video streaming hasattracted significant attention from researchers.Liu et al. [3] employ layered video to accommo-date asynchronous requests from users of het-erogeneous bandwidths. Baccichet et al. [4]develop a mathematical framework to quantifythe advantage of using a scalable codec for tree-based overlays, particularly during network con-gestion. Ding et al. [5] and the MMV platform[6] present a P2P video on demand (VoD) sys-tem that utilizes SVC for delay minimization andto deal with heterogeneous user capabilities aswell as dynamic end-to-end resource availability.The possibility to exploit the flexibility given byscalable bitstreams within P2P overlays has alsobeen an important topic in large cooperativeprojects. Among others, P2P-Next [7] and SEA[8] aim to build the software infrastructureenabling high-quality and reliable P2P-based TVservices over the Internet. In the following sec-tions we explain the fundamentals of videostreaming techniques used in some of these pro-jects.

SCALABLE VIDEO CODINGIn general, a scalable video sequence can beadapted in three dimensions: temporal (framerate reduction), spatial (resolution reduction),and quality (quality reduction), by simple parsingand dropping specific parts of the encoded rep-resentation. Thus, the complexity of adaptationis very low, in contrast to the adaptation com-plexity of non-scalable bitstreams. The SVCscheme gives flexibility and adaptability to videotransmission over resource-constrained networksin such a way that, by adjusting one or more ofthe scalability parameters, it selects a layer con-taining an appropriate ST resolution and qualityaccording to current network conditions. Figure1 shows an example of video distribution throughlinks supporting different transmission speedsand display devices. At each point where videoquality/resolution needs to be adjusted, an adap-tation is performed. Since the adaptation com-plexity is very low, the video can be efficientlystreamed in such an environment.

The latest video coding standard, H.264/MPEG-4 AVC, provides a fully scalable exten-sion, SVC1 [1]. It reuses key features ofH.264/MPEG-4AVC, and also uses some othertechniques to provide scalability and improvecoding efficiency. The scalable bitstream is orga-nized into a base layer and one or severalenhancement layers. SVC provides temporal,spatial, and quality scalability with a low increaseof bit rate relative to the single-layer H.264/MPEG-4 AVC.

The SVC standard is based on a hybrid tech-nology. In principle, it uses a combination of

spatial transform based on discrete cosine trans-form and temporal differential pulse code modu-lation. An alternative approach is to use waveletsfor both temporal and spatial decorrelation. Thisapproach is commonly referred to as wavelet-based SVC (W-SVC). Several recent W-SVCsystems [2] have shown exemplary performancein different types of application scenarios, espe-cially when fine-grained scalability is required.Observe that fine-grained scalability is not sup-ported by the current SVC standard.

STREAMING OF SCALABLE VIDEOOVER P2P NETWORKS

P2P protocols have been widely deployed forsharing files over the Internet. One of the mostcommonly used P2P protocols is BitTorrent [9].However, BitTorrent is not suitable for stream-ing applications since segments of the video fileare generally not received in sequential order.Thus, substantial research has been conductedrecently to extend the BitTorrent protocol andmake it suitable for streaming. An example ofsuch an extended protocol is Tribler [10].

A generic P2P streaming architecture usingSVC is depicted in Fig. 2. At the sender side, thevideo is compressed by a scalable encoder. Thecompressed bitstream may optionally be furtherprocessed to make it more suitable for transmis-sion or add additional data into the stream. Theprocessing stage may consist of separating thescalable bitstream into files, each carrying anindividual scalable layer, or multiplexing theaudio and video streams. The corresponding bit-

Figure 1. Streaming of scalable video.

Cinemaprojector Stored

video

Adaptation

PC connected tooffice network

Laptopconnected to

phone lineMobile phone

High definitionTV

Scalable videoencoder

Adaptation

Adaptation

1 In the remainder of thisarticle, the acronym SVCis used interchangeably todenote both the standardand the concept of scal-able video coding.


IEEE Communications Magazine • March 2011130

stream description is created during either theencoding or processing phase. The descriptionmay contain information about the organizationof the video into scalable layers, the resolutionand quality of each layer, and so on. Finally, thetorrent file is produced, which, among otherinformation, describes the mapping of the storedvideo into chunks. A chunk represents the small-est unit of data that will be transmitted over theP2P network. Sometimes, the term piece is usedto denote a chunk. In this article both terms(chunk and piece) are used interchangeably.

At the consumer side, the peer downloadsthe torrent file and requests the video. Here,conventional P2P protocols used for file sharingrequire modifications. In BitTorrent, file chunksare downloaded in rarest-first fashion. This is anefficient strategy in file sharing applicationssince the availability of rare chunks is eventuallyincreased, and higher downloads rates can beachieved for these chunks. However, in videostreaming this can result in an interruption ofthe video playback since chunks are not receivedsequentially. Therefore, special care needs to begiven to those chunks that are close to the play-back position. An example of an algorithm thattakes into account these considerations is Give-to-Get (G2G) [11], implemented in Tribler [10].In this algorithm chunks of compressed videoare classified into three priority categories: high,medium, and low. This classification depends onthe current playback position. Chunks close tothe playback positions are marked as high-priori-ty chunks; they are downloaded first and insequential order. Medium- and low-prioritychunks are downloaded according to the stan-dard BitTorrent strategy: rarest-first.

Given a scalable encoded video unit, a peercan initially decide to recover all or just a subset

of available layers, depending on its capabilities.For instance, a mobile device can decide toretrieve the base layer providing CIF (352 × 288)resolution, while a set-top box may additionallyretrieve the 4CIF (704 × 576) enhancementlayer. Besides, in such a static selection, a peercan dynamically retrieve just a subset of layers inorder to react to a temporary narrowing of thebandwidth. Such dynamic adaptation can beachieved through a carefully designed piece-picking policy. For this purpose the G2G algo-rithm can be modified to take into account notonly the playback position, but also different lay-ers in the scalable bitstream.

To ensure continuous video playback, chunksclose to the playback position need to bereceived on time, at least for the base layer ofscalable video. Therefore, neighboring peersneed to be carefully selected. Ideally, these peersshould be able to deliver video pieces beforethey are requested by the video player.

In the following subsections we explain threerecent state-of-the-art P2P scalable video stream-ing systems based on the principles describedabove.

THE MMV PLATFORMThe system proposed in [12] is based on Tribler.The main modifications are in the G2G algo-rithm and peer selection policy. The videosequence is compressed by the W-SVC encoder[2]. The compressed sequence consists of groupsof pictures (GOPs) and scalable layers. Thenumber of frames within a GOP and the numberof layers are set during encoding and are con-stant throughout the sequence. Along with thebitstream, the description file is generated,which contains information on mapping of GOPsand layers into chunks and vice versa. The

Figure 2. P2P streaming of scalable video.

Input video sequence

Content producer side

Scalable bit-stream

SVC encoder

SVC decoder

Audio

User

User

User

User

User

Torrent file

Bit-stream description

Adaptation Peer

selection Chunk picking

Consumer side

P2P Network

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.



description file is transmitted with the videosequence. It has the highest priority and there-fore should be downloaded before the bitstream.

The size of a chunk in the MMV platformhas been set to 32 kbytes; however, other sizesare supported as well. If the size of a GOP inbytes is not an integer multiple of the chunksize, padding bytes are added at the end of theGOP. In this way each GOP consists of chunksthat are independent from other GOPs.

Piece Picking Strategy — At the beginning ofthe streaming session, information about GOPsand layers is extracted from the bitstreamdescription file. At this point, a sliding window isdefined, made of several GOPs (typically threeto four), and the prebuffering phase starts.Chunks are picked only from those inside thewindow unless all of them have already beendownloaded. In the latter case, the piece pickingpolicy will be rarest-first. Inside the window,chunks have different priorities, following theidea from the original G2G algorithm. First, apeer will try to download the base layer (BL),

then the first enhancement layer (EL1), and soon. Pieces from the BL are downloaded insequential order, while all other pieces aredownloaded rarest-first (within the same layer).

The window shifts every tGOP s, where tGOPrepresents GOP duration in seconds. An excep-tion is given in the first shift, which is performedafter prebuffering. The duration of the pre-buffering stage corresponds to the length of thesliding window in seconds.

Every time the window shifts, two operationsare made. First, downloaded pieces are checkedto evaluate which layers have been completelydownloaded. Second, pending requests concern-ing pieces of the GOP located just before thewindow are dropped. Fully downloaded layersfrom that GOP are sent to a video player forplayback. Note that the window shifts only if atleast the BL has been received; otherwise, thesystem auto-pauses. Figure 3 shows the behaviorof the system with a window three GOPs wide.An early stage of the prebuffering phase is shownin Fig. 3, first row. The peer is downloadingpieces from BL in a sequential way. In Fig. 3,

Figure 3. Sliding window operations. First row: prebuffering phase starts; second row: prebuffering phaseends; third row: the window shifts the first time; fourth row: the window shifts the second time.

Enhancement layers

Vid

eo

qual

ity

GOP 0

Playback position

GOP 1

Sliding window

GOP 2 GOP 3 GOP 4 GOP 5

Base layer

Enhancement layers

Vid

eo

qual

ity

GOP 0

Playback position

GOP 1 GOP 2 GOP 3 GOP 4 GOP 5

Base layer

Enhancement layers

Vid

eo

qual

ity

GOP 0

Playback position


Base layer

Enhancement layers

Vid

eo

qual

ity

GOP 0

Playback position

Time


Base layer

The size of a chunk

in 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.



second row, the first two layers have been down-loaded, and chunks are being picked from EL2according to the rarest-first policy. These piecescan belong to any GOP within the window. InFig. 3, third row, the window has shifted,although not all pieces from EL2 in GOP 0 havebeen received. This layer is discarded from GOP0. Inside the window, before downloading anyother pieces from GOP 1 or 2, the system willpick chunks from GOP 3 until the quality ofreceived layers is the same. In other words,before picking any chunks belonging to EL2,chunks belonging to the BL of GOP 3 and EL1of GOP 3 will be picked. In Fig. 3, fourth row,all GOPs within the window have the same num-ber of completed layers, and pieces are pickedfrom EL3.

Peer Selection Strategy — Occasionally, slowpeers in the swarm may delay the receiving of aBitTorrent piece even if the download band-width is high. This problem is critical if therequested piece belongs to the BL, as it mightforce the playback to pause. Therefore, thesepieces should be requested from good neighbors.Good neighbors are those peers that own thepiece with the highest download rates, whichalone could provide the current peer with atransfer rate that is above a certain threshold.Each time the window shifts, download rates ofall the neighbors are evaluated, and the peersare sorted in descending order. Pieces are thenrequested from peers providing download ratesabove the threshold.

The performance of this framework is shownin Fig. 4. Here, the download rate is not highenough to allow the transfer of all layers. More-over, the download rate is not constant; there-fore, the received video bit rate needs to matchthe behavior of the download speed. It can beseen that the video is received at a higher bit rateimmediately after the prebuffering phase and atthe end of the sequence. The higher quality after

the prebuffering phase results from the fact thatthe first couple of GOPs are in the window for aslightly longer period than other GOPs. At theend of the sequence, when the window cannot beshifted anymore, the window is shrinking. There-fore, more enhancement layers can be download-ed for GOPs at the end of the sequence.

THE NEXTSHARE PLATFORMBased on the Tribler P2P protocol, theNextShare platform has been designed and isbeing implemented in the framework of theP2PNext project [7]. The NextShare platformsupports delivery over the P2P overlay of com-pressed video contents conforming to the specifi-cations of the SVC standard [1]. At the senderside, first, the SVC bitstream is divided into sev-eral files, each carrying a single scalable layer.Only the BL is encapsulated with audio inMPEG-TS transport format. Within the torrentfile, layers are indexed as independent files, leav-ing the user free to select the one to be down-loaded. Additional metadata is included in thetorrent to provide a description of the scalablebitstream in terms of resolutions and bit ratessupported. SVC layers are downloaded in theform of data segments from different files andcomposed by the NextShare P2P engine at theconsumer side. Once a target resolution is com-posed, the corresponding data is forwarded to amedia player.

Adaptation Strategy — In NextShare themaximum target layer is selected and providedto the piece picking algorithm by matching con-text information and available scalable resolu-tions extracted from the torrent. To react to atemporary narrowing of the bandwidth, theadaptation decision is made periodically bychecking the status of the input buffer, playbackposition, and pieces availability. Adaptationactions occur in correspondence to a synchro-nization point; for a compressed SVC bitstreamthis corresponds to an instantaneous decodingrefresh (IDR) frame. IDR represents a specialintra picture, which cuts off all inter-picturedependencies from previously decoded frames.The stream is therefore divided in units of con-stant temporal duration called time slots; eachtime slot corresponds to a period of framesbetween two consecutive IDRs.

The size of a NextShare chunk has been setto 56,400 bytes in order to have multiple MPEG-TS packets in each chunk, while preserving areasonable chunk size for efficient transmission.Here, the size of each MPEG TS packet is 188bytes. Each scalable layer is encoded at a con-stant bit rate (CBR), and hence is representedby a constant amount of bits in each time slot.Since CBR is used, it is possible to predict thenumber of chunks in a time slot of each layer.For example, for an SVC layer encoded at 512kb/s and 25 frames/s, there will be a time slot of64 frames (2.56 s), and the size of the corre-sponding block of frames will be approximately164 kbytes, which corresponds approximately tothree NextShare chunks. A bit overhead is con-sidered in piece mapping for each scalable layer,in order to compensate for the drift from thetarget bit rate always present in CBR algorithms.

Figure 4. Received download rate and received video bit-rate for Crew CIFsequence.

Time (s)40

200

Dow

nloa

d ra

te (

kb/s

)

0

400

600

800

1000

1200

1400

80 120 160 200 240 280 320 0

Video download rateReceived video bit rate



Piece Picking Strategy — The procedureimplemented in NextShare to download scalabledata chunks is an extension of the G2G algo-rithm. Priorities are defined as in G2G andextended to the multiple files, as depicted in Fig.5. In the high-priority set pieces are downloadedsequentially, while in the low-priority set piecesare downloaded in a rarest-first fashion. Eachblock in the figure represents a time slot.

In Fig. 5 at time instance t (playback posi-tion), the algorithm has to decide which block todownload for time point (t + x). Here, the algo-rithm might decide to start downloading piecesinside EL1 at time t + 1 in order to improve thequality for the near future or may decide to con-tinue downloading blocks for BL to ensure thatthe playback will not stop even if network condi-tions become worse. Periodically the algorithmmakes such a decision depending on the currentstatus of the download, pieces lost, and playbackposition. The controller implemented inNextShare tries to switch to a higher quality assoon as there is enough saved buffer for the cur-rent quality. Therefore, a safe buffer of chunksdownloaded and not yet delivered to the playeris defined; the size of this buffer is a function ofthe parameter x depicted in Fig. 5. The mini-mum value for x corresponds to five time slots,and can vary depending on network perfor-mance. When enough segments for the BL havebeen downloaded, the quality is increased, andthe download of the next layer is selected. In thiscase the high-priority set is redefined, and highpriorities are assigned to blocks belonging to theupper layers (the sequence of high priorities willfollow layer dependencies H0 → H1 → H2). Inorder to guarantee a safe time alignment, foreach increase in quality the initial time slots todownload are ahead in time with respect to pre-vious layers. An offset of one time slot is addedat the beginning of each enhancement layer asdepicted in Fig. 5. When not enough pieces areavailable for a certain resolution, the controllerswitches back to a safer position by interruptingthe download of the correspondent file and reas-signing priorities to lower layers.

Peer Selection Strategy — The peer selectionstrategy is inherited from the approach imple-mented in Tribler. For each layer, pieces with anearly deadline are downloaded from good (i.e.,fast) peers. Bad peers (i.e., peers that missed agiven deadline for a particular piece) are movedfrom the high-priority set to a low-priority onestarting from the BL. A bad performancecounter is incremented each time a piece down-load fails. As a consequence, peers with a posi-tive bad performance counter are only availablefor picking low-priority pieces.

SEACAST PLATFORMIn the framework of the SEA project [8], a differ-ent P2P architecture to support scalable videostreaming has been implemented. While theNextShare and MMV platforms were both basedon full mesh P2P topology, in SEA the scalablecontent is delivered over a multitree overlay. P2Pplatforms developed in SEA are based on the Vid-Torrent protocol [13], which creates an overlay for-est of independent trees, each one carrying adifferent part of the stream. A central entity (track-er/broker) is used for creating and managing theoverlay. Nodes of a tree structure have well definedparent-child relationships. Such an approach is typ-ically push-based, that is, when a node receives adata packet, it also forwards copies of the packetto each of its children. If peers do not change toooften, tree-based systems require little overhead,since packets are forwarded from node to nodewithout the need for extra messages. However,with respect to mesh topologies in high churn envi-ronments, the tree must be continuously destroyedand rebuilt, which requires considerable controlmessage overhead. Furthermore, nodes mustbuffer data for at least the time required to repairthe tree in order to avoid packet loss.

In the SEA project two different platformshave been developed. The first platform(SEABone) targets code optimization focusingon cross-platform development for set-top boxes.The second platform (SEACast) aims at addingsupport for layered and multiple-descriptive cod-ing schemes [14].

Figure 5. Layered priorities in NextShare.

Quality switch

Quality switch

Time slotV

ideo

qua

lity

t t + x

Time Playback position

Low priority L2 High priority H2 EL2

Low priority L1 High priority H1 EL1

Low priority L0 BL High priority H0

The size of

NextShare chunk has

been set to 56400

bytes in order to

have a multiple

number of MPEG-TS

packets in each

chunk, while preserv-

ing a reasonable size

of a chunk for

efficient transmis-

sion. Here, the size

of each MPEG TS

packet is 188 bytes.



SVC Support in SEACast — The structure ofthe P2P tree generated with the SEACast appli-cation is depicted in Fig. 6.

The content is injected in the tree overlay bya root node that informs the broker about thepublished content. In case of layered video, theroot node also generates a file containing infor-mation about the content structure, in terms ofsupported resolutions and dependencies amongthe layers. Such information is formatted in a so-called Session Description Protocol (SDP) mes-sage [15].

The original VidTorrent protocol was modi-fied to deliver layered contents over multitreeoverlays. That is, for an SVC video, each layer isdelivered over a different tree. The granularityintroduced by splitting the content into multiplelayers allows peers with limited upload band-width to contribute to the swarm by uploadingdata relative to a reduced version of the scalablebitstream. Intrinsic robustness to node failures isadded, as the loss of connections carrying anenhancement layer will cause temporary degra-dation of the overall quality. Clearly, in case offailure or congestion of a connection carryingthe BL, there is no possibility to easily recoverthe quality even if enhancement layers arereceived. In such a situation, the performancemay be improved by assigning priorities to eachdifferent tree according to the importance of theSVC layer carried, and injecting and forwardingthe BL over the most reliable path.

Data Transport in SEACast — In SEACastdata packets are simply forwarded from parent tochildren nodes. As shown in Fig. 6, the publisheris connected to the SEACast root node by means

of a different Real-Time Transport Protocol(RTP) connection for each scalable layer. RTPconnections act also as interfaces between clientnodes and the media player. SVC data are encap-sulated by the publisher in RTP payload. In theSEACast root node, RTP packets are directlypushed over a different tree according to the cor-respondent layer. Each SEACast client keeps abuffer of a few seconds for each tree in which itparticipates; RTP packets are extracted from theclient buffer and again delivered to the mediaplayer over different sessions. The SVC stream isfinally reconstructed inside the media player byaggregating the sub-bitstream, and synchroniza-tion among sessions is kept by using timestampinformation contained in packet headers.

Peer Selection and Adaptation Strategy inSEACast — When a peer wants to join theswarm, it first contacts the broker to receive thelist of neighboring nodes that already have thevideo. The SDP message is also transmitted bythe broker. By parsing the SDP, the peer knowsavailable resolutions and dependencies amongthe layers for the selected video. By matchingthis information with local capabilities and localbandwidth, it selects a target resolution. Accord-ing to the layers hierarchy, the peer pings itspotential parent nodes, starting from the BL andrepeating the operation for ELs. Each SVC layeris therefore retrieved from a different node. Alocal probe technique is used to select the bestparent. In particular, a combination of round-trip time, available bandwidth, and the numberof already active connections is used. Once theparent node is selected for each layer, connec-tions are established. Periodically, available

Figure 6. SEAcast architecture.

Broker

High-end STB and laptop

Video producer

and publisher

SEAcast root node

SEAcast leaf node

SEAcast leaf node

SEAcast leaf node

SEAcast leaf node

SEAcast leaf node

Low-end smartphones

SDP(Session and scalabilityinformation)Data packets BLData packets EL

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.



bandwidth is checked, and in case of congestionor connection failure, the peer contacts the bro-ker again to rebuild the tree.

CONCLUSIONSIn P2P networks video is streamed to the user ina fully distributed fashion. Network resources aredistributed among users instead of handled by asingle entity. However, due to the diversity ofusers’ displaying devices and available bandwidthlevels in the Internet, the underlying coding andtransmission technology needs to be highly flexi-ble. Such flexibility can easily be achieved bySVC, where bitstreams can be adapted in thecompressed domain according to available band-width or user preferences. When using SVC inP2P streaming, special care needs to be given tohandling different bitstream layers according tothe current playback position. Since it is highlyimportant that pieces close to playback positionarrive on time, these need to be downloadedfrom good peers. In this article we have present-ed several advanced P2P systems supportingstreaming of scalable video and designed to sup-port future Internet applications. Considering theflexibility given by scalable bitstreams within P2Poverlays, it is clear that P2P streaming systemssupporting SVC technology will play an impor-tant role in the Internet of the future.

ACKNOWLEDGMENTThe authors wish to thank Simone Zezza fromthe Department of Electronics, Politecnico diTorino, for his help with revising this manuscript.This research has been partially funded by theEuropean Commission under contract FP7-247688 3DLife, FP7-248474 SARACEN, andFP7-248036 COAST.

REFERENCES[1] H. Schwarz, D. Marpe, and T. Wiegand, “Overview of

the Scalable Video Coding Extension of the H.264/AVCStandard,” IEEE Trans. Circuits Sys. Video Tech., vol. 17,no. 9, Sept. 2007, pp. 1103–20.

[2] M. Mrak et al., “Performance Evidence of Software Pro-posal 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 LayeredVideo Chunks in P2P Live Streaming,” IEEE Trans. Multi-media, vol. 11, no. 7, 2009.

[4] P. Baccichet et al., “Low-Delay Peer-to-Peer StreamingUsing Scalable Video Coding,” Proc. Packet Video ‘07,2007, Lausanne, Switzerland, pp. 173–81.

[5] Y. Ding et al., “Peer-to-Peer Video-on-Demand withScalable 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-to-

Peer 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-ResilientVideo-on-Demand in P2P Systems,” Proc. SPIE Multime-dia Comp. Net., vol. 6818, San Jose, CA.

[12] S. Asioli, N. Ramzan, and E. Izquierdo, “A Novel Tech-nique for Efficient Peer-To-Peer Scalable Video Trans-mission,” 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 VideoStreaming Supporting Multiple Description Coding,” Proc.IEEE Int’l. Conf. Multimedia Expo, New York, NY, 2009.

[15] T. Schierl and S. Wenger, “Signaling Media DecodingDependency in the Session Description Protocol (SDP),”IETF RFC 5583, July 2009; http://tools.ietf.org/html/rfc5583.

BIOGRAPHIESNAEEM RAMZAN ([email protected]) is a post-doctoral researcher at the Multimedia and Vision Group,Queen Mary University of London. His research activitiesfocus around multimedia search and retrieval, image andvideo coding, scalable video coding, surveillance-centriccoding, multimedia transmission over wireless, and P2Pnetworks. Currently, he is a senior researcher and coremember of the technical coordination team in the EUfunded projects PetaMedia and SARACEN. He is the authoror co-author of more than 40 research publications.

EMANUELE QUACCHIO ([email protected]) receivedan M.S. degree in electronic engineering from the Poly-technic University of Turin, Italy, in 2003. He worked twoyears as a researcher in the Department of Electronics ofthe same university and joined STMicroelectronics in 2006.His activities are focused on embedded software develop-ment for STB/mobile platforms and multimedia communi-cation. He has published several papers in the principaljournals of engineering and conferences. Since 2006 he hasparticipated in a number of EU funded projects.

TONI ZGALJIC ([email protected]) received a Ph.D.degree from Queen Mary University of London in 2008. Heis currently a research assistant in the Multimedia andVision Group in the School of Electronic Engineering andComputer Science at the same university. His research inter-ests include scalable video coding and transmission, univer-sal multimedia access, surveillance-centric coding, and videotranscoding. He has published more than 20 technicalpapers in these areas, including chapters in books.

STEFANO ASIOLI ([email protected]) received anM.Sc. degree in telecommunications engineering from theDepartment of Information Engineering and Computer Sci-ence (DISI), University of Trento, Italy, in 2009. He is cur-rently pursuing a Ph.D. degree in electronic engineering atthe Multimedia & Vision Group, Queen Mary University ofLondon. His research interests include peer-to-peer net-works and scalable video coding.

LUCA CELETTO ([email protected]) received a Master’sdegree in electronic engineering from the University of Pado-va, Italy, in 1998. He joined STMicroelectronics in 1999,where he contributed to research projects in video compres-sion and streaming. He has published and co-authored sev-eral papers in the principal journals of engineering andconferences, and has been granted several patents on videotechnologies. As an MPEG committee member, he partici-pated in the standardization of the H.264 specifications. Hehas collaborated on EU-funded projects.

EBROUL IZQUIERDO ([email protected]) isChair of Multimedia and Computer Vision and head of theMultimedia and Vision Group in the School of ElectronicEngineering and Computer Science at Queen Mary Univer-sity of London. He received a Ph.D. from Humboldt Univer-sity, Berlin, Germany. He has been a senior researcher atthe Heinrich-Hertz Institute for Communication Technology,Berlin, and the Department of Electronic Systems Engineer-ing of the University of Essex. He holds several patents inmultimedia signal processing and has published over 400technical papers, including chapters in books.

FABRIZIO SIMONE ROVATI ([email protected]) received hiselectronic engineering degree from Politecnico of Milano in1996. In 1995 he joined STMicroelectronics in the AST Sys-tem R&D group working on digital video processing algo-rithms and architectures. He currently leads the corporateR&D group in the field of networked multimedia. Duringhis career he has authored or co-authored 15 British, Euro-pean, and U.S. granted patents, and 10 publications inconferences or technical journals.

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.


Documents

Peer-to-peer streaming of scalable video in future Internet applications