Live Streaming Video: Techno Babble

This may seem very out of place on this type of blog.  I assure you it is not, but this may not be evident until later posts. Anyway… 

Over the past few years I’ve dabbled in streaming video. With very little funding, I used open source software to experiment with different ways to incorporate video into basic website and a few social networking sites. I’ve used VLC and Darwin Streaming Server 1 as my primary tools. I later added some AVATAR software into the mix. I was pleased. But all was not well…

I openly admit my propensity to deal with difficult software environments. So what I thought was cool, streaming video with a interactive avatar environment, did not translate into a workable GUI for normal people. OK normals, what seems to be the problem? I just spent 9 months screwing around in my off time and you’re telling me this is too hard?!?!.

However, this is reality. I spend too much time with computers. The big black line that should divide work and play, in my world is one solid shade of grey. Maybe that means I work too hard or I don’t get out enough.

So normals, you win… I need to figure out how to make this really cool techno babble understandable by people who do not spend 20 hours a day in front of a computer. So what then are the problems?

First, lets illustrate the current environment. Live video embedded inside of a single webpage with an interactive AJAX environment, check it out here.

Well, first off… its not flash… Yes, I will swallow my pro open source pride, plus my cheapskate ways and will admit Flash makes it much easier for the non-technical web video consumer to participate. There is really only one reason, Adobe uses simple method for installation of flash. It’s a plugin.

Next on the list… Connection speed. I’ve learned that my audience uses many different methods to connect to the internet. For the most part, my webstats reflect consumer internet services over more expensive business internet. One of the more interesting connection methods is consumer grade WiMAX. 

This might actually be causing problems in my usage of Darwin Streaming Server. Latency, the time required to send a packet of information from point a to point b and then get a response, seems to vary greatly.

Darwin Streaming Server uses RTSP (real time streaming protocol)… And in my testing of RTSP on a network with a high rate of packet loss, it doesn’t work well. Now, I didn’t use WiMAX in my test, but it seems reasonable. I tracked down a few users of consumer WiMAX in Colorado and heard stories of 1 to 3 second delays followed by typically quick load times. This makes me think RTSP and consumer WiMAX may not work well in less than optimal network situations.

How does one address these RTSP and low network quality with video… Well, it may not be possible. Live video depending on its bitrate (Quality) can seriously tax a slower DSL connection, and for that matter on a cable network that is in a period of high use. On networks with high levels of packet loss, RTSP may not work at all. 

But there is hope… I could offer multiple bit rates that the user could choose from. This assumes they know which to use. Or I could find a way to outsource the relay server to a company that offers a software solution that could adjust bitrate based on the consumers ability to receive higher quality video. Thus, Mr. or Mrs. Normal will not need to do anything, its done for them. Check these guys out, they’ve figured it out.

Ok, what else… Wouldn’t it make more sense to offer the live video at relevant times? Yes, and that is  complicated and expensive. I’ll cover that later. I’ll leave you with this sweet image. My next post will cover the amazingly interesting topic of business WiMAX. 

This is dedicated to Nicole… With out her influence I would not have written this down. This is just a start, there will be much more to come. Hopefully this techno babble can one day be converted into a non-geek manual.