• 沒有找到結果。

1.1 Introduction

The growth of the Internet has been changing people’s habits in an inestimable speed.

Traditional services have been translated into “e-services”, such as e-mail, e-paper, e-payment, etc. The Internet has become the most direct way that people who want to know about weather or working opportunities will access. The burgeoning bandwidth and processing power create many innovative applications which bring us more convenience and can share our experiences to others around the world easily. Besides, with the wireless technology expanding the access ability of the Internet, we can write down words, take pictures or record video any time and publish them right away.

In the meanwhile, VoIP is considered as the recommended solution for the next generation telecommunication. Not only the telephony services but also the broadcasting radio or cable television will be totally changed by this new network technology. It means that almost our daily life could not depart from the Internet. We believe that the live multimedia streaming over IP network will be a potential application that can catch the user’s attention and stimulate more users to join it.

Although MBone[1] , a IP layer multicast solution, provides a pretty good method to transmit streaming data through IP network, it also has a big constraint limiting its usage.

There is no standard or particular organization to manage the IP multicast group address, so the probability of IP confliction will rise when more users create live streaming services.

Hence, we try to use Application Layer Multicast (ALM) to construct a platform where users can create their own channels to show live stream captured from their video cameras.

1.2 Related Works

There are many types of delivery architectures providing solutions for broadcasting live Audio/Video streaming. One of them is based on a powerful source server or a cluster of servers that receivers can subscribe the service and receive streaming data from. ICEcast [2], an open source project developed by this architecture, has been downloaded by lots of users.

The defect of this solution is the lack of scalability and sudden peeks may lead the disruption.

The source provider has to prepare a powerful server with lots of bandwidth to serve the streams for a lot of people, because the need of the bandwidth is linear related to the number of subscribers.

In order to improve the system scalability and reduce bandwidth requirements, multicast approaches have been proposed to reduce the amount of duplicated packet transmissions over the Internet and the burden of the source providers. The overlaid network multicast, which essentially consists of some well-organized or dynamically arranged super nodes, is different from the IP-Multicast solution that we described above. Peer-to-peer multicast trees, such as end system multicast [3] or chunk-driven P2P streaming [4, 5], are recently the most popular architectures. Typically, the nodes organize themselves into an efficient overlay tree and forward data.

Peercast [6] uses P2P technologies to make each participating node become a

broadcaster without the costs of traditional streaming. The source should handle the whole distribution tree and process the participations, departures or failure events of the nodes.

When a user subscribes to receive streaming, the source will randomly pick a node to serve the user. This is useful and easy to setup for a small group sharing live streaming, but an embedded device such as mobile phone or PDA may not tolerate the sudden peeks of workload increasing.

Unicast

Scattercast [7] is composed by three components. Figure 1-1 shows the architecture of

scattercast. The source provider and receiver are implemented on a client and SCXs (Scatter-Cast proXy) are the specific network nodes that construct an overlaid network on the internet. A client which wishes to participate in the scattercast session communicates with the nearby SCX and served by that SCX. The role of SCX is a super node of a two tier overlay network. Scattercast needs ISP’s proxy servers to play as the media relay servers. This is expensive and not easy to be constructed by a small company.

Figure 1-1 The architecture of Scattercast

SplitStream [5] is designed for high-bandwidth data spreading. It stripes the data across

multicast trees to balance the uploading/downloading traffic ratio of each node. This method also reduces the influence of any single node whose failure can only lead to the interruption of one tree. All of N nodes take their role as a serving node in one tree, and a leaf node in the other N-1 trees. Each peer gives back to the network as many bandwidths as it consumes.

However, the tree construction cost is high, a streaming description method, such as MDC (Multiple Description Coding) to identify each streaming part, is needed and the delay of each

tree are not stable for real-time application.

However, those existing multicast approaches only focused on how to construct and maintain a network topology to deliver packets from a source provider to the subscribers.

However, like watching TV programs, more choices will encourage users to switch channels to get different stuffs. Streaming services should enable users to depart from the original channel and join another one. When users traverse between some favorite channels, the latency of joining the delivering trees should be minimized. In this paper, we design a fast switching mechanism to solve this problem.

1.3 Objectives

In the thesis, we target on the "live video streaming sharing" from many source providers to a dynamic, large number of receivers. The first issue we addressed in the thesis is to develop a live streaming system that includes many content delivery multicast trees and the management policy for dynamic events such as user departure or node failure.

The root of each tree is a source provider that sends his streaming data by an ALM network. Peers can subscribe a streaming service (channel) through a well-known channel information server. Like many P2P system, it’ll send back a peer list and update the status about this channel. Peers use the list to be initiating information to associate with other peers.

All users can voluntarily become a source provider and others may subscribe to receive/relay streaming data at any time. We also propose a simple mechanism to reduce the latency when users switch between their favorite channels.

1.4 Overview of this thesis

The remaining of the thesis is organized as follows. In Chapter 2, we describe the background of live streaming service. In Chapter 3, we present the architecture and the design of our system. The implementation and conclusions are shown in Chapter 4 and Chapter 5.

相關文件