BBB HTML5 Client

From CDOT Wiki
Jump to: navigation, search

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: 1.0)

The requirements are:

  • Ubuntu 14.04 64-bit server
  • 4 GB of memory with swap enabled (8 GB is better)
  • Quad-core 2.6 GHZ CPU (or faster)
  • TCP ports 80, 1935, 9123 are accessible
  • UDP ports 16384 - 32768 are accessible
  • Port 80 is not in use by another application
  • 500G of free disk space (or more) for recordings
  • 100 Mbits/sec bandwidth (symmetrical)
  • Dedicated (bare metal) hardware (not virtualization)

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 14.04 on your virtual machine.

  • Take a look at the overview of [1]
  • Setup the [2] for HTML5 Client


  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
  2. Add BigBlueButton repository as your master branch’s upstream: git remote add upstream
  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

HTML5 Client Development References

Javascript in the browser/client:

(!) Basics:


(!) Basics:

(!) Selectors:

(!) Changing elements:

More: and




(!) MVC:

(!) The items in the “Beginner” section are all important (at least the first aspects in their pages):

Example of a simple TODO list application in backbone:


(!) A tutorial:

(!) You can paste your javascript code in the “Try Coffeescript” section in and see them converted to coffeescript

(!) Coffeescript video tutorials:

Coffeescript + Backbone.js examples:

Backbone.js + Require.js: Javascript in the node.js server:

(!) Hello World:

(!) A basic HTTP server:

(!) Basics, a first example of a server:

Another guide for beginners with more details:

Lots of links to other guides:


A very fast guide showing how it works:

(!) Good tutorial showing why and how is used:

Research Progress

Replacing Red5


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.[3]

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.


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.