 |
Vol. 5: July 1998
|
07-15-1998: Live Video on the Web
Greetings once again!
Today's topic is.....Bandwidth! But what,
you say? I mentioned video in the heading? Well, you are correct. The two go
hand in hand, and a breakthrough in one has an impact on the other. Have you
ever visited a Webcam, viewed live streaming video , saw a stored video
presentation (we'll see these later) or videoconferenced via the Internet? If
so, was the experience unpleasant? The pictures tiny, grainy, choppy,
distorted, along with any accompanying sound competing with the video for lowest
quality? Well, fortunately, in most cases the video and audio capture hardware,
and software, has the capacity to produce stunning quality compared to what we
see today. The primary limitations are:
A. Bandwidth between the video
server and the "Internet"
B. Bandwidth between the client PC and
the "Internet"
By "Internet" I mean the next
significant increase in bandwidth off-site from the Server as the data packets
traverse a route from server to client and vice-versa. Even a T3 line can
become a bandwidth bottleneck, given enough traffic! Although server
bottlenecks can occur, the Pentium Pro, P2, and Xeon processors nowadays, plus
the advanced RISC processors used on many UNIX boxes make them less of a factor.
Server bottlenecks can most easily be detected by the layperson as a delay in
receiving the data (Netscape's "Contacting Host" dialog), although a
severely congested router may be dropping packets and thus having the same
apparent effect. Now, if every Web surfer had 350 kilobits of switched* (thus
guaranteed) bandwidth, and every server had increased (though not by as much)
bandwidth, plus the Internet infrastructure could handle it, we could all watch
television via the Internet. How is this possible? IP multicasting, where a
server sends out only a few streams, takes a lot of the burden off of the server
and it's immediate bandwidth. The signal is reproduced by the routers along the
data's path and thus the load is shared quite effectively. 350 KB of bandwidth
is adequate for full-screen video, and 56 KB can't do it justice, not even
considering that 56 KB modems typically only reach 48 KB on a good connection.
So, the lack of breakthroughs in bandwidth are the primary restraint on all
video over IP at present.
XDSL technologies perhaps have the most
promise, as with these a consumer can get up to a megabit and a half or more of
downstream bandwidth, and with that much to work with, as long as at least 25%
of that can be maintained, video becomes more viable. This technology has more
potential promise than cable modems since they connect directly to the central
office and thus high-capacity SONET rings, whereas cable modems are constricted
by 1-several T1's or a T3 at the cable headend. This allows cable modems to
suffer bandwidth congestion if enough users are downloading large files, with
live video being considered an infinite size file. Forget it if 25% of the
cable modem users started viewing video at once, unless IP multicasting were
used at the cable modem head end and they were viewing the same content.
OK, so now we know not to expect TV-quality video on the Net. Now, where
can we find some interesting sources of video? First, I recommend getting the
Real Player G2 from RealNetworks.
They offer a free download preview version that doesn't expire. The system
requirements are a Pentium system, but it will run acceptably on less,
especially if your bandwidth is low anyway due to a modem rather than a LAN
connection to the Net. Next, open your Web browser to
www.dailybriefing.com and
setup your daily briefing programs. Usually, the ABC & Fox news ones are
good for starters. After you click on the Finish button, you can then find on
the left the Start my briefing text, and clicking on that will activate the Real
Player. There are so many controls and options at this point that I will have
to save that for a later session. But for right now, have fun watching TV
(albeit recorded) over the Internet. :-)
Is there anything else? Of
course! Because of the aforementioned bandwidth shortage, slide shows of image
snapshots are currently popular, and although updates are much slower than
streaming video, picture clarity is often much higher. Without needing a lengthy
download and plugin install, try going to
NetWatch
which has some cool "WebCams" which are simply color cameras that
often update the image on the Web page. Go to the bottom of the page, and place
your mouse pointer over the various "cams" for listings of sites. I
hope to have a Webcam site of my own soon and will be able to explain the
technology in greater detail then. That's enough for today, have fun!
*Switches vs. Hubs 101: Please note that this example presented below is a
very unlikely scenario, and please don't call your cable company to upgrade your
nonexistent "Hub" as this is all made up for the purpose of
clarification.
A Hub shares traffic on a backbone that is the same speed as
every connection to it, ie a 10 MB Hub has a 10 MB backbone. Say you are House
C. House A and B to your left are exchanging a 1 GB file at 10 MBPS, and you
all are connected to Hub 216 of A1-ISP. Although you want to get to House D,
and neither you nor House D are creating Net activity, the Hub is already
congested and thus you get a very small fraction of your 10 MBPS maximum
throughput. After complaining to Network Provider A1-ISP, they decide that they
will upgrade your local Hub 216 to a Switch, maintaining your 10 MBPS port to
the Internet. But, that's no good you say, 10 MBPS so far seems too slow, you
already have that speed! Well, after they install it, your Web surfing is 10
times faster, even though A and B are still transferring that 1 gigabyte file
from last week, and you still have a 10 MBPS modem. As this example implies, a
switch provides dedicated bandwidth to every port, and activity on any port does
not impact the throughput on another. It does this by having a high-speed
backbone that has much more bandwidth than any one port, and thus explains the
greater price and desirability of Switches versus Hubs. :-)
|
