8-10-02

(Editor's Note: The discussion was about live and realtime Videoconferencing across the internet. Since then, internet bandwidth has increased and new protocols, such as [wiki:Session_Initiation_Protocol SIP] and H323, have become popular, which work around some of the issues discussed here.)


["Akili"] rumbles lightly, "No guarantee that it'll be useful, though. High-quality is possible, and live is possible - with a 20-second realtime delay. The closer you get to live, realtime broadcasts, quality goes way down."

["Kimia"] asks, "Why is that?"

["Akili"] smiles softly. "Unfortunately, it makes perfect sense, which is why I doubt it will get better. I'll explain."

["Kimia"] says, "Ok."

["Akili"] rumbles lightly, "When you make a phone call, all sorts of devices assemble to make an unbroken connection - wireless, hardline, satellite uplink, transatlantic cable, other stuff - between the callers. That data path is just for the two of you alone (more if it's a partyline, but I'll leave that out for simplicity). Once the call ends, all of those pieces disconnect and might be used for the next caller. That method is great - real time, decent quality - but expensive, because it's requiring that bits of data from each end get to the other end without being scrambled or delayed beyond reason."

["Akili"] rumbles lightly, "That's phones."

["Kimia"] nods.

["Akili"] rumbles lightly, "Now, the internet. The common protocol that everyone loves, [wiki:Transmission_Control_Protocol TCP/IP], is great - it allows you to send a stream of data from your computer to someone else's, and guarantees that it will be reassembled in the correct order without dataloss. When you send a Packet, it goes from your modem to your ISP (a phone connection), which then takes that and sends it to their [wiki:Router router]. Their [wiki:Router router] looks at your Packet, determines which [wiki:Router router]s would know what to do with it, and sends it to the fastest, most available [wiki:Router router] *at that moment*. That Packet keeps hopping [wiki:Router router]s until it gets to your intended destination. However, this method has a catch: By all of these [wiki:Router router]s recalculating on the fly, it means that Packets may arrive out of order, or sometimes missing. This isn't a problem, usually, since the [wiki:Transmission_Control_Protocol TCP/IP] protocol is designed to deal with this without affecting the quality of your data."

["Akili"] rumbles lightly, "This system, for public shared use, works well - everyone can access it at any point, and the [wiki:Router router]s will adjust to the traffic pattern accordingly. Routers that fail will be routed around in short order. And, it means that the cost for such a huge network does not have to be taken by a single company - it can be shared among many hosts, all of whom maintain their own equipment. Even AT&T couldn't support the entire internet themselves for the rates we pay."

["Akili"] rumbles lightly, "However, now we're trying to send live, realtime video. It takes a certain number of Packets to build a video image, interlaced with audio. But these Packets, due to the nature of the internet, might arrive out of order, or might be missing and have to be resent. For internet broadcasts, this is handled by buffering: when you start to watch a digital broadcast, your computer downloads a certain percentage of data before showing you the clip. This buffer allows for missing or delayed Packets to be fetched and inserted before you notice a drop in quality. This is partly how RealPlayer works: as long as you're getting a certain percentage of the Packets in a certain length of time, you won't have a problem."

["Kimia"] ohs.

["Akili"] rumbles lightly, "Now, what we're trying to do is work without a buffer, since that buffer adds in ten to twenty seconds of delay to handle those missing Packets. Unfortunately, by removing that buffer, we run into a problem. If you send ten Packets, and they arrive in the order of 3 1 4 2 5 6 7 8 10 9 ... what's your viewer to do? Pause and wait, or omit the out of sequence Packets and just show you what it got in order? Either way, quality just went down the tubes."

["Kimia"] says, "Ahh."

["Akili"] rumbles lightly, "And therein lies our problem."

["Kimia"] says, "I see..."

["Akili"] rumbles lightly, "Which, since it's due to the nature of the internet, I don't see an easy workaround for, or even a possible one that's cost effective."

["Kimia"] nods.

["Akili"] rumbles lightly, "What we *need* for Videoconferencing is relatively low bandwidth - we could do with 56k - and no latency (lag), or very very little. We need a guarantee that those Packets will always arrive in the exact sequence they're being sent, preferably with no missing Packets, either. The Internet as it stands can't manage that type of guarantee, to the best of my knowledge. Faster connections - [wiki:Dsl DSL], [wiki:Digital_Signal_1 T1], [wiki:T-carrier T4], OC3, and up - lower the average latency while raising the overall bandwith, but when you get to a connection speed that would be reasonable enough to support that kind of guarantee... you might as well pay for direct phone lines between the two or more sites."

["Kimia"] nods.

["Akili"] rumbles lightly, "And that's ["Akili"]'s Tech Talk for today. Thanks for watching. ;)"

["Kimia"] giggles. "Thanks for explaing."

["Akili"] rumbles lightly, "["Calin"] and I discussed this once before I moved out here, actually, when we were experimenting."

["Kimia"] says, "For some reason I think I remember that."

["Akili"] rumbles lightly, "I don't know if you were in the room at the time, but you might have overheard some of it."

["Kimia"] nods. "Possible."

VideoConferencingOnTheInternet (last edited 2008-06-08 17:40:04 by calin)