Evertz Media Server

The system overcomes the workflow and storage limitations of traditional SAN-based servers.
Author:
Updated:
Original:

In the past 15 years, numerous media server products have come and gone in the broadcast market. First-generation products were standalone chassis with integrated A/V I/O and Direct Attached Storage (DAS), which function well for a small number of I/O channels and when the content does not need to be shared.

Second-generation products separated the A/V I/O and storage, thereby enabling higher I/O channel counts. They typically used a Fiber Channel-based SAN to build larger, shared storage servers. These systems provided high-performance but required proprietary client access to the content, creating an “island of storage” that was not easily accessible to third-party applications. This storage access problem led to the deployment of multiple SANs, thereby creating islands of storage that had to be separately administered, maintained and serviced.

In parallel, the increased growth of file-based workflows in the broadcast enterprise labored against the islands-of-storage approach of application-specific SANs. Many resources were expended in creating logical and physical gateways between SANs and then in managing the movement of content between them. Furthermore, many applications require specific data structures (A/V codecs and multiplexes) to assure interoperability, thereby adding yet another layer of logical or physical resources to transform the data into a format that the applications can use. All these gateways, transcoders and data-movers add time, cost and inefficiencies to a file-based workflow that was originally promised to be faster, simpler and more integrated than a tape-based sneaker-net.

To overcome the workflow and storage deficiencies of managing multiple SANs, Evertz has introduced the third generation in media server architectures. Evertz Media Server (EMS) is based on a robust, field-proven client/server architecture that overcomes the workflow and storage limitations of traditional SAN-based servers while also providing high performance. This next-generation architecture provides the scalability, flexibility and reliability to match the requirements of broadcasters, whether they are single-channel local originators or national and transnational content providers that deliver hundreds of HD channels.

Fault-resilient core storage

The core of the system is the Media Server, a clustered NFS server that provides scalable, high-performance file-serving to attached application clients. The server cluster can scale from two to 16 nodes. Each node has two 10Gb/s Ethernet ports connected to a pair of redundant 10G to 1Gb/s switches on the client-side IP network. Each node can provide a minimum of 500MB/s of combined read/write bandwidth to the IP network.

All clients attach to the server cluster via IP using NFS file access protocols. Client network connections are typically dual 1Gb/s Ethernet ports for read/write of compressed content. For high-performance live, sports or post-production environments, dual 10Gb/s Ethernet ports can be installed in the clients to support read/write of uncompressed HD and even 3Gb/s content.

The cluster provides N-1 hi-availability and load balancing. Hi-availability assures that the failure of any single node in the cluster will not take the server offline, while load balancing avoids performance bottlenecks in the cluster.

Furthermore, for client operating systems that support active-active IP port-bonding, the Media Server OS assures that no Single-Point-of-Failure (SPoF) in the client-side network will interrupt file read/write. This capability operates independently of the client application, thereby freeing the application of knowing and recovering from a SPoF event in the IP network.

On the storage side, each node has two 8Gb/s Fiber Channel (FC) ports connected to a pair of redundant 8Gb/s switches on the storage-side FC network. The storage sub-system is actually composed of a collection of SANs. This means that one or more Storage Controllers (SC), and their SAS-attached Storage Expansion (SE) chassis, can be connected to the FC network to provide high-bandwidth, high-capacity or both.

Because this collection-of-SANs can be organized as one or more independent SANs, they can be composed of differing storage technologies. Therefore, some SCs and SEs can contain 15K RPM drives, and others can use 7.2K RPM drives.

The EMS system allows combining multiple storage tiers in one physical machine. For example, high-performance Tier 0 storage using RAID10 15K RPM drives for live production can be supplemented with a Tier 1 composed of RAID6 15K RPM drives for online performance, both of which are supplemented with a high-capacity Tier 2 near-line archive composed of RAID6 7.2K RPM HDDs.

The storage-side FC network also supports active-active multipathing. This not only provides each node with two paths to each SC, but also it enables data to travel across both paths for all reads and writes. Active-active multipathing assures that there are no latent double-faults that could take data offline as are inherent in active-passive arrangements.

Media Clients

The sole purpose of the Media Server is file-serving. No A/V I/O or processing is performed on it. All A/V I/O and content processing is performed by hardware or software applications running on the attached clients. These clients can be either HW/SW platforms from third-party vendors or highly-optimized Evertz Media Clients.

The Ingest Client is a broadcast-quality, frame-accurate ingest station that performs real-time software encoding and multiplexing of HD/SD-SDI in either MPEG-2 or MPEG-4 formats. Currently supported HD codecs include XDCAM HD 4:2:2 and AVC-Intra 100. Plans for future codecs include JPEG 2000, as well as mezzanine-level HD 4:2:2 codecs used by popular NLEs. Each Ingest Client also supports a confidence playback output (with a minimal delay), as well as a full jog/shuttle/play output. This mode can be used to review the content as it's being ingested, or as a general-purpose output for any stored content.

While encoding, content-based metadata is generated, as are MPEG-4 based low-resolution proxies. An advanced metadata schema provides hooks for supplemental data structures such as multiple closed captions and an unlimited number of audio language tracks.

The Playout Client provides multichannel, linear, frame-accurate content decode and playout, plus real-time SD/HD up/down and HD-crossconversion. This allows an output channel to be assigned a particular raster format. Subsequently, all content played on that channel will be automatically and frame-accurately converted to the designated output raster, no matter the raster, codec or multiplex format of the original content.

File Ingest

To radically accelerate file-based workflows, Evertz introduced the File Ingest Client, which supports faster than real-time ingest of file-based content. When coupled with the Playout Client, content can be played in its multiplex and A/V codec format using the advanced metadata generated by the File Ingest Client. Evertz refers to this new feature as NativPlay. NativPlay effectively eliminates the need for transcoding, transrating and remuxing of content in order for it to play on the Playout Client.

Integrated solution

The EMS provides next-generation features and capabilities that stem largely from a simple and robust client/server architecture. The architecture contains the scalability, flexibility and fault resiliency to enable multiple operational models and host multiple applications using only a few functional components.

Production houses, broadcast operators and content delivery providers can now build a core server infrastructure that provides high-performance, as well as supports open standards. This represents a significant evolution in media server architecture, one that simultaneously realizes a more integrated facility as it exploits the inexorable price/performance advances of commodity IT components.

John L. Pittas is senior director - product development, Evertz Microsystems.