Part I of II
The broadcast video server is not quite 10 years old and already a number of ancillary capabilities and components have become commonplace in their implementation. Today, the video server itself may only be one part of the multisegmented sections of a television broadcast media storage system. An entire solution includes a video server, ingest (or input) devices and a server automation subsystem with external archive.
It is the archive that now seems to add the most mystery to today’s complete media solution and will be the subject of the next series of installments. The past several months of this TV Technology column has provided many in-depth tutorials on data-tape technologies. The reader is encouraged to review previous issues for specific details as we will now be looking at how the archive works and how to select the proper components.
The video server archive is made up of various components. Other than the video server, there are devices that allow the data to be removed from on-line activity and store in near-line or off-line fashion. Generally this is a data-tape subsystem but there are also solutions that involve direct to videotape archive.
These data-tape transports generally reside inside an automated tape library (ATL), controlled by a robotics manipulator. Beyond the ATL, there are additional software and hardware components that comprise the balance of the archive system. These range from add-on modules attached to the server to complete standalone, independent computers that manage the data flow between video servers and tape devices.
There is an operating system and its applications are directly associated with the archive manager. Additional software may be resident on the video server, on the archive library or on the automation computers that control the interaction between all these devices.
The archive manager manipulates the instruction set of the ATL to retrieve and transfer data to and from peripheral tape drives and the video server. It also requests status and responds to instructions directly from the automation system. The archive manager keeps a data set that tracks where the data resides on the archive tapes and in turn handles the commands it receives in a preset order of priorities based upon the user’s total system requirements.
WORTH ITS WEIGHT IN GOLD
The latter of these requirements adds the most depth to the system, establishing what the tape library needs to do and in what order. It is this depth of these instruction sets that truly makes the archive manager worth its weight in gold.
Some video server manufacturers provide simple spot playback and ingest (or input) operations software. Other, third-party vendors provide second-level, add-on server-resident software as well. Automation vendors also provide a third level of software, beyond station automation for program schedules, intended for only server-based library control. Beyond that, nearly all providers of server control systems look to an independent software architecture to control the data-tape library for archive purposes.
The primary purpose, as we’ve stated, for the archive manager platform is to control the flow of data between a tape library system and the server platforms themselves. The server platform consists of multiple elements all bound around one or more compute servers and interfaced either directly on the video server or between the server and the tape devices themselves.
The archive manager consists of a data movement application, a database element that tracks the location of the content, a handler that manages the video server transfer activities and an interface that describes to the tape library or tape deck what to do with the data and when. Total tape archive performance depends upon several factors including the type, structure and number of data-tape transports, the archive’s robot performance, the ability for the video server to accept streaming data and the station automation’s ability to issue and respond to commands that the archive manager handles.
Knowing these parameters helps greatly in the selection process. For example, some tape systems do not allow the use of tape partitioning, and others, although they may allow partitioning, may actually reduce by as much as a third the amount of storage possible on the given tape. How data is managed on the individual data-tapes can depend as much upon that tape’s architecture as the automation system’s abilities and degrees of control in making requests for writes or reads from the archive.
SYSTEM PERFORMANCE
System performance is determined by defining the system requirements we intend to implement. This involves determining the amount of archive activity expected and then matching it to the individual components’ performance. First, establish the expected encoding data rate for the video server.
Using MPEG-2 422@MP at 12 Mbps will produce a suitable video encode and decode quality equal to what the industry has dubbed "Betacam" quality. Note that Motion JPEG would need to use 24 Mbps for an equivalent encoding rate, which effectively will double the amount of storage required.
Next, determine what kind of content will be stored, basically the format type (programs, promotions, spots or PSAs) and the lengths for each type of material. Then set how much content per unit period (usually per day) will need to be ingested into the system, how much is transferred to the servers’ air-and-protect systems and how much needs to be transferred between the video server and the archive in both read to and write from directions.
This process requires some real thinking on the part of the various television operations departments. Those with any level of video server experience will tell you that managing the space on the drives is the most difficult process in operations and makes or breaks the operations cost equation.
The station needs to agree on just how the system will operate day in and day out, shift to shift and daypart to daypart. Often, outside consultants or systems integrators provide some of the best resources to the station.
In selecting a proper match for the archive storage system, there are four principal areas that need to be considered. The tape deck’s native drive speed, data management and archive server performance, the video server’s performance and finally the automation system’s ability to batch process commands that do not require a tape mount and dismount for each operation.
We will spend the remainder of this article and the following month describing just what these components do and how they make up the archive manager’s platform and role in the video server solution.
WORST-CASE SCENARIO
Let’s say that the station is expecting to store both program length and interstitial material on the archive. We need to look at this from the "worst-case" scenario perspective. The maximum single program length expected could be as much as two hours (a typical motion picture length.) Using an encoding rate of 12 Mbps, the data rate per hour that the system must be capable of handling is found by taking the data rate (12 Mbps) and converting it to gigabytes per hour, which equals 5.4 GB for every hour of storage.
A two-hour movie will therefore consume 10.8 GB of physical drive space.
Next, the operations director should estimate what the station is expected to air (that is, read out of the store) and what it is expected to ingest (read into the store) per day. Take the sum of these two numbers, multiple it by the worst-case number of 10.8 GB per two-hour movie and you will get approximately how much storage (tape or disk) will be required per day.
If we ingest eight movies to the store and play back five movies for air in a given day of programming, we would have 13 x 10.8 GB/per program equaling 140.4 GB of read/write activity per day.
DRIVE CONSIDERATIONS
Now we need to consider the native data-tape throughput rates. If you are considering different drives (DST, DTL or Exabyte), consider the specifications for each type of drive. For comparison, we’ll use one of the tape drive’s transfer rate of 20 MBps and the other unit as 10 MBps. It is advisable to only consider native data rates, as using the more marketing-popular "compressed" data rates is not practical for video server applications.
The data you will be recording is already encoded in a compressed format (MPEG-2); trying to compress it any more for storage on data-tape may actually increase the data size.
Next, take both data rates and normalize them to gigabytes per hour. For a 20 MBps data rate, we get 72 GB per hour; and the other unit is half that, or 36 GB per hour. Using these numbers, you can see that 10.8 GB of drive space can be loaded to or from the fastest archive tape drive at 12x real time or about 0.15 hour (around 10 minutes) to move a two-hour movie from server to store or vice versa. It will take twice that long for the 10 MBps drive.
Because the data being transferred is effectively streamed onto the tape medium, we only need to account for overhead related to mounting the tape, searching to the correct start of message and a few more seconds for all the tasks to align themselves before recording starts. For a continuous single program stream, as in the movie example, this becomes negligible. However, when you have a multitude of :30 spots, this overhead can become significant.
Now that you have a basic idea of the time required to get material into and out of the archive, and the amount of storage per day required, we’ll continue next month by exploring the other factors in selecting a video server archive system.
