This article takes a look at a new class of machines called
video servers. Here we examine the major application types and look
at the performance requirements and how they affect the hardware
and software design.
There are two major applications of the digital technology. One
is for ad insertion, which is of interest mostly to the cable
television industry; the second is for a general class of problem
known as video on demand (VOD), which can be a cable TV application
or an enterprise training application as well. The ad insertion
application, or rather the economics of ad insertion, have been
driven by storage costs. VOD, because of the need for seamless,
real-time, two-way interaction between users (subscribers) and the
server, had to wait for compression technology and reliability
improvements, as well as storage efficiency.
A video server is the multimedia equivalent of a data file
server. It is a full computer system, including storage,
processing, and input output functions. In addition, it contains
video encoders and decoders to convert analog content into digital
and vice versa. The difference between ordinary data files and
video data files places extraordinary demands on the architecture
of a video server. Video data, particularly MPEG-2 data, differs
from typical computer files in that the MPEG file is a large,
continuous, and complex stream of information that must be managed
as it travels through then entire system.
VOD can actually be thought of as two classes of applications.
Near video on demand (NVOD) is a set of several video streams, with
starting and ending times that are separated by some fixed interval
(for example by 10 minutes). Hence NVOD is a schedule-based
broadcast service. Because the video streams are transported
separately, a subscriber or viewer can choose when to begin viewing
the content by picking a start time that matches the NVOD schedule.
Should the subscriber stop viewing in the middle of the program it
is possible to redirect the viewer through software control to
another stream to pick up the video content near the point where he
or she left off. Since there is only a redirection and no
subscriber interaction with the video stream, only one video stream
per time interval is needed an danynumber os subscribers can access
the ocntent on any one of the video streams at any give time. The
critical parameter for NVOD then is the number of separate
intervals needed, which determines the required number of video
streams the server must process.
In contrast to NVOD, VOD allows subscribes or viewers to see
video content at any instant they choose. To make this possible,
the video stream must be capable of being started on subscriber
command. Since any subscriber can access the video content at
anytime, the hardware and software must support a separate
independent stream for each subscriber. The critical parameter
here, then, is the number of video streams that can be processed at
one time. In many industrial or real-world applications, the
specification for the number of simultaneous streams a server must
process can be determined by probability analysis, not unlike
telephony traffic theory, which determines how many switch ports
are needed to support a given number of users and phone lines.
Because each user can request any VCR-like function at any time in
a true VOD environment, it is necessary to have separate,
independent video streams for each active user. Here again, the
specification for the number of streams that can be processed at
any instant is a critical parameter, often determined by some sort
of probability analysis. The ability of the server to respond in
real time to input commands rom the viewer is also a critical
VOD obviously requires more bandwidth than NVOD since VOD
systems have to process a larger number of video streams. In most
community cable systems, if VOD is offered as a service, three to
six video channels are usually set aside, regardless of the number
of titles offered.
When looking at the hardware and software architecture for video
server computer systems, the following parameters are usually the
first to be considered:
- Server Output Capacity
This is measured by the number of simultaneous video streams which
the server can process. Traditionally, these streams originated in
external storage devices and were switched onto the distribution
network as required. Today many designs distribute the stored video
data across RAID disks which allows multiple access to the files.
With RAID technology, a stream is not stored as a complete data
file in one place, but is created as required by playing segments
stored on each of the disks in the array.
- Storage Capacity
In video server terms this is defined as the total hours of stored
content available to the system. Some systems may not use an
all-disk storage design, but rather use a hierarchical design,
where some or all of the data is backed up on lower cost secondary
(and slower) storage.
- Independence of Video Streams
With independence, the video data in each stream can be
independently accessed and controlled.
- I/O Performance
This term is interpreted in a way that is peculiar to the
application. I/O Performance is how well the inut and output
channels move entire streams of video data and this is different
from how a computer file server works. Video files are relatively
long and must be delivered as a continuous stream. Therefore video
server I/O channels must have direct access to video content
storage to be effective; buffers are not the best design.
- Operating System Performance
This refers to the need for a video server operating sytem to meet
the I/O expectations. "In-kernel" buffer management is a term often
used to describe the method of managing data movement directly from
content storage to output to improve the operating system
This is very important in most video server applications, since it
addresses the way server or storage capacity is added over time.
Scalability is achieved by adding CPUs or memory to a server, or by
networking complete servers.
- CPU Speed
Often this is used to describe the system's capability to recover
from potential system and component failures to ensure subscriber
video services remain available. If the video server generates $X
in revenues per hour, then downtime is expensive, and easily