Workflows for the post boutique
Storage costs have come down as the industry transitions to file-based production, post and delivery. This has created a happy confluence where once out-of-reach shared storage solutions are now within the budget range of most small production companies, broadcasters and post facilities.
Shared storage networks for film and video editing originally came to market in the ‘90s through Avid MediaShare. This evolved into Avid Unity MediaNet and more recently Avid ISIS. The beauty of the system is complete collaboration among a group of editors, where all can be working within the exact same open project. To this day few NLEs has been able to achieve this, although there are effective FCP workflow solutions, as well as EditShare’s approach to Media Composer, Final Cut and Lightworks project sharing. The Avid Media Composer/NewsCutter+Unity/ISIS+Interplay combination is still the gold standard for editorial collaboration and media asset management.
On the small-shop side, Avid has aggressively lowered the price of their solutions, such as the cost-effective ISIS 5000 solution. They have also opened their storage to connect with Final Cut “client” workstations. Many small shops are FCP-centric and are looking at what the broader market has to offer. This frequently takes a “roll-your-own” approach with varying degrees of success. I’m going to focus my comments on Final Cut Pro-based facilities, since those are the ones doing the most experimentation with different collaborative network topologies.
Storage Area Network (SAN) types
Shared storage solutions are designed to permit multiple rooms (edit suites, audio studios, graphics, etc.) to connect to a common media network in order to access files from any room. The two basic types are file-level and volume-level systems.
As the name implies, in a file-level system, permission to read/write files is granular down to the individual file level. Storage is partitioned and organized as a single volume (a single virtual hard drive mounted on the desktop), to which all connected users have read/write access. The SAN administrative software functions as the “traffic cop” to prevent one user from accidentally overwriting another user’s files.
In a volume-level system, storage is divided into numerous volumes or partitions (organized by room or by project). Various read-only or read/write profiles are established in the controlling SAN software. Typically a user will have write authority in one room for only a single volume, but can mount the other storage volumes with read-only permission. Of course, various profiles can be established based on project needs, so a user can be assigned write authority to additional volumes when not in use by another editor.
SANs typically use Fibre Channel or 10 Gigabit Ethernet (10-Gig-E) for fast media data rates, but a SAN can also be built upon standard Gigabit Ethernet (Gig-E), especially when large data rates aren’t required. If you have over six rooms – or you need to work with multiple streams of online-quality media – then Fibre Channel is the best option. On the other hand, a shop with a handful of bays cutting with a low bandwidth resolution like OfflineRT or DV25 will probably be happy with a Gig-E system.
There’s a third approach made possible by Apple File-sharing Protocol, in which Ethernet can be used to access another machine’s local storage over a standard local area network (LAN). Although no SAN software is used in this configuration, AFP is robust enough to prevent disastrous media results. In its simplest form, such as two edit rooms working in tandem, one computer would have a locally-connected array. That could be accessed by the second system over the LAN. The danger is that if one system crashes, there’s no protection for the other, however that’s relatively low risk. This is actually a pretty easy and simple way for a film editor and assistant to collaborate on a low-budget feature film.
In more advanced installations – all SANs or any AFP configuration with more than two computers – the hardware units will consist of the local workstations, a central server, storage attached to the server, a Fibre Channel or Ethernet hardware switch, Fibre Channel or Ethernet cards installed in the client systems and cabling (copper or fiber optic). Gig-E systems would likely utilize the Ethernet connections already designed into the computer.
The largest, most advanced SANs for FCP environments commonly use Apple’s Xsan networking software. This would be used to establish a file-level system, capable of connecting a large number of users. For maximum robustness, installations have historically employed Apple Xserve computers running OS X Server as the system’s metadata controller (the “traffic cop”). Although OS X Server can also run on a Mac Pro or a Mac Mini, most enterprise customers have sought better alternatives for the discontinued Xserve.
One such answer might be Active Storage’s newly-announced ActiveSAN. It runs on the Linux OS in an “appliance” design. As an appliance, the server is designed around a single function – in this case, storage and running an Xsan system – instead of other possible server functions, like e-mail or website hosting. Unfortunately Xsan implementations have proven to be relatively “IT-intensive” and not well-suited for small facilities that don’t have access to knowledgeable local tech support. However, if you are a large enterprise connecting 100 Final Cut editors to 100TB of shared storage, few if any other systems are up to the task. An Xsan system is also appropriate for other large Mac-based enterprises, like a magazine publisher’s creative team.
At the other end of the spectrum are the AFP/Gig-E systems. These are a good match for small shops with a handful of connected systems, who want the least amount of future maintenance issues. A Mac Pro running standard OS X (not the Server version) functions as the “server”. The upside of this is that no SAN software license is involved, so there’s no additional cost for another client seat when a new system is added to the storage network. The downside is that you have to dedicate a workstation to the system as the de facto server to host the storage. It shouldn’t be used for editing or anything else, if you want the system to stay stable.
In between are the so-called SAN-in-a-can systems, which tend to offer the best approach for small editing boutiques. Examples include Avid ISIS 5000. Facilis Technology TerraBlock, iStorage Pro, Small Tree GraniteSTOR, CalDigit SuperShare, etc. Most units consist of a single chassis holding both the storage array and a self-contained server. The latter would be an “appliance”, consisting of a motherboard with an embedded OS, like Linux. It’s a “headless” server, so no monitor or OS controls to access, except possibly some front panel system controls. There’s no server to launch or OS to enter in the usual sense. SAN software, like Command Soft’s FibreJet, would be installed to partition volumes, manage the configuration and establish user profiles for mount/read/write configurations.
As a volume-level system, it’s easy to maintain and also easy when an administrator needs to organize the storage access around particular clients or projects. The increased cost of Fibre Channel hardware is offset by not needing a separate computer as the server/metadata controller. (Note: Some of these systems – like Avid ISIS – are based on Ethernet and not Fibre Channel.) However, as you add systems, you will have to pay for extra SAN licenses and Fibre Channel cards. This sets up a trade-off in cost versus the number of rooms when you compare a SAN-in-a-can system to an AFP deployment.
In actual practice
One approach that offers many benefits is to augment a volume-level SAN with an installation of Final Cut Server. This Apple software is an asset management solution that competes with CatDV and Avid Interplay. If you want the best asset management solution for FCP, then CatDV is it. Avid Interplay excels in a broadcast environment with Avid NLEs. Final Cut Server’s strength is with small shops that need both asset management and a robust database to track clip metadata. It not only makes media files searchable, but also provides a way to control media across multiple FCP projects.
I frequently work at one such facility and here is how it works. The network layout was designed by area systems integrator, PEI Graphic Technology. There are four edit suites running Final Cut Studio, which are all linked to a 32TB PEI SAN-Storm chassis (based on the iStorage Pro hardware). This includes a self-contained metadata controller/server appliance. The unit connects to a Fibre Channel switch, which is turn connects to the edit suite workstations. Command Soft FibreJet is installed as the SAN management software.
Apple Final Cut Server is installed on a separate Apple Xserve computer running OS X Server, which is also a connected as a Fibre Channel “client” to the SAN. Each edit suite is assigned its own 2TB “local” volume with read/write permission for working space on the SAN. The Xserve is assigned the largest portion of the SAN, which is used by Final Cut Server as its permanent location for writing files.
When an editor start a session for the first time, a new FCP project is created locally on one of the workstations. Media is ingested via import, Log & Capture or Log & Transfer and ends up on the local volume of the SAN, which is assigned to that station. At the end of Day 1, the FCP project is uploaded to Final Cut Server (launched through a client applet installed on the workstation). Based on profiles established when Final Cut Server is initially configured, all media that appears within the FCP project is also automatically moved into Final Cut Server.
This consists of several processes. Media (such as ProRes HQ) is copied from the local volume to the Final Cut Server-controlled volume. A lower-resolution edit proxy file (such as ProRes Proxy), a low-resolution viewing proxy (H.264) and a thumbnail are created. You can set up a profile to delete the original file after the copying is complete, but it’s safer not to do that. This temporarily leaves two sets of media on the local and server volumes until you elect to delete the local media. The upload process can be done overnight.
You will typically edit with the high-res files. Low-res edit proxy files are created in case you want to export media in a lightweight format for off-site rough-cut editing. The H.264 files are used for media searches, previews and client reviews via the web.
On Day 2 and each of the subsequent editing days, the editor starts by checking-out the FCP project from Final Cut Server. The check-out step copies the FCP project file from Final Cut Server to a local destination, such as the editing workstation’s desktop. Assuming all media files were successfully uploaded to Server the night before, all clips in the FCP browser are now linked to the media that’s on the Final Cut Server volume and not the local volume any more. Any new media added during the course of the day stays local during that day.
At the end of each editing day, the FCP project is checked back into Final Cut Server. As this stage, the editor can optionally add versioning information that becomes part of the asset information for the FCP project. Additionally, all FCP comments and descriptions made by the editor for master clips within FCP become part of the data assets of FC Server. Any media files that have been added to the project on these subsequent edit days are also uploaded to Final Cut Server as part of the check-in process.
Archiving can still be an issue with modern SAN systems, but Final Cut Server adds a level of control. You can move media to external storage, like raw eSATA drives or LTO tapes and then subsequently identify on-line and near-line media files. Proxy files stay of the system for review and searches and Final Cut Server will prompt editors to reload the high-res media from an archive, should a requested clip have been archived off of the Server volume.
Since this is a shared storage solution, all workstations can access the same high-res media files resident on Server volume (as well as the mounted partitions). Files located in a Final Cut Server search can be dragged-and-dropped into any open FCP project and used in that edit. When the project is uploaded or checked-in, Final Cut Server will know which files are already within its managed system and won’t duplicate those media files.
Although such a system isn’t for every facility, it does provide a level of automated media control that can turn basic FCP editing stations into a broader, enterprise-level system. The beauty of a solution like this is that Final Cut Server aggregates all project media into a single location, complete with asset management and search capability. This combines many of the benefits of an Xsan system, Avid Unity and Avid Interplay. Robust storage and a database at a price point lower than ever before.
© 2011 Oliver Peters