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

Tech Video Expo

eNewsletters
DVD TodayDigital EarfulSubscript
Ad Links

Recipes for Successful Streaming Video

David Doering

 

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 itself.

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 small.

 

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 be played.

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 developers.

 

Picture-Moving Basics

When assembling the rudiments of network video streaming delivery, it is important to remember that IP network addressing distinguishes three kinds of streaming throughput, as follows:

ï 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.

 

Scenario One:

Multicast HDTV

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 TV resolution.

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 library.

 

Scenario 2:

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 system.

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.


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