direkt zum Inhalt springen

direkt zum Hauptnavigationsmenü

Sie sind hier

TU Berlin

Page Content

Adaptive Peer-to-Peer Video Streaming

Motivation

The adaptive streaming technology contributes a great improvement in the quality of experience of end users during video playback. It enables users or clients to stream a video with quality that is appropriate to their available bandwidth, resulting with less buffering and faster starting playback time. On the other hand, peer-to-peer (P2P) is an approach to distribute media content over the IP network, giving clients alternative locations other than a server to download the content. In other words, a client can stream a video from another clients or peers. In this project, both methods, adaptive streaming and P2P are basically combined in order to realize an adaptive P2P streaming that is intended to handle certain problems with the usual adaptive streaming technology.

Problem

Clients somewhere in the Internet decide to stream a video hosted on a web server at approximately the same time using VLC player. An available plugin for VLC player enables the clients to stream the video using MPEG- DASH standard. According to the standard, a web server hosts a video divided in segments and in several quality levels (bit rates) which are called representations. Somewhere on the path to the server the clients may share an access link. This link might be a link connecting a local area network with the Internet as shown in the figure below. Since the access link is shared, the available bandwidth of the link is divided equally to the streaming clients, placing the bottleneck at this link. Thus it might not be possible for every client to stream the video at the highest quality.

The main goal of this project was to enable all the clients to stream the video at a better quality to improve the user’s experience. The approach is to avoid the shared link by streaming via P2P.

Lupe

Challenges and solution approaches

Are there peers that are currently streaming the same video? If yes, where are they located? What representations do they have and which is the best source to download the video segments? These are some of the challenges that should be solved.

In order to realize the P2P video streaming by means of MPEG-DASH, the work has been divided into subtasks according to the challenges:

  1. Design and implementation of a tracker that provides information of the participating peer
  2. Design and implementation of the communication between peers, so that they can exchange availability information of the video segments.
  3. Design and implementation of the logic that executes the algorithm of choosing a source
  4. Evaluation of the implementation with predefined scenarios.

Design and Implementation

To get a better overview of the development steps, the communication flow or procedure in adaptive P2P streaming should be explained. The communication flow is focused on a peer’s side. In MPEG-DASH, a content server provides a Media Presentation Description file (MPD) that contains the available bit rates of a video and URL of each video segments. The next thing the peer should know is if there are other peers who possess the same content as the server offers. In order to find this information, the peer contacts the server where the tracker is located and downloads the tracker file where all the streaming peers at that time are listed. The peer obtains IDs and IP addresses of the other peers from the tracker file. Then the peer will request an XML file from every other peer to know which video segments and which bit rate they currently have. Finally the peer will decide from which source it will stream the video.

The tracker is implemented in PHP whereas the rest is a VLC player plugin written in C++.

Tracker

The tracker possesses a URL, which is basically its IP address, so that it is addressable by the peers in the network. The peers communicate with the tracker via HTTP GET by providing its ID, IP address, port number and the MPD ID which are appended to the tracker’s URL. A PHP program is written and stored at the tracker server. This program is invoked when peers initiate a connection to the tracker server and it is able to process all the received parameters from the peers. The PHP program creates an SQL table where these parameters will be written. Such SQL table is created for each streamed video, and each table is distinguished by MPD IDs. Therefore a new table is constructed in case a video is not yet streamed by any peer, or in other words the table with the indicated MPD ID does not exist. The first peer to stream the video will have their parameters directly stored in the table. Additionally, the tracker prepares an XML file as shown below to be downloaded by the peers. After downloading the XML file, the peers will parse it and create a list of streaming peers locally.

Lupe

Communication between the peers

When a peer streams a video, it downloads the video segments either from server or from other peers. The information of the downloaded segments (segment number and bit rate) is recorded in an XML file called MPDpeer which is stored locally. Every time a new video segment is received, the segment information is appended to the existing MPDpeer. In the case where the first segment of the video is received, or the peer just began with streaming, a new MPDpeer will be created and the segment information will be appended to the file. The file is distributed to other peers upon request via HTTP. When a peer receives MPDpeer from other peers, it will parse the file to obtain the information about the segments that the other peer has. The information will be assigned to the corresponding peer in the local list of peers. This is the fundament of information sharing between peers before they can start to stream a video.

Logic

In order to make a decision from which source (server or peer/which peer) to download the required segments in best quality some additional information is needed. Until now is known, how to reach the peers and what kind of representations can they offer. But can we afford to download segments from certain peers? To answer this question an initial measurement phase is implemented. In this measurement phase the bandwidth to the selected peer will be measured by downloading some data from that peer. In order not to decrease the user’s experience the measurement will be conducted by downloading segments. In this way the playback of the video can start earlier. The procedure is illustrated below.

Lupe

After the measurement of the bandwidth to the server and the peers, there is a fundamental base to decide which source is more appropriate for streaming.

Performance Evaluation and Results

In order to evaluate our system a set of measurements was conducted to get enough information about the performance of the system. The video used for the measurement is available in 7 quality levels: (176445, 261338, 343010, 455590, 657249, 955928 and 1370929) bit/s and consists of 200 segments. The duration of the video is 6 minutes and 30 seconds.

Scenarios

Three scenarios were considered. In each scenario 3 computers and one server were used and settings of scenarios were made by changing the upload bandwidths of each of the Peers or Server with help of the traffic shaping application. The download Bandwidths remained unchanged by all computers and the server. Scenarios were chosen in such way, so we can see the performance of the system with edge settings. For each scenario 100 measurements were conducted in both P2P and NO_P2P mode.

Evaluation Metrics

As decided in the beginning of the project for evaluation metric the mean video quality was chosen. According to this metric, the project will be successful if the P2P logic provides better mean video then the case when no P2P logic is used.
Additionally another evaluation metric was chosen to evaluate the fairness among the peers, i.e. if all peers get the same video quality or some get much better than the others.

Results

Global mean video quality
The global mean video quality gives the global overview of our System. This is the mean video quality averaged over everything it could be averaged (over all measurements, over all peers, over all scenarios). This metric showed that the P2P logic performed better than the NO_P2P logic. The improvement in the mean video quality introduced with the P2P logic was about 35%.
The 95% confidence interval was also calculated and its value relative to the mean value was approximately zero, which means that these mean values are reliable.
On the figure the standard deviation for both mean values is also plotted, and it can be concluded that the set of P2P mean values is less variable then the set of NO_P2P set of values.

Mean bitrate all measurements with standard deviation
Lupe

Fairness
In order to evaluate the fairness among the peers, i.e. if all peers get the same video quality or some get much better than the others, the “mean distance” metric was chosen. The “distance” is the difference between the maximum and the minimum mean video quality of all peers. On the end the average value over all measurements is calculated. The smaller this mean distance is, the greater the fairness.
The figure shows the mean distance with the confidence interval. It can be seen that in the first scenario there is high fairness in both P2P and NO_P2P modes. In the second and third scenario the P2P mode is more fair then the NO_P2P mode. In the second scenario we are 95% confident (according to the confidence interval) that P2P is fairer then NO_P2P and in the third scenario we are 95% confident that the NO_P2P logic cannot be more fair then the P2P logic.

Unfairness with CI
Lupe

Conclusion

The overall conclusion is that the goal of this project was achieved and the P2P logic performs better than the NO_P2P logic i.e. provides better mean video quality and is fairer for the users.
For detailed description for each scenario and more details about evaluation results per scenario see the documentation.

Zusatzinformationen / Extras

Quick Access:

Schnellnavigation zur Seite über Nummerneingabe

Auxiliary Functions

Participants

Benjamin Barth
Farid Rosli
Jasminka Serafimoska

Advisor