Post-production networks have always been at the forefront of networking technology for video. In the early days, a post facility was able to move still images from its graphics areas throughout the facility using 10Base-T networks. As network speeds increased, post facilities were some of the first to use networks to send short motion sequences through computer networks. Today, post facilities have wholeheartedly embraced networks and are pushing the limits of what is possible.
A case in point
Figure 1. Shown here is a multi-floor post facility with 10/100Base-T connectivity on each floor and Gigabit Ethernet between floors. Click here to see an enlarged diagram.
For example, let's look at one particular large post facility. It began its experience in networking as many others have — an ad-hoc network here, a connection between a couple of paint workstations there. The facility installed 10Base-T hubs and concentrators to provide more connectivity. Up to a certain point, the network grew organically. As new equipment was delivered, engineers connected it to the existing network. Bandwidth demands increased, and it was time for planning. The facility reconfigured the network and added routers to segment the traffic. It replaced hubs with switches, and as new networking equipment was installed, the people running the network took advantage of monitoring and diagnostics available through SNMP.
When the facility relocated to a new building, network engineers took the opportunity to redesign the network from the ground up. They configured the multi-story facility with 10/100Base-T switches on each floor. The switches provided connectivity to equipment on each floor. Multiple Gig-E connections between floors provided 42 Gigabits of bandwidth floor-to-floor. (See Figure 1.)
The new network was a great success. As the facility grew, it continually added new equipment. As applications improved and as workflows changed, network traffic continued to grow. Several years later, the facility finds itself facing a real challenge. It uses state-of-the-art equipment, and the network design is sound. Unfortunately, the network is a victim of its own success. And while the network definitely has become a critical part of the post-production infrastructure, the users want more in the way of support for collaborative workflows.
Desktop post-production has become a critical part of the overall post process. Almost all post facilities and freelancers use desktop applications as part of the creative process. Desktop video editing, graphics and effects creation, and audio-post tools are now extremely powerful and full-featured. In many cases, people prefer to use these tools during a project because they are comparatively low-cost, they produce usable results, and they are, in many cases, portable, allowing a creative person to work with a client wherever he or she may be. Of course, at some point, this work must be integrated into the more traditional post facility. Typically, this is done by using Firewire or an Ethernet connection.
Shared storage
Having an industrial-strength network is one way to enable collaborative workflow. Users working on a project can save their output in a reasonably ubiquitous file format such as Targa or TIFF. The next person in line can import that image or sequence and take things from there. But there is a limit to how much this improves work-flow. For one thing, the metadata about the project generally does not flow with the image file. Secondly, if you have two people working in different areas of the same project at the same time, this model does not help.
Let's look at the first issue. While the Targa and TIFF files are well understood, they do not contain much information about the context within which the images were generated. There is one common solution to this today, and that is to use a proprietary format for sharing. This works well because it provides information about the project, but it can be disadvantageous if other manufacturer products are involved in the workflow because it is likely that they will not be able to read the proprietary files. Another potential solution is to use the Advanced Authoring Format (AAF) for interchange. AAF is still under development, but even at this early stage, it is successfully exchanging information between edit and audio applications.
As for the second issue, it is probably true that an import/export model does not really support collaboration. In this case, the only likely solution is to use a proprietary format stored on shared storage. Note that there are two pieces to this solution. The proprietary format is important because interactive, collaborative work on a single file or set of files requires not just a high level of understanding about what is going on within the file, but also it requires intimate knowledge of what is going on in the application as well. For example, if two editors are working on the same file, the manufacturer must be sure of how simultaneous access to the file is granted to be sure that the results are coordinated. You can imagine that if two editors attempt to edit the same part of the file at the same time, chaos can result.
The second important piece of the puzzle is to have rock-solid shared storage. And, while this shared storage could be network-attached storage or NAS (where a remote drive is attached to a local device through the network), a storage-area network or SAN is probably required.
Figure 2. Combining NAS and SAN allows designers to provide high-speed direct storage connections where needed while still allowing more conventional network-drive storage for desktop applications. Click here to see an enlarged diagram.
If two editors are working on different parts of the same project using SAN, each editor thinks that the remote, shared disk storage is directly attached to the device — most likely using SCSI over Fibre Channel (FC). The network is transparent as far as the application is concerned. Well-written applications will be able to read, write and modify data in place on the shared storage concurrent with other applications. For this to work, there must be interoperability between the two (or more) systems on several levels. Typically, this requires close collaboration between the manufacturers involved.
SAN meets NAS
What do you do if you have a modern facility with a 10/100 Mb/s network, you are out of capacity, and your users are demanding even more collaborative work-flow support? One solution would be to employ both SAN and NAS. Let's take a look at one implementation you could build today. (See Figure 2)
Figure 3. SAN meets NAS. The gateway provides NAS access to the SAN. The gateway mounts the SAN storage and then shares it with desktops on a conventional Ethernet network. Click here to see an enlarged diagram.
Start with SAN storage connected to a high-capacity FC switch. The switch is connected by FC to other SAN devices — no Arbitrated Loop, just straight connections from the switch to the FC devices. At this point, you have created a SAN and, in theory, any SAN/FC capable device can attach to the switch and work. But in our case, we also have several hundred desktop devices to support. Given that an FC connection for a desktop costs approximately €2500 (including the license and the interface card), an FC connection for each of these 200 desktops seems a bit pricey to say the least.
NAS seems like the best way to connect these devices to the production SAN. But how do you wire a NAS to a SAN? The answer is you do it with a gateway computer. The gateway has one network-interface card attached to your desktop network, and a SAN-interface card connected to the SAN switch. The gateway mounts the SAN drive and then offers it as a drive on the desktop network. There is more to it than that, but you get the idea. At that point, desktop devices drop their files on the gateway. But the gateway shared drive is actually part of the SAN storage. Once the content is on the SAN, high-end SAN devices can pick it up and run from there. At the same time, SAN devices can use the SAN storage for collaboration. (See Figure 3.)
It is important to understand that SAN and NAS employ fundamentally different protocols. It may look the same in physical implementation (both may run over the same type of fiber, for example), but the signals traveling over the fiber are very different.
Brad Gilmer is executive director of the AAF Association, executive director of the Video Services Forum and president of Gilmer & Associates.
