One of the unique things about how Control Group works is that our focus is much more involved than simply putting in a solution for a client and then moving on. We work with our clients to determine how they work, so we can design IT solutions that really fit their needs. Since we have partnerships with a variety of vendors, we work with our clients to arrive at the best solutions for their business. This means we do quite a bit of research and planning before we begin a project — and then a great deal of testing during and after we install new hardware or software.

I do some work on implementing storage systems for our clients, and we’ve found that different applications have different storage requirements. For example a video post production facility — like the facility at WWE — generally needs lots of disk space that is very good at reading and writing large files at high speeds. The storage here needs to provide good streaming throughput, because high quality video files generally have high bit rates, and are being stored or played back from the disk in real-time for ingesting, editing, or playout. If the storage system is not fast enough to read or write the file in real-time, frames will be dropped. This can cause unsatisfactory media files, programs to crash, or audio and video to become out of sync.

10,000 RPM SAS disks. That's some serious storage.

Suboptimal read/write performance can become a huge problem. When we put in a new system this is something we need to test. I usually do the test with a tool called lmdd.

lmdd comes from the lmbench tools which are provided by Bitmover for benchmarking systems. lmdd is great for testing streaming bandwidth. In most of our engagements with video, we install a Stornext or Xsan filesystem so we’ll run our tests against this. lmdd will probably work on any filesystem that you can mount on your Mac or Linux computer (Leave a comment if you need a version for Mac OS X, I have one compiled).  lmdd lets us verify exactly what the maximum number of megabytes per second we can push through the storage and point us to where we need to make changes to the hardware or software configuration. I use lmdd like this :

lmdd of=/path/to/test_file count=1g

lmdd if=/path/to/test_file

The first tests write performance and the second tests read performance. More information about the syntax is available in the manual page for lmdd. The results of the command from a server I was testing looked like this:

2147.4755 MB in 6.8003 secs, 315.7914 MB/sec

lmdd is great because it’s easy to read. This result shows I could write to the filesystem at 315 megabytes per second. That’s really fast! This is from a test with a server with a lot of RAM and a special filesystem that took advantage of that cache. When I run it on my Macbook, I get a result like this:

18342.6171 MB in 376.7685 secs, 48.6841 MB/sec

So the next time you’re interested in how your storage is performing give lmdd a shot and let me know how it goes. If you’re looking for more information about storage performance testing then stay tuned; I’ll be posting about testing storage with tools that benchmark small reads and writes next.

Share this:

Check out this great video that our friends at SPIN put together to show off the new SPIN Mobile iPhone app. Read more about how we built the app, and download it for free from iTunes!

[vimeo 4493737]

Share this:

As an Enterprise Consultant at Control Group, I help lead our Broadcast, Media, and Entertainment technology consulting group. While CG employs experts in a wide variety of technologies, my area of experience and expertise is focused around Apple solutions for professional video and design. A few months ago, I wrote an article for O’Reilly on Final Cut Server that was targeted at consumers and covered the basics for professionals in the production industry. I wanted to expand on that article and share some thoughts on Final Cut Server as part of an integrated media workflow.

Final Cut Server client

Apple markets Final Cut Server as a tool primarily for Final Cut Pro users. Apple’s focus is on enabling users to manage their FCP projects and related files, providing them with automations to save time, and giving production teams a centralized system for collaboration. Beyond Apple’s sales pitch, we think Final Cut Server has real potential to play a central role in a production and distribution platform made up of a framework of connected systems.

Here’s an example of a typical broadcast infrastructure:

• Storage area network (SAN) for storage
• Media asset management system (MAM) for organizing and versioning
• Editor/artist workstations
• Producer workstations
• A transcode system for delivery

Now here’s an example of how those pieces might fit together in a broadcast workflow:

1. Content from tape or tapeless media is ingested through the MAM. Metadata is added at ingest – both technical metadata (shot, tape, take, etc) and possibly contextual metadata (actor, object brands, locations).
2. Data is saved to the SAN, where it is cut and crafted by editors and artists. As the content comes together, project files and new assets are saved to the SAN by editors and artists, and reviewed by producers.
3. As content is completed, it is transcoded for delivery to television, tape, and the web. Web distribution might include delivery in a custom player, and/or Hulu, YouTube, Vimeo.
4. Once content is in the wild, content owners need analytics tools to understand who is watching what and where.

Beyond its out-of-the box capabilities, Final Cut Server can be customized to play a key role in workflows like these. While it doesn’t include an API, developers can leverage custom responses in Final Cut Server to read and write XML and run external scripts. On its developer website, Apple provides an example of Final Cut Server integration with an external Rails application that enables the viewing and commenting of movie clips in a web browser. An example like this serves as a useful starting place when exploring building the middleware to connect Final Cut Server to other applications or platforms in a workflow.

Episode Engine Admin

For example, Final Cut Server leverages Compressor for all of its out-of-the-box transcoding. However many existing infrastructures exist using established transcoding systems, such as Telestream’s Episode Engine. By combining metadata subscriptions and watch folders in Final Cut Server with custom responses that leverage external scripts, Episode can easily be integrated as the transcode delivery component for a Final Cut Server workflow. Similarly, the ability to read and write XML to assets in Final Cut Server makes possible the development of web applications that interact with assets, and can even store information in their own disparate databases, populating Final Cut Server when appropriate.

What excites us about this are the many Final Cut Server integration possibilities that are not currently being talked about. And since Control Group marries Apple video integration expertise with a team of developers under the same roof, we’re excited to continue to innovate in this area. Give us a shout if you’d like to open up a dialog on how Final Cut Server might fit into your broadcast or production workflow.

Share this: