A file format is a wrapper into which a system places video, audio and metadata.
Stream transfers (using PAL, NTSC, SDI or even SDTI) will co-exist with file transfers in new television facilities.
If you are going to exchange video and audio using computers, you have two choices. The first is streaming; the second is file transfer. Broadcasters are very familiar with stream mode. Put a tape in a machine and press play — a stream comes out the video connector. We are also quite familiar with file transfer. Most of us e-mail documents to colleagues all the time. However, file transfer for video is something many of us are still learning about.
Why file transfer?
The first question to ask is why use files to move video and audio at all? After all, NTSC, PAL and 601 have been around for some time. One reason to use file transfer is if you want to know for sure whether the content got to the other end. Another reason is if you want to send your content at a rate other than real time. (True, you can stream at non-real-time rates as well, but file transfer is completely independent of frame rate.) A third reason to use file transfer is if you are sending files between computer-based video devices.
Of course, stream transfer (such as NTSC and 601) has its place too. It is not that one is better than the other. However, in the future, both will be used.
Purpose of a file format
What is the purpose of a file format? A file format is a wrapper into which a system places video, audio and metadata. You can think of the wrapper as an envelope. It holds the contents, and it has an address on the outside that says where the envelope should be delivered. Some wrappers also have “labels” that describe the contents so that receiving systems can tell whether they can read the contents of the envelope without having to open it. (You might use a similar system, marking boxes in your attic as “Christmas,” so that you do not have to open each box to see what is inside.)
On the surface, this seems simple — put the video, audio and metadata in an envelope and send it across a computer network to the recipient. The fact is, people understand envelopes very well. Computers are infinitely less flexible.
When it comes to wrappers and their contents, computers have to know how to read the header of the wrapper, they have to know how the wrapper works so they can unwrap the contents and, finally, they have to know how to interpret the contents. This can create considerable challenges. So sending a file from one vendor to another can actually be quite challenging.
A common file interchange format
What are some possible solutions to this problem? One is for a manufacturer to come up with a proprietary wrapper or file format. Since the manufacturer knows everything about the format, he or she can use it to send content from one system to another without any difficulty, so long as both systems are made by the same manufacturer. The vendor may share information about the file format with a few partners so that they can exchange content.
There are a number of proprietary file formats in use today. These formats work very well in single-vendor environments, but of course they do not work well in installations where users require several different vendors' equipment to work together. In these situations, a common file interchange format is required.
These help the broadcaster build multivendor facilities by clearly documenting interchange information in a public forum. Individual companies can implement the interchange format so users can interchange information.
Current work on file formats
There are several activities underway in the file format area. These are GXF, MXF and AAF (no it is not a prerequisite that a file format end in “F”).
GXF stands for the General Exchange Format. It is promoted by Grass Valley Group (www.grassvalleygroup.com). GXF supports transfers using data networking technology. It also supports storage on data devices such as tape streamers. It is compression format independent, and it is now undergoing standardization within the Society of Motion Picture and Television Engineers (SMPTE).
GXF is designed for on-air applications. It is extensible by design, but does not comply with SMPTE KLV coding. (KLV is one way to wrap data for transport over networks.) GXF supports MPEG (elementary streams), DVCPRO and JPEG video. It also supports uncompressed AC3 and Dolby E audio. GXF supports cuts-only video edits, audio fade in/out and allows for the encapsulation of user metadata. GXF can encapsulate KLV or XML, but it is not KLV native.
GXF has limited editing features — it does not support complex transitions, effects or editing of complex packages. However, it fits the on-air applications space very well. It is not intended to support post-production applications.
MXF is the Media Exchange Format. MXF is supported by ProMPEG (www.pro-mpeg.org). MXF is a file for the exchange of program material between file servers. It is also a format for tape streamers and digital archives. It usually contains one complete sequence, but this may comprise a sequence of clips and program segments. There are six operational patterns: Simple, Compiled, Compound, Uncompiled Simple, Uncompiled Compound and Metadata only.
The body can be based on one of several basic kinds including MPEG, DV and uncompressed. The body contains an interleaved sequence of picture frames, where each frame comprises audio, video and data essence plus frame-based metadata. MXF is fully SMPTE KLV compliant. It is also a subset of the AAF metadata allowing direct reading and writing with AAF implementations.
AAF is the Advanced Authoring Format. AAF is supported by the AAF Association (www.aafassociation.org). It is used primarily in the post-production and authoring environment. AAF is different from MXF and GXF in several ways. First, it has very rich metadata capabilities. This enables it to describe complex edits, compositing, effects and other functions that are used in the post-production environment. Second, AAF can contain a finished program, but more usually, it contains all of the source elements that will be used to render a finished program. Third, AAF permits external references. For example, an AAF file can contain three audio clips, two video clips and the EDL in metadata form telling a system what to do with the clips. In addition, the AAF file can contain a reference to a closed-caption file that is kept in a separate system. In this way, the AAF file can contain all the information about a post-production project, regardless of how large the project is or where project elements are stored. Finally, AAF differs from GXF and MXF in the wrapper structure. While GXF and MXF store data in a simple “flat file” structure, AAF uses structured storage, which is best described as a “file system within a file.” This has several important implications. Both GXF and MXF support playback before an end of file is received. In other words, it is possible to start playing an MXF file back from a file server before the server is finished receiving the transfer. With AAF this is not possible. The transfer must be complete before the contents of the file can be viewed. However, structured storage supports AAF's full feature capability and allows users to make alterations and additions to the file easily without having to rewrite the entire file. For those of you who know a little about how FAT works, structured storage supports similar functionality. Files can be expanded without having to be contiguous.
While AAF can be used with a number of compression formats, it also supports uncompressed. This is important since AAF's primary application space is the post-production environment. For the same reason, AAF's complexity may not be appropriate for the store and forward or broadcast playout environment.
Stream transfers (using PAL, NTSC, SDI or even SDTI) will co-exist with file transfers in new television facilities. As file transfer becomes more common, well-established file formats will serve a similar role to signal standards in the streaming world. GXF, MXF and AAF are three new file formats. There will be more. As the industry matures we will settle on a few of these standards, just as the industry settled on the analog stream standards of the past.
Brad Gilmer is executive director of the AAF Association and president of Gilmer & Associates, a broadcast consulting firm.
Send questions and comments to: brad_gilmer@intertec.com
