Recipes for Successful Streaming Video
Applications that demand broadcast-quality
streamed video like video conferencing (a real horror in the ISDN
era), distance learning, surveillance, and intranet-delivered
corporate training applications are actually happening these days,
and producing satisfying results over gig-ether and comparable
network installations. Of course, the horizon keeps moving, but
todayís final frontier is MPEG-2, thanks to the popularity and
razzle-dazzle of DVD-Video, which is MPEG-2-based. For todayís
networks, even MPEG-2 is an ambitious but not impossible goal.
While not every corporation or networked
computing environment demands high-quality MPEG (1 or 2) video
delivery, in a way it is just the applications listed earlieróand
others requiring successful online video content distributionóthat
have been the goal of all research, development, and all-around
envelope- pushing in the network pipeline technology field. From
where some people stand, streamed, on-demand digital video isnít
just the future of networked computingóitís the future of video
A few months ago, we discussed the merits
of creating an on-demand video network [see ìWide Load Coming
Through: Designing Networks for MPEG Video Streaming,î October
2000, pp. 36-44óEd], and what it takes to fortify a network to
deliver on that promise. That installment looked at both the challenges
and potential bottlenecks for creating such a system. In this
article, weíll provide a few recipes for how that type of network
could be cooked upówith a minimum of heartburn and heartache.
We call these recipes since network design and implementation
are as subjective as cooking itself. As with any recipe, you will
likely want to substitute ingredients to suit your own requirements,
tastes, and limitations. While what we suggest here includes hardware
and software from certain vendors, these are by no means the only
products by which you could achieve comparable results. An equally
effective system might be created using other vendorsí components.
Our focus is on streaming MPEG-2 content
across a dedicated LAN to multiple clients. This requires a much
more sophisticated system than does simply downloading files and
playing them from a local hard drive, which closely approximates
downloading any file from a server. While a downloadable library
of MPEG-2 video might answer the needs of some sites, it would
inevitably create a management problem for administrators.
Among these problems is that users are
inclined to retain outdated content (the ìpackratî mentality)
with the redundant copies of content, wasting local disc space.
The size of MPEG-2 files will result in users having to wait for
content downloads, and they simply wonít utilize the resource
if it is too time-consuming. And, perhaps the most problematic
issue is whether or not copyright issues would be a concern for
the content in question. Allowing local downloads of copyrighted
content is a Napster disaster waiting to happen, the kind that
can make the big WAN on campus all of a sudden seem distressingly
Whereís the DVD-Video?
While our suggestions here focus on MPEG-2
and HDTV content, we should mention why we donít address DVD-Video.
Some may desire to create a homegrown networked-solution for accessing
DVD-Video content from workstations, however, this is not do-able
except in a purpose-built system such as for hotels (i.e., nStreamís
Hospitality system). Commercial DVD-Video is CSS-encoded, so playback
requires local access to the disc to read the license key. Even
though a networked DVD-ROM drive might read the DVD-Video disc,
it cannot provide client workstations with the required access
to the embedded key so video playback wonít occur. It might be
possible to create a system where the content was decoded at the
server then stored on a server-attached RAID device, but this
approach may just violate copyrights ? la Napster. However, if
a company masters its own DVD without a key code, it could certainly
For our purposes, we look at accessing
real-time, generated MPEG-2 streams or MPEG-2 files stored on
a network. (The actual capture component for creating this real-time
stream is beyond our discussion here. Suffice it to say that there
are many such capture solutions available.) We will also look
at 2NetFXíÝ solution for HDTV as a resource for broadcast multimedia
When assembling the rudiments of network
video streaming delivery, it is important to remember that IP
network addressing distinguishes three kinds of streaming throughput,
ï Unicast, where the MPEG-2 stream is
sent to a single requesting workstation
ï Multicast, where the stream is sent
to a defined set of receiving workstations
ï Broadcast, where the stream is sent
to an entire subnetwork
Broadcast can be problematic and wasteful
of network bandwidth, and is less applicable to LAN environments
than unicast and multicast. So for our discussion here, we will
provide recipes for unicast and multicast network solutions.
In the previous article on designing
networks for MPEG streaming, we discussed that MPEG-2 content
requires significant network bandwidth. At a minimum, a network
must be a 100BaseT to meet these requirements. In fact, we went
further and suggested employing a Gigabit Ethernet for a Video-on-demand
(VOD) system as well as discussing how to avoid potential pitfalls.
Thanks to work done by 2NetFX, 3Com,
and TeraLogic, it is possible to create viable HDTV access over
an Ethernet network. This system provides essentially three to
four separate HDTV channels in real-time.
The primary component is the HDTV streaming
server (in this case, the 2NetFX SAM RAID Server v1.0).Ý The SAM
server provides multiple streams of HDTV content to a 3Com Switch
4007 using Real Time Protocol (RTP) over standard 100BaseT. (100Mbps
Ethernet works here because the SAM server only has one ìclient,î
the 3Com Ethernet switch.) Since each HDTV stream is 20Mbps, the
server could handle up to four streams with overhead. Of course,
the SAM server could also deliver various combinations of lower
resolution content if required, such as MPEG-1 or MPEG-2 in standard
The switch connects to the clients via
a series of 3Com SuperStack II Gigabit Ethernet switches (model
3300 in our example.) These 3300 switches support 12 or 24 ports,
so the client population density can be fairly high with this
system. We are talking multicast here, so increasing the number
of clients does not increase the bandwidth use by the HDTV channels.
The workstation connects to the 3300
switch via 100BaseT and a 3Com EtherLink card, and requires a
card supporting offloaded IP networking tasks to reduce CPU utilization.
One version is the EtherLink 10/100 PCI NIC with the 3XP processor
made by 3Com.
We also recommended using Windows 2000
as the client operating system, as it handles streaming video
better and also supports the previously mentioned IP offload to
the NIC. However, you will still need an HDTV decoder at the workstation,
as Windows doesnít support HDTV natively.
TeraLogic has developed a chipset for
performing this decode, for which various vendors have announced
support. For example, Sigmacom out of South Korea will be one
of the first with a shipping HDTV decoder board. ATI also has
support for HDTV streams in its All-In-Wonder Radeon card. It
should be noted that, while the Radeon card does support the HDTV
stream, it is not an HDTV tuner/demodulator. So you cannot use
the current Radeon card to hook up to a cable TV connection and
receive HDTV broadcasts.
A second solution might be Ravisentís
CineMaker HDTV product. CineMaker HDTV supports software decoding
of HDTV streams, but also does not include a ìtunerî and so requires
a network feed instead (or locally stored content).
Finally, for the 2NetFX system to work,
you will need to have its proprietary media player, Stream Rider.
In effect, this is the HDTV ìtunerî for the SAM serverís multicasts.
Only workstations running the Stream Rider viewer will receive
the multicast. Stream Rider comes in two flavors: a freeware version
with basic playback and an advanced version available for purchase
from 2NetFX. Hardware-wise, the player itself requires no more
than the Windows 2000 OS would.
The 20Mbps HDTV stream can also run over
a WAN via satellite to remote locations. The key here is having
the T3 access and transponder time, which various corporations
do. This would allow company-wide access to the centralized video
Video on Demand
In contrast to the HDTV scenario, where
the multicast is initiated by a system administrator, this scenario
describes creating a user-initiated VOD system. Here, individual
users can request specific MPEG-2 video content for delivery to
their workstations. This design supports individual workstations
requesting MPEG-2 content.
The primary difference between a multicast
and a unicast system is that in the multicast system, the channel
requires only 20Mbps. In the unicast system, each requesting workstation
requires its own stream. Depending upon the resolution requested,
this could be up to 9-10Mbps for a DVD-Video-quality stream. So
to scale the service up to 30-40 workstations simultaneously requires
Gigabit Ethernet throughout.
This scenario shows an NSM 6000 DVD-RAM
jukebox for storage of the MPEG-2 content. The DVD-RAM drives
record the data to the disc for archive purposes. Although these
drives could also play DVD-Video discs, the content cannot be
played at workstations because of the aforementioned key problem.
The 6000 offers the maximum number of
drives available in a single jukeboxó14ówhich theoretically could
support 14 simultaneous streams using an Ultra 160 SCSI card (such
as Adaptecís 29160 or 39160) for MPEG-2 playback. An even better
solution would involve caching the MPEG-2 content onto a RAID
0 subsystem attached to the server.
The server could be a dedicated system
such as EMCís Celerra Media Server, REALmagicís NetStream 2000,
or RealNetworksí RealSystem Server Plus with the Digital Bitcasting
Inc.ís MPEG-2 Plug-in. By again attaching the server to a Gigabit
Ethernet switch, such as 3Comís 4007 or SSII 3300, we can provide
30 simultaneous MPEG-2 streams to client workstations.
The client workstation, as we mentioned
for multicasting, should support offloading the IP networking
tasks to the NIC. So again we use a 3Com EtherLink 10/100 PCI
NIC with the 3XP processor to handle incoming network traffic.
Here again, we recommend using Windows 2000 as the client operating
At the workstation, an MPEG-2 player
is needed. There are many available, or one of the commercial
DVD players such as CyberLinkís PowerDVD or InterVideoís WinDVD
can be employed. (PowerDVD seems to hold the lead for best performance
and features, although WinDVD isnít far behind.) Both these players
need at least a 333mHz CPU, but since we specified Windows 2000,
weíd expect at least a 500mHz or faster system anyway.
While you might expect Windowsí own Media
Player would support MPEG-2, it does not do so natively. It still
requires a third-party MPEG-2 decoder along with the Media Player
in order to display the streaming content.
>While either of these systems wonít
be cheap to implement (running upwards of $50,000 with both the
video server and Gigabit Ethernet switches), they do provide the
ultimate in user online experienceófull-motion, high-resolution
video on demand. For professional training facilities or broadcast
houses, this expense would seem quite in line with the other hardware
requirements needed. Fortunately, with the strong capabilities
of todayís PC platform, plus the significant drop in prices for
this equipment, more administrators can add streaming to their
menu of services.