220 IEEE TRANSACTIONS ON CIRCUITS AND SYSTEMS FOR VIDEO TECHNOLOGY, VOL. 21, NO. 2, FEBRUARY 2011

Transactions Letters

A Collaborative Transcoding Strategy for Live Broadcasting overPeer-to-Peer IPTV Networks

Jui-Chieh Wu, Polly Huang, Jason J. Yao, and Homer H. Chen, Fellow, IEEE

Abstract—Real-time video transcoding that is often needed forrobust video broadcasting over heterogeneous networks is notsupported in most existing devices. To address this problem,we propose a collaborative strategy that leverages the peeringarchitecture of peer-to-peer Internet protocol television networksand makes the computational resources of peers sharable. Thevideo transcoding task is distributed among the peers and com-pleted collaboratively. A prototype of the live video broadcastingsystem is evaluated over a 100-node testbed on the PlanetLab.The experimental results show that the proposed strategy workseffectively even when the majority of the peers have limitedcomputational resource and bandwidth.

Index Terms—IPTV, live broadcasting, multiple descriptioncoding, P2P network, video streaming.

I. Introduction

V IDEO CONTENT distribution over peer-to-peer (P2P)networks has evolved and become an everyday norm [1].

The evolution will continue as the deployment of broadbandwireless access, such as WiFi, 3G, and WiMAX, accelerates[10] and as more people create and share contents of their ownover the Internet. The problem we are concerned with in thisletter is related to the support of live video broadcasting overa P2P Internet protocol television (IPTV) network.

Multiple description coding (MDC) [2], [3] and layeredvideo coding (LVC) [4]–[6] techniques have been developedto enhance the quality of service for networks that are het-erogeneous in nature. However, most multimedia devices onlysupport popular coding standards such as MPEG-4 [7], [8] as

Manuscript received September 29, 2008; revised April 27, 2009 andNovember 29, 2009; accepted August 13, 2010. Date of publication Jan-uary 13, 2011; date of current version March 2, 2011. This work wassupported in part by the grants from the National Science Council of Taiwan,under Contracts NSC 95-2219-E-002-012, NSC 94-2220-E-002-027, andNSC 95-2219-E-002-015. This paper was recommended by Associate EditorM. Comer.

J.-C. Wu is with the Graduate Institute of Computer Science and InformationEngineering, National Taiwan University, Taipei 10617, Taiwan (e-mail:r93922115@ntu.edu.tw).

P. Huang and J. J. Yao are with the Department of Electrical Engi-neering and Graduate Institute of Communication Engineering, NationalTaiwan University, Taipei 10617, Taiwan (e-mail: phuang@cc.ee.ntu.edu.tw;jasonyao2000@hotmail.com).

H. H. Chen is with the Department of Electrical Engineering, Graduate In-stitute of Communication Engineering, and Graduate Institute of Networkingand Multimedia, National Taiwan University, Taipei 10617, Taiwan (e-mail:homer@cc.ee.ntu.edu.tw).

Digital Object Identifier 10.1109/TCSVT.2011.2105571

the native compression format and cannot perform MDC orLVC in real time.

To break the computational bottleneck, we leverage theP2P streaming architecture of an IPTV system and makethe computational resource, in addition to bandwidth, ofthe peers sharable. Under this strategy, the native streamgenerated by the source peer is divided into small segmentsand assigned to peers that have the computational resource toshare the transcoding workload. That is, the transcoding taskis distributed among peers and completed collaboratively.

The notion of P2P networking for resource sharing hasbeen adopted in various systems [11]–[14]. However, ourapproach is different in that the source peer does not collectthe distributed results from the peers and that the transcod-ing is carried out in a pure P2P fashion without centralgoverning.

II. System Overview

The collaborative video transcoding strategy is built upon aP2P IPTV system [2] as the baseline, which incorporates pull-based content delivery (swarming) and layered encoding tostream media to heterogeneous viewers. The system architec-ture is shown in Fig. 1. The partnership formation componentmaintains the partner relationship between the peers, and thepeer information exchange component maintains a buffer mapthat records the data availability. The exchange period of thebuffer maps is referred to as the swarming cycle. Based onthe buffer map, the segment scheduling module searches thevideo segments that can arrive before the display time and aredownloadable within the available bandwidth.

The baseline system is extended to incorporate thecollaborative transcoding strategy for live video broadcasting.A peer passes a transcoding task to its downstream peers ifit cannot handle the task, which involves decoding a segmentin the native compression format and re-encoding it into thetarget format.

The source peer generates a native compressed video streamand broadcasts it through the P2P network. The receivers areclassified into transcoding peers (those which transcode thereceived segments) and transporting peers (those which onlytransport the received segments without transcoding them).After going through one or more overlay hops in the P2P

1051-8215/$26.00 c© 2011 IEEE

WU et al.: A COLLABORATIVE TRANSCODING STRATEGY FOR LIVE BROADCASTING OVER PEER-TO-PEER IPTV NETWORKS 221

Fig. 1. P2P IPTV system architecture with collaborative transcoding for livevideo broadcasting. The highlighted area represents the baseline system.

network, a segment in the native format is converted to thetarget format.

There are three requirements. First, a peer should collectthe information about the available computing power of otherpeers. Second, to avoid assigning a transcoding task too manytimes, a peer should collect information of the transcodingstatus of a segment. Third, based on the collected information,a peer should assign a transcoding task (defined in Section IV)to each downstream peer, and each downstream peer shouldbe able to determine if a task is acceptable and, if yes, itspriority.

Consequently, the baseline system is extended to equipwith: 1) capability estimation; 2) exchange of capability andtranscoding status information; and 3) job scheduling. Thecapability estimation component periodically estimates theavailable computing power of a peer. The extended peerinformation exchange component manages the exchange ofinformation with other peers about the computational capabil-ity of a peer and the transcoding status of a video segment.The job scheduling component, which is integrated with thesegment scheduling component of the baseline system, deter-mines for a partner peer which segments should be sent to therequesting peer and which requesting peers can transcode thesegments. For a requesting peer, this component determineswhich segments to download.

III. Computational Capability Estimation

Computational capability estimation is a challenging issuebecause the available computational resource varies fromdevice to device and depends on factors such as the centralprocessing unit (CPU) clock speed, the random access memory(RAM) size, the current CPU load, the transcoding scheme,and the video characteristics. For each specific CPU clockspeed and RAM size, it is possible to determine and recordthe available computing power in a lookup table. However, it ispractically impossible to enumerate all possible combinations.

To have a robust and universal mechanism that is indepen-dent of codec, hardware platform, and operating system, weuse the average transcoding time ta of a 1-s video segment for

Fig. 2. Structure of a buffer map.

Fig. 3. Five phases of collaborative video transcoding and their values inbinary format.

computational capability estimation and update it whenever thepeer completes a transcoding task. The number of segments apeer can handle in one swarming cycle Cs is determined bydividing the swarming cycle ts by ta.

The capability estimate cannot be completely accurate sincethe available resource of a peer varies over time. Therefore,in the event that a peer is unable to finish all tasks within aswarming cycle due to an overestimate of its computationalcapability, the pending transcoding tasks must be subtractedfrom Cs in the next swarming cycle.

IV. Peer Information Exchange

In each swarming cycle, a peer requests the buffer mapfrom its partner peers. The request message also contains theavailable uplink bandwidth, the number of requesting peers,and the computational capability of the peer. The availableuplink bandwidth is estimated by using the transmitted mediadata as the probing packets to avoid traffic overload. Uponreceiving the request, a partner peer uses the informationcontained in the request message to determine the candidatesegment and responds to the request with a buffer map for jobscheduling.

The buffer map extended from the baseline system carriesadditional information about transcoding, as shown in Fig. 2.A buffer map consists of one 8-bit long ID and 64 contiguoussegment descriptors, each of which is 8-bit long and corre-sponds to a 1-s video segment. The last 4 bits of a segmentdescriptor indicate which MDC descriptions [2] are availableif it is an MDC segment, or the number of requesting peersthat receive the segment for transcoding if this segment is nottranscoded yet. The latter is needed for job scheduling.

The first 4 bits of the descriptor of a segment describe thetranscoding status of the segment, namely, initial (1), transport(2), candidate (3), progressing (4), and complete (5), as shownin Fig. 3. The first four phases mean that the segment is stillin the native compression format, whereas the last one meansthe segment is completely transcoded to the MDC format.

The transcoding status of a new segment in the nativecompression format is set to initial. Once requested, its statusis changed to transport. If a peer finds that it can transcode

222 IEEE TRANSACTIONS ON CIRCUITS AND SYSTEMS FOR VIDEO TECHNOLOGY, VOL. 21, NO. 2, FEBRUARY 2011

the segment, it changes the status of the segment to candidate.As the segment is being transcoded, its status is changed toprogressing. When the segment is finally converted to theMDC format, its status is changed to complete. The buffermap is updated every second in our system to match with thevideo rate since each live video segment is 1 s. long.

V. Job Scheduling

The job scheduling module relies on the information period-ically exchanged between peers to determine the transcodingschedule of the video segments. The message flow of the jobscheduling is as follows. First, a peer sends to all its partnerpeers a buffer map request. Upon receiving the buffer maprequest, a partner peer decides which segments to announce(or expose) to the requesting peer. This operation is referred toas candidate segment selection. The descriptors of the selectedsegments are inserted in the buffer map and sent along with thebuffer map to the requesting peer. After collecting all buffermap responses, the requesting peer decides which segments todownload and schedules the transmission of these segments.

A. Candidate Segment Selection

The candidate segment selection runs on partner peers. If allsegments in the buffer of a partner peer are MDC segments,the partner peer just has to announce all the segments to the re-questing peer. However, when some of them are untranscoded,the partner peer needs to decide how many of them it cantranscode and which of the remaining segments it should passto the requesting peer. It works as follows.

First, all MDC segments are selected and announced to therequesting peer because we want MDC segments to populatethe live broadcasting network as soon as possible.

Second, those segments in the native compression formatwhich cannot be converted to the MDC format before thedisplay deadline are announced to the requesting peer.

Finally, given the computational capability C of the re-questing peer, the partner peer selects additional segmentsand announces them to the requesting peer. These additionalsegments are the first C segments of the remaining segmentsin the native compression format sorted by three criteria:1) transcoding status; 2) request count; and 3) display deadlineof the segments. These criteria are applied in order.

B. Segment Transmission Scheduling

The candidate segment transmission scheduling runs onrequesting peers. After the buffer map is acquired, a requestingpeer has the information about the transcoding status ofthe segments and can decide which segments to downloadfor display and which for transcoding. Since our goal isto disseminate each MDC segment as soon as it becomesavailable, we download the MDC segments first.

Then we download the segments in the native compressionformat, which are divided into urgent and non-urgent seg-ments. If no peers, including the peer itself, can transcodeor complete the transcoding of a segment before its displaydeadline, the segment is classified as urgent, otherwise, it is

non-urgent. All urgent segments are downloaded next. Thenthe peer evaluates which non-urgent segments it can transcodebefore the other peers. C of these segments are downloadedfor transcoding according to the score defined as follows:

Ai =∑

j∈Si

βri, j , β ≥ 1 (1)

where Ai is the score of the ith segment, Si the set of partnerpeers that have the ith segment, ri, j the transcoding statusof the ith segment assigned by the jth partner peer, and β aparameter that controls the preference of selection. Non-urgentsegments with lower scores are selected first.

VI. Experimental Results

The performance of the collaborative transcoding strategyon a P2P live broadcasting system is tested with differentcoded streams as the source video data.

A. Experimental Settings and Metrics

The prototype of the proposed strategy is loaded into thenodes on the PlanetLab [9] for evaluation, and the experimen-tal P2P network is constructed by using the TYPHOON part-nership formation protocol of the baseline system [2]. Sincethe PlanetLab does not provide functions for controlling thecomputational resource of a node, we simulate the computingpower of a node by controlling the average transcoding timeof a video segment. The P2P network of our testbed consistsof 100 peers, 80 in North America, 15 in Europe, and 5 inEastern Asia. The swarming cycle is set to 4 s, and β is set to2. Each experiment lasts 3500 s, and all peers join the networkin the first 400 s.

The system broadcasts the common international format-size Foreman sequence repeatedly in all the experiments. Theframe rate is set to 30 f/s, and the native compression formatis the simple profile of MPEG-4 Part 2. The bit rate of theMPEG-4 stream is set to 400 kb/s and the corresponding MDCstreams to 500 kb/s. We evaluate the system performance bycontinuity index (CI), and transcoding load.

CI is defined as the ratio of the number of segments receivedin time to the total number of segments sent by the source peer.In our experiments, four types of CIs are computed becausedifferent coded streams are generated as the source video. Theoverall CI, which is the same as the one in CoolStreaming [1],is the ratio of the number of received segments (either MPEG-4 or MDC) to the total number of segments sent by the sourcepeer. It measures the display smoothness. The MDC CI is theratio of the number of MDC segments received in time to thetotal number of segments sent by the source peer. It measuresthe performance of the collaborative transcoding strategy. Thepure MDC CI is defined in the same way as the MDC CIexcept that the source video is already pre-coded in the MDCformat. Likewise, the pure MPEG-4 CI refers to the casewhere the source video is pre-coded in the MPEG-4 format.Transcoding load is defined as the time used for transcodingby a peer divided by the total time during which the peerstays in the system. It represents the additional computationalresource consumed by the collaborative transcoding strategy.

WU et al.: A COLLABORATIVE TRANSCODING STRATEGY FOR LIVE BROADCASTING OVER PEER-TO-PEER IPTV NETWORKS 223

In the ideal situation, each segment is transcoded only once,thus the ideal load is the average transcoding time of a segmentdivided by the total number of peers.

B. Heterogeneous Network

In the experiment, the proposed strategy is evaluated on asimulated network that has strong, medium, and weak peers,with an average transcoding time per segment of 4, 16, and28 s, respectively. Both the uplink and downlink bandwidthsof the strong peers are in the 2–4 Mb/s range. The uplinkbandwidth of the medium peers ranges from 0.5 to 1 Mb/sand the downlink bandwidth from 2 to 2.5 Mb/s. The uplinkbandwidth of weak peers is in the 300–600 kb/s range andthe downlink bandwidth is in the 500–800 kb/s range. We setthe weak peers to 10% and vary the ratio between strong andmedium peers to evaluate the efficiency of job scheduling.

1) CI: Fig. 4 shows that the CI increases with the per-centage of strong peers. The pure MDC CI representsan ideal case where each source video is already inthe MDC format. The distance between the pure MDCCI curve and the overall CI curve is the performancedegradation when real-time transcoding is not supported.The pure MPEG-4 CI represents the performance ofthe system that simply transmits each MPEG-4 streamwithout transcoding it to the MDC format. This curveis a threshold, below which collaborative transcoding isnot worth doing. As the percentage of strong peers goesfrom 0 to 90%, the percentage of medium peers goesfrom 90 to 0%.When the percentage of strong peers is larger than 40%,the overall CI and the MDC CI are close to 1, meaningthat most segments are transcoded to MDC segments andreceived by all peers. In other words, the collaborativetranscoding strategy works to our satisfaction. Notethat the CI of pure MPEG-4 drops rapidly when thepercentage of bandwidth resourceful peers decreases toless than 50%. In contrast, the proposed strategy onlyhas small performance degradation even when there isno strong peer.

2) Load: Fig. 5 shows that the average load of the weakpeers gradually decreases as the percentage of strongpeers increases because the strong peers take over thosesegments originally handled by weak peers. In a central-ized P2P network, the minimum computation load canbe achieved by that each video segment been transcodedby one peer. However, the centralized strategy requiresa central server to collect the global information forscheduling and is impractical for the applications con-sidered in this letter. On the contrary, the load of theproposed strategy is higher than that of the centralizedstrategy, meaning that each segment is transcoded sev-eral times by different peers. This transcoding redun-dancy is advantageous to the P2P system because it canenhance the error resilience to peer dynamics.

C. Parameter Choices

There are tradeoffs in deciding the system parameters suchas swarming cycle ts, video bit rate, and β. In this section,

Fig. 4. CI of a network with heterogeneous computational resource andbandwidth.

Fig. 5. Load of a network with heterogeneous computational resource andbandwidth.

TABLE I

Overall CI Value and the Average Message Overhead for

Different Swarming Cycles

ts Overall CI Message Traffic2 0.9992 24.08 kb/s4 0.9965 20.22 kb/s8 0.9963 17.57 kb/s12 0.9411 14.52 kb/s16 0.6459 13.04 kb/s

we evaluate the system performance with different parametersettings. The average transcoding time of a segment is set to20 s in the following experiments.

1) Video bit rate: If the network has unlimited bandwidthand is lossless, transmitting videos at a higher bit rategives better quality. This is, however, not possible onthe Internet. When the video bit rate approaches theavailable bandwidth, CI starts to decrease, as shown inFig. 6. The choice of the video bit rate is determinedby the available bandwidth of the network and thereforeshould be decided carefully by the system operator.

2) Swarming cycle: The choice of the swarming cycle tsintroduces a tradeoff between the efficiency of infor-mation exchange and message overhead. If ts is large,the information exchange process becomes less frequentand thus a peer may not have enough information toschedule transcoding tasks efficiently. However, if ts issmall, the message overhead becomes high. To evaluatethe impact of ts, we perform a series of experimentswith ts ranging from 2 to 16 s. The average messageoverhead of each peer and the overall CI are listed inTable I. As ts increases, both the message overhead andthe overall CI decrease. However, the decrease of CI andthat of the message overhead are not proportional. Thissuggests that the value of ts should be determined beforethe rapid decrease of the overall CI starts.

224 IEEE TRANSACTIONS ON CIRCUITS AND SYSTEMS FOR VIDEO TECHNOLOGY, VOL. 21, NO. 2, FEBRUARY 2011

Fig. 6. CI for different video bit rates.

TABLE II

CI for Different β Values

MDC CI Overall CI MDC CI Overall CI(50 peers) (50 peers) (100 peers) (100 peers)

Random scheduling 0.891 0.957 0.935 0.966β = 1 0.998 0.998 0.997 0.997β = 2 0.997 0.997 0.997 0.997β = 4 0.996 0.996 0.997 0.997

TABLE III

Load for Different β Values

Load (50 peers) Load (100 peers)Random scheduling 0.898 0.720β = 1 0.715 0.564β = 2 0.568 0.447β = 4 0.531 0.415

3) β: Tables II and III enlist the overall CI, MDC CI,and the resulting computational loads for different β

values, including the case where the transcoding phaseinformation is hidden so that the segment scheduling isdone in a random fashion.

With the hidden transcoding phase information, the peer hasno access to the transcoding status of the segments. Therefore,it may select segments that are being transcoded by other peersand perform the transcoding again. Thus, as we can see, theaverage transcoding load rises significantly to 0.898, and theMDC CI drops to 0.891.

We can also see that the average transcoding load decreasesas β increases. This is due to the fact that a larger β gives ahigher preference over segments that are not yet transcoded.However, a large β does not necessarily guarantee highervideo quality in terms of CI, as we can see from Table IIthat the overall and MDC CI values drop slightly. This isbecause when the peers are too conservative to downloadthe segments for transcoding, fewer segments are availablefor parallel download. In practice, one may set β to a valuebetween 1 and 2, depending on the desired video quality versustranscoding load.

VII. Conclusion

The main technical challenge in providing live video broad-casting over heterogeneous P2P networks was the lack of com-

puting support for real-time transcoding. We have described acollaborative strategy to solve the problem by leveraging thepeering architecture of P2P networks and evaluated it over a100-node testbed on the PlanetLab. The CI remained 98% orhigher even in the presence of scare computational resource.The approach can also be applied to live content deliverysystems with critical time constraints.

Acknowledgment

The authors would like to thank M.-T. Lu for implementingpart of the system described in this letter.

References

[1] X. Zhang, J. Liu, B. Li, and T.-S. P. Yum, “DONet/CoolStreaming: Adata-driven overlay network for live media streaming,” in Proc. IEEEINFOCOM, vol. 3. Mar. 2005, pp. 2102–2111.

[2] M.-T. Lu, J.-C. Wu, K.-J. Peng, P. Huang, J. J. Yao, and H. H.Chen, “Design and evaluation of a P2P IPTV system for heterogeneousnetworks,” IEEE Trans. Multimedia, vol. 9, no. 8, pp. 1568–1579, Dec.2007.

[3] S. Khan, R. Schollmeier, and E. Seinbach, “A performance comparisonof multiple description video streaming in peer-to-peer and contentdelivery networks,” in Proc. IEEE Int. Conf. Multimedia Expo, Jun.2004, pp. 503–506.

[4] J.-R. Ohm, “Advances in scalable video coding,” Proc. IEEE, vol. 93,no. 1, pp. 42–56, Jan. 2005.

[5] R. Rejaie and A. Ortega, “PALS: Peer-to-peer adaptive layered stream-ing,” in Proc. Int. Workshop Netw. Oper. Syst. Support Dig. Audio Video,Jun. 2003, pp. 153–161.

[6] Y. Shen, Z. Liu, S. S. Panwar, K. W. Ross, and Y. Wang, “Streaminglayered encoded video using peers,” in Proc. IEEE Int. Conf. MultimediaExpo, Jul. 2005, p. 5.

[7] Information Technology—Coding of Audiovisual Objects—Part 2: Vi-sual, document ISO/IEC 14496-2, Dec. 1999.

[8] T. Wiegand, G. J. Sullivan, G. Bjontegaard, and A. Luthra, “Overviewof the H.264/AVC video coding standard,” IEEE Trans. Circuits Syst.Video Technol., vol. 13, no. 7, pp. 560–576, Jul. 2003.

[9] PlanetLab. (2007) [Online]. Available: http://www.planet-lab.org[10] C. Eklund, R. B. Marks, K. L. Stanwood, and S. Wang, “IEEE standard

802.16: A technical overview of the WirelessMAN air interface forbroadband wireless access,” IEEE Commun. Mag., vol. 40, no. 6, pp.98–107, Jun. 2002.

[11] P. Li, B. Veeravalli, and A. A. Kassim, “Design and implementation ofparallel video encoding strategies using divisible load analysis,” IEEETrans. Circuits Syst. Video Technol., vol. 15, no. 9, pp. 1098–1112, Sep.2005.

[12] G. Kola, T. Kosar, and M. Livny, “A fully automated fault-tolerantsystem for distributed video processing and off-site replication,” in Proc.Int. Workshop Netw. Oper. Syst. Support Dig. Audio Video, Jun. 2004,pp. 122–126.

[13] F. Chen, T. Repantis, and V. Kalogeraki, “Coordinated media streamingand transcoding in peer-to-peer systems,” in Proc. IEEE Int. ParallelDistributed Process. Symp., Apr. 2005, p. 56b.

[14] D. Liu, E. Setton, B. Shen, and S. Chen, “PAT: Peer-assisted transcodingfor overlay streaming to heterogeneous devices,” in Proc. Int. WorkshopNetw. Oper. Syst. Support Dig. Audio Video, Jun. 2007.

[15] S. R. Narayanan, D. Braun, J. Buford, R. S. Fish, A. D. Gelman, A.Kaplan, R. Khandelwal, E. Shim, and H. Yu, “Peer-to-peer streamingfor networked consumer electronics,” IEEE Commun. Mag., vol. 45, no.6, pp. 124–131, Jun. 2007.

[16] I. Foster and A. Iamnitchi, “On death, taxes, and the convergence ofpeer-to-peer and grid computing,” in Proc. IPTPS, vol. 2735. Oct. 2003,pp. 118–128.