BBB HTML5 Client

Developing the HTML5 Client for BigBlueButton

Our aim in this iteration of our collaboration with BlindSide Networks is to develop a Flash-free, iOS compatible implementation of BigBlueButton. The first step in this is to develop a "bare-bones", non-presenter client that can still communicate with the existing Flash application. This requires the in-depth process of researching alternatives to Red5, the Flash Event structure, and the existing methods of streaming audio and video.

Setup HTML5 Client Development Environment

• Install BigBlueButton Newest Version (current version: 0.81-Beta-2)

The requirements are:

• Ubuntu 10.04 64-bit (Note: The packaging is for Ubuntu 10.04 64-bit only. There is no 32-bit packaging yet for 0.81.)
• 4 GB of memory (8 GB is better)
• Quad-core 2.6 GHZ CPU (or faster)
• Ports 80, 1935, 9123 accessible
• Port 80 is not used by another application
• 500G of free disk space (or more) for recordings

Please follow the link to install your Bigbluebutton server. If you are working on Windows Operating System, we suggest using the VMware Player 4.0.4 and install Ubuntu 10.04 on your virtual machine.

• Take a look at the overview of HTML5 Client
• Setup the development environment for HTML5 Client

Note:

1. After Clone the SenecaCDOT-BigBlueButton repository to your local machine,you must build and deploy or run the Client, BBB-Web, and Red5 Applications components. git clone git@github.com:SenecaCDOT-BigBlueButton/bigbluebutton.git
2. Add BigBlueButton repository as your master branch’s upstream: git remote add upstream https://github.com/bigbluebutton/bigbluebutton/bigbluebutton.git
3. Before creating a working branch, make sure your master branch is up-to-date: git fetch upstream
4. Create a working branch: git checkout -b yourbranchname upstream/html5-bridge
5. Push your local working branch to SenecaCDOT-BigBlueButton (your origin): git push -u origin yourbranchname

Research Progress

Replacing Red5

SharedObjects

So far, our research has indicated that the best replacement for the Red5 server would be jWebSocket. Red5 synchronizes all clients in a meeting by using the SharedObject class, which is essentially a form of socket. By instructing jWebSocket on which Red5 SharedObject to listen to and mimic, the HTML5 client should be able to join a meeting in the same manner as the Flash client.

UPDATE (June 7 '12): A plugin exists for jWebSocket containing a SharedObject class designed to mimic the SharedObjects in Red5. This could reduce the complexity of adapting the ActionScript code to JavaScript, depending on how similarly the JWS SharedObject behaves to the Red5 version.[1]

Video Streaming

Media streaming is proving to be a challenge. Red5 broadcasts video encoded as FLV through RTMP, which can be received and decoded by the Java-based Xuggler. The problem arises in re-encoding it to H264 (currently the only video format supported by iOS devices, and very proprietary) and re-broadcasting through a non-RTMP protocol (RTMP also being proprietary to Adobe). The "bare-bones" client will only be concerned with receiving video, not broadcasting any of it's own.

Replacing the Flash Event structure

Research into this topic has been cursory, but it appears that custom event definition in JavaScript will suffice.

Architecture

In a very general sense, our architecture will need to mirror the existing BigBlueButton architecture. The client (of which there can be many) will communicate back and forth with the server, which in turn is tasked with keeping the clients synchronized. The main difference will be that the new server will need to listen in on what is occurring on the Red5 server (of course, this element will become obsolete when the HTML5 application is in a state to replace the Flash application)

Further research is required into whether Red5 will be "aware" of the listening (ie, we can edit Red5 to take an active role in communicating with the new server) or whether it will remain oblivious as an entirely passive partner in the inter-server communication. To simplify further: Will this be a conversation, or someone eavesdropping at the door? If the latter, then how will the Flash clients synchronize themselves with the HTML5 clients? Again, further research required.