/
01.09.2007
Originally featured on BroadcastEngineering.com
How to streamline HD workflow

Viewers aren't the only ones who are astonished by HD sports production. Networks that have to ingest, categorize and archive the massive amount of HD data associated with a baseball or football game can be equally overwhelmed.

Recently, HD Technology Update had the chance to discuss a solution that IBM is offering to broadcasters. Since 2005, Fox Sports has used the IBM ASI solution to streamline its archiving. HDTU spoke with John Hoehn, IBM senior consultant/senior IT architect, about the solution and how it might be used beyond archiving to improve the HD production/post-production workflow.

HD Technology Update: Describe how Fox Sports is using the IBM ASI solution.

John Hoehn: The system we have had in place since April 2005 at Fox Networks —and used by Fox Sports — is primarily an archive system today. We take an ASI feed off an ASI router and route it to one of our servers. Our system just looks like ports to the ASI router. So, we schedule on both sides. We schedule on our system, and we schedule on the TOC side. When the feeds reach our servers, we start recording to disk. We take the payloads out of the ASI streams, the MPEG-2 transport streams; and, we're actually storing those bits on disk.

Fox uses 720p, and, apparently, they also get some free feeds that come from the other networks and are able to record those, even though they're 1080i. Our system is agnostic as far as which high-definition standard is being broadcast, because we're just recording the bits. At Fox, we add a few control bits along with the transport stream. It comes out to be an odd number, 73Mb/s, which includes the MPEG-2 payload 64Mb/s, plus 9Mb/s for control. These extra bits help us keep track of the changes in the bit rate.

This also enables us to reconstruct the original ASI stream when we recall the transport stream files from disk or data tape. We insert the house clock time codes on the way in, and we can actually create synthetic time codes (LTC) on the way out — we can reconstruct the original ASI stream. The other thing we're doing is chunking the transport stream so we can do clip extraction on transport stream files. We can do this from disk as well as from data tape. These data tape transfers are pretty fast, too — between 480Mb/s and 800Mb/s (60MB/s and 80MB/s) per tape drive in the library system.

We have what amounts to a transfer stream data mover between disk and data tape over fiber, so the only thing that is really throttling the transfer rate is the number of tape drives. They're not inexpensive, but they're fast. For example, at Fox, we have eight servers connected to four tape drives, and that works well in an archive sense moving off all the high-definition NFL games, NASCAR, "American Idol" and MLB by 6 p.m. the day of broadcast.

HDTU: Is this strictly an archiving solution, or does it also offer a solution for post?

JH: One of the things we are looking to do with new clients is to move the archive closer to the front of the workflow. In other words, now we are starting to wade into a space where there are many digital workflows for standard def, where you typically find some kind of common storage architecture, usually SANs and network attached storage. We can use the system we currently have and instantiate it so that you're storing not just to local disk as a backup, but you're ingesting these transfer stream files directly to the storage area network or the network attached storage. With some form of digital asset management layered on top of this shared storage, we can support quick-turnaround production as well as post production.

HDTU: Does the Fox Sports implementation include production or post applications?

JH: They currently are only using the archive. We're working on several different extensions to the current HD archive. We're looking to create what we call an import-export capability, so it's possible to take content that was originally stored as transport stream and export it onto any digital medium — DVDs, tape cartridges and so forth.

For example, the NFL requires D5 videotapes to be shipped to NFL Films in Mount Laurel, NJ, as a part of the broadcaster's compliance with the league. Imagine if Fox were shipping much smaller, less expensive tape cartridges instead.

One of our LTO data tape cartridges can store three full-length HD football games. Obviously, this would cut down on shipping costs. With an analogous import capability at the other end, it is possible to exchange content using these LTO data cartridges.

HDTU: Beyond the specifics of the Fox application, what bottlenecks have you identified in general with regards to sports production, and how can your solution help?

JH: Well, if we're ingesting directly into a storage area network, heterogeneous file system, like a Quantum/ADIC StoreNext, or an IBM GPFS, we can start reading or editing the files while they are being written. High speeds can be supported using fiber channel or high-speed GigE. We now have 10Gb network adapter cards. If I'm working in the same facility, then I may not want to work using proxy video at all; I may want to work immediately and directly on shared storage to shorten my time-to-air. Using the logging metadata, I can find what I want quickly and make earlier decisions about what video I want to archive.

We have some exciting new tools coming out of IBM Research, including Marvel, which is a system that can do much of the semantics-based metadata generation with reduced human intervention. With at least 1000 video samples, Marvel starts to learn what is in the video. The worst case is it can start to identify what's a play, what's not a play. What's a score, what's not a score. Marvel learns as it goes. The more samples you give it and the more you start combining these with existing metadata or metadata from audio or closed caption, it starts getting more and more intelligent.

So, the amount of logging by humans is reduced. We don't think it will ever be eliminated; but then we start talking about pre-screening content. This saves broadcasters time and money.

Our goal is to make the high-definition workflow more efficient than what we've traditionally done with standard def. Once a video becomes digitized in an IT space, which is what we're good at, this is our sweet spot — digital workflow.

The other thing we can do once we have ingested MPEG-2 from ASI and selected the program from a multiprogram stream, is break the MPEG files up into chunks. Now, we are working with many smaller files, not one large contiguous file. Let's say we have configured the system to create 5-minute chunks. Now, we can move these smaller files around an IP-based network, not merely on a LAN, but on a WAN as well. We have designed our system to recall clips of MPEG transport files. Now you can request a playable clip from one location and move it asynchronously to another location — ready to be played out. Because it is a file and not a stream, it can be moved much faster than real time too. Now, you only move what you need, not entire programs or events. This has value not just in sports, but in news as well.

Tell us what you think!
HDTU invites response from our readers. Please submit your comments to editor@broadcastengineering.com. We'll follow up with your comments in an upcoming issue.



Comments
Post New Comment
If you are already a member, or would like to receive email alerts as new comments are
made, please login or register.

Enter the code shown above:

(Note: If you cannot read the numbers in the above
image, reload the page to generate a new one.)

No Comments Found




Friday 3:00PM
Google Debuts Android TV
“We’re simply giving TV the same level of attention that phones and tablets have traditionally enjoyed.” ~ David Burke, Google


 
Featured Articles
Discover TV Technology