Using P2P Technologies for Providing Video

Streaming
Călin-Andrei Burloiu
Scientific Advisor: Nicolae T, ăpus,
Technical Advisor: Răzvan Deaconescu
Automatic Control and Computers Faculty
University Politehnica of Bucharest
Splaiul Independent, ei nr. 313, Bucharest, Romania
calin.burloiu@cti.pub.ro, {razvan.deaconescu, nicolae.tapus}@cs.pub.ro
February 8, 2011

Abstract
The continuous advance of Peer-to-Peer systems during the last decade has
sparked numerous extensions and scientific and research interests. Numerous over-
lays, social networking facilities, moderation techniques, anonymity are just of few
of the topics that ignite the interest of various scientific entities.
A specialized topic is the introduction of video-streaming in Peer-to-Peer proto-
cols, both video on demand (VoD) and live streaming. Streaming in Peer-to-Peer
bandwidth promises to use potentially unused bandwidth, remove bottlenecks and
improve user experience. Projects such as P2P-Next address the issue of building a
sustainable next-generation content delivery system.
Our work deals with usability and performance issues when deploying video
streaming on top of a Peer-to-Peer video streaming solution part of the P2P-Next
project, dubbed NextShare.

1 Introduction
1.1 Objectives and Motivation
P2P-Next is a consortium of industrial and academic players which aims to build by its
projects the next generation Peer-to-Peer (P2P ) content delivery platform [10]. It involves
21 partners from 12 different countries like BBC, Technische Universiteit Delft, Pioneer,
Technical Research Centre of Finland and also University Politehnica of Bucharest. P2P-
Next takes as design principals the usage of open standards, open source development
and future proof iterative integration.
The research and implementation of this project is motivated by the increasing need
of multimedia content for Internet users. The television is no longer the main medium
for audio and visual information content. New technologies built over the Internet for
computers and mobile devices are increasingly advancing. The current Internet infras-
tructure was not initially designed for simultaneous transmission of live events to millions

1
of people and proposed technologies like multicasting do not seem to resolve the problem.
That is why P2P-Next decided to develop a new multimedia infrastructure based on P2P
technologies like BitTorrent. As a result of the projects developed by the consortium,
the users are going to share multimedia content and live streams more easily, in a more
scalable infrastructure, by using web-based technologies, IP-TV, video-on-demand, social
networks and many more personalized tools.
The reference platform of content distribution developed by P2P-Next is named NextShare,
which enables services for both PCs and digital set-top-boxes (STB ), usable with TVs.
Among the basic services and features are live video and on-demand video available online
with an interactive experience and with most of the content being free.

1.2 Activities
Through the Automatic Control and Computers Faculty, University Politehnica of Bucharest
(UPB) provides a Living Lab for the P2P-Next, among others from Slovenia, Norway,
UK and Finland. The purpose of it is to offer early access to the technologies developed by
the consortium and to receive feedback from users determined to test the infrastructure.
The UPB Living Lab from Romania provides high speed access to Peer-to-Peer technology-
enabled content through 10 systems kindly provided by the NCIT cluster. The users
determined to test the NextShare infrastructure use as an interface to the Living Lab,
the UPB Living Lab trial site [13], p2p-next.cs.pub.ro, where video content is offered for
distribution and occasionally live streams. Through the feedback form, the users are giv-
ing valuable information about the problems and issues of the technology which is under
development.
Being part of the Living Lab team we are testing the NextShare technologies and
components with various parameters and comparing them with other related technologies
in matters of performance, usability and reliability. An important activity in Living Lab
is analyzing users’ feedback in order to diagnose the issues of NextShare and to report
them to the design and developing team from P2P-Next.
Processing video in order to give users the best quality-performance ratio is an activity
which involves a lot of documentation and experimentation with video streaming, video
containers, codecs and tools.
NextShare core technologies testing is made up on the P2P Testing Infrastructure [16],
which runs peers, seeders and trackers on our cluster. The reports generated by the tools
contain performance information which can be used to improve NextShare.

1.3 Keywords
Peer-to-peer or P2P is a distributed networking application architecture that partitions
tasks between peers, which are participants with the same role in the application, being
equally privileged and equipotent [11].
BitTorrent is a peer-to-peer file sharing protocol used for distributing large amounts
of data. In a BitTorrent system, a peer is typically a computer program that is actively
participating in sharing a file in the network. The context in which a BitTorrent content
distribution session takes place is defined by a BitTorrent swarm which is the peer en-
semble that participate in sharing a given file. A swarm consists of two types of peers:
leechers and seeders. A seeder is a peer that has complete access to the distributed con-
tent and is, thus, only uploading data. A leecher has incomplete access to distributed

2
content and is both uploading and downloading. The BitTorrent negotiation protocol
uses a form of tit-for-tat that forces peers to upload in order to download (though this
has been proven to be abused [17]) therefore ensuring fairness and rapid distribution. A
swarm is given birth by an initial seeder which is the peer sharing a file it has complete
access to. The seeding/sharing process within a swarm is started through a metafile, a
.torrent file, that defines swarm trackers and piece hashes to ensure content integrity.
Typically, a peer uses a web server to download a .torrent file and then uses a BitTorrent
client to interpret it and take part into a swarm.
NextShare technologies use BitTorrent because of its efficiency that made it one of
the most popular protocols for transferring large amounts of data. It is estimated that in
2009 it was responsible with roughly 27% to 55% of all Internet traffic [15].
Classical BitTorrent protocol uses TCP for the communication between peers. µTorrent
developed a more appropriate protocol for this purpose over UDP, named µTP (Micro
Transport Protocol ), sometimes spelled uTP. Although the source code of its library was
published, it is still a proprietary protocol, thus as a response, P2P-Next designed the
swift protocol. In Section 5 more details are going to be given about this two protocols.
Typical terms for video handling like container, codec, frame rate, resolution and
aspect ratio are going to be explained in Section 4. Also, details about the technologies,
compression standards and libraries are going to be given in the same section.

2 Related Work
Video content is currently the dominating force in Internet traffic [15]. With BitTorrent
and HTTP traffic dominating the Internet backbone, video traffic accounts for a large
part of that. Video streaming, the possibility of viewing video content while downloading
is the type of traffic with the largest increase, due to the advance of popular services such
as YouTube or Google Videos. Other services such as Vimeo allow streaming of high
definition (HD) content.
Peer-to-Peer systems have begun incorporating streaming features since their incep-
tion. Protocol updates such as Give-to-Get [?] have been specially designed to cope with
the particularities of both video streaming and Peer-to-Peer protocols. Multicast trees, se-
quential reordering and other features have been deployed to allow Peer-to-Peer protocols
to incorporate video streaming.
Streaming may refer to other Video-on-Demand (VoD) or Live Streaming. Video-
on-Demand refers to downloading and playing an existing video file. The entire file is
stored on the host system. Clients will prioritize pieces that are closer to the current
position but still request files that will be accessed later on. The existence of a Peer-to-
Peer network for video streaming allows efficient use of existing bandwidth and increases
scalability. Live Streaming is distribution of live content, that is content generated in
real-time. The requirements for this kind of streaming are more stringent as it requires
rapid transmisition (low delay) of data that is generated in real-time and there is no
“future” pieces that may be collected. Live streaming solutions have been incorporated
in the recent years. Magharei et. al [18] have provided a study of the advantages and
disadvantages of using meshes or multi-trees for live streaming.
This work is integrated in the EU FP7 P2P-Next project [10]. P2P-Next’s stated goal
is building the next generation Peer-to-Peer content delivery platform. The core of the
project is the NextShare core, which is an updated and extended BitTorrent implementa-
tion with incorporated streaming support. The actual implementations, running on top

3
of the core are the NextShareTV implementation, deployed set-top boxes (STBs) and
NextSharePC for general use on commodity hardware. NextShareTV is distributed as
firmware for specific STBs, while NextSharePC is usable as a stand-alone player or as a
browser plugin, also dubbed NextShare Plugin or SwarmPlugin. The NextShare techology
has also been incorporated in several Wikipedia experiments [12].
One of the most well known streaming platform using P2P technology is Octoshape [9].
Octoshape is used for delivery of HD content and has been used for several important
video events such as the US Election 2008 and the Eurovision Song Contest since 2006.
Akamai Technologies, an imporant CDN (Content Delivery Network) has also developed
interest in using P2P technology for their clients [2].
Adobe has also improved its Flash technology with Peer-to-Peer support, in the form of
Adobe Cirrus or Adobe LiveCycle Collaboration Service [1]. With YouTube responsible
for a large chunk of streaming traffic in the Internet and Flash player being the core
technology it is expected that the P2P features of Flash will be deployed and usable in
the recent future.

3 Infrastructure
The current infrastructure is the actual Living Lab that is used as part of the WP8
package in P2P-Next. It consists of commodity hardware systems running in the NCIT
Cluster [8]. The hardware systems run seeders, trackers and store video and .torrent files.
The Living Lab site allows interaction with users.
The UPB Living Lab [13] site consists of a CMS Made Simple installation that has been
updated to accomodate the NextShare plugin, allowing users to render P2P technology
enabled video streams in a browser.

3.1 Hardware Infrastructure

We are using 10 commodity hardware systems in the NCIT cluster. These systems have
been suitable for our needs, but we plan to make a switch to a KVM-based infrastructure
due to the flexibility it offers and the improved availability. Each system consists of the
following hardware components:

• SATA hard-disk, 300GB

• Intel Pentium 4 CPU 3.00GHz (dual-core)

• 2GB RAM

• two 1Gbit Ethernet interfaces

All connections are 1Gbit connections with Internet hosts as provided by the RoE-
duNet infrastructure.
All systems are running the same operating system and basic application:

• Debian GNU/Linux 5.0 Lenny

• kernel: 2.6.26-2-openvz-amd64

• gcc 4.3.2

4
 • OpenSSH 5.1p1

Apart from updating video content, an important step we plan to undertake with
respect to the infrastructure is move it to a KVM-based environment on in the NCIT
cluster. The use of the current infrastructure for different experiments means we lack the
running continuity required for a presenting a service-like platform. The migration to a
KVM-based infrastructure will ensure dedicated resilient systems and proper availability.

3.2 Software Infrastructure

The software infrastructure consists of the basic files and applications required for pro-
viding content: publishing site, trackers, .torrent files and running clients (seeders).
The publishing site is the UPB Living Lab site allowing access to the NextShare plugin
and video files.
A tracker is required for all video content to be served. Video content is embedded in
.torrent files – metafiles used by the BitTorrent protocol. Seeders are usually NextShare
implementations running on top of the hardware infrastructure. As they need to be
running in background they are usually started with the help of the nohup command. A
script that may be used for deploying .torrent files as seeders is the shown below:
#!/bin/bash

torrent_dir=/home/p2p/p2p-video-trial

pushd "$torrent_dir"
nohup btlaunchmany . >> btlaunchmany.log 2>&1 &
popd

4 Multimedia
4.1 Keywords
An audio-video container file is used to identify and interleave different multimedia data
types, usually storing different audio, video and subtitle streams. One of the most popular
containers is AVI (Audio Video Interleave), which was introduced by Microsoft and can
may carry audio/visual data in virtually any compression scheme. MP4 is MPEG-4 Part
14, a multimedia container format standard, specified as a part of MPEG-4 and should
not be confused with MPEG-4. Ogg is a free, open standard container format maintained
by the Xiph.Org Foundation. The creators of the Ogg format state that it is unrestricted
by software patents and is designed to provide for efficient streaming and manipulation
of high quality digital multimedia. In the Ogg multimedia framework, Theora provides
a lossy video layer. The audio layer is most commonly provided by the music-oriented
Vorbis format but other options include the human speech compression codec Speex, the
lossless audio compression codec FLAC, and OggPCM. The new HTML5 standard, which
is still published as a draft includes native video support, without any third-party plug-ins,
for OGG and WebM containers. Google is sponsoring the WebM format which consists
of VP8 video and Vorbis audio streams.
To digitally represent audio signals, Pulse-code modulation (PCM) is used. The
magnitude of the analogue signal is sampled regularly at uniform intervals, with each
sample being quantized to the nearest value within a range of digital steps. A digital
audio stream is characterized by sampling rate (sampling frequency), which is the

5
number of times per second that samples are taken, and by bit depth, the number of
possible digital values that each sample can take. A standard audio stream, used also for
audio CDs, has a sampling rate of 44.1 kHz with 16 bits per sample.
Video streams are usually characterized by the frame rate, display resolution and bits
per pixel. The frame rate or frame frequency (frames per second abbreviated as
fps) is the number of still pictures per second for video. Typical values for this char-
acteristic are between 25 and 30 fps. The display resolution is the size of a video
image, which is measured in pixels for digital video, or horizontal scan lines and vertical
lines of resolution for analog video. Pixel aspect ratio (often abbreviated PAR) is a
mathematical ratio that describes how the width of a pixel in a digital image compares to
the height of that pixel. The aspect ratio or display aspect ratio (often abbreviated
DAR) of an image is the ratio of the width of the image to its height, expressed as two
numbers separated by a colon. The number of distinct colors that can be represented by
a pixel depends on the number of bits per pixel (bpp), also known as color depth.
Typically there are used 24 bits per pixel with 8 bits for each color component (red, green
and blue), achieving more than 16 million colors. There is an extension of this color depth
for images with 32 bits per pixel, which adds 8 extra bits for the alpha channel, which
sets pixel’s opacity. PNG images use this feature.
Video can be interlaced or progressive. Interlacing was invented as a way to achieve
good visual quality within the limitations of a narrow bandwidth. The horizontal scan
lines of each interlaced frame are numbered consecutively and partitioned into two fields:
the odd field (upper field) consisting of the odd-numbered lines and the even field (lower
field) consisting of the even-numbered lines. NTSC, PAL and SECAM are interlaced
formats. Abbreviated video resolution specifications often include an i to indicate inter-
lacing. For example, PAL video format is often specified as 576i50, where 576 indicates
the vertical line resolution, i indicates interlacing, and 50 indicates 50 fields (half-frames)
per second. Progressive or noninterlaced scanning is a method for displaying, storing
or transmitting moving images in which all the lines of each frame are drawn in sequence.
For this kind of scanning, the video resolution may include a p, like 1080p, which means
that there are 1080 pixels on the height scanned progressively.
Recently the television image quality was extended in order to take advantage of the
technological progress. The old television quality standard, including PAL (for Europe)
and NTSC (for America) are now known as Standard-Definition television (SD or
SDTV). It is usually used when broadcasting at the same (or similar) resolution as analog
systems, with an aspect ratio of 4:3 and a resolution of 480i (NTSC) or 576i (PAL).
The newer extended quality standard is known as High-definition television (HD
or HDTV) and refers to video having resolution substantially higher than traditional
television systems. HDTV is usually specified as 720p/720i (HD), with a resolution of
1280x720, or as 1080p/1080i (Full HD), with 1920x1080. The aspect ratio is typically
16:9 for TVs, but computer monitors usually use 16:10 (8:5).
A codec is a computer program, usually a library, or a device which can encode
or decode a digital data stream. There are lossless codecs which reduce the stream size
without discarding information and lossy codec, which alter the quality in order to achieve
a smaller size. MPEG-4 is a collection of methods defining compression of audio and
visual (AV) digital data, in a set of standards developed by ISO/IEC. MPEG-4 Part
2 (Visual) includes lossy codecs such as DivX, Xvid, Quicktime 6, Nero Digital and
it is compatible with H.263. H.264/MPEG-4 Part 10 or AVC (Advanced Video
Coding) is a more performant video lossy compression standard from MPEG-4. HTML5

6
currently supports two open video lossy compression formats: Theora, developed by the
Xiph.Org Foundation and VP8, released by Google. For the audio layer, Vorbis is used
by HTML5, which is also developed by Xiph.Org Foundation. The most popular audio
lossy codec used today is MP3 (MPEG-1 or MPEG-2 Audio Layer 3 ). AAC (Advanced
Audio Coding), released under MPEG-4 Part 14, was designed to be the succesor of the
MP3 format, generally achieving better sound quality at similar bit rates.
An audio/video stream is also characterized by its bit rate, which is the number of
bits necessary for coding one unit of time (second) of a stream. Some codecs support a
variable bit rate.

4.2 Audio-Video Conversion

All audio-video handling that we have made was realized under the Linux environment,
using command line tools, that offer the opportunity of integrating them into scripts for
automation.
For UPB Living Lab we are using as input videos from technical presentations, courses,
conferences and social events from our university. They were shot with a Full HD camera,
specified as 1080i. Although the resolution is 1440x1080, which defines an aspect ratio of
4:3, the real aspect ratio is actually 16:9 because this is the PAR (pixel aspect ratio). The
raw movie stream loaded from the camera is packed into a .mts multimedia container,
which is based on the MPEG-2 Transport Stream container format. The audio stream has
an AC-3 (Audio Coding 3, Dolby Digital) format, which permits the coding of 6 surround
channels, with a sampling rate of 48 kHz (higher than the CD one, which is 44,1 kHz).
The video stream has an H.264/AVC format, with low compression and a frame rate of
25 fps. The overall bit rate of the raw stream is 3982 kilobits per second, which is quite
big, thus it needs compression in order to distribute the content over the Internet. Also,
some of the movies need to be cut into peaces and others need to be joined together.
An useful command line tool that retrieves information about an audio/video file is
mediainfo, from MediaInfo project [7]. It prints to the console all the information
needed about the container, the audio stream and the video stream, like bit rate, format,
duration, display resolution, aspect ratio, scan type, frame rate, audio sampling rate and
bit rate etc.
We have made most of the multimedia handling with FFmpeg [4], a free open source
project that produces libraries and programs for handling multimedia data. It uses two im-
portant libraries, libavcodec, an audio/video codec library used by several other projects
and libavformat, an audio/video container multiplexer and demultiplexer library. The
command line program used for transcoding that offers an interface to all of this compo-
nents is ffmpeg.
UPB Living Lab trial site plays the videos with P2P-Next’s plugin NextShare Plugin,
which is going to be detailed in Section 5. Because it uses VLC Player for rendering
movies, a lot of audio/video formats can be used. We have mainly used as container
AVI, OGG, WebM and MP4. Video streams were coded using H.264/AVC, Theora and
Google’s VP8. Audio is coded as MP3, with the exception of the files which used OGG
and WebM as container, which included Vorbis format, in order to test the video files also
with HTML5.
During the transcoding, we needed to alter the display resolution from 1440x1080 to
800x600 for example. We also had to change the audio sampling rate from the professional
48 kHz to the standard 44,1 kHz.

7
 The conversion to different kind of containers and audio/video formats is made by
ffmpeg with the aid of libraries. Video format H.264/AVC needs for coding the library
libx264, Theora needs libtheora and VP8, libvpx. For audio coding libmp3lame is needed
for MP3 format and libvorbis, for Vorbis.
The following line is an example of transcoding a raw .mts file taken from the camera
to an AVI audio/video file, including an MP3 audio stream and an H.264/AVC video
stream:

ffmpeg -i in.mts -f avi -acodec libmp3lame -ab 256k -ar 44100 -ac 2
-vcodec libx264 -vpre normal -b 1400k -r 25 -threads 0 out.avi

Argument -i establishes the input in.mts file, while the last argument is the output
out.avi file. AVI container format is set with -f parameter, MP3 audio coder with -acodec,
which selects libmp3lame library. The video coder is set with -vcodec, that set libx264
library. The bit rates for audio and video are set respectively with -ab and -b. The audio
needs to be resampled from 48 kHz to 44,1 kHz, with -ar 44100 and the 6 surround
channels need to be mapped to two stereo channels, -ac 2. The video frate rate is set to
25 (remains the same) with -r 25.
We have written a series of scripts to automate the process of conversion, including
ones which automatically transcodes all our video raw files to specific formats required
for testing.

5 Technologies
5.1 Keywords
P2P-Next’s NextShare platform implements its core functionality into NextShareCore,
that is written in Python scripting language. Thus, a PC or STB needs a Python
interpreter.
As it was said in the introduction of this article, NextShare uses BitTorrent P2P
technology, which is integrated into NextShareCore.
Instead of using a TCP connection between peers, like in the classical BitTorrent
implementation, NextShare uses swift. Similar to swift is µTP or uTP, developed by
µTorrent. They recently published the source code of its library, so that other BitTorrent
clients could implement it. However the is still under their’s license, thus P2P-Next, which
uses free and open-source code, decided to create swift protocol. Both swift and µTP are
implemented over UDP transport protocol.
µTP is designed to provide reliable, ordered delivery while maintaining minimum
extra delay, aiming to provide a better performance that the more general TCP protocol.
It is actually a TCP-like implementation of LEDBAT (Low Extra Delay Background
Transport) [6], documented as a BitTorrent extension of BEP-29 [3]. The LEDBAT scope
is to standardize a congestion control mechanism that should saturate the bottleneck,
maintain low delay, and yield to standard TCP. µTP is the primary transport for µTorrent
P2P connections.
Swift, the multiparty transport protocol is also known as BitTorrent at the transport
layer. Like µTP, it does not use the ordered data stream abstraction, used in TCP. A
peer splits files into 1KB packets and sends them to the other peer, using Merkle hash
trees and binmaps.

8
 The video rendering in a PC browser using NextShare can be done with two types of
plugins. SwarmPlugin uses VLC Player libraries to render the video and SwarmPlayer
uses HTML5 for that.
W3C (The World Wide Web Consortium) is working to a new HTML standard, known
as HTML5 [5], which extends the facilities of HTML4 and XHTML. One of its purposes
is also to integrate native video support into HTML, without the need of RIA (Rich
Internet Application) plugins, such as Adobe Flash Player, Microsoft Silverlight or Oracle
JavaFX. The current HTML5 draft specification [5], does not specify the video formats
the browsers should support, however the HTML5 Working Group consider it desirable
to specify at least one video format which all browsers should support. Internet Explorer
does not support HTML5 yet, but the other popular browsers, Mozilla Firefox, Google
Chrome and Opera support it. The current playable formats via HTML5 are Ogg Theora,
with Theora video and Vorbis audio, and Google’s WebM which includes VP8 video and
Vorbis audio.
So the lack of support for HTML5 in Internet Explorer and the fact that HTML5 is
still a draft specification, determined P2P-Next to implement NextShare into browsers
also with VLC, not only with HTML5.
VLC media player [14], written by the VideoLAN project is a free and open source
cross-platform multimedia player and framework. SwarmPlugin uses its libraries to render
video currently in Internet Explorer or Mozilla Firefox, but only under Windows. The
big advantage is the fact that a lot of audio-video formats are supported. Basically, all
formats supported by VLC media player are also supported in the SwarmPlugin.
On the other hand, SwarmPlayer uses HTML5 for rendering, so only Ogg Theora
and WebM are supported. SwarmPlayer was previously known as SwarmTransport. In
Figure 1 the architecture of the SwarmTransport is presented. Components in yellow
are implemented in Python, components in red are implemented in C or C++, and
components in green are implemented in JavaScript. The SwarmTransport consists of
two major parts: the browser plugin itself, running in the browser’s address space, shown
on the right in Figure 1, and the Next Share Agent (NSSA) running on Python, shown
on the left in Figure 1.

5.2 Technologies Evaluation

The Living Lab site [13] links various video files that may be played back through the
NextSharePlugin. Video files have a variable length from 3 to 30 minutes from social
events and technical presentation in the local university. Some of them are in HD and
others, used for testing and evaluation have 800x600 resolution. During the last two
months multiple events have been filmed and will be published through the local Living
Lab portal. The site links the most recent version of the SwarmPlugin (Internet Explorer
and Firefox) for user download.
We have taken a medium-sized user-centric experiment for evaluating the NextShare
technology and user satisfaction described in Section 6. The Living Lab site was the center
of the experiment: it provided the interface for downloading the SwarmPlugin, linking
video files, publishing the feedback form and providing support through the forum.
As playback problems were encountered during the user-centric experiment we decided
to focus our efforts on analysing video playback when dealing with different files both in a
standalone player and in the NextSharePlugin. Having direct access to the original .mts
files, we converted them to different formats (containers and codecs) and observe their

9
 Figure 1: Architecture of the SwarmTransport

behavior. As somewhat expected, there were issues with playback both in the VLC player
and the SwarmPlugin, as decribed in the Table 1. We used ffmpeg and related tools and
tested H.264 and Theora codecs on AVI, MTS and OGG containers.
All tests described as lines in Table 1, have been made on video files transcoded from
the same original .mts file, which has 46 minutes. A part of the transcoded files are cut,
in order to have a smaller duration. We varied the bit rate using 1400 kbps, 1050 kbps,
700 kbps and 350 kbps, the display resolution using 1440x1080 (Full HD) and 800x600
(roughly SD quality). Some of the file were transcoded with 30 fps, instead of 25 fps.
The last characteristic variated was the format. The videos marked as AVI, contain MP3
audio and H.264/AVC video. Those with an Ogg container include Vorbis audio and
Theora video and WebM, contain VP8 video and Vorbis audio. All file have a 256 kbps
for the audio stream.
As it can be observed from table, both VLC media player and SwarmPlugin could not
play videos with 30 fps. For files with 25 fps the playback worked in VLC media player
both in Windows and Linux, but with SwarmPlugin worked just for videos with a frame
rate below and including 700 kbps. Although this could be a good bit rate for standard
definition videos, for full high definition it is not satisfiable.
At this point, our conclusion is that the SwarmPlugin has issues with the bitrate. As
can be seen, a high enough bitrate means the video doesn’t work. Some of the time (non-
deterministic) playback in VLC would also not work. There may be something wrong
with our video files but the plugin definitively has its problems.
We will do more testing to investigate whether the bitrate is solely responsible for
this issue and whether that is because of the NextShare plugin implementation, the VLC
implementation or the video file format (codec, container).
Due to our discovery of problems regarding bitrate variation influencing quality (or
functionality) of video playback, we are considering the possibility of providing the end
user with multiple versions of the same video file: different resolution, different bitrate,

10
 Duration Bitrate Resolution Framerate Format Plugin VLC VLC
(minutes) (kbps) (fps) (Win) (Win) (Lin)
3 350 800x600 25 AVI Yes Yes Yes
3 350 800x600 25 OGG Yes Yes Yes
3 700 800x600 25 AVI Yes Yes Yes
3 700 1440x1080 25 AVI Yes Yes Yes
3 1050 800x600 25 AVI No Yes Yes
3 1050 1440x1080 25 AVI No Yes Yes
3 1400 800x600 25 AVI No Yes Yes
3 1400 800x600 25 OGG No Yes Yes
3 1400 1440x1080 25 AVI No Yes Yes
3 1400 1440x1080 25 OGG No Yes Yes
3 3857 1440x1080 25 MTS N/A Yes Yes
46 1400 1440x1080 25 AVI No Yes Yes
46 1400 1440x1080 25 OGG No Yes Yes
5 1400 1440x1080 30 AVI No No No
5 1400 1440x1080 30 OGG No Yes Yes
5 1400 1440x1080 30 WebM doesn’t start Yes Yes
5 3857 1440x1080 25 MTS No Yes Yes

Table 1: Video Files Testing

different codec, different container. That would imply some disparate statistics but may
provide the user with better quality of experience when using a “less demanding” video
file.

6 User-centric Experiments
During December (30th of November to 20th of December) we have undertaken a medium-
sized experiment for evaluating the NextShare technology and user satisfaction. The
Living Lab site was the center of the experiment: it provided the interface for download
the NextShare plugin, linking video files, publishing the feedback form and providing
support through the forum.
Users were mostly students at the University Politehnica of Bucharest.
In order to collect information regarding the problems we enabled an FTP upload
form to allow users to provide us their log files.

6.1 Experimental Setup

The experiment used the infrastructure described in Section 3.
The Living Lab site links various video files that may be played back through the
NextShare plugin. Video files are HD files with variable length (3 to 30 minutes) from
social events and technical presentation in the local university. During the last two months
multiple events have been filmed and will be published through the local Living Lab portal.
The site links recent version of the NextShare plugin (Internet Explorer and Firefox) for
user download.

11
 Video files are HD content. They are encoded using H264 and use the AVI container.
Each file is incorporated into a .torrent file and provided to users on the Living Lab
site.
Users were also allowed to access a support forum where we could provide them with
answers and suggestions.

6.2 Experimental Results

A total number of 54 users completed the feedback form. The feedback consisted of the
following questions:

1. Did you have any problems during the installation?

2. Did you successfully install the SwarmPlugin?

3. In case of problems, what were the issues you encountered?

4. How would you classify the quality of the video playback?

5. How would you classify the plugin’s interface?

6. What was the average download speed?

7. What OS are you running?

8. What browser did you use for testing the SwarmPlugin?

9. What version of the browser are you running?

10. What are your computer hardware specifications?

11. What is your external IP network address?

12. What videos did you watch?

13. Do you have any comments, remarks or suggestions?

A brief of the results in the feedback:

• 13 users had problems installing the plugin and most of them were unable to properly
start the playback;

• video playback was deemed mediocre (a score of 2.4 out of 5); some may be due to
the problems in installing the plugin;

• the plugin interface

• most users used the Firefox version of the Plugin;

• users were using high bandwidth connections (> 512KB/s) or fairly good ones (>
50KB/s, < 100KB/s);

• video freezing and the lack of a seek and volume bar were among the most significant
remarks.

12
 The most important issues were problems during the installation and poor video play-
back (freezing).
A similar experiment would need to provide proper video content (if the problem is
from video files), a properly working version of the NextShare plugin and a seek bar on
the playback interface. As such, the most stringent issue deals with playback problems
in the NextShare player for a diversity of video files. Through the video testing we have
discovered that, past a certain bitrate threshold, video playback in the NextShare plugin
is either flawed (freezes) or not functional.

7 Conclusion and Future Work

We have presented our work regarding video streaming and performance evaluation using
Peer-to-Peer technology. With major Internet content providers such as Akamai, Oc-
toshare and Adobe Flash Player considering the use of Peer-to-Peer technology and as
part of the P2P-Next project.
We have investigated the diversity of characteristics of video files and the deployment
of video files in the UPB Living Lab site. The site uses P2P-Next’s NextShare technology
in the form of a browser plugin. During both test and live trials we have collected
information regarding technical aspects of the implementation and user experience. We
have pulled out several issues which we are going to address in the next period.
Our current goals revolve around the generic objective of providing feedback and
bug reports, measure user satisfaction and promote NextShare technology and the
particular objective and comparing classical P2P/BitTorrent distribution against P2P-
based video streaming, such as provided by NextShare.
We aim to use status information such as peer download speed, peer upload speed,
number of connections and extensive information (usually provided through verbose log-
ging) such as protocol messages, protcol inner workings, piece picker algorithm (piece
selection) to compare and analyse classical (pure BitTorrent-based data distribution) to
video streaming (through NextShare technology). We aim to distinguish among the var-
ious patterns employed by each type of distribution, measuring variation/penalty in per-
formance and identify weak and strong spots in each of the approaches.
There are two kinds of experiments we are considering:
1. public experiments: designed to run “in the wild”, using the Living Lab site and
requesting feedback from users;
2. lab experiments: designed to run in a closed environment at University Po-
litehnica of Bucharest, with the ability to be fully under the control of the ex-
perimenter.

References
[1] Adobe P2P. http://www.adobe.com/devnet/flashmediaserver/articles/p2p apps cir-
rus lccs.html.
[2] Akamai. http://seekingalpha.com/article/127949-akamai-technologies-getting-
serious-about-p2p.
[3] BEP-29. http://www.bittorrent.org/beps/bep 0029.html.

13
 [4] FFmpeg. http://www.ffmpeg.org/.

[5] HTML5 Draft Specification. http://dev.w3.org/html5/spec/Overview.html.

[6] LEDBAT (Low Extra Delay Background Transport).

http://datatracker.ietf.org/wg/ledbat/charter/.

[7] MediaInfo. http://mediainfo.sourceforge.net/.

[8] NCIT Cluster. http://cluster.ncit.pub.ro/.

[9] Octoshape. http://octoshape.com/.

[10] P2P-Next. http://www.p2p-next.org/.

[11] Peer-to-Peer. http://en.wikipedia.org/wiki/Peer-to-peer.

[12] Tribler on Wikipedia.

[13] UPB Living Lab Site. http://p2p-next.cs.pub.ro/.

[14] VLC media player. http://www.videolan.org/vlc/.

[15] ipoque Internet studies. http://www.ipoque.com/resources/internet-

studies/internet-study-2008 2009, 2009.

[16] R. Deaconescu, G. Milescu, B. Aurelian, R. Rughinis, , and N. T, ăpus, . A Virtual-

ized Infrastructure for Automated BitTorrent Performance Testing and Evaluation.
Internation Journal on Advances in Systems and Measurements, 2(2&3):236–247,
2009.

[17] T. Locher, P. Moor, S. Schmid, and R. Wattenhofer. Free Riding in BitTorrent is

Cheap. HotNets, 2006.

[18] N. Magharei and R. Rejaie. Mesh or multiple-tree: A comparative study of live

p2p streaming approaches. In in INFOCOM 2007, Anchorage, Alaska,6-12, pages
1424–1432, 2007.

14