DVD PRO Conference
V2B Conference
TechVideo Expo
Current Issue
Article Archive
News Archive
Buyer's Guide
nbsp; Home Magazine eNewsletters Events Contact Navigation

Current Issue Current Issue
Buyers Guide 2001

Buyers GuideCompany SearchProduct Search

News Indices

CD TrackerCD/DVD-ROM IndexFact, Figures & FindingsConference Calendar

NEW! 2002 Online
Buyer's Guide

DVD TodayDigital EarfulTechVideo NEWSSubscript
Ad Links

dvd today feature

Wide Load Coming Through:
Designing Networks for MPEG Video Streaming

David Doering

EMedia Magazine, October 2000
Copyright © Online Inc.

T oday's network design is a far cry from that of just five or six years ago. Back then, it seemed a nifty trick just to get data back and forth from local workstations to servers at some reasonable speed. Then someone decided to show off what you could do on the Internet with streaming video. Sure, the images were crude, worse than MPEG-1 from a 2X CD-ROM on a 486, but they were moving and mostly in sync with the sound. That's when we network administrator types began to talk seriously about things like Quality of Service (QoS) and higher delivery speeds. The definition of data shifted from text info to full multimedia.

Now, as we near the dawn of our new millennium, streaming video technology continues to promise a richer, more satisfying experience on the Internet. Unfortunately, the Internet's lack of bandwidth still limits its ability to deliver on this promise, despite major strides in strengthening the backbone. Fortunately, although this promise remains elusive for most Internet users, streaming video is an enjoyable reality for many intranet users today. In this article, the first part of a two-part series, we'll look at practical design for offering streaming video over local area networks (LANs) and wide area networks (WANs), such as those found on university and industrial campuses, where distance learning and training programs increasingly demand good-quality streamed video. In part two, we'll describe the exact components required for the various scenarios.

As for image delivery, we are not just talking about MPEG-1 or using Real Video or Media Player formats; today's networks can handle MPEG-2 (i.e. DVD-Video) streams and HDTV broadcasts as well. Curiously enough, this latter capability may come as a surprise. While the consumer market will wait years for HDTV to penetrate the installed base, today's computer monitors can display HDTV feeds just fine. Several vendors, including Sony and the threesome of 3Com, TeraLogic, and 2NetFX, are already working out the encoder/decoder hardware, software, and distribution video network architecture to support this. So you can well have a higher-performing video experience at your desktop more than you can at your home theater–and without nearly the investment you'd expect.


Two things have contributed to the ease of creating effective streaming video solutions on LANs and WANs: first, the plummeting price of Gigabit Ethernet hardware; second, the incredibly increasing capabilities of individual workstations.

With Gigabit Ethernet networks–i.e., 1000BaseT–prices have fallen much faster than expected. By mid-year 2000, four-port Gigabit Ethernet switches were available for under $1,500 with network adapters going for under $300; part of what is driving down the price is the onrush of newer technology itself.

At Networld+Interop in Las Vegas in May 2000, chip vendors were expected to announce the new spec for 10Gb Ethernet. More remarkably, several vendors actually showed working prototypes of the technology. The buzz was that actual product wouldn't be years off, but rather just a few months or maybe a year away.

Meanwhile, the average workstation four years ago was a Pentium 120mHz with a 2GB hard drive and 32MB RAM which sold for $2,500. Today, a system with a 750mHz Pentium III with a 15GB drive and 128MB RAM sells for under $1,000 (plus $200 if you need a monitor.) Along with the upgraded CPU also comes the faster bus–100mHz versus just 66\mHz–and a wonderfully upgraded video card with 16MB versus just 4MB with the older system. Simply put, it's much, much easier for today's systems to display video.


Designing a network for MPEG streaming means addressing four basic considerations:
  • What is your input?
  • What is your available bandwidth?
  • What is your destination?
  • How many users do you want to service at once?

Network-ready digital video can be streamed in real time (such as video conferencing or a live event broadcast), which is broadcast from networked storage libraries or delivered on-demand to a single user from those libraries. Solutions are available for both types. For our discussion here, we will focus on a Video-on-Demand (VoD) system from an optical disc source. IP network addressing distinguishes between three kinds of streaming throughput:

  • Unicast, in which the video packets stream to a single workstation
  • Broadcast, in which the stream is sent to an entire subnetwork
  • Multicast, in which the stream goes to a user-defined set of workstations

Of the three, Unicast is the most challenging, since you have to design the system to support sending separate streams to each workstation. Broadcasts are much simpler, since a single stream supports as many workstations as want to tune in (à la TV broadcast). Most network routers, however, limit broadcasts to just a single subnetwork. (Routers do this to prevent overloads called broadcast storms from flooding the entire network.) Multicasts are fully supported in IP networks, but often are not implemented since they do require setup. We'll see later that sending HDTV signals over networks requires setting up a Multicast.

While Unicast is difficult, it is the most desirable of the streaming options since it produces the Video-on-Demand structure users look for. With all three types of video throughput, users can typically request their own video when they want, but with Unicast, they can pause, rewind, and replay the stream, something they cannot do with broadcasts or Multicasts.

A complete system for on-demand delivery of optical disc-derived video involves a variety of components including a DVD-Video disc storage subsystem, which could be a RAID box or a jukebox; a dedicated or shared network server; for network topology, Fast or Gigabit Ethernet; a Hub or switch because Hub-based networks cannot support MPEG-2 consistently; a PCI network card; an MPEG-2 decoder card, which is essential unless the workstation is about 1gHz; and a 400mHz or better workstation CPU.

To anticipate and prepare for potential bottlenecks, users must consider where the video will be expected to go and what it will need to get there, with network bandwidth being the most critical consideration. The video stream must pass to reach the user's monitor. The stream must do so in a timely fashion as well. This "disc-to-desk" time ideally should be the same as or less than the time it takes for the user's local workstation to present the same video.


Next, we need to have enough bandwidth to support our desired resolution and there are a variety of compression types with a number of requirement variables. It isn't the bandwidth of a single streaming video session that is important–almost every Fast Ethernet network can support a single MPEG-2 stream or even HDTV for that matter. What is important is in creating a network that scales for additional users. Each new user requires a sustainable bitrate to the desktop, and this bitrate must be consistent, otherwise the video or sound will be choppy, losing frames.


In order to understand how a consistent video stream is delivered across a network, let's look at a typical enterprise network. Most networks have one or more hubs in a local wiring closet where user workstations attach. Since the entire network bandwidth is shared amongst all users, this may reduce the average bandwidth to 1Mbps or less per workstation. This is good enough for teleconferencing or future MPEG-4 (i.e., lower-bandwidth) applications, but not for MPEG-2.

There are certainly layouts designed to make life easier for the installer than the video user, and low-cost hubs easily support typical office automation tasks, but unfortunately, leave each user with only 1Mbps of bandwidth–good enough for teleconferencing or future MPEG-4 applications, but not for MPEG-2. By substituting Fast Ethernet (100BaseT) switches for the existing hubs, each workstation can now access up to 10Mbps on a dedicated connection, which is enough to support MPEG-2 video delivery. Note that this throughput will require at least a Gigabit Ethernet backbone to the network router. That's because each switch will require its own 100Mbps connection to the video server in order to maintain throughput.

A Gigabit Ethernet backbone, when properly configured, can handle up to 70-75 simultaneous MPEG-2 video streams. A Fast Ethernet-only network, on the other hand, is limited to eight simultaneous streams. With this type of system in place, a site could then upgrade each switch and workstation to Gigabit Ethernet to support HDTV feeds to the desktop as well.


We just described how a switched Fast Ethernet network could sustain MPEG-2 playback for up to 75 workstations from a video server–which isn't quite true. In order for that to happen, we have to overcome eight potential bottlenecks to achieving effective multiple-user streaming video.

Trick Number 1– RAID Video Cache Storage

Many network servers create their video caches on RAID subsystems. (While the DVD-Videos may reside in a jukebox or may have been retrieved via a DVD-ROM drive, their contents are accessed by end-users from a RAID box.) Most data RAID systems use RAID 5 for maximum data protection. Streaming video, however, performs better from a RAID 0 configuration; data security is less important in this configuration since the content is still available in the jukebox.

TRICK NUMBER 2– Good NAS Performance

For many sites, a dedicated NAS unit serves up video content to users. However, most NAS units are not specifically tailored for streaming video. A NAS video solution needs to handle a lengthy connection with each requesting workstation to deliver its video stream. Most NAS systems are tailored for discrete, small data packet requests rather than a continuous stream of data. Newer systems are now emerging that do support MPEG video as their primary job.

Trick Number 3– Good Network Cable

Gigabit Ethernet does support Cat5 copper cabling. Copper GigEther networks are significantly less expensive to construct than their fibre-based counterparts, since both network cards and switches are less costly. However, you'll need to verify the quality of each installation to ensure support for the higher speeds. You should also verify the length of each connection to the switch; copper GigEther connections can run only about 300 feet (100 meters). Beyond that, you have to go with fibre. (Network bandwidth, of course, is also a concern. For MPEG-2 purposes, we need at least switched Fast Ethernet to support multiple MPEG-2 users simultaneously.)

Trick Number 4– Right Frame Size

Gigabit Ethernet, either as a backbone for router-to-server or router-to-switch links, should support Jumbo Frames. This generates a five-fold increase in throughput over conventional frames. Gigabit Ethernet introduces a new frame type to the protocol. Jumbo frames are super-sized versions of their regular cousins–the 1615-byte frame–in Ethernet. Jumbo Frames can be a whopping 9014 bytes, more than five times larger. This significantly reduces overhead and vastly improves performance.

Trick Number 5– Legacy Operating Systems

Network streaming users will be encouraged to discover that Microsoft has improved Windows I/O with its latest OS release. Windows 2000 supports offloading various I/O tasks, such as packet checksum processing and IP security, to the network card. Since every data packet has a checksum, every Windows 95, 98, or NT workstation took quite a hit in CPU utilization to handle this processing. For Fast Ethernet (100BaseT), CPU utilization is 21% as compared with 58% for Gigabit Ethernet.

Trick Number 6– Right Network Card

If you have Windows 2000, then you'll also need a PCI network card with onboard intelligence for handling the checksum and security processing. Legacy ISA cards in particular will not deliver a consistent stream.

Trick Number 7– Right CPU and Motherboard

Installing Gigabit Ethernet will not improve consistent data delivery unless the workstations and servers have at least a 400-500mHz Pentium II or III processor and a 100mHz motherboard. Legacy systems, such as a Pentium 233 or 300, even if fully equipped for office automation, do not process data fast enough for streaming video.

Trick Number 8– Software vs. Hardware Decoding

Once data arrives at your workstation, you will need an MPEG-2 decoder to process it. (Contrary to what some users might expect, the network transmission doesn't convert the stream to Real Video format.) If you choose a hardware decoder, you'll need a minimum of a 233mHz Pentium MMX. You'll also need an AGP video card to handle MPEG-2 streams at 30 frames per second. If you want to do everything in software, however, expect to use an 800mHz-1gHz AMD Athlon processor or better.


A streaming video network setup can be more effective than a standalone workstation's performance in displaying smooth, full-motion, full-screen video. As we've discussed, by sharing the tasks between the video server, the network card, the video card, and the workstation's CPU, the workstation can maintain a more consistent playback image onscreen than it could from its own DVD-ROM drive.

Tune in next time, when we'll look at two scenarios–DVD-Video Unicast and HDTV multicast–with products and models as a recipe for you to construct your own effective video network.

The Sweet Science: Boxing MPEG in the Network Appliance

The fundamental difference between networked and so-called "standalone" computing, naturally, is that networked computing requires that multiple products and technologies work effectively in concert with one another. With a network application as demanding as serving MPEG-1 or MPEG-2 video over LANs and WANs, highly performing, highly compatible componentry is a must.

This article looks at overarching architectural issues of creating networks well-fortified for MPEG delivery, and elements essential to avoid the inevitable bottlenecks that result when you attempt to distribute high-bandwidth content over network configurations that aren't up to the challenge. But there are other pieces to the puzzle. Of course, there are the specific components, the storage and server devices available for keeping and delivering video online in intranet environments. These will be examined in Doering's follow-up piece.

Another essential enabling factor of network streaming as we know it comes, appropriately enough, from companies whose core technologies are video-centric, or those who have at minimum set out to tackle digital video encoding and network delivery in equal measure. These companies have taken their MPEG encoding/decoding technology and implemented it in so-called "network appliances," compact MPEG hardware designed expressly with the intent of connecting to networks and serving MPEG video efficiently over them.

These products were examined in detail in Jeff Sauer's September article, "Band-Aid: Network Appliances for MPEG Streaming" [pp. 39-45], which serves as something of a companion piece to Doering's exploration of the architectural demands of network-streamed MPEG and tells a crucial part of the story. Providers of "Network Appliance" products looked at in Sauer's article include VBrick Systems (http://www.vbrick.com), InnovaCom (http://www.transpeg.com), Optivision (http://www.optivision.com), Minerva Networks (http://www.minervanetworks.com), and Optibase (http://www.optibase.com). These products help complete the picture of an MPEG-ready network.

–Stephen F. Nathans

What's This Overhead?

It may surprise you that Fast Ethernet and Gigabit Ethernet don't deliver a full 100Mbps (megabit per second) and 1Gbps (gigabit per second), respectively. Often, the rationale is that Ethernet simply is an inefficient protocol and suffers from too much overhead. Actually, there's a workstation component to the problem outside of just protocol overhead, which can be reduced using Jumbo Frames.

The CPU utilization issue hampers Ethernet throughput on all but Windows 2000 workstations. With up to 50% of the CPU cycles involved in packet processing, is comes as no surprise that there's not enough throughput. But there's also the hard drive hurdle. In fact, hard drive performance is the primary cause of slow throughput on Gigabit Ethernet; even with 10,000 RPM SCSI drives, the networks aren't fast enough to tackle Gigabit speeds, causing about a six-fold reduction in throughput alone. Fortunately, 100 Mbps is fast enough for consistent MPEG-2 playback on a workstation.

NETWORKOBSERVER columnist David Doering (dave@techvoice.com), an EMedia contributing editor, is also senior analyst with TechVoice Inc., an Orem, Utah-based consultancy.

Comments? Email us at letters@onlineinc.com.


[EMedia Live]


Copyright 2000-2001 Online, Inc.
213 Danbury Road, Wilton, Connecticut 06897-4007
203/761-1466, 800/248-8466
Fax 203/761-1444