Shibata, N., Yasumoto, K., and Mori, M.: P2P Video Broadcast based on Per-Peer Transcoding and its Evaluation on PlanetLab, Proc. of 19th IASTED Int'l. Conf. on Parallel and Distributed Computing and Systems (PDCS2007), pp. 478-483, (November 2007). http://ito-lab.naist.jp/themes/pdffiles/071121.shibata.pdcs2007.pdf We have previously proposed a P2P video broadcast method called MTcast for simultaneously delivering video to user peers with different quality requirements. In this paper, we design and implement a prototype system of MTcast and report the results of its performance evaluation in the real Internet environment. MTcast relies on each peer to transcode and forward video to other peers. We conducted experiments on 20 PlanetLab nodes, evaluated startup delay and recovery time from peer leaving/failure, and confirmed that MTcast achieves practical performance in a real environment.

1. P2P VIDEO BROADCAST BASED ON PER-PEER TRANSCODING AND ITS
EVALUATION ON PLANETLAB
Naoki Shibata, Masaaki Mori Keiichi Yasumoto
Dept. Info. Processing & Management Graduate School of Information Science
Shiga University Nara Institute of Science and Technology
1-1-1 Bamba, Hikone 522-8522, Japan 8916-5 Takayama, Ikoma 630-0192, Japan
email: {shibata, mori}@biwako.shiga-u.ac.jp email: yasumoto@is.naist.jp
ABSTRACT trees to the receiver nodes while the server load is high.
We have previously proposed a P2P video broadcast OMNI and CoopNet, unfortunately, do not treat heteroge-
method called MTcast for simultaneously delivering video neous quality requirements.
to user peers with different quality requirements. In this There are some approaches for heterogeneous quality
paper, we design and implement a prototype system of MT- video delivery on P2P network. PAT [8] is a method to re-
cast and report the results of its performance evaluation in duce computation resources necessary for on-line transcod-
the real Internet environment. MTcast relies on each peer ing in P2P network by making peers share the part of data
to transcode and forward video to other peers. We con- generated during encoding and decoding of video. We have
ducted experiments on 20 PlanetLab nodes, evaluated start- also proposed MTcast (Multiple Transcode based video
up delay and recovery time from peer leaving/failure, and multicast)[9] which achieves efficient and robust video
confirmed that MTcast achieves practical performance in a broadcast to multiple heterogeneous users by relying on
real environment. user peers to transcode and forward video. MTcast con-
structs a tree whose root is the sender of the original video
KEY WORDS content as a variation of a perfect n-ary tree, where peers
P2P, Video, Broadcast, Transcoding, Overlay Network with higher quality requirements are located near the root
of the tree.
In this paper, aiming to validate practicability and ef-
1 Introduction fectiveness of MTcast in the real Internet environment, we
design and implement MTcast system with a more effi-
Recently, many types of computing terminals ranging from cient tree construction mechanism than the original MT-
cell phone to HDTV are connected to the Internet, and con- cast. In the new tree construction mechanism, parent-child
sequently efficient video delivery method for many termi- relationship between peers is decided based on bandwidth
nals with different computation powers, display sizes and and topology measurement on physical path. We have
available bandwidths is required. There are some studies also designed and implemented a prototype system of MT-
on simultaneously delivering video to multiple users with cast. With the prototype, we have conducted experiments
different quality requirements. In the multiversion tech- on the PlanetLab[10], and confirmed that MTcast achieves
nique [1], multiple versions of a video with different bi- reasonably short start-up latency, small channel switching
trates are stored at a server so that the most appropriate time, and small recovery time from peer leaving/failure.
video can be delivered to each user within resource limi-
tation. In the on-line transcoding method [2], the original 2 MTcast Overview
video is transcoded at a server or one of intermediate nodes
(i.e. proxy) to videos with various quality, according to re- In this section, we provide an overview of MTcast [9].
ceivers’ requests, and forwarded to the receivers. However,
large computation power is required for transcoding by a 2.1 Target Environment
server or an intermediate node. In the layered multicast
method [3, 4], video is encoded with layered coding tech- MTcast is a peer-to-peer based video broadcast method for
niques such as the ones in [5] so that each user can decode heterogeneous peers whose available bandwidths, compu-
the video by receiving arbitrary number of layers, although tation powers, screen sizes, etc. are different. The target
splitting into many layers imposes computation overhead environment of MTcast is shown in Table 1.
on user nodes. MTcast does not treat the VoD (Video on Demand)
Furthermore, there are many studies on video stream- service. Instead, it provides a service of broadcasting a
ing in peer to peer networks such as OMNI[6] and the video during the scheduled time to peers requiring the
CoopNet[7]. In OMNI(Overlay Multicast Network Infras- video, which is very similar to ordinary TV broadcasts. Af-
tructure), each user node works as a service provider as ter a video broadcast starts, new users can join to receive
well as a service user, and a multicast tree is composed of the video delivery from the scene currently on broadcast.
user nodes so that the video delivery service is provided
2.2 Definitions
to all the user nodes through the tree. OMNI can adapt to
the change of the user node distribution and the network Let s denote a video server, and U = {u1 , ..., uN } de-
conditions. In CoopNet, user nodes cache parts of stream note a set of user nodes. We assume that for each ui ,
data, and deliver them through multiple diverse distribution available upstream (i.e., node to network) bandwidth and

2. internal layer
Table 1. Target Environment 1500 leaf layer
1300 700
Item Explanation
1100 900 500 300
Types of peers Desktop PC, laptop PC,
PDA, cell phone, etc
Peer’s home network ADSL, CATV, FTTH, 1400 1200 1000 800 600 400 200 100
WLAN, cellular network,
etc connected to the Internet 1100 1100 900 500
Number of peers up to 100,000
Contents for broad- pre-recorded video Figure 2. Layer Tree Construction
cast
800kbps
2.4 Construction of Transcode Tree
700kbps 600kbps
In MTcast, the transcode tree is calculated in a centralized
way by a peer uC ∈ U . We assume that the server s de-
cides uC or behaves as uC . The tree construction algorithm
400kbps 300kbps 200kbps 500kbps consists of the following three steps.
Step 1: For each peer u ∈ U , the algorithm checks if u
Figure 1. Video Broadcast through a Transcode Tree (n = can transcode one or more video streams in real time by
2, k = 6) inequality (1), and can transmit n + 1 video streams at the
same time by inequality (2).
downstream (i.e., network to node) bandwidth can be mea-
sured. We denote them by ui .upper bw and ui .lower bw, u.ntrans (u.q) ≥ 1 (1)
respectively. Let ui .q denote ui ’s video quality require- u.nlink (u.q) ≥ n + 1 (2)
ment. We assume that ui .q is given by the bitrate of video
calculated by the required picture size and frame rate. Let If the above two inequalities hold for u, then u is put into
ui .ntrans (q) denote the maximum number of simultaneous UI which is the set of internal peers, otherwise put into UL
transcoding which can be executed by ui for videos with which is the set of leaf peers. s is always put into UI . If
quality q. Let ui .nlink (q) denote the maximum number |UI | < n |U |, the whole network resource is not sufficient
1
of simultaneous forwarding of videos with quality q which to satisfy the quality requirements of all peers. In such a
can be performed by ui . ui .ntrans (q) and ui .nlink (q) are case, we let |UL | − n−1 |U | peers in UL with larger up-
n
calculated from computation power of ui , ui .upper bw and stream bandwidths to reduce their quality requirements so
video quality. that the inequalities (1) and (2) hold. Then, those peers are
MTcast constructs an overlay multicast tree where s is moved to UI . By the above procedure, |UI | ≥ n |U | always
1
the root node and user peers in U are intermediate (internal) holds.
or leaf nodes. Hereafter, this multicast tree is called the Step 2: Peers of UI are sorted in decreasing order of their
transcode tree. quality requirements and every bunch of k peers is packed
to an internal layer, where k is the constant defined in 2.3.
2.3 Structure of Transcode Tree Here, we select the first and second peers of each layer as
Internal nodes in the transcode tree transmit a video stream the responsible peer and the sub-responsible peer of the
to children nodes. In MTcast, each internal node basically layer, respectively. The average value of quality require-
has n children nodes. The value of n is decided based on ments in each layer is called the layer quality, and all peers
the available resource of peers as explained in Sect. 2.4. In in the layer adjust their quality requirements to the value.
order to reduce the start-up delay for video playback and For the set of leaf nodes UL , elements are similarly packed
the number of transcoding applied to video, the transcode to leaf layers.
tree is constructed as a modified complete n-ary tree where Step 3: The algorithm sorts internal layers in decreasing
degree of the root node is k instead of n (k is a constant order of the layer quality, and constructs the complete n-
and explained later). The transcode tree is constructed so ary tree called the layer tree consisting of those internal
that for each node ui and each of its children nodes uj , layers where the layer quality of each layer does not ex-
ui .q ≥ uj .q holds. That is, from the root node to each leaf ceeds that of its parent layer. In MTcast, we use the depth
node, the nodes are ordered in decreasing order of quality first search order to assign internal layers to the layer tree
requirements. In order to tolerate node leave/failures, ev- as shown in Fig. 2. Next, the algorithm attaches each leaf
ery k nodes in U are bunched up into one group. We call layer L to the internal layer whose layer quality is closest to
each group a layer, where k is a predetermined constant. L. If the layer quality of L exceeds that of L’s parent layer,
In MTcast, peers in the same layer receive video with the the layer quality of L is adjusted to that of L’s parent. Fi-
same quality. This quality is called the layer quality. A nally, the transcode tree is obtained by assigning internal
representative peer is selected for each layer. Parent-child nodes and leaf nodes to the corresponding internal layers
relationship among all layers on the transcode tree is called and leaf layers in decreasing order of their required qual-
the layer tree. An example of the transcode tree with n = 2 ity, respectively, and assigning parent-child relationships
and k = 6 is shown in Fig. 1, where, small circles and big between peers according to the layer tree.
ovals represent peers and layers, respectively. How to decide transcode tree degree n and layer size k

3. In MTcast, the transcode tree is constructed as a mod-
ified complete n-ary tree. So, as the value of n becomes
large, the tree height (i.e., the number of transcoding) also
decreases. Since the required upstream bandwidth of each
node increases in proportion of n’s value, the value of n
must be carefully decided considering upstream bandwidth
limitation of each node. In order to avoid reducing the qual-
ity requirements in Step 1, we should decide the value of n (a) before failure (b) after recovery
so that the number of peers satisfying the inequality (2) is
no less than U .
n Figure 3. Recovery from Node Failure
The value of k affects the tolerance of leave/failure of
peers. If f peers may leave from a layer at the same time
before the transcode tree is reconstructed, the remaining using its extra upstream bandwidths similarly to the case of
k − f nodes in the layer must transmit video streams to processing new delivery requests. An example is shown in
n · k children nodes. So, the following inequalities must Fig. 3.
hold in order to recover from f simultaneous failures in (3) Reconstruction of Transcode Tree The transcode
each layer.Thus, the appropriate value of k can be decided tree is periodically reconstructed to adjust tentatively in-
from values of n and f . creased degree (n + 1) to normal one (n). Peer uc recon-
structs the transcode tree in the following steps.
(k − f )u.nlink (q) ≥ n · k (3) First, uC collects quality requirements effective after
k time tr from all peers along the layer tree. Then, it calcu-
(k − f )u.ntrans ≥ n (4) lates the new transcode tree with the algorithm in Sect. 2.4,
u.nlink (q) and distributes the information of the transcode tree to all
peers.
2.5 MTcast Protocols At time tr , all nodes stop receiving streams from
current parent nodes and the nodes in the root layer of
Start-up Behavior Let t denote the time of video de- the new transcode tree starts to deliver video streams.
livery. Each user who wants to receive video stream sends Nodes in internal layers also forward video streams after
a video delivery request to the video server s before time receiving them. The video stream transmitted along the
t − δ. At time t − δ, s calculates the transcode tree with new transcode tree arrives after a certain time lag due to
the algorithm explained in Sect. 2.4. Here, δ is the time transcode and link latency. During the time lag, each node
to calculate the transcode tree and distribute the necessary plays back video from its buffer. For the next reconstruc-
information to all nodes. Next, s distributes the following tion of the transcode tree, the buffer of each node must be
information I or I to all peers along T . filled with video data of the above time lag. This process
is done by transmitting the video stream slightly faster than
• I: information distributed to a responsible peer uR of its playback speed.
a layer L
All information of T including addresses of peers
and their parent-child relationship, the structure of the 3 Implementation of MTcast System
layer tree and the membership of peers, the addresses
of responsible/sub-responsible peers, the layer quality In the original MTcast in [9], parent-child relationship of
in each layer, and the next reconstruction time tr . peers in the transcode tree is decided without consideration
of property of overlay links. However, in the Internet, an
• I : information distributed to each peer p of layer L overlay link could be a long path with many hops in the
other than L’s responsible peer physical network. So, first, we have designed and imple-
The addresses of L’s responsible peer, p’s children mented effective decision of parent-child relationship be-
peers, the responsible peer and sub-responsible peers tween peers. Then, aiming to investigate usefulness of MT-
of L’s parent layer, and the next reconstruction time cast in the real Internet environment, we have implemented
tr . belongs, MTcast system. We address details of the implementation
in the following subsections.
(2) Protocols for peer joining and leaving As explained
before, each peer in an internal layer has an extra upstream 3.1 Decision of parent-child relationship between
bandwidth for forwarding one more video stream. A user peers
peer unew who has requested video delivery after time t can
use this extra bandwidth to receive a video stream instantly. As we already explained, the algorithm in Sect. 2.4 does
Here, the fan-out of the forwarding peer uf which sends a not make a distinction between overlay links over different
stream to unew is allowed to be n + 1 tentatively. ASs (autonomous systems) and those within an AS. In this
If one or more peers in a layer fail or suddenly leave subsection, we propose a technique to save bandwidths of
from the transcode tree, all of their descendant nodes called inter-AS links without spoiling the advantages of MTcast.
orphan peers will not be able to receive video streams. In As our basic policy, we consider the physical network
MTcast, each orphan peer can find an alternative parent topology to decide the parent-child relationship of peers in
peer by asking the responsible peer of the parent layer. The the transcode tree.
responsible peer received such a request ask one of peers Let C and P be the sets of peers which belong to a
in the layer to forward video stream to the orphan node by layer and its parent layer, respectively. For each pair of

4. peers between the child layer and the parent layer, the phys- modules like lost connection or the amount of buffered data
ical path and the available bandwidth can be obtained with exceeding a threshold. In our design, the central process
tools such as traceroute and Abing, respectively. Fro peers is informed of these changes through a queue for status
c ∈ C and p ∈ P , let bw(c, p) and L(c, p) denote the change message arranged in the central process. In case
available bandwidth measured with such tools (called mea- of status change, the corresponding module puts a message
sured available bandwidth, hereafter) and the set of phys- into the queue, and the central process takes an appropriate
ical links between c and p except for links connected to action according to the incoming message.
nodes c and p, respectively.
Next, we estimate the available bandwidth of each 3.3 Devices to facilitate video stream handling
overlay link (called estimated available bandwidth, here- Although a mechanism similar to InputStream and Output-
after) by considering some of links are shared among mul- Stream classes in the standard Java library can be used to
tiple overlay links. For each link l ∈ L(c, p), the estimated exchange video streams between modules, it would be trou-
available bandwidth dl and the sharing degree dl are de- blesome to realize a procedure like restarting transcoder
fined as follows. with different parameters during processing a successive
stream. In the prototype system design, we made an orig-
ml = M in{ bw(c, p) | l ∈ L(c, p), c ∈ C, p ∈ P }
inal class whereby each end of frame data is explicitly de-
dl = | { c | l ∈ L(c, p), c ∈ C, p ∈ P } | clared by transmitter, and receiver reads data until end of
frame data as usual, but after that, the read method returns
Based on the measured available bandwidth ml and -2 like when it reaches EOF, and then the receiver contin-
the sharing degree dl of each physical link, we decide the ues reading data of the next frame. With this specification,
parent node of each child node as follows. each end of frame data can be easily processed without de-
For each p ∈ P and c ∈ C, we investigate if c can re- stroying and remaking module instances.
ceive video stream with the required quality. If only a peer Stream processing can be realized using JMF(Java
(say, p1 ) in P can transmit a video stream with the required Media Framework), but it is known that there will be a large
quality to c, then the p1 is assigned as the parent node of processing delay due to buffers placed on each processing
c. If some of peers in P can transmit the video stream to module. In the prototype system, we tried to minimize pro-
c, M axp∈P M inl∈L(c,p) mll which represents the peer with
d cessing delay by reducing buffering on each module. In
maximum available bandwidth per share, is assigned as c’s the system, while each module basically corresponds to a
parent node. thread, we made the write method to block until the cor-
We designed the prototype system with emphasis on responding reader thread reads all of written data by that
the following two points: (i) ease of implementation and call. By this design, processing delay is reduced since
(ii) reusablility of the finished software; when we change when a module invokes write method, control is immedi-
the proposed method, the prototype system should be easily ately passed to the reader thread, and thus there is no pro-
modified to comply with the new specification, and a large cessing delay due to thread switching interval of operating
part of the software should be able to be reused in other system.
similar projects. With these two requirements satisfied, we
devised the prototype system not to sacrifice performance. 3.4 Devices to facilitate evaluation on many PlanetLab
By adopting modular design, which is described below, we nodes
made the process which runs on each node a generic pro-
gram, and its functionality can be changed by changing the In order to facilitate evaluation using several tens of Plan-
code for central server process. etLab nodes, we devised the following manner. Conditions
of PlanetLab nodes momently change, and good nodes fre-
3.2 Modular design quently becomes unavailable after short period of time. In
order to cope with this situation, we made a set of scripts
In order to flexibly change formation of process on each which checks currently installed files on each node, and up-
node and facilitate performance evaluation under various date them if necessary. The scripts consist of ones run on
configurations, we designed the process on each node to the operator’s host, and ones run on PlanetLab nodes. The
be a set of modules like buffer or transcoder. Process on former scripts copies necessary scripts and files on Planet-
each node makes instance of these modules and connects Lab nodes using scp command, and execute them. This
them according to commands from the central server pro- operation is executed in parallel. The latter scripts check
cess. The central server process can also issue commands the version of installed files, and if necessary, download
for particular modules on each node. We made these mech- and install them using wget command. We used these
anisms using Java language and RMI(Remote Method In- scripts, and confirmed that it takes less than 30 minutes
vocation). The modules include transcoder, video player, to install java run time environment to 30 PlanetLab nodes.
network data receiver, transmitter, buffer, user interface, We also confirmed that installing java class files for the pro-
configuration file reader, etc, and each of these modules totype system on these nodes takes about 1 minute.
corresponds to one class. Each instance of the modules
corresponds to one thread so that the modules can be pro-
grammed more easily than event-driven style code. 4 Performance Evaluation
Each instance made by commands from the central
server process is registered in a hash table on the node with In order to show practicality of MTcast, we need to val-
a unique key. Methods of these instances can be invoked idate (1) overhead of real-time transcoding by user peers
later by referring this hash table. The prototype system and (2) network and processing overhead for constructing a
should make some action according to status changes on transcode tree, (3) recovery time after peer leaving/failure.

5. For the usefulness of MTcast, we also need to validate (4) Table 3. Time required for starting up
user satisfaction (i.e., whether each user can receive and
play back video at his/her requested quality), (5) efficiency # of nodes establishing connection receiving data
of the transcode tree (in terms of overlay link lengths), and 4 10,871ms 19,040ms
(6) start-up delay (i.e., the time delay for video to be dis- 8 11,681ms 16,993ms
played after its request). 12 15,307ms 15,307ms
In [9], we already showed that the validity of the 16 11,317ms 18,781ms
above (1), (2) and (4), and confirmed that desktop PCs and 20 12,144ms 17,562ms
lap-top PCs have enough power for real-time transcoding
of a video stream (for (1)), an ordinary PC can calculate Table 4. Delay introduced by forwarding
the transcode tree with 100,000 peers in 1.5 second and the
tree size is within 300Kbyte (for (2)), and MTcast achieves # of nodes delay
higher user satisfaction than layered multicast using 10 lay- 14 7,002 ms
ers through computer simulation (for (4)). 16 8,603 ms
In Sect. 4.1, we present the detailed experimental re- 20 20,573 ms
sults of applying our prototype system to show the validity 23 10,024 ms
of the above (3), (5), and (6). 27 9,435 ms
4.1 Evaluation on PlanetLab nodes Time required for start-up
In order to evaluate the performance of proposed method Table 3 shows the times required for starting up. The
in the real environment, we operated our prototype system columns for establishing connection and receiving data in-
on PlanetLab nodes. In this section, we describe the result dicate the required times since start of the system until
of measurement for time required to join, delay introduced the last node establishes connection and until the last node
by successive forwarding and transcoding, the behavior in receives first byte of data, respectively. Please note that
case of abrupt departure of node, and effectiveness of band- these times include Java JIT compiler to compile byte code.
width saving method for backbone links. Since all nodes establish connections in parallel, the ob-
tained time is the maximum time required for nodes to es-
tablish connection. Since leaf nodes have to receive data
Configuration via their descendant nodes, the time to receive data is con-
sidered to be proportional to the height of tree. But actually,
We used video with pixel size of 180 × 120 and frame increase of time is not observed as the height of tree grows.
rate of 15fps, without audio. We used motion JPEG as the This is because the time required to establish connection is
CODEC of video. dominant. Anyway, these times are less than 20 seconds,
We used TCP to transmit video data between nodes. and thus these values are practical.
In order to evaluate scalability, we constructed the
transcode tree as a cascade of layers with two nodes, in-
stead of the modified n-ary tree. In the experiments, Delay introduced by successive forwarding and
we used several tens of PlanetLab nodes including nodes transcoding
showed in Table 2. We also used katsuo.naist.jp and
wakame.naist.jp, which do not belong to PlanetLab. We Table 4 shows the time since the first node receives first
executed the originating video server at katsuo.naist.jp, and byte of data until the last node receives first byte of data.
one user node process on each other nodes. Due to constant The result is similar to the result of start-up delay measure-
high processing load on PlanetLab nodes, it was difficult to ment. The times are less than 21 seconds, and thus these
allocate processing power required for transcoding, and so values are practical.
we did not performed transcoding on each node. Instead,
we make each node just buffer data for one frame, and
transmit it unprocessed. We believe that when our method
is used for practical use, the processing power for transcod- Behavior in case of abrupt node departure
ing is surely available.
Table 5 shows the time to reestablish connection after node
Table 2. Nodes used in experiments departure. The time to reconnect and restarting receiving
data are the time since the departure node sends depar-
katsuo.naist.jp pl1-higashi.ics.es.osaka-u.ac.jp ture request until its child node reestablishes connection to
wakame.naist.jp planetlab3.netmedia.gist.ac.kr
planet0.jaist.ac.jp planetlab1.netmedia.gist.ac.kr a new parent node, and the child node receives first byte
planetlab-01.naist.jp planetlab2.iii.u-tokyo.ac.jp of data from the new parent node, respectively. We used
planetlab-02.naist.jp planetlab1.iii.u-tokyo.ac.jp the cascading transcode tree topology which is same as the
planetlab-03.naist.jp planetlab5.ie.cuhk.edu.hk last measurement, and made the node indicated in the ta-
planetlab-04.naist.jp planetlab4.ie.cuhk.edu.hk
planetlab1.tmit.bme.hu planetlab-02.ece.uprm.edu ble leave the system. The measured times are less than two
planetlab2.tmit.bme.hu planetlab-01.ece.uprm.edu seconds, and users see video uninterruptedly in this period
planetlab02.cnds.unibe.ch since video stream data is buffered in each node. Thus, the
planetlab01.cnds.unibe.ch results are practical.

6. Table 5. Behavior in case of node departure
departure node new parent node time to time to
reconnect restart
planetlab1.netmedia.gist.ac.kr thu1.6planetlab.edu.cn 1,471ms 1,805ms
planetlab4.ie.cuhk.edu.hk planetlab1.netmedia.gist.ac.kr 288ms 411ms
planetlab-01.ece.uprm.edu planetlab5.ie.cuhk.edu.hk 1,114ms 1,657ms
planetlab1.tmit.bme.hu planetlab-02.ece.uprm.edu 1,383ms 1,626ms
planetlab01.cnds.unibe.ch planetlab1.tmit.bme.hu 1,541ms 1,841ms
planetlab2.iii.u-tokyo.ac.jp planet0.jaist.ac.jp 61ms 1,004ms
Effectiveness of bandwidth saving method for backbone [2] S. Jacobs and A. Eleftheriadis: “Streaming Video
links using Dynamic Rate Shaping and TCP Flow Con-
trol,” Visual Communication and Image Representa-
In order to evaluate the effectiveness of bandwidth saving tion Journal, 1998. (invited paper).
method for backbone links described in 3.1, we compared
the number of total hops in the transcode tree when the sys- [3] J. Liu, B. Li, and Y.-Q. Zhang: “An End-to-End
tem chooses parent nodes for each node at random, using Adaptation Protocol for Layered Video Multicast Us-
the method in 3.1, and using a method to choose nearest ing Optimal Rate Allocation,” IEEE Trans. on Multi-
hop parent. In this experiment, we set the number of nodes media, Vol. 6, No. 1, 2004.
per layer to be 4, and used cascaded transcode tree. We [4] B. Vickers, C. Albuquerque and T. Suda : “Source-
make the system obtain route between nodes and available Adaptive Multilayered Multicast Algorithms for
bandwidth between nodes using traceroute and Abing[11], Real-Time Video Distribution,” IEEE/ACM Trans. on
respectively. Some routers between nodes did not respond Networking, Vol.8, No.6, pp.720-733, 2000.
to ICMP Echo message, and these routers are treated as
different routers for each route between nodes. Routes [5] H. Radha, M. Shaar, Y. Chen: “The MPEG-4 Fine-
and available bandwidth are obtained before constructing Grained-Scalable video coding method for multime-
transcode tree, and these are performed in parallel for each dia streaming over IP,” IEEE Trans. on Multimedia,
route, and this took about 30 seconds. Table 6 shows the Vol. 3, No. 1, 2001.
total hop counts in the transcode tree measured three times.
Note that even if we used the method in 3.1, the resulting [6] S. Banerjee, C. Kommareddy, K. Kar, B. Bhattachar-
transcode tree differs each time since the results of mea- jee and S. Khuller : “Construction of an Efficient
surement for available bandwidth differs each time. The Overlay Multicast Infrastructure for Real-time Ap-
results indicate that using the method in 3.1 leads to 16% plications,” Proc. of IEEE Inforcom 2003, pp.1521-
fewer hop count, and choosing nearest hop parent leads to 1531, 2003.
41% fewer hop count.
[7] V. Padmanabhan, H. Wang, P. Chow and K. Sripanid-
Table 6. Effectiveness of backbone bandwidth saving kulchai : “Distributiong streaming media content us-
ing cooperative networking,” Proc. of the 12th Int’l
method # of hops Workshop on Network and Operating Systems Sup-
random 343, 361, 335 port for Digital Audio and Video (NOSSDAV 2002),
method in 3.1 314, 280, 277 pp.177-186, 2002.
minimum hop count 204, 204, 204
[8] D. Liu, E. Setton, B. Shen and S. Chen : “PAT: Peer-
Assisted Transcoding for Overlay Streaming to Het-
erogeneous Devices,” Proc. of 17th Int’l Workshop on
5 Conclusion Network and Operating Systems Support for Digital
Audio and Video (NOSSDAV 2007), pp.51-53, 2007.
In this paper, we have implemented the algorithm and pro-
[9] T. Sun, M. Tamai, K. Yasumoto, N. Shibata, M.
tocols of MTcast proposed in [9] and showed the practical-
Ito and M. Mori : “MTcast : Robust and Efficient
ity and performance of MTcast through experiments made
P2P-Based Video Delivery for Heterogeneous Users,”
on PlanetLab.
Proc. of the 9th Int’l. Conf. on Principles of Dis-
In the future work, we will extend the algorithm of tributed Systems (OPODIS 2005), pp.176-190, 2005.
MTcast to treat multi-dimensional quality requests includ-
ing picture size, frame rate, and bit rate, and transcode each [10] PlanetLab: “An open platform for developing, de-
quality factor independently of others. ploying, and accessing planetary-scale services,”
https://www.planet-lab.org/.
References [11] J.Navratil and R. L. Cottrell : “ABwE: A Practical
Approach to Available Bandwidth Estimation,”
[1] G. Conklin, G. Greenbaum, K. Lillevold, and A. http://www-iepm.slac.stanford.edu
Lippman: “Video Coding for Streaming Media De- /tools/abing/
livery on the Internet,” IEEE Trans. on Circuits and
Systems for Video Technology, Vol. 11, No. 3, 2001.