A Collaborative Transcoding Strategy for Live Broadcasting over Peer ...

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 over Peer-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 for robust video broadcasting over heterogeneous networks is not supported in most existing devices. To address this problem, we propose a collaborative strategy that leverages the peering architecture of peer-to-peer Internet protocol television networks and makes the computational resources of peers sharable. The video transcoding task is distributed among the peers and completed collaboratively. A prototype of the live video broadcasting system is evaluated over a 100-node testbed on the PlanetLab. The experimental results show that the proposed strategy works effectively even when the majority of the peers have limited computational resource and bandwidth. Index Terms—IPTV, live broadcasting, multiple description coding, 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 broadband wireless access, such as WiFi, 3G, and WiMAX, accelerates [10] and as more people create and share contents of their own over the Internet. The problem we are concerned with in this letter is related to the support of live video broadcasting over a P2P Internet protocol television (IPTV) network. Multiple description coding (MDC) [2], [3] and layered video coding (LVC) [4]–[6] techniques have been developed to enhance the quality of service for networks that are heterogeneous in nature. However, most multimedia devices only support popular coding standards such as MPEG-4 [7], [8] as Manuscript received September 29, 2008; revised April 27, 2009 and November 29, 2009; accepted August 13, 2010. Date of publication January 13, 2011; date of current version March 2, 2011. This work was supported 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, and NSC 95-2219-E-002-015. This paper was recommended by Associate Editor M. Comer. J.-C. Wu is with the Graduate Institute of Computer Science and Information Engineering, National Taiwan University, Taipei 10617, Taiwan (e-mail: [email protected]). P. Huang and J. J. Yao are with the Department of Electrical Engineering and Graduate Institute of Communication Engineering, National Taiwan University, Taipei 10617, Taiwan (e-mail: [email protected]; [email protected]). H. H. Chen is with the Department of Electrical Engineering, Graduate Institute of Communication Engineering, and Graduate Institute of Networking and Multimedia, National Taiwan University, Taipei 10617, Taiwan (e-mail: [email protected]). Digital Object Identifier 10.1109/TCSVT.2011.2105571

the native compression format and cannot perform MDC or LVC in real time. To break the computational bottleneck, we leverage the P2P streaming architecture of an IPTV system and make the computational resource, in addition to bandwidth, of the peers sharable. Under this strategy, the native stream generated by the source peer is divided into small segments and assigned to peers that have the computational resource to share the transcoding workload. That is, the transcoding task is distributed among peers and completed collaboratively. The notion of P2P networking for resource sharing has been adopted in various systems [11]–[14]. However, our approach is different in that the source peer does not collect the distributed results from the peers and that the transcoding is carried out in a pure P2P fashion without central governing. II. System Overview The collaborative video transcoding strategy is built upon a P2P IPTV system [2] as the baseline, which incorporates pullbased content delivery (swarming) and layered encoding to stream media to heterogeneous viewers. The system architecture is shown in Fig. 1. The partnership formation component maintains the partner relationship between the peers, and the peer information exchange component maintains a buffer map that records the data availability. The exchange period of the buffer maps is referred to as the swarming cycle. Based on the buffer map, the segment scheduling module searches the video segments that can arrive before the display time and are downloadable within the available bandwidth. The baseline system is extended to incorporate the collaborative transcoding strategy for live video broadcasting. A peer passes a transcoding task to its downstream peers if it cannot handle the task, which involves decoding a segment in the native compression format and re-encoding it into the target format. The source peer generates a native compressed video stream and broadcasts it through the P2P network. The receivers are classified into transcoding peers (those which transcode the received segments) and transporting peers (those which only transport the received segments without transcoding them). After going through one or more overlay hops in the P2P

c 2011 IEEE 1051-8215/$26.00


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

Fig. 2.

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

network, a segment in the native format is converted to the target format. There are three requirements. First, a peer should collect the information about the available computing power of other peers. Second, to avoid assigning a transcoding task too many times, a peer should collect information of the transcoding status 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 should be able to determine if a task is acceptable and, if yes, its priority. Consequently, the baseline system is extended to equip with: 1) capability estimation; 2) exchange of capability and transcoding status information; and 3) job scheduling. The capability estimation component periodically estimates the available computing power of a peer. The extended peer information exchange component manages the exchange of information with other peers about the computational capability of a peer and the transcoding status of a video segment. The job scheduling component, which is integrated with the segment scheduling component of the baseline system, determines for a partner peer which segments should be sent to the requesting peer and which requesting peers can transcode the segments. For a requesting peer, this component determines which segments to download.

III. Computational Capability Estimation Computational capability estimation is a challenging issue because the available computational resource varies from device to device and depends on factors such as the central processing 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 clock speed and RAM size, it is possible to determine and record the available computing power in a lookup table. However, it is practically impossible to enumerate all possible combinations. To have a robust and universal mechanism that is independent of codec, hardware platform, and operating system, we use the average transcoding time ta of a 1-s video segment for

221

Structure of a buffer map.

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

computational capability estimation and update it whenever the peer completes a transcoding task. The number of segments a peer can handle in one swarming cycle Cs is determined by dividing the swarming cycle ts by ta . The capability estimate cannot be completely accurate since the available resource of a peer varies over time. Therefore, in the event that a peer is unable to finish all tasks within a swarming cycle due to an overestimate of its computational capability, the pending transcoding tasks must be subtracted from Cs in the next swarming cycle. IV. Peer Information Exchange In each swarming cycle, a peer requests the buffer map from its partner peers. The request message also contains the available uplink bandwidth, the number of requesting peers, and the computational capability of the peer. The available uplink bandwidth is estimated by using the transmitted media data as the probing packets to avoid traffic overload. Upon receiving the request, a partner peer uses the information contained in the request message to determine the candidate segment and responds to the request with a buffer map for job scheduling. The buffer map extended from the baseline system carries additional information about transcoding, as shown in Fig. 2. A buffer map consists of one 8-bit long ID and 64 contiguous segment descriptors, each of which is 8-bit long and corresponds to a 1-s video segment. The last 4 bits of a segment descriptor indicate which MDC descriptions [2] are available if it is an MDC segment, or the number of requesting peers that receive the segment for transcoding if this segment is not transcoded yet. The latter is needed for job scheduling. The first 4 bits of the descriptor of a segment describe the transcoding status of the segment, namely, initial (1), transport (2), candidate (3), progressing (4), and complete (5), as shown in Fig. 3. The first four phases mean that the segment is still in the native compression format, whereas the last one means the segment is completely transcoded to the MDC format. The transcoding status of a new segment in the native compression format is set to initial. Once requested, its status is 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 to progressing. When the segment is finally converted to the MDC format, its status is changed to complete. The buffer map is updated every second in our system to match with the video rate since each live video segment is 1 s. long.

V. Job Scheduling The job scheduling module relies on the information periodically exchanged between peers to determine the transcoding schedule of the video segments. The message flow of the job scheduling is as follows. First, a peer sends to all its partner peers a buffer map request. Upon receiving the buffer map request, a partner peer decides which segments to announce (or expose) to the requesting peer. This operation is referred to as candidate segment selection. The descriptors of the selected segments are inserted in the buffer map and sent along with the buffer map to the requesting peer. After collecting all buffer map responses, the requesting peer decides which segments to download and schedules the transmission of these segments. A. Candidate Segment Selection The candidate segment selection runs on partner peers. If all segments in the buffer of a partner peer are MDC segments, the partner peer just has to announce all the segments to the requesting peer. However, when some of them are untranscoded, the partner peer needs to decide how many of them it can transcode and which of the remaining segments it should pass to the requesting peer. It works as follows. First, all MDC segments are selected and announced to the requesting peer because we want MDC segments to populate the live broadcasting network as soon as possible. Second, those segments in the native compression format which cannot be converted to the MDC format before the display deadline are announced to the requesting peer. Finally, given the computational capability C of the requesting peer, the partner peer selects additional segments and announces them to the requesting peer. These additional segments are the first C segments of the remaining segments in the native compression format sorted by three criteria: 1) transcoding status; 2) request count; and 3) display deadline of the segments. These criteria are applied in order. B. Segment Transmission Scheduling The candidate segment transmission scheduling runs on requesting peers. After the buffer map is acquired, a requesting peer has the information about the transcoding status of the segments and can decide which segments to download for display and which for transcoding. Since our goal is to disseminate each MDC segment as soon as it becomes available, we download the MDC segments first. Then we download the segments in the native compression format, which are divided into urgent and non-urgent segments. If no peers, including the peer itself, can transcode or complete the transcoding of a segment before its display deadline, the segment is classified as urgent, otherwise, it is

non-urgent. All urgent segments are downloaded next. Then the peer evaluates which non-urgent segments it can transcode before the other peers. C of these segments are downloaded for transcoding according to the score defined as follows:
Ai = βri, j , β ≥ 1 (1) j∈Si

where Ai is the score of the ith segment, S i the set of partner peers that have the ith segment, ri, j the transcoding status of the ith segment assigned by the jth partner peer, and β a parameter that controls the preference of selection. Non-urgent segments with lower scores are selected first. VI. Experimental Results The performance of the collaborative transcoding strategy on a P2P live broadcasting system is tested with different coded streams as the source video data. A. Experimental Settings and Metrics The prototype of the proposed strategy is loaded into the nodes on the PlanetLab [9] for evaluation, and the experimental P2P network is constructed by using the TYPHOON partnership formation protocol of the baseline system [2]. Since the PlanetLab does not provide functions for controlling the computational resource of a node, we simulate the computing power of a node by controlling the average transcoding time of a video segment. The P2P network of our testbed consists of 100 peers, 80 in North America, 15 in Europe, and 5 in Eastern Asia. The swarming cycle is set to 4 s, and β is set to 2. Each experiment lasts 3500 s, and all peers join the network in the first 400 s. The system broadcasts the common international formatsize Foreman sequence repeatedly in all the experiments. The frame rate is set to 30 f/s, and the native compression format is the simple profile of MPEG-4 Part 2. The bit rate of the MPEG-4 stream is set to 400 kb/s and the corresponding MDC streams to 500 kb/s. We evaluate the system performance by continuity index (CI), and transcoding load. CI is defined as the ratio of the number of segments received in time to the total number of segments sent by the source peer. In our experiments, four types of CIs are computed because different coded streams are generated as the source video. The overall CI, which is the same as the one in CoolStreaming [1], is the ratio of the number of received segments (either MPEG4 or MDC) to the total number of segments sent by the source peer. It measures the display smoothness. The MDC CI is the ratio of the number of MDC segments received in time to the total number of segments sent by the source peer. It measures the performance of the collaborative transcoding strategy. The pure MDC CI is defined in the same way as the MDC CI except that the source video is already pre-coded in the MDC format. Likewise, the pure MPEG-4 CI refers to the case where the source video is pre-coded in the MPEG-4 format. Transcoding load is defined as the time used for transcoding by a peer divided by the total time during which the peer stays in the system. It represents the additional computational resource 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 segment divided by the total number of peers. B. Heterogeneous Network In the experiment, the proposed strategy is evaluated on a simulated network that has strong, medium, and weak peers, with an average transcoding time per segment of 4, 16, and 28 s, respectively. Both the uplink and downlink bandwidths of the strong peers are in the 2–4 Mb/s range. The uplink bandwidth of the medium peers ranges from 0.5 to 1 Mb/s and the downlink bandwidth from 2 to 2.5 Mb/s. The uplink bandwidth of weak peers is in the 300–600 kb/s range and the downlink bandwidth is in the 500–800 kb/s range. We set the weak peers to 10% and vary the ratio between strong and medium peers to evaluate the efficiency of job scheduling. 1) CI: Fig. 4 shows that the CI increases with the percentage of strong peers. The pure MDC CI represents an ideal case where each source video is already in the MDC format. The distance between the pure MDC CI curve and the overall CI curve is the performance degradation when real-time transcoding is not supported. The pure MPEG-4 CI represents the performance of the system that simply transmits each MPEG-4 stream without transcoding it to the MDC format. This curve is a threshold, below which collaborative transcoding is not worth doing. As the percentage of strong peers goes from 0 to 90%, the percentage of medium peers goes from 90 to 0%. When the percentage of strong peers is larger than 40%, the overall CI and the MDC CI are close to 1, meaning that most segments are transcoded to MDC segments and received by all peers. In other words, the collaborative transcoding strategy works to our satisfaction. Note that the CI of pure MPEG-4 drops rapidly when the percentage of bandwidth resourceful peers decreases to less than 50%. In contrast, the proposed strategy only has small performance degradation even when there is no strong peer. 2) Load: Fig. 5 shows that the average load of the weak peers gradually decreases as the percentage of strong peers increases because the strong peers take over those segments originally handled by weak peers. In a centralized P2P network, the minimum computation load can be achieved by that each video segment been transcoded by one peer. However, the centralized strategy requires a central server to collect the global information for scheduling and is impractical for the applications considered in this letter. On the contrary, the load of the proposed strategy is higher than that of the centralized strategy, meaning that each segment is transcoded several times by different peers. This transcoding redundancy is advantageous to the P2P system because it can enhance the error resilience to peer dynamics. C. Parameter Choices There are tradeoffs in deciding the system parameters such as swarming cycle ts , video bit rate, and β. In this section,

Fig. 4. CI of a network with heterogeneous computational resource and bandwidth.

Fig. 5. Load of a network with heterogeneous computational resource and bandwidth. TABLE I Overall CI Value and the Average Message Overhead for Different Swarming Cycles ts 2 4 8 12 16

Overall CI 0.9992 0.9965 0.9963 0.9411 0.6459

Message Traffic 24.08 kb/s 20.22 kb/s 17.57 kb/s 14.52 kb/s 13.04 kb/s

we evaluate the system performance with different parameter settings. The average transcoding time of a segment is set to 20 s in the following experiments. 1) Video bit rate: If the network has unlimited bandwidth and is lossless, transmitting videos at a higher bit rate gives better quality. This is, however, not possible on the Internet. When the video bit rate approaches the available bandwidth, CI starts to decrease, as shown in Fig. 6. The choice of the video bit rate is determined by the available bandwidth of the network and therefore should be decided carefully by the system operator. 2) Swarming cycle: The choice of the swarming cycle ts introduces a tradeoff between the efficiency of information exchange and message overhead. If ts is large, the information exchange process becomes less frequent and thus a peer may not have enough information to schedule transcoding tasks efficiently. However, if ts is small, the message overhead becomes high. To evaluate the impact of ts , we perform a series of experiments with ts ranging from 2 to 16 s. The average message overhead of each peer and the overall CI are listed in Table I. As ts increases, both the message overhead and the overall CI decrease. However, the decrease of CI and that of the message overhead are not proportional. This suggests that the value of ts should be determined before the rapid decrease of the overall CI starts.

224

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

puting support for real-time transcoding. We have described a collaborative strategy to solve the problem by leveraging the peering architecture of P2P networks and evaluated it over a 100-node testbed on the PlanetLab. The CI remained 98% or higher even in the presence of scare computational resource. The approach can also be applied to live content delivery systems with critical time constraints. Fig. 6.

CI for different video bit rates.

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

TABLE II CI for Different β Values

Random scheduling β=1 β=2 β=4

MDC CI (50 peers) 0.891 0.998 0.997 0.996

Overall CI (50 peers) 0.957 0.998 0.997 0.996

MDC CI (100 peers) 0.935 0.997 0.997 0.997

Overall CI (100 peers) 0.966 0.997 0.997 0.997

TABLE III Load for Different β Values

Random scheduling β=1 β=2 β=4

Load (50 peers) 0.898 0.715 0.568 0.531

Load (100 peers) 0.720 0.564 0.447 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 phase information is hidden so that the segment scheduling is done in a random fashion. With the hidden transcoding phase information, the peer has no access to the transcoding status of the segments. Therefore, it may select segments that are being transcoded by other peers and perform the transcoding again. Thus, as we can see, the average transcoding load rises significantly to 0.898, and the MDC CI drops to 0.891. We can also see that the average transcoding load decreases as β increases. This is due to the fact that a larger β gives a higher preference over segments that are not yet transcoded. However, a large β does not necessarily guarantee higher video quality in terms of CI, as we can see from Table II that the overall and MDC CI values drop slightly. This is because when the peers are too conservative to download the segments for transcoding, fewer segments are available for parallel download. In practice, one may set β to a value between 1 and 2, depending on the desired video quality versus transcoding load.

VII. Conclusion The main technical challenge in providing live video broadcasting over heterogeneous P2P networks was the lack of com-

References [1] X. Zhang, J. Liu, B. Li, and T.-S. P. Yum, “DONet/CoolStreaming: A data-driven overlay network for live media streaming,” in Proc. IEEE INFOCOM, 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 heterogeneous networks,” IEEE Trans. Multimedia, vol. 9, no. 8, pp. 1568–1579, Dec. 2007. [3] S. Khan, R. Schollmeier, and E. Seinbach, “A performance comparison of multiple description video streaming in peer-to-peer and content delivery 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 streaming,” 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, “Streaming layered encoded video using peers,” in Proc. IEEE Int. Conf. Multimedia Expo, Jul. 2005, p. 5. [7] Information Technology—Coding of Audiovisual Objects—Part 2: Visual, document ISO/IEC 14496-2, Dec. 1999. [8] T. Wiegand, G. J. Sullivan, G. Bjontegaard, and A. Luthra, “Overview of 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 for broadband 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 of parallel video encoding strategies using divisible load analysis,” IEEE Trans. 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-tolerant system 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 streaming and transcoding in peer-to-peer systems,” in Proc. IEEE Int. Parallel Distributed Process. Symp., Apr. 2005, p. 56b. [14] D. Liu, E. Setton, B. Shen, and S. Chen, “PAT: Peer-assisted transcoding for overlay streaming to heterogeneous devices,” in Proc. Int. Workshop Netw. 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 streaming for 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 of peer-to-peer and grid computing,” in Proc. IPTPS, vol. 2735. Oct. 2003, pp. 118–128.