How much performance can be squeezed from a 1RU device when its primary purpose is to ingest and play back video clips? Perhaps surprisingly, it's an amazing amount with today's technology.
For example, it's possible to get four SD/HD channels, a few days of HD storage, an extensive array of video codecs with file interchange and a long list of other capabilities. A couple of years ago, it would have been considered lucky to get a small number of channels or file interchange capabilities in that space. Storage, codec flexibility and many other functions we now consider “must have” features would have been sacrificed in the process.
Managing the I/O package
Packing more performance into an increasingly small space is expected as technology advances. Vendors are divided into two camps for the I/O part of the server: those that favor hardware, and those that favor software for handling compression and decompression.
Either approach can drive down the amount of space a server will occupy in the rack with the appropriate application of technology. The hardware approach offers a solid fixed performance, while software brings the ability to leverage the CPU performance cycle to improve system capabilities over time.
Many players in the server space have adopted software. It scores over hardware as it adds flexibility. New codecs, compression quality improvements and a whole host of other capabilities can be added over time. These include capabilities that are not accessible to a hardware-based solution without board or chassis replacement.
Software updates can be made at little or no cost and are non-invasive; it is not required to open the machine to make changes. More value is packed into the solution, consuming the same amount of space. Relative density to functionality often favors a software solution.
Software also allows a simpler physical interface card that connects to the outside world because there is no encode or decode chipset needed, reducing the overall complexity and cost. This cost impacts the end user a second time when upgrading a server to add a new codec or feature set. The hardware approach means a costly board, module or chassis replacement. The software approach means a download to a USB drive to upgrade the machine.
What drives storage performance?
Standards-based IT computers, simple I/O cards and software-powered encode and decode solutions keep density high and offer great value. Be sure to evaluate the underlying storage system performance to get the best overall performance. It will determine what you can accomplish and is a key element in deploying an effective solution.
A number of factors need consideration:
- Do you need to share the content with other devices?
- How quickly do you need access to content that is entering a system?
- Will you need to edit, trim and/or sub-clip to export content during ingest?
- How much content do you need available at one time?
To understand how much performance is needed, we'll consider two scenarios: a simple ingest and playout solution that relies predominantly on file-based ingest, and a production environment where lots of users need access to content, managing ingest, QC, editing and playout.
The objectives in each case are to drive value through the system by minimizing costs and processes, and to avoid downtime and time-consuming steps when delivering a product from the system. We will also consider the impact of space and power consumption.
Simple ingest and playout performance
Playout systems typically rely on an MPEG-2 based codec. However, with the HD trend and continued growth of file-based content delivery, H.264 is well positioned to dominate as the playout format of the future. It is, therefore, important to support both codecs.
While it is true that transcoding (converting content from one codec type to another, which essentially re-encodes it) can be used to support a playout server's MPEG-2 requirement, it does not support streamlined performance. Transcoding is expensive and time-consuming, increases workflow complexity, and adds generational loss to already highly compressed content.
Skipping a transcode or even a transwrap makes the process simpler and has a direct ROI impact. The transwrap process is where video and audio essence remain the same, but the file type and, hence, the way this data is packaged to suit a different server or editing system is changed.
The ability to pack a lot of functionality into a 1RU device today means combining file import of MPEG-2, H.264 and other codecs, seamless playback of these codecs with up/down/crossconversion, aspect ratio conversion, AFD and other metadata management. The large amount of processing tasks being handled inside the server reduces the number of downstream devices needed.
The individual chassis can do a great deal and is likely a great fit for this case. It is possible to deploy this type of solution as a single box product or look to a shared storage approach that uses the same I/O chassis. Both have merit based on operational needs. This means it can be an edge server device, part of a disaster recovery system or a component of a transmission SAN, or it can serve other play-to-air functions.
Complex production system performance
Production systems vary but typically feature baseband ingest, file-based ingest, editing and content delivery. Access to archive material may also be required. Whether the system is for news, high-end studio production work, sports or content preparation, ad hoc access to content is needed. It should be assumed that any user has complete random access to any content, starting at the time when ingest begins.
Because access is effectively random and speed of access is often important, we cannot silo bandwidth in different storage systems based on available functionality. This implies a single shared storage solution.
The objective is to minimize the time delay in making content available to QC, edit, playout or for file transfer out of the system. The shared storage system will need to guarantee a sustained quality of service, both in data delivery (every frame on time, every time) and continual uptime.
Drives never fail at a convenient time, so when they do, they should not cause degraded system performance. Neither should a storage enclosure failure or the act of rebuilding failed drives. Appropriate application of technology such as RAID-601 (RAID-6 for drive parity protection, RAID-0 to stripe across the RAID-6 volumes to provide high bandwidth, and RAID-1 to mirror storage so that the bandwidth is always available, even if an entire storage enclosure or sub-system is offline) makes the shared storage system available and fully functional, removing concerns over reliability.
The amount of bandwidth needed depends on the compression scheme chosen and the number of simultaneous video streams being serviced. Table 1 provides a good guideline in assessing bandwidth needs.
It is fairly simple to determine needs when the system is initially designed. Knowing where you might need to go over time is less predictable. Therefore, it helps to have an architecture that can scale both bandwidth and storage capacity over time, ideally independently of each other to avoid wasting resources. This provides options if there is a need to add more services, change codecs and/or adopt new workflows as time progresses. It also means support for speed improvements in connected sub-systems such as editing (rendering time, etc.), file-based QC processing, read and write performance of the archive system and other functions that are non-real-time.
In our first example, we discussed a playout server that can combine MPEG-2 and MPEG-4. In the production space, it might mean mixing, for example, Avid DNxHD and Panasonic DVCPRO HD and/or AVC-Intra. In news, this could be significantly more complex. SD and HD sources are likely to mix, and non-broadcast sources such as cell phone footage come into play.
Mixed codecs do not present much of a challenge from an editing standpoint. From a baseband ingest and playout perspective, it rules out hardware solutions or means you need a different server chassis to handle different codecs. This is expensive and affects space, power and workflow efficiency.
Again, the software approach to servers resolves the problem because an appropriately designed server will have codec flexibility. It can switch codecs, on an ingest-by-ingest basis if necessary. And it will play any codec, in any resolution, back-to-back in any order seamlessly.
Latency is another key performance metric to consider. It will take a finite amount of time from the moment a file or baseband ingest begins for it to be available for QC, editing, playout and file transfer. That latency should be as short as possible. This is easily handled by a well-designed storage solution that offers deterministic turnaround time both for ingest and export/playout. This performance metric should not change as the system grows.
The role of a server may change from day to day in some production environments. This might occur in a studio situation where the number of cameras used on a given day changes, or the resolution or codec required changes.
There are two key approaches that help add efficiency. First, servers can be part of a common pool of resources, rather than allocating a fixed number of servers to a studio to handle the worst case scenario. Second, having a quick and easy configuration tool with a set of predefined configurations or templates that lets you change the configuration from a drop down menu makes changing the server setup quick and trouble-free.
Summary
If we combine functions of the basic server building block and allow it to perform more than the standard ingest and playout role, we can reduce the number of individual box products needed in the broadcast chain. These multifunction servers have combined functionality that offers a variety of savings: power and HVAC, space and maintenance time, and faster deployment times.
While we have discussed two examples where higher density I/O, advanced storage and system performance are advancing rapidly, the concepts discussed here can be applied to other solutions. The way storage systems are architected clearly defines the optimal performance they are able to deliver. Everyone's workflow has its unique requirements, so solutions that are flexible and cost-effective prove their worth in the long run.
Ingest and playout channels = one stream per channel Editors = four to six streams each File import = variable; internal sources, GbE or 10GbE, external sources vary File export = variable; internal targets, GbE or 10GbE, external sources vary Archive = as fast as the cache or sending/receiving archive system will allow A stream is the declared video codec size + audio data + ancillary data needed. For example, MPEG-2 at 50Mb/s with eight channels of 24-bit audio and three ancillary data lines is approximately 62Mb/s (50 for video + 9.2 for audio + 2.8 for three full lines of ancillary data @ 1080i/p).
Table 1. Shown here is a guideline in assessing bandwidth needs.
Andrew Warman is product marketing manager for servers, editing and graphics at Harris Broadcast Communications.
