FEATURES Continued

Video Servers: Live From Your Network

by Todd Tannenbaum and Andy Covell with Dave Brown

To view theReport card.

For low-bit-rate video, Intel boxes with sufficient memory and fast drives serve as fairly capable video servers. Video servers based on RISC chips with RAID technology and high-speed serial interfaces such as Ultra-SCSI, Fibre Channel or Serial Storage Architecture can scale to deliver more streams and/or higher quality video, providing a higher-end solution for enterprise and Internet client desktops.

The Network Two requirements make video delivery across digital networks extremely challenging: bandwidth and isochronous media delivery.

For bandwidth, video at 30 frames per second (fps), 24-bit color and 720x576 pixels is very good quality by most people's standards. You need about 300 Mbps to transmit uncompressed video of this quality. You can decrease the quality to 15 fps, 16-bit color and 352x240 pixels and provide good video, yet need more than 20 Mbps of bandwidth. If you consider the future of high-definition TV (HDTV) video at resolution s up to 1,080x1,920 pixels at 24 fps or 30 fps, bandwidth requirements for uncompressed video soar into the stratosphere. As a result, compression technology looms large in any digital video networking scheme (see "The Big Squeeze") .

For isochronous media delivery, quality video playback will not occur if there are excessive delays or significant delay variation (also called jitter), since clients need continuous, uninterrupted data flow to achieve smooth audio and video playback. Though the video component of a stream can tolerate some data error and loss (an occasional dropped frame won't be noticed), the audio stream is less tolerant of data irregularities, since dropped packets and jitter can be distracting and render audio totally unintelligible in extreme cases.

These two requirements necessitate the juggling of quality, scalability and cost to implement video on the network--a challenge that has led to an array of new products with very different methods of streaming video across the network or the Internet to client desktops.

Low-end products typically use proprietary compression schemes and target smaller, lower resolution video images, lower fidelity audio and frame rates below 15 fps. Higher-end solutions offer larger resolution images at 15 to 30 fps, using standards-based compression such as H.261, Motion-JPEG, MPEG-1 or MPEG-2.

Another major product differentiator is the network transport. All intranet and Internet solutions use IP, while some high-end LAN, enterprise and WAN products use ATM directly (many IP video solutions will run over ATM as a Layer 2 backbone or LAN transport).

ATM benefits from having been designed from the ground up for very demanding data-transmission requirements, such as those posed by real-time video. This connection-oriented, cell-switching solution offers a quality of service (QoS) mechanism, so adequate bandwidth and isochronous data delivery can be ensured. It even offers an interface for video applications, called ATM Adaptation Layer 1 (AAL1), which is designed specifically to transmit constant-bit-rate audio and video data, though many video applications run over ATM Adaptation Layer 5 (AAL5), a variable-bit-rate service used in many ATM environments.

ATM products are still new and largely untested, and the cost of implementing ATM as a general network architecture, including ATM to the desktop, remains high. But some applications, notably those in the health-care and entertainment industries, require the high-quality video delivery that ATM affords. ATM implementations run the gamut from those that offer a proprietary middleware layer between application-level multimedia programs and the ATM transport, and hardware solutions that bundle a codec with an ATM switch.

Where IP is already in place, implementing network video is more straightforward and less expensive, so many network managers will explore IP-based video first. The primary problems with video over IP are the lack of guaranteed bandwidth, given IP's connectionless orientation and "best effort" packet delivery, and the absence of standards for media formats and client/server transmission negotiation/feedback. The Internet Engineering Task Force (IETF) and industry efforts are well under way to address these problems; the Resource Reservation Protocol (RSVP) defines Internet bandwidth reservation, and the Real Time Transport Protocol (RTP) and Real Time Transport Control Protocol (RTCP) standardize real-time media format and transmission. RSVP/RTP/RTCP-compliant products (including routers and switches, applications software and operating system upgrades and utilities) will appear late this year and on into 1997.

Video applications that offer one-to-many (that is, video transmitted from a single source to many clients) or many-to-many (typified by a multiparty videoconference) video across packet-switched networks also differ in how they use bandwidth. Some products deliver a separate stream of data for each user, known as unicasting; for one-to-many applications, a unic ast streaming server is used. Products that offer unicasting for many-to-many applications use a reflector to send all streams to all users. Others multicast a single stream to multiple recipients. Multicast streams can be restricted to a single LAN segment or the enterprise intranet, or be sent out over the public Internet.