Browser plug-in for P2P video

Status: Diego has started working on this

The goal is to craft a player for Bittorrent swarms inside a web browser. This player would be an web browser based mediaplayer using the Tribler P2P core.

A big issue is the on page requirement with deep-integration with a web browser, similar to the Flash plug-in. This means that no separate browser window is opened. The P2P video is rendered in a region with around it some standard HTML content display. VLC is already capable of this(Demo), requires integration with the swarmplayer.

Open issues:

• Fork single thread of control with P2P core.
• VLC integrationinternet explorer
• 1 backend with P2P core, multiple windows with playback, define API
• WxWindows??

General Architecture

The first architecture proposal divides the plug-in in two parts:

• a background process containing the core of Tribler
• the plug-in itself embedded in the borwser

The background process handles the download of the stream and pass it to the Vlc player.
The crucial choice is whether to include Vlc in the BG side or in the plug-in side:

• the first choice would keep the plug-in side lightweight hence high responsive. It would be also simpler to pass the stream from the tribler core module to the Vlc player since they would work in the same address space. The main disadvantage of this choice is that a high bandwidth stream (the decoded video) is to be passed from the BG process to the plug-in. Such a high bandwidth stream would require a fast and high responsive communication mechanism between the BG process and the plug-in. This could be solved using a shared memory IPC mechanism that guarantees high performance. On the other hand using SHM means to loose code portability on different platforms and would introduce synchronization issues.

• the second choice would weigh down the plug-in side but would keep the architecture enough flexible to be adapted to different platforms. Keeping Vlc integrated in the plug-in means that the stream between the BG process and the plug-in itself has the same bandwidth as the download stream (the decode happens in the plug-in side), hence a socket IPC mechanism can be used without loss of performance and portability.
  

Depending on where Vlc will be integrated (plug-in or BG side), two different communication protocols have to be defined. Integrating Vlc in the plug-in side seems at the moment the best choice. In this case the communication between the two different modules would involve mainly passing the video stream from the tribler core to the Vlc player.

Some javascript code will trigger the user events and pass the commands to the Vlc player without involving any communication to the BG process. For this reason a javascript interface has to be included in the plug-in side.

Even if the architecture should be platform independent, the first target will be Internet Explorer on Windows (XP?). To this purpose the architecture should provide a modular way for dealing with different browsers and enough flexibility to be easily ported to different platforms.

Since the IE plug-in system requires the plug-in to be most likely (or only?) implemented as an ActiveX control it would be handy to use the same strategy for Firefox as well. In this case ActiveX would conflict with a multiplatform architecture.

Another aspect to keep into consideration is the way the MIME type will be handled in the different platforms. This doesn't actually affect the architecture of the system.

Notes

VLC HTTP interface

VLC ships with a little HTTP server integrated. It is used both to stream using HTTP, and for the HTTP remote control interface. The interesting part stands in the interaction between javascript and the VLC plugin. The same strategy could be used with the SwarmPlayer. The javascript code embedded in the web interface has been attached below. Launch the following command to have a try:

vlc -I http --http-host localhost:8088

and open http://localhost:8088 in a browser.

MIME type

A MIME type is to be defined (application/x-tribler-plugin ?). In this way the stream will be handled by the plug-in. The MIME type has to be registered in the system during the plug-in installation phase. This requires the installation script to be differentiated for the different platforms. Once the MIME type has been registered the following, the Tribler plug-in will be associated to the following tag:

<embed type="application/x-tribler-plugin" target="...">

Installation script on Windows

• To register the ActiveX controll:

  REGSVR32 C:\PATH\TO\PLUGIN\PLUGIN.DLL
  

• If other external components are needed (not sure):

  [HKEY_LOCAL_MACHINE\Software\Tribler\Plugin]
  InstallDir="C:\Program Files\Tribler\Plugin"
  

• Take into account the CAB file.

Vlc and Vlc source building

The easiest way to develop the Tribler plug-in is starting from the Vlc code. In the Vlc source tree is possible to find the source code for the Vlc plug-in developed as an ActiveX control. Several files implement modules needed to interface the plug-in with the ActiveX system. The modules that are in our interest are VlcPlugin? and VlcControl?. They implement Vlc control functionalities and handle IE events. The idea is to bypass the flow of events from IE to Vlc adding a layer in between able to communicate with the BG process and control the Vlc module. Since Vlc is a Linux native player, the compiling process requires some cross-compilation technique. Vlc can be compiled in Windows only in a Cygwin environment, there's no Visual Studio porting of the compiling process (yet). An HowTo? on how to build Vlc for Windows can be found here