Video Conferencing on the Internet 8-10-02 (Editor's Note: The discussion was about live and realtime videoconferencing across the internet, and why it's not bloody likely anytime soon) 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, 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 router. Their router looks at your packet, determines which routers would know what to do with it, and sends it to the fastest, most available router *at that moment*. That packet keeps hopping routers until it gets to your intended destination. However, this method has a catch: By all of these routers recalculating on the fly, it means that packets may arrive out of order, or sometimes missing. This isn't a problem, usually, since the 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 routers 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 video conferencing 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 - DSL, T1, 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."