SEWICKLEY, PA.—With the many options available for receiving, distributing and playing out video files, for both media and corporate A/V use, there’s a lot to consider when choosing the right server for your specific application.
Modern video servers are critical to playout and production workflows. As part of my job as a systems design engineer, I’m often asked which video server is the best. It’s not a question I take lightly. I could satisfy this basic request to specify a replacement for an existing video server by simply giving the client a quick, perhaps glib answer in the form of a single manufacturer’s model. However, you have to remember that consultants don’t give simple answers often, so please bear with me while I give you some background on the options.
First, you need to consider scale. There are server manufacturers that can offer credible products that provide a limited number of inputs and outputs, and others— like Harmonic, Imagine Communications, Grass Valley and EVS—that have systems that can scale quite large. If you have any intention of eventually providing many streams, we need to strongly consider systems that can scale. I don’t need to remind you that although some companies would suggest that their servers can scale quite large, the real issue is not how many I/Os can be supported, but, rather, whether the storage platform service a large number of outputs reliably.
A BUNCH OF DISKS
I was recently talking to a client about trying to use a JBOD (“just a bunch of disks”) array and I cautioned that the aggregate bandwidth was limited by the read/write bandwidth and the amount of throughput in the loop between the storage and the I/O channels. I should be clear that I acknowledged his assertion that with local disks attached to each playout channel, you can “cache” content, but if all channels are loaded fully, the math is still the same.
The storage bandwidth determines the ability of a large system to service a large number of heavily loaded channels, whether there is a local cache disk or not. Of course, if you tell me that the channels won’t ever run full-time, or perhaps that they would play mostly SD content, I would concede that a JBOD array could work. I remain concerned, however, since we talked about upper management’s plan to be the first company to provide 4K streams at high bandwidth. That complicates the problem.
The solution I suggested was to use a striped RAID array of disks so that any one stream is coming from multiple disk-read operations all the time. The more disks in the RAID structure, the better the chances are of staying ahead of the read/write bandwidth. It’s important to remember that this setup also allows for one or more disks to fail at the same time without degrading the capability of the system. It’s true that when a disk fails and a replacement is installed, the system must rebuild the media to reestablish the redundancy that RAID offers. When that is happening, the ability of the system to provide maximum bandwidth is compromised. We have to hope that won’t happen very often. Of course, since all of the new disks will be the same age, the probability is that failures will happen in clusters. Unfortunately, there’s no easy way to avoid that.
FORMAT SUPPORT
We also have to take into account the formats your facility or production department needs to support. I could specify a system using MPEG-2 only, but MPEG-2 is a pretty old format, and increasingly content suppliers are delivering files coded with H.264 (AVC) compression, which must be transcoded at least once before being ingested into your current servers. With management’s desire to move to 4K playback, I want to caution you that even AVC will not suffice.
There are servers for sports replay that have 4K ports, but it is probably too early to expect to see HEVC (H.265) supported directly. When that happens, my expectation is that lots of server manufacturers will convert to HEVC, since it offers much better performance due to lower bit rates for high-quality video. For current and near-term needs, however, I strongly suggest clients stay with manufacturers that have proven AVC capability. That will offer some performance gains, and migrates away from MPEG-2, which I think will begin to disappear in a few years.
JBOD arrays can limit aggregate bandwidth by the read/write bandwidth and the amount of throughput in the loop between the storage and the I/O channels. HEVC: HOW DO WE GET THERE?
What if your management expects to see 4K capability? How can we get there given that no current servers supply H.265 codecs? There are two possible choices. One is to find a technology supplier that can offer JPEG2000 compression support or other capability in the interim. Another is to accept that for the limited amount of content now available, we might need to look at a huge chunk of storage for uncompressed 4K files.
That brings up a second question: What is the 4K interface to the rest of the world? Streaming content as IP files, which is what I believe many will do sooner rather than later, requires only enough bandwidth to supply the data to a delivery chain that can provide the necessary compression. For the time being you should expect that to be non-real-time compression.
We also need to look at the range of standards available from SMPTE to interface UHDTV signals to other devices, like the compression subsystem. Today, SMPTE continues to work on both baseband and IT-related interfaces. The SMPTE/Video Services Forum (VSF) Joint Task Force will likely have a set of recommendations soon. My caution is that none of this is really ready for 4K at full frame rate and bit depth today, so we need to have conversations with whatever vendor we pick about a migration path from current interfaces and compression standards to future capabilities we will certainly need. This is not an easy conversation.
Customers have to recognize that they are really not picking a video server. Rather, they are picking IT hardware that will offer video streams on interfaces of their choosing.THE ‘RIGHT’ SOLUTION?
One thing I cannot make clear enough is that we are really not picking a video server; rather, we are picking IT hardware that will offer video streams on interfaces of our choosing. This fact fundamentally changes how you look at the system. It is appropriate to acknowledge that common IT-sourced hardware is not appropriate for this use. This is the reason I have shied away from computers with video cards simply added in. The big difference between a video server and a server “trying to do video” is the real-time nature of the product, and the demand it places on the rest of the server platform. We need streams to be frame-accurate and reliable in all modes of operation.
I sat with a client and listened to a prospective vendor salesman pitching a commercial off-the-shelf (COTS) clone computer running a largely unmodified version of “a popular windowed operating system.” Getting that to run with real-time characteristics and deterministic frame-accurate content delivery is at best difficult. Because my client needed the ability to scale to many playout channels, and in the future deliver high-frame-rate 4K streams, I knew it would be difficult to use a COTS platform as the basis of the system. I have often thought that as processing power climbs, this would cease to be an issue, but so far it remains a valid concern. I’m always willing to look at a new vendor’s approach, but let’s be cautious in this choice.
In particular, a COTS solution is less likely to have a well-integrated storage platform able to service the combined needs of many playout I/O channels. There is no secret that COTS-based platforms use OEM RAID and disk offerings, which are integrated in-house. Servers built from the ground up for the demanding needs of video services may start the same way, but they also feature heavily customized code that optimizes performance for the large media files we use.
The author strongly suggests clients stay with manufacturers that have proven AVC capability.DETERMINING THE IT STRENGTHS OF A PLATFORM
Take, for instance, the need of all disk systems to do “thermal calibration” of the servos. An off-the-shelf disk drive and RAID controller from a generic source may not rewrite the microcode on the drives to control the timing of the recalibration. You certainly don’t want it to happen at the moment you begin streaming content from the disk. This is one of the considerations that traditional video server companies address that a common IT platform might not.
The IT nature of this platform is perhaps clearest when you look at a full system configured in a rack. Most of the wiring is IT-specific, connecting control and I/O to the storage subsystem. If we choose to use an IT interface for delivery of the content, as we might if we can deliver preformatted MPEG or H.264 streams directly to the delivery platform without using video and separate compression engines outside the server platform, there will be very few video cables. This is not a warning sign. It is a sign we have made great progress.
PICKING THE RIGHT VENDOR
Finally, how are we going to choose from the available vendors? When spec’ing a project, I typically provide a short list of preferred vendors. All of them clearly recognize that in a few short years baseband video interfaces may be obsolete, and are well along the way to providing a realtime streaming interface as an option. All of them use either software codecs that can be upgraded as new compression systems become practical or hardware codecs that can be reprogrammed and reused with new systems. I also include a couple of the usual suspects that offer very high-quality hardware codecs that are fine for today’s uses.
At the end of the day, selecting the right server for your needs takes a lot of research, including conversations with friends in the business, and some on-site testing. Getting down to a single choice will be hard but worth the time and effort in order to keep your business successful.
John Luff is consultant in electronic media.
