P2P-Tube: A Video Sharing Web Platform Basedon Next-Share Technology

Calin-Andrei BurloiuAutomatic Control and Computers Faculty

University Politehnica of BucharestEmails: calin.burloiu@gmail.com

Abstract—In this paper we propose P2P-Tube, a video sharingweb platform, similar with YouTube, which uses Next-Share,a video sharing technology developed within European projectP2P-Next. This project’s goal is to build the next generationpeer-to-peer content delivery platform. Next-Share is based ontwo browser plugins which provide video-on-demand and livestreaming through BitTorrent peer-to-peer protocols. Users areable to retrieve video content not only from a number of deliveryservers, which assume the role of seeders, but also concomitantlyfrom other users, which are leechers.

Index Terms—Video-On-Demand, NextShare, P2P-Next

I. INTRODUCTION

Part of our work at the European project P2P-Next [9]is P2P-Tube, a web platform which aims to be a com-plete solution for video sharing, video-on-demand and livestreaming through Next-Share [8] content delivery platform.Users are able to watch videos through one of the twoNext-Share browser plugins, one based on HTML5 and theother based on VLC [14]. They can sign up for an accountusing three different ways of authentication: internal P2P-Tubeauthentication, authentication through LDAP [16] or throughOpenID [18], using a third-party account. Logged in userscan share their thoughts by uploading new video assets. Socialinteraction between them is possible through the possibility ofcommenting each other’s videos and voting them with likesand dislikes.

In order to make P2P-Tube scale to a large amount of userswhich are concurrently uploading new video assets, we havedesigned a distributed system which uses one or more ContentIngestion Servers (CIS). Their role is to prepare uploadedvideos for sharing with other users and make those videosavailable on the platform. We have chosen web services as theway of communication between web servers, which deliverP2P-Tube application to the users, and Content IngestionServers.

Next-Share technology and plugins used in our platform arepresented in §II. P2P-Tube platform design architecture andimplementation are presented in §III and §IV, respectively. Wepropose future work in §V and conclude this article in §VI.

II. P2P-NEXT’S NEXT-SHARE TECHNOLOGY

P2P-Next is an FP7 European project made up by aconsortium of academic and industrial players which aim tobuild the next generation peer-to-peer (P2P) content delivery

platform. 21 partners from 12 different countries are involvedhere: BBC, Technische Universiteit Delft, Pioneer, TechnicalResearch Center of Finland and also University Politehnica ofBucharest, were P2P-Tube platform was developed. P2P-Nexttakes as design principals the usage of open standards, opensource development and future proof iterative integration.

In the last ten years two emerging trends sparkled the evo-lution of Internet: first of all more and more users share theircontent through social networks and P2P systems and secondlyvideo sharing, video-on-demand and live streaming are in-creasingly gaining popularity. The current Internet infrastruc-ture was not initially designed for simultaneous transmissionof live events to millions of people and proposed technologieslike multicasting do not seem to solve the problem. Televisionis no longer the main medium for audio and visual informationcontent. Motivated by all these facts, P2P-Next started researchand development of a new multimedia infrastructure based onboth P2P technologies like BitTorrent and video streaming.

Next-Share is the name of the content delivery technologyprovided by P2P-Next which enables features such as on-demand video and live video for both computers and STBs(digital set-top-boxes) usable with TVs. Its main advantageagainst a classical video streaming technology is that theoverhead of the video stream provider is diminished. Part ofthe computational and network resources are taken by eachconsuming peer from the system.

Next-Share platform implements its core functionality intoNextShareCore which is written in Python. Video rendering ina PC browser using Next-Share can be done with two typesof plugins: SwarmPlayer and NextSharePC.

A de facto standard today for playing videos in a browser isAdobe Flash Player. Because this is a proprietary technologyand P2P-Next uses open standards, other technologies neededto be explored. W3C (World Wide Web Consortium) currentlyworks at a new version of HTML, HTML5, which supports,besides other revolutionary features, audio and video tags.Thus video files can be easily embedded into web pages,just like images, without any browser extensions or plugins.Although HTML5 is still a draft, most modern browsersalready implement some of its features including video andaudio tags. On this background, non-profit organizations andbig corporations have engaged in a codec war. Some of theproblems were whether to accept or not proprietary codecs,which codecs should standardly accepted etc.. For instance

Microsoft promotes AVC / H.264, a proprietary video codec.Despite of its image quality and its good compression ratio,non-profit organizations criticized it for being proprietary andclosed standard. As a consequence Ogg containers with Vorbisaudio codec and Theora video codec were included intoHTML5. Google also stepped into this war and acquired On2Technologies, for VP8, an open video compression format.They proposed WebM containers with Vorbis audio compres-sion and VP8 video compression. Because Google’s proposalis a free open standard it was accepted into HTML5 alongwith Ogg (Vorbis + Theora). Currently most modern browserssupport video tags with Ogg and WebM containers.

P2P-Next developed SwarmPlayer, a Next-Share compliantbrowser plugin which is based on HTML5. It is currentlysupported in Windows in Mozilla Firefox as an extension andin Internet Explorer and there is also a Mac version.

Because only a few video formats are supported in HTML5and older browsers do not support HTML5 video tags P2P-Next developed another variant of its Next-Share plugin,named NextSharePC. This one is based on VLC Playerlibraries to render videos and is able to play a lot of videoformats, basically anything that is supported by VLC Player.Written by the VideoLAN project, VLC Media Player is a freeopen source cross-platform multimedia player and framework.Its disadvantage is that it is currently supported only inWindows, for both Mozilla Firefox, as a plugin, and InternetExplorer.

A NextShare plugin consists of two major parts: the browserplugin / extension, running in the browser address space andthe Next-Share Agent API which facilitates communicationwith the NextShareCore.

III. DESIGN OVERVIEW

Besides the need to incorporate Next-Share technologies,P2P-Tube was also designed to be useful to the users. Inthe next subsections the usability and technical needs thatgoverned our architecture are explained.

A. Design Principles

P2P-Tube platform has been designed with a few basicdesign principles in mind:

1) Provide as much as possible the features needed by sucha platform, as they appear on similar platforms from theweb.

2) Provide to users a familiar user interface which resem-bles similar platforms from the web.

3) Ensure that the platform scales well to a size of a fewthousands of users.

4) Ensure that the platform is general purpose.5) Make the platform available for free and distribute the

code as open-source, encouraging community contribu-tions.

Being developed in academia, in University Politehnica ofBucharest, P2P-Tube was designed to fit well to our needs. Thescalability requirements of a few thousands users, enumeratedin Principle 3 above is enough for our Faculty of Automatic

Control and Computers. However, despite this product wasdesigned in the academia and fits its needs, we ensure that itcan be generally purpose as stated in Principle 4 because of thefeatures incorporated and its user interface tied to Principles1 and 2.

B. Features

P2P-Tube provides to the users the following features:• Categories. Video assets can be grouped in categories

for a better organization of them.• Video plugin switching. If the user has installed both

Next-Share plugins (NextSharePC and SwarmPlayer) heis able to switch between them at any moment from thevideo watching page.

• Users and accounts. Users can apply for an account byregistering to the site. Throughout registration, severalfields can be completed, some of them mandatory, someof them optional, defining the user profile. Authenticationis possible through three methods: internal authentica-tion, LDAP authentication and OpenID authentication.

• Uploading video assets. Logged in users can upload newvideo assets to the site, which can be seen by others.

• Social interaction. Users can see each other’s profiles,comment each other’s video assets and vote them. Videoassets uploaded by an user can be explored.

• Searching. Video assets can be searched by keywordsand the results must be ordered by their relevance. Thesearch can be done in the whole set of videos or in aparticular category.

Internal authentication is for users that applied for anaccount by the Registration page. There are situations whenthe platform must be integrated with other services or sites.For example in our university we use P2P-Tube to share videosof technical presentations, courses or social events. We alsohave Moodle learning platform where students already have anaccount, so it was desired that users can authenticate on P2P-Tube with the same account credentials from Moodle. Thishas been achieved thorough LDAP which permits studentsto authenticate on both sites with the same user name andpassword, without requiring them to create an additionalaccount. Another way to make users skip signing up is byusing OpenID, a standard protocol which allows them tosign in through an account from another site. However, thisthird party site must support OpenID. So, for example, usersthat already have an account on Yahoo!, Google, Twitter orWordPress can securely sign in with the same user names andpasswords from that accounts. When users log in for the firsttime using external authentication, like LDAP or OpenID, theymust complete their profile.

Users can upload video assets through an upload mechanismdescribed in the next subsection.

C. Content Ingestion

NextSharePC can play any video format as long as VLCsupports it and SwarmPlayer supports only video containersand codecs which are compliant with HTML5. Most modern

browsers support videos having Ogg containers with Vorbisaudio compression and Theora video compression or WebMcontainers with Vorbis audio compression and VP8 videocompression. Users must be able to upload videos in aformat of their choice like MPEG, DivX or AVC/H.264.Thus, the platform must perform a conversion, also knownas transcoding, from an input user format to a NextSharecompliant format. P2P-Tube converts all video assets to videoswith Ogg containers and Vorbis+Theora compression in orderto be compatible with most modern browsers and to makevideo assets playable with any of the two NextShare plugins.However this can be changed from the platform configuration.

Besides video transcoding, several other operations must beperformed in order to make new video assets available on theplatform. This is done by a Content Ingestion Server (CIS)which is typically located on a different machine.

An user uploads a video file, referred here as raw video file,to a web server and may also provide additional informationabout it, like title, description, tags etc.. When video uploadis finished the process of content ingestion is started by theweb server by sending a content ingestion request to a CIS.This is done directly, if the system has a single CIS, orindirectly via a CIS Load Balancer (CIS-LB), which forwardsthe request to one CIS from a pool of several CIS machines.By doing load balancing, the indirect request method providesscalability because more content ingestion jobs can run inparallel, allowing more users to add content simultaneouslyto the platform. By these means availability is also increased,the system becoming fault tolerant in case of CIS failures.

Note that sending content ingestion requests is transparentfor the web server. There is no difference for it if this isdone directly to a CIS or indirectly through a CIS-LB. Thissimplifies implementation of the web server and hides theabstraction of content ingestion from it.

Figure 1. Content Ingestion Process

CIS operation through a CIS Load Balancer is describedin Figure 1. Until the end of this subsection, the numbers in

brackets refer to arrows from the figure. The web server sendsa content ingestion request to CIS-LB (1), which must choosethe least loaded CIS from the system. To do this it querieseach CIS for its load by sending a get load request (2) andestablishes by processing the answer which one is the leastloaded. The content ingestion request previously received isthen forwarded to the least loaded CIS (3), informing it aboutthe new video file that has been uploaded. The message alsocontains information about one or more formats in which thevideo must be converted referred here as destination formats.This information includes parameters for each format likeimage resolution, frame rate, audio quality etc.. The leastloaded CIS which received the request executes a job on theuploaded raw video file by doing the following operations:

• Transfers locally (4) the raw video file from the webserver.

• Transcodes (5) the raw video file to one or more desti-nation formats resulting transcoded video files.

• Extracts image thumbnails (6) from the raw video file.• Creates torrent files (7) (.tstream) for transcoded video

files.• Seeds (8) the transcoded video files by using the torrent

files previously created.• Transfers back (9) torrent files and image thumbnails to

the web server.• Notifies the Web Server about the job completion (10)

so that it can make the video accessible to the users.

In the end of the content ingestion process all other ContentIngestion Servers from the system must be aware of the newtorrent files in order to seed them. First of all, the new torrentfiles need to be locally accessible to them, so all torrentfiles can be shared by CIS machines on a distributed filesystem such as NFS, LustreFS or GlusterFS. The overhead ofusing shared storage between CIS machines shouldn’t affectperformance, even if NFS is used, which serves files througha single machine. This is because torrent files are very smallso concurrently accessing more files on the shared file systemcan affect performance in a negligible manner.

When the web server is notified about the job completion(10) a seed request must arrive to each CIS so that they canstart seeding the new torrent files available in the distributedfile system. This request is originated from the web server andthere is no need to do this on a single CIS system, becausethis is already done in step 8 from Figure 1, so the webserver can be configured to skip this redundant step from itsconfiguration. In a multiple CIS system this step is mandatoryfor ensuring high availability of the new video assets. Thus,a seed request is sent from web server to CIS-LB, whichforwards this message to all CIS from its jurisdiction. Uponreception they will start seeding requested torrent files whichare located in the distributed file system.

There may be situations when a seed request is lost bya CIS. For instance, a CIS is temporarily down or it hasa temporary network failure and does not receive a seedrequest from CIS-LB. After recovery it will not know about

the existence of new torrent files. This can lead to availabilityproblems, so to solve this a CIS periodically scans the torrentdirectory for new torrent files.

When a CIS daemon starts running it begins seeding alltorrent files from the distributed file system.

IV. IMPLEMENTATION

One of the basic design principles of our platform was topublish it as open-source encouraging community contribu-tions. To facilitate this we have chosen popular programminglanguages, frameworks and technologies in order to betterattract open-source communities around our platform. Thesedecisions along with implementation details are given in thissection. Information found here accompanied by commentsfrom the source code should hopefully provide enough infor-mation to a new contributor to this project.

Our implementation was designed to work on GNU/Linuxdistributions, so our back end dependencies, such as FFmpeg,has been chosen based on this. However we tried as muchas possible to choose them such that they also run on otheroperating systems, such as Windows. Thus, porting P2P-Tubefor them should be easy, but until this point creating a cross-platform implementation was not a priority for us.

Figure 2. UPB Living Lab Site – An Implementation of P2P-Tube

We are using P2P-Tube in our university for P2P-NextLiving Lab Site (see Figure 2) as a test bed for the Next-Sharetechnology.

A. Web Application Front End

The front end of P2P-Tube provides an interface with theusers of the platform. Today more and more applications aremigrating from a classical desktop interface to a web interface.For instance, applications like Microsoft Office started toappear on the cloud, providing a web interface; one popularexample is Google Docs. Besides this new trend, Next-Sharecontent delivery platform was successfully implemented in

browsers by P2P-Next. So implementing P2P-Tube as a webplatform came as a natural choice.

Because almost any hosting provider offers a standardLAMP stack, we decided to cope with such a configuration.LAMP stands for Linux, Apache, MySQL, PHP, the technolo-gies which is based on. We tested P2P-Tube on Apache webserver, but it should work well on others.

P2P-Tube server side application is implemented in PHPwhich is one of the most popular programming languagesfor this purpose. To facilitate development we decided touse CodeIgniter [1] open-source framework. Thanks to thisframework the platform uses a MVC (Model-View-Controller)design pattern, which separates the user interface part (View),from the data stored (Model) under the rule of the Controller.

Our implementation uses a MySQL database, butCodeIgniter abstracts the interface with the database, so port-ing our platform for a different SQL technology such asPostgreSQL should be easy.

As a web application, on the client side P2P-Tube usesHTML, CSS and JavaScript. As stated before SwarmPlayeronly works with browsers that support HTML5. We decided touse jQuery [4] as a JavaScript framework to ease developmenton the client side programming. We developed a jQueryUI [5]widget which is used to control video playing with featureslike play, pause and stop buttons, time progress slider, volumecontrol etc.. This widget is detailed in Subsection IV-C.

The web application currently uses two models. videosmodel is an interface to the database for accessing informationabout video assets. videos table contains on each row dataabout a video asset. videos_comments stores each videocomment created by an user on a row. Both videos andcomments can be voted with like or dislike. Methods forreturning detailed information about a video, for returningvideo summaries and for searching in the videos set areimplemented here. Video summaries are lists of video assets,with brief information about each one. For instance, get_-videos_summary method can create a list of videos from aspecific category, uploaded by a specific user, within a definedrange described as offset and count and ordered in a specificway. Methods for adding and retrieving comments for votingor for incrementing the number of views for a video are alsoavailable here.users model is an interface to the database for accessing

information about users. users table stores on each row dataabout a registered user, including its user name, its passwordSHA1 hash, its e-mail and profile information such as gen-der, country, city, birth date etc.. Authentication information,authentication method (internal, with LDAP or with OpenID)and user preferences are also stored in this table. When signingin with OpenID, users table is joined with users_openidtable which maps OpenID URLs with rows from userstable. After registration, new users have to confirm their e-mail address by providing an activation code received onthat address. Unactivated users with their activation codes arestored in users_unactivated. User activity is logged inusers_actions table. This kind of information can be used

to ensure that an user votes a comment or a video only onetime during a day, but user history can also be tracked here.users model methods can be used to check authentication

credentials, to register new users, to activate accounts, to sendpassword recovery e-mails and to modify user data. Columnauth_src from users table identifies the authenticationmethod used by the user. If internal authentication is usedthe password entered by the user is hashed with SHA1 andchecked against the hash from password column. For LDAPauthentication this field is NULL, because users modelconnects to an LDAP server for logging in. For authenticationthrough OpenID, users model uses a third-party librarydeveloped by JanRain Inc. [10] which implements OpenIDprotocol.

Pages are organized around a few controller classes.catalog controller manages web pages that help usersexplore video assets. Index page shows the five most hottestvideo assets from each category which are the newest and themost appreciated ones. The appreciation score is calculatedas the number of views plus the number of likes minus thenumber of dislikes, so a video with a greater appreciation scoreis more appreciated. Category page permits users to explorevideo assets by category. Videos can be ordered alphabetically,by upload date or by showing the hottest first.video controller manages the watch page were users

can play a video asset with one of the two Next-Shareplugins and the video widget presented in Subsection IV-C.Commenting and voting mechanisms are also implementedinto this controller through AJAX, such that when using thisfacilities the web page is not refreshed interrupting videoplaying.user controller is used for user management. login

method controls a web page which permits users to sign inwith their user name and password or by providing an OpenID.Tree buttons for Yahoo!, Google and myOpenID ease authen-tication through OpenID with this services. login methodchecks authentication credentials by using users model andsets a new session in a cookie if authentication succeeded.To delete the session and sign out, logout method is used.Registration and account activation pages are managed by thesame controller and logged in users can access account pageto change account and profile information or to change theirpassword. To verify that a real person applied for an account,a CAPTCHA is provided on the registration page. Users cansee each other’s profile through the profile page where onecan also see what videos that user uploaded.

The platform provides a way to load static HTML as pagecontent through article controller. The HTML is loadedfrom “application/views/article/<language>/<article -name>.php” when URL “article/<article name>” isaccessed. <language> is the name of the current languageset in “application/config/config.php”. CodeIgniter’s URIrouting feature can be used in order to have a different URLfor an article. In the default configuration of the P2P-Tubesite there are four articles used: Install Plugins, About, Helpand Contact. All of them use URI Routing in order to have a

friendlier address.CodeIgniter supports running its script from the command

line. admin_cli controller implements a few methodsthat can be used by system administrators exclusively fromthe command line. Database cleanup methods are currentlyimplemented here, which can be conveniently called as cronjobs.

Some parts of a web page are common to more thanone page. This include headers, menus, footers, side partswith optional information etc.. All these components areimplemented as views and are loaded within the controllerof each page. header view renders the top of a web pageand includes a menu, a logo, information about the loggedin user if required and a search box that help users searchvideo assets, described in Subsection IV-B. footer viewrenders the bottom of a web page and typically containscopyright information or links. Common HTML tags likethose found into head tag can be easily loaded by usingviews html_begin and html_end. View html_begin isused with Html_head_params library to load CSS files,JavaScript files, set the page title and add meta data.

B. Searching Video Assets

As stated before the default user interface of the platformprovides a search box in the page header along with an optionslist for narrowing results to a specific category.

The search functionality depends on MySQL Full-Textfunctions [7], thus the search query language is similar. Twomodes of full-text searching are used from MySQL: naturallanguage full-text search and boolean full-text search.

Natural language full-text search allows users to enterspace separated keywords that are matched against tablerows. Searching is performed only in table columns thatare indexed for full-text search, so we are indexing title,description and tags columns from videos table.What MySQL calls natural language is in fact vector spacesearch, which calculates the relevance of each result rowagainst the query with some variation of tf-idf formula [17],one of the most popular used in information retrieval. Thiskind of searching performs well on our video set of about120 items. However, natural language search mode has someproblems. For instance, any word shorter than four charactersis not indexed, so a query like “let it be” or “git c repo”wouldn’t retrieve anything. Also, wild cards, quotations andboolean operators like and, or, not are not supported.

To handle this problem P2P-Tube’s search feature alsouses MySQL’s boolean full-text search functions. This modeallows users to enter special characters at the beginning ofthe keyword from the search query. For example + and −operators indicate if a word is required to be present or absent,respectively, in the results. A full reference of the operatorssupported can be found in MySQL documentation [6]. Booleansearch mode is only used when at least one of this operatorsis present in the search query, otherwise natural search modeis used. Boolean search mode offers a little bit more flexibilityto the user, but on the other hand it has a big disadvantage,

results are not ordered by their relevance. Instead of assigninga relevance score for each row, this mode adds one for eachmatch of a column and zero otherwise. We weighted columnsdifferently to mark their importance. We mark title as themost important column of the video table with respect tosearching, by weighting it with 50% of the total weight. tagscolumn gets 30% and description gets 20%. So if a querymatches against the title, 0.5 instead of 1 is added to therelevance, if tags matches, 0.3 is added and if descriptionmatches, 0.2 is added.

Like natural language mode, boolean mode also skips wordswith less than 4 characters, so in our implementation we alsosearch for word fragments in the indexed columns. To supportthis we use the SQL keyword LIKE along with strings ofwords containing character % at the beginning and at theend. If such fragments are matched they affect very little therelevance because the weights of matching columns title,tags and description are very small, being 25%, 15%and 10%, respectively. So, a query string “let it be” will matcha Beatles’ video with the same name, but will also matchvideos containing “letter”, because “let” from the query is afragment of “letter”.

For our small video set the search feature performs wellwithout any performance issues. For future work we areplanning to use more advanced search tools such as Luceneor Solr from Apache Software Foundation.

C. Video Widget

Next-Share browser plugins do not provide an user interfaceto control and monitor playing of video assets. Users needat least a play button in order to start watching. However,browsers typically offer play controls for HTML5 video tags,but their functionality is limited and depends on the browser,making video tags look browser dependent. While Swarm-Player has some kind of user interface by using HTML5,NextSharePC is based on VLC browser plugin, which doesnot come with any interface.

We decided to create a browser widget, based on jQueryUIthat can be used with both Next-Share plugins. Besidesthis functionality our widget, named NS Video (Next-ShareVideo), can be used without Next-Share technology for playing“pure” HTML5 videos and to control “pure” VLC plugins. Asnapshot of the widget be seen in Figure 3. It was designedas a separate component of P2P-Tube and it can be used inany other web application, just like any jQueryUI widget. Itis a widget combined from other standard jQueryUI widgetslike buttons, sliders and check boxes and it uses jQueryUI’sCSS framework.

HTML5 triggers events for the video tag, so for examplewhen the video finishes playing an event is triggered. Thissimplified a lot the widget implementation for SwarmPlayer.This was not the case with NextSharePC, which uses VLCand does not trigger any events. To solve this problems weused JavaScript timers which check plugin’s state periodicallyand applies the appropriate actions.

Figure 3. NS Video Widget

The widget contains two interfacing objects (which havethe same interface), one for HTML5 (named html5) and onefor VLC (named vlc). With this two objects the widget’sinterfacing with to the two different video technologies issimplified. If a future extension for another technology, otherthan HTML5 and VLC, is required, a developer only needs toimplement the methods of a new interfacing object.

D. Content Ingestion Back End

Content Ingestion Server is written in Python, mainly be-cause of the need of using threads. A master thread takesthe role of a producer by receiving requests from clients andsubmitting them to a job queue. The consumer is a workerthread which gets jobs from the queue and executes them,using a first-come first-served servicing policy. If the queue isempty the worker waits without blocking until a new job isavailable.

Client requests are received by the master through a REST-ful web service. This functionality was implemented withWeb.py [15], a lightweight web framework for Python. Sim-pler messages, like the one which requests CIS’s load areimplemented with HTTP GET methods, but more complexones which require structured data format use POST methods.The posted data is encoded with JSON (JavaScript ObjectNotation) which allows messages to be formated as an im-brication of lists and dictionaries.

CIS implementation depends on NextShareCore library forthe functionalities of creating and seeding torrent files. Asstated before this library is also written in Python, so thatwas another motivation for writing CIS in this programminglanguage. NextShareCore provides an efficient implementationof seeding by using threads.

Besides creating torrents and seeding, a content ingestionjob also needs to transfer locally raw video files from the webserver, to transcode them to destination formats, to extract

image thumbnails and to transfer back torrent files and imagethumbnails to the web server. For this purpose all this featuresuse a pluggable interface. In api package, file base.pycontains this interfaces detailed below:

• BaseFileTransferer abstracts file transfers be-tween CIS and web server.

• BaseTranscoder abstracts video asset transcoding, soraw video files can be transcoded to destination formatsby using an implementation of this base class.

• BaseThumbExtractor abstracts image thumbnailsextraction from video assets. Multiple extraction policiescan be provided. A thumbnail can be extracted froma specific position from the video given in seconds,from random a position or summary thumbnails can beextracted, where a series of thumbnails by taking severalsnapshots are captured.

• BaseAVInfo abstracts a tool for retrieving informationabout a video asset. Currently this interface can be usedto get the duration of a video.

Developers can extend this interface classes with theirown implementation. In CIS configuration file (config.py)system administrators can choose between several al-ternative implementations of a feature. Currently filetransfers are done with FTP (File Transfer Protocol)[3] with class FTPFileTransferer which extendsBaseFileTransferer. Standard FTP Python libraries areused for this purpose. FTP uses two ports for communicationbetween client and server, one corresponding to the controlchannel, the other one to the data channel. The controlchannel could transfer sensitive information, thus TLS (Trans-port Layer Security) [11] is used for encryption. Developersare encouraged to implement other alternative protocols forfile transfers. For example, we are planning an rsync [12]implementation which recovers better from failures and checksdata integrity. Despite the fact that FTP is less advanced thanrsync, we decided to implement it because of its popularity.

Our BaseTranscoder implementation,FFmpegTranscoder, uses FFmpeg [2] a softwaresolution for recording, converting and streaming audio andvideo. Transconding is possible between almost any formats,by using third-party libraries. Being written in C, CIS forksa new process when using FFmpeg, and creates a pipefor monitoring standard output and standard error. PortingP2P-Tube to Windows should be easy because FFmpeg alsoworks on this operating system.

FFmpeg can also be used for extracting thumbnails,so we used the same software for implementingFFmpegThumbExtractor, which extendsBaseThumbExtractor. Information about a video assetcan be obtained with FFprobeAVInfo, an implementationof BaseAVInfo base class, which uses ffprobe an utilityfrom FFmpeg software package.

CIS-LB (CIS – Load Balancer) usually lays on the samemachine with a web server and also communicates with itvia web services. Thus, we implemented CIS-LB in Python,using Web.py as CIS. Messages received from a web server

are forwarded to a CIS from the pool by using a load balanc-ing policy. Policies are implemented as pluggable interfacesexactly as features of CIS are. Three possible policies can beused:

• Random: choose a random CIS from the pool andforward the request from web server to it.

• Optimum: send a get load request to each CIS, calculatewhich one is the least loaded and forward the requestfrom web server to it.

• Randomized Suboptimal: choose k random CIS ma-chines, send a get load request to each one, calculatewhich one is the least loaded and forward the requestfrom the web server to it.

The optimum policy is slower because it must wait untilall CIS machines respond to get load request, so although itfinds the best solution it does not scale for systems with abig number of CIS machines. This policy is recommended forsmall scale systems. The random policy is the fastest, but itdoesn’t found the best solution, but it loads each CIS machinewith equal probability, providing a good load balancing. It isrecommended for big systems. Randomized suboptimal policyis a compromise between optimum policy and random policyand is recommended for medium sized systems. The choicebetween the three policies not only depends on the number ofCIS machines from the system, but also on the size of the rawvideo files that need to be processed.

E. Front End and Back End Communication

The web server needs to communicate with Content In-gestion Server, whether or not through a CIS Load Balancer(CIS-LB), by sending a content ingestion request. By using aweb service for this communication implementation overheadis reduced. Sending HTTP requests from the PHP web serverapplication is much more easy then creating a custom newprotocol. The same applies at the other communication point,the Python server, where requests are received by Web.pyframework, which makes HTTP methods processing extremelyeasy.

If another video platform decides to use our solution basedon CIS machines, interoperability is simplified by using webservice interfaces, no matter what programming language isused for web server application.

F. The Choice for the Web Service Type

Our choice between a SOAP web service and a simpleRESTful web service was based on our needs. We wantedto make a server with a low communication overhead andSOAP has the disadvantage of consuming more computationalresources when processing requests. Our messages that needto be passed through different services have a simple structure.

The get load request does not have any parameters, so asimple HTTP GET request is sufficient and any extra datatransmitted as XML with SOAP is redundant.

Content ingestion request is a message with a greatercomplexity. The name of the uploaded file located on theweb server needs to be transmitted, along with video formats

information such as containers, codecs used, resolutions, framerates, aspect ratios, audio sampling rates and bit rates. All theseinformation would fit well as parameters in a SOAP message.However encoding them in a JSON seemed to be a muchsimpler solution. Both PHP and Python offer functions thatconvert their primitive types and data structures, like lists anddictionaries, into JSON strings. XML messages have a greaterverbosity comparing to JSON messages. Features like XMLtag attributes are not required for our application.

We expect web servers and their CIS Load Balancers toknow CIS machines in advance. So there is no need fordiscovery services that could provide contact information fornew CIS machines. This would reduce administrative controland would raise security concerns like discovering maliciousCIS machines. So there is no need for service discoveryfeatures like UDDI from SOAP ecosystem.

Services functionality does not need to be described becauseit is expected to be known in advance by the client application,so SOAP’s WSDL feature is not needed.

The simplicity of our web services and our need for alow communication footprint suggested us to use a RESTfulweb service with JSON encoded information when the POSTmethod is needed. SOAP extra features like WSDL and UDDIare not required for our application, giving us another reasonto exclude it as a candidate.

V. FUTURE WORK

Our video-sharing platform is far from being a completeone, so we are planning to extend it in the following directions:

• Administration Interface: the platform must have anadvanced administration interface, where features, theuser interface and moderation can be easily managed viaa web interface. With moderation system administratorscan ban users, delete video etc.. The general purposeopen-source platform Joomla for example provides anadministrion interface.

• Video Support: extending P2P-Tube to support othervideo technologies besides Next-Share. Normal HTML5and VLC support and also Adobe Flash Player supportwithout P2P streaming must be considered.

• Swift Support: P2P-Tube was designed to work withNext-Share by using BitTorrent protocol. Another betterprotocol that can be used is swift [13], which is currentlyan IETF draft.

• Hierarchical Categories: categories are currently definedas a list. In the future they should have a tree structurewith categories, subcategories, subsubcategories etc..

• Better language support: currently our platform sup-ports multiple languages with the native support fromCodeIgniter and with article controllers language sup-port. A better support would allow users to change thelanguage directly from a P2P-Tube site. Also automaticlanguage detection should be considered by locating theIP address of the user or by inferring it from the URL.For example, http://www.example.com/fr/page should useFrench, http://example.ro/ should be in Romanian and

http://it.example.org/page should be in Italian. The cur-rent language should be reflected in the currect URL as inthe previous examples such that search engines can alsodetect it, providing SEO (Search Engine Optimization).

• Better Search Feature: changing the current implemen-tation of the search mechanism which is based on MySQLFull-Text with a more powerful one, such as one basedon Apache Lucene or Apache Solr.

• Porting for Other Operating Systems: P2P-Tube shouldbe ported for Windows Server.

• Alternative Features for CIS: file transfers should besupported with other more reliable protocols such asrsync and other tools for transcoding and thumbnailextraction should be considered.

• Adapting CIS for Other Video Technologies: if theplatform includes normal support for HTML5, VLC,Adobe Flash or other technologies, CIS must be modified.One good reason could be that other technologies do notneed seeding and creating torrents.

VI. CONCLUSION

We designed and implemented P2P-Tube, a video-sharingplatform which supports the new Next-Share content deliverytechnology from P2P-Next. The most common features neededto implement a video-sharing site are found on this platformwhich allows users to share their thoughts through videos. Itensures scalability for a few thousands users by using the Next-Share technology, which moves part of the overhead to theusers, and by using a distributed system of content ingestionmachines (CIS). It offers organization of video assets throughcategories and social features through users, comments andvoting. Community contributions are encouraged, becauseP2P-Tube is free and open-source.

ACKNOWLEDGMENT

Special thanks go to the P2P-Next [9] team who is workingenthusiastically to deliver the next generation peer-to-peercontent delivery platform. Their dedication, professionalismand vision are a constant factor of motivation and focus forour work.

REFERENCES

[1] CodeIgniter - Open source PHP web application framework.http://codeigniter.com/.

[2] FFmpeg. http://ffmpeg.org/.[3] FTP, RFC959 – File Transfer Protocol.

http://www.w3.org/Protocols/rfc959/.[4] JavaScript Library. http://jquery.com/.[5] jQuery User Interface Library. http://jqueryui.com/.[6] MySQL Boolean Full-Text Searches.

http://dev.mysql.com/doc/refman/5.0/en/fulltext-boolean.html. [Online,accessed 2-February-2012].

[7] MySQL Full-Text Search Functions.http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html. [Online,accessed 2-February-2012].

[8] Next-Share deliverable D4.0.6.[9] P2P-Next. http://www.p2p-next.org/. [Online, accessed 2-February-

2012].[10] PHP OpenID library by JanRain, Inc. https://github.com/openid/php-

openid. [Online, accessed 2-February-2012].

[11] RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2.http://tools.ietf.org/html/rfc5246.

[12] Rsync – file synchronization network protocol.http://en.wikipedia.org/wiki/Rsync.

[13] swift – The Generic Multiparty Protocol. http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-02.

[14] VideoLAN. http://www.videolan.org/vlc/. [Online, accessed 2-February-2012].

[15] web.py – Python web framework. http://webpy.org/.[16] Lightweight Directory Access Protocol (LDAP).

http://tools.ietf.org/html/rfc4510, 2006. [Online, accessed 2-February-2012].

[17] H. S. C.D. Manning, P. Raghavan. Introduction to Information Retrieval.2009.

[18] B. Fitzpatrick. Openid authentication 2.0. OpenID Foundation, 2007.