By Michael and Judith Dinowitz
On Tuesday, November 12, the New York ColdFusion User Group (NYCFUG) became the first CFUG ever to broadcast and distribute our meeting over the Internet using a webcam and the Flash Communications Server. The broadcast was an experiment and an effort to expose more people to NYCFUG.
The experiment was a success. We now have new members from all over the world who are interested in attending future meetings. A few minor technical issues did crop up and this report is an attempt to address them. We hope that other user groups will use the Flash Communications Server to do the same thing and will profit from our experience, and avoid these potential pitfalls.
Equipment Used to Broadcast:
A more perfect solution would be one of the new Sony digital video cameras. They have USB streaming, which means you can stream to a laptop as you are recording. It's a bit expensive, but if you plan to record a meeting and broadcast it, then it may be the best you can do.
Some people suggested using two cameras (one for the presentation and one for the presenter). While this is a good idea, it is not possible for most people. It would require either a physical switch or a special piece of software to differentiate between each camera. Rather than doing this, I suggest having the presenter's material located on the web somewhere where it can be linked to. A better idea is to have the presenter's material set into Flashcom to be broadcast to the participants. This will help people see what is happening as well as hear it. This solution does require more coding though.
One of the keys to a Flashcom presentation is the audio. The microphone used for our meeting was part of the webcam and while it's good for up close work, it's not perfect for the distance we were using. A separate microphone is suggested. If you can get one, a wireless would be best, as it'll allow your presenter to move around. If not, a standard clip on microphone either near or on the presenter will suffice in giving good audio quality.
For those who can not hear the presentation, a 'monitor' is needed. This is someone who will paraphrase what the presenter is saying and field any comments or questions for the presenter. This is not an easy job, as the person has to listen to the presentation, compile what was said quickly and type just as fast.
We had a problem with that, as the laptop used was an ultra-portable. The keyboard was not designed for touch-typing and this led to many mistakes. The second typist was better as he had never learned to touch type and used two fingers (fast, but...). Having a good keyboard is a must in this situation. A plug in keyboard or a larger laptop should fill this need.
As I was writing this, I was told that an update for the Flashcom server
components was out. One of the items in the update was this:
"The SimpleConnect component no longer has a memory leak on the client-side; previously, the memory leak occurred if you typed faster than 1 character every 10 milliseconds."
One of the biggest problems we had was the Flash client running in IE. The more we typed (and we typed fast), the more the system got lagged. This update should fix the problem. This may be due to one of two important issues, the hardware used to broadcast to the Flashcom server and the Flash client.
We were presenting on a Toshiba Protégé 3110, which is a P300 with 128 meg of RAM. This is a nice laptop, but might be a bit underpowered to act as a projection client. Something with a larger CPU should probably be used. As time goes on, the browser running the Flash client seems to take up 100% of the CPU. This will be dealt with in a moment, but the same effect is NOT seen on my home system, which is in the gigahertz range.
The final piece of the puzzle is the Flash client. This component is what's used to take the camera's input and send it to the Flashcom server. It also seems to be the piece that caused the most problems (and the piece that is probably the most easily fixed). As mentioned before, a memory leak with the client has already been fixed. How? Because the client is just a Flash component, and all that needs to be done is a small rewrite to fix any part of it. This is also where I feel the other big memory leak is. When the client is viewed inside of Internet Explorer, the more that happens in the client, the faster IE eats up CPU. I've been told that you can run the client outside of the browser and I think this will solve many of the CPU issues.
One known issue is that the more text that is typed in (both locally and from others), the more text is stored in the buffer and the more memory it takes up. This can easily be solved by setting a limit on the buffer or a clear cache button. Both are easily added to the flash client component.
One final thing that we found was that even if with our faster connection, setting the broadcast quality to DSL was more than enough to send good quality audio and video. A larger setting (like LAN) would mean more data being sent, and if there is a memory issue in IE as I believe, it would show up faster.
Even with a few technical and equipment- based problems, the presentation was good enough for people to stay on through the entire meeting. We did have to refresh the browser every 10-15 minutes to deal with the memory issue, but it wasn't that big a deal. With a few tests and tweaks, I believe that the refresh can be avoided and the quality can be maintained throughout the entire presentation.
As a side note, the entire presentation was 2 hours and 39 minutes of broadcast time. Others may vary. :)