##CategoryRants ##CategoryComputers ---- 8-10-02 (Editor's Note: The discussion was about live and realtime WikiPedia:Videoconferencing across the internet. Since then, internet bandwidth has increased and new protocols, such as [wiki:WikiPedia:Session_Initiation_Protocol SIP] and WikiPedia: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:WikiPedia: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 WikiPedia:Packet, it goes from your modem to your ISP (a phone connection), which then takes that and sends it to their [wiki:WikiPedia:Router router]. Their [wiki:WikiPedia:Router router] looks at your WikiPedia:Packet, determines which [wiki:WikiPedia:Router router]s would know what to do with it, and sends it to the fastest, most available [wiki:WikiPedia:Router router] *at that moment*. That WikiPedia:Packet keeps hopping [wiki:WikiPedia:Router router]s until it gets to your intended destination. However, this method has a catch: By all of these [wiki:WikiPedia:Router router]s recalculating on the fly, it means that WikiPedia:Packets may arrive out of order, or sometimes missing. This isn't a problem, usually, since the [wiki:WikiPedia: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:WikiPedia:Router router]s will adjust to the traffic pattern accordingly. WikiPedia: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 WikiPedia: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 WikiPedia:Packets to build a video image, interlaced with audio. But these WikiPedia: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 WikiPedia:Packets to be fetched and inserted before you notice a drop in quality. This is partly how WikiPedia:RealPlayer works: as long as you're getting a certain percentage of the WikiPedia: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 WikiPedia:Packets. Unfortunately, by removing that buffer, we run into a problem. If you send ten WikiPedia: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 WikiPedia: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 WikiPedia:Videoconferencing is relatively low bandwidth - we could do with 56k - and no latency (lag), or very very little. We need a guarantee that those WikiPedia:Packets will always arrive in the exact sequence they're being sent, preferably with no missing WikiPedia:Packets, either. The Internet as it stands can't manage that type of guarantee, to the best of my knowledge. Faster connections - [wiki:WikiPedia:Dsl DSL], [wiki:WikiPedia:Digital_Signal_1 T1], [wiki:WikiPedia:T-carrier T4], WikiPedia: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."