March 2001|No single application has ever left network administrators reaching for the Rolaids like delivering digital video. Harbingers of heartburn lurk everywhere. High expectations have always met with complications and cold, hard reality. Somewhere at the other end of a painfully stretched pipeline, as the video emerged ever the worse for wear, lessons were learned and expectations diminished. Literally exponential growth in network throughput has yielded more light at the end of that tunnel, and brought the safe and speedy streamed delivery of TV-quality MPEG-1 well within the reach of a significant portion of today's more-robust corporate and institutional networks.
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," www.emedialive.com/EM2000/doering10.html), 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.
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.