1
edit
Changes
no edit summary
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.
==Research Progress==
===Replacing Red5===
====SharedObjects====
So far, our research has indicated that the best replacement for the Red5 server would be [http://jwebsocket.org/ 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.
====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 [http://www.xuggle.com/xuggler/ 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.
