Digital Video for the Next Millennium


This publication is copyright 1999 by the Video Development Initiative (ViDe). The document may not be reproduced, in whole or in part, without written permission from ViDe, except that a single copy for personal use may be printed by the reader. Please direct all comments to the author of this white paper.

   


Section Three: Selecting a Client/Server System
[You can view/print this section with Acrobat Reader.]

Digital audio and video exist today in a state of paradox: demand for digital files in audiovisual formats is great; mature standards supporting digital video and audio on optical media (CD, CD-ROM and DVD) and broadcast systems (satellite, TV, HDTV) are widely available. Systems to support digital video, however, while offering exciting functionalities and tremendous potential, are still emerging rather than proven, particularly in critical areas of interoperability and adherence to open standards. It is possible to select the right system for your needs, among many good, fairly solid offerings, but more care must be taken than in the selection of client/server systems to support electronic text. In early 1999, selecting the right digital video client/server system to grow with your developing needs is still a risky venture, requiring careful planning and needs assessment.

Hardware and software must be selected for two separate but convergent processes to support digital video: encoding (file creation) and service (file storage, transmission and display). Generally, these two processes are completely separate purchases, yet they must seamlessly interoperate. A major problem with digital video, even in 1999, six years after the adoption of the MPEG1 standard, is the fact that most digital servers remain sensitive to the digital encoder card used to create MPEG1 and MPEG2 files, as well as to the decoder cards used to read MPEG files, particularly MPEG2 files. The situation improves each year but remains a frustrating and expensive problem to solve, depending on the systems selected. Forcing interoperability can involve custom API programming, particularly at the client end, serious performance issues at the client, and, in some cases, re-encoding of the video assets.

How can this problem be addressed? If at all possible, the encoding system and the client/server system should be selected in tandem or at least with due consideration to the interoperability of both processes. Don't encode too many files before knowing that the encoding system selected can be supported by the chosen client/server system. Otherwise you may be limiting your options to a client/server system based on the encoding system rather than on user need. It is tempting to say that the more expensive system should be chosen first. But which system is more expensive? In actual dollars, a client/server system will generally range from $15,000 to $100,000 while the encoding system ranges from $300 to $10,000. However, video encoding is a time-consuming, labor-intensive process. The cost in staff hours is much greater for encoding than for client/server set-up and support. Also, like all magnetic media, videos have a fairly short shelf-life, which decreases, with each use. Rare, irreplaceable videos should be encoded only once, and then digital use copies should be struck from the digital master.




It is best to give precedence in selection to the client/server system. The client/server system provides the functionality to support current user needs and to respond to changing need. Therefore it has the greatest impact on user satisfaction. Any encoder system supporting MPEG standards at an acceptable level (composite bit stream for MPEG-1, main level for MEPG-2) is going to produce acceptable files for the user, provided the operator creating the files is competent and well-trained. The human eye cannot distinguish small differences in quality among MPEG files. Problems with the client/server system, such as denial of service, jitter and poor audio/video synchronization resulting from streaming problems, incompatible files, client interoperability issues, or network overload will be very noticeable to the human senses. When selecting a client/server system, load a copy of the client on a range of local computers and test MPEG1 files created from different encoding systems. These files may be created in-house, "borrowed" from other institutions, or found on the web. For example, the Library of Congress now offers MPEG videos for view. Test different frame resolutions, bandwidth encoding speeds and, preferably, 30 frames/second. Test files with audio (talking heads, music) and video, high action, etc. Compare playback quality among vendor clients and also compare playback quality against inexpensive or shareware players, such as Window Media Player, VMPEG-1.7 from the MPEG Software Simulation Group, or Xing MPEGPlayer.

It is possible, and sometimes unavoidable, to select the encoding system first. Most client/server vendors test encoder cards for interoperability and either publish acceptable encoder systems on their web pages or provide that information to prospective buyers on request. A fairly safe strategy is to purchase an encoding system supported by the largest number of client/server vendors. If you have purchased an encoding system that is not widely supported by client/server vendors, your options are to negotiate, or provide in-house, custom API programming to create hooks to your files or to select a vendor with very open file support, providing streaming and client playback independent of the encoder card and encoding software used. Always test a system with your encoded files before purchase, however, regardless of vendor claims.

Decoding at the client end is another significant issue, particularly for MPEG-2 service. Many vendors support hardware decoding only and may be very limited in the different cards they support. Again, client/server vendors publish tested decoder cards or should provide this information on request. It is important to know your client population before selecting both the encoding and the client/server system. Do you already have an widely-deployed decoder system that you do not want to replace? Are you supporting a controlled user base, such as a computer lab, or a large heterogeneous user population with varying and unknown operating systems, processing speeds and RAM? Are you supporting a wide range of bandwidths, such as different LAN topologies and dial-up traffic? What percentage of your user population uses Windows, MacOS or Unix desktops? Which Unix desktop operating systems must be supported — Linux or a vendor-proprietary OS, such as Solaris or Irix?

The installed user base is a critical criterion for selecting both the encoding system and the client/server system. You can control client conditions by purchasing a system for a managed computer lab but you risk serious user dissatisfaction. Most users won't settle for anything less than full access at their desktops — and the system will be blamed for performance failures, not the inadequate desktop. If you are serving (and most of us are!) a heterogeneous, somewhat unknown user population, it is best to select flexible systems — encoding systems supporting a range of bandwidths and standards and client/server systems supporting a range of bandwidths and offering a range of clients from web plug-ins to system-proprietary clients.

There are several components of a system or vendor selection process.