Video Server Appliances

Two Out of Three

When sending video to the desktop, you want to deliver high quality in real time using minimal bandwidth. And while you can satisfy two of these criteria, meeting the third is virtually impossible. Often when you have high quality and low bandwidth, you sacrifice real-time delivery. With good quality and real-time delivery at either end, bandwidth slides between them, growing toward real-time delivery and shrinking toward good quality.

Although products are getting better at delivering high quality using low bandwidth, longer processing times are the trade-off. The Holy Grail of networked video is a full-screen, 56-Kbps signal using almost no bandwidth. Compression rates like this aren't really achievable, but it's nice to dream.

The Best Codec

Microsoft and RealNetworks have proprietary codecs for video and audio transmission. In contrast, Apple provides a framework that supports many codec standards, including MPEG-4, Pixlet and Sorenson. Cisco Systems also uses a framework-delivery method, but only for its IP/TV products.Codecs have come a long way over the past few years, as have the microprocessors they rely on to do the compression work. Even so, in most situations you'll need to choose between real-time delivery and high quality. Contrary to what codec vendors would have you believe, the best-quality video can't be delivered in real time using off-the-shelf computing hardware--you must have hardware that's specially designed for video compression.

Microsoft's Windows Media 9 and the ISO MPEG-4 standard are two formats that are gaining a lot of attention. Both do a good job, whether or not real-time delivery is involved--and both have their proponents and detractors. What differentiates them is their degree of openness. MPEG-4 is an open standard; WM9 is created and controlled by one vendor--Microsoft. Both MPEG-4 and WM9 are included with MPEG-2 as compression standards for high-definition DVDs.

Shrinky Dinks

On the encoding and compression side, there are several factors to consider. At the head end, do you want to store the video you're delivering for later use as video on demand, or will you stream it just once in real time? If you need to store it, Fibre Channel, SCSI and its big brother, Ultra SCSI, are synonymous for storage; but SATA (serial ATA) is making inroads because it's cheaper than SCSI, and its drives offer greater capacity.

In addition to drive throughput, you need to think about the network and hardware capabilities of the server. The hardware is less of an issue for sending out just one video stream than it is for delivering several simultaneous streams of different video. Streaming video can be sent in unicast (one-to-one) or multicast (one-to-many) sessions. Multicast is easier and more efficient in terms of server hardware and bandwidth, but if video on demand is in your future, you shouldn't rule out unicast.Getting the video to its destination is just part of the equation. You also must consider the type of management available. Can the products be configured and monitored remotely from a terminal session, SNMP or, better yet, a browser window? Do you need those capabilities?

You may want access to log files or reports. A W3C (World Wide Web Consortium)-compatible file is easy to parse by many log analyzers, and the log files are handy for analyzing which videos are being viewed the most and by whom. Log files are also invaluable for determining peak usage times and when upgrades might be necessary.

Beware of vendors pushing one-box solutions--they can become so overwhelmed trying to pat their heads and rub their stomachs that the video quality will suffer. Conversely, the more pieces of equipment you have, the more likely it is that one of them will fail. As a rule of thumb, it takes a minimum of two machines to stream live video: one computer or video appliance to encode the video, and another to do the actual streaming. If you need to archive the video for rebroadcast, you should assign this task to a third server or device.

Securing Your Rights

If you need to protect the video you broadcast, look to manufacturers building devices that actively support some form of digital rights management. DRM can protect your video from being copied, archived or played on unauthorized systems. With many enterprise customers creating their own in-house videos and audios for training and sales, it's important to maintain control over how and by whom these resources are used. For more details about how DRM affects your enterprise, see Security Pipeline's "DRM Protects Data At the Source."Darrin Woods is a Network Computing contributing editor. He has worked as a WAN engineer for a telecom carrier. Write to him at [email protected].

1) Will video be delivered to the desktop or TV?

2) What level of quality is needed at the destination?

3) Over what type of network will the video be transported?

4) Do you need to store the video or just transmit it live?5) Do you need to deliver video on demand?

6) How many users do you want to accommodate at any one time?

7) Do you require logging features for billing or other purposes?

To deliver video to the desktop, you can transmit over the corporate Ethernet network, but without any flow control or some sort of traffic management like QoS (quality of service), you'll experience a large number of dropped frames. You also can deliver over the Web from within a plug-in-equipped browser window or from within a separate player application. Both plug-in-equipped browser window apps and separate player apps are dominated by three vendors: Apple Computer, Microsoft and RealNetworks.

If you transmit from within the network, transmission flow control can be handled by the transport protocol. RTP (Real-time Transport Protocol) fills a gap between UDP and TCP protocols to create a framework to easily transmit streamed data. Data can be placed in the transport stream within one of several protocols, including RTSP (Real-time Streaming Protocol) and MMS (Microsoft Media Server), SDP (Session Description Protocol) and HTTP. Some of these can be used in conjunction with one another to enable better transport of the video data.If you go outside your corporate network for transmission, other options to consider are ATM (asynchronous transfer mode) and DVB-ASI (digital video broadcast-asynchronous serial interface). ATM was designed to transmit video and voice traffic over data networks. It carries the ubiquitous cell tax, however, and many carriers charge a premium for ATM circuits; but if you happen to have an ATM network in place, it's well-suited for video transmission.

DVB-ASI is relatively new to the United States. Geared for video on demand, it places multiple MPEG-2 video streams within a Sonet frame. Although it's most appropriate for service providers wanting to get into the video market, enterprise customers can use it to transmit corporate video. Supported by many vendors, including DVEO and Motorola, DVB-ASI is quickly becoming the de facto method of transporting video over fiber.