NEW NET Streaming Video...Not!

Of the eight or so times we have streamed video from a NEW NET meeting, the experience during the 05 August 2008 gathering was the most spectacular failure.

At one point during the Keystone Cops adventure which was our meeting, things were so messed up, garbled and hard to follow that I just burst out laughing because I had no idea whether we coming or going and no clue as to how to fix things. We had feedback, dropped video, dropped audio and participants were being booted out of the Stickam room and logging back in. We also had a very confusing two minute lag between the time we heard someone speak directly at Tom's Drive In and the time we heard them say the same thing through the Stickam streaming video we were watching on our laptop screens.

On the plus side, Andy M figured out how to make Luke's video camera run continuously without a tape so we didn't have to shut down to rewind the tape.

We've had other streaming video sessions where everything seemed to work fine. During the session two weeks ago, Mike S was connected remotely and seemed to think that using Stickam as our streaming video service worked well for him. I remember a few glitches in the past, but never anything quite so totally fouled up as last night.

One of the people who connected remotely, Mike P, was a first time visitor to a NEW NET meeting. He certainly didn't have the type of experience that would make anyone want to come back right away. Before the NEW NET group scares off too many potential participants and tech enthusiasts, it appears we need to do a bit of streaming video homework.

One lesson I took away from the experience was that I'd like to figure out all the variables which determine whether we'll have a quality connection for remote participation during a given NEW NET meeting. So what we need is a good wireless/network 'engineer' type person to meet with us and discuss what all those factors are. To start with, what variables should/can we measure on the internet connection we're using and how do those affect the performance of our up and down transmissions? Is there traffic shaping on the router to which we've connected, or more likely, what type of traffic shaping is being done on our feeds? How much bandwidth does our video feed require, and should we limit ourselves to one common microphone for the group because of the increased audio bandwidth load caused by multiple headsets?

...you can hardly tell I'm an engineer, huh??...

We probably also need a way to figure out if the streaming video service we're using is performing well on a given night. Different services, such as Stickam, Y! Live, ooVoo, Yahoo! IM video, and others likely have good days and bad days. On an average basis, the various services quite possibly have inherently different bandwidth requirements for acceptable levels of performance for remote telecollaboration. How do we measure those different services, both their 'normal' requirements for good performance and their 'actual' bandwidth efficiency on a given day when we need to use them? We should evaluate and choose the top two video services, or possibly the top three, and also have predetermined communication back-channels such as IM, IRC, Skype, cell phone, etc.

Finally, all the details of the above information, along with an overview and instructions for connecting remotely to NEW NET meetings, should be figured out over the next two months, then made available to people who'd like to connect remotely. Guess I've got some learning to do and some wireless/network engineers and sys admins to track down to help me with that learning...

Help!

*****