Today I was confronted with a situation not unlike many I deal with on a regular basis: How can one of my clients use a media file of a particular format, in a specific application that does not inherently support working with files of that format? Working through the solution to the problem reiterated to me the fact that many people are confused about what media files really are, what a codec is, and what a wrapper or container-format is.

Folks use these terms incorrectly, interchangeably, and vaguely, but it’s really not all-too-difficult to understand. I’ll go about trying to explain it to the best of my ability and then I’ll describe how I had to attack the issues of both codec (essence) and wrapper, to address my client’s specific workflow requirement.

Most media files we work with contain several key components: audio, video, or both audio and video. Often, there’s non-media data as well: timecode, captions, and all sorts of other potential metadata (information about the media itself, the camera that shot it, when it was shot, the geolocation of where it was shot, etc).

The audio and video “layers,” or components, of our media files are encoded in one of many different digital formats. These can be uncompressed, or compressed using one of many compression formats (codecs). Note that the word “codec” can have several uses, but for most editors and creatives manipulating digital media, it refers to a particular flavor of digital audio or video that’s usually (but not always) compressed.

Some video codecs you’ve probably come across are: DVCPROHD, XDCAM HD & XDCAM EX, and Apple’s ProRes, just to name a few. Common audio codecs include PCM Uncompressed, MP3, and AAC. Keep in mind, many of these codecs are related to one-another, and many are based on other formats, which are also technically codecs in and of themselves, such as MPEG-2 and H.264. Also, some codecs are agnostic to the type of recording media involved. For instance, Panasonic’s HD camcorders, both tape-based and tapeless P2-based, can record as DVCPROHD. However, many video ingest servers also record to DVCPROHD as an available codec.

Digital videotape cameras record a raw stream of data, in a particular codec, to a linear magnetic tape medium, spooled up in a cassette. Tapeless cameras and video ingest servers record the video (and audio) not simply as streams of data, but streams of data contained within a particular container, or wrapper. This stream of media data inside of a wrapper file makes up the media files we use day in and day out.

The wrappers themselves can also contain other tracks, or layers, of information, in addition to the raw audio and video data. These other types of data are often referred to as metadata, or “data about the data.” As I discussed previously, this could be as basic as a timecode track, or as extensive as geolocation tags, that tie each frame of audio and video shot to a particular GPS coordinate.

We work with many wrapper formats on a regular basis. The Quicktime wrapper format is a .mov file. An MPEG wrapper format is .mpg. MXFs can be found on the P2 cards that Panasonic cameras shoot, and in this case, the .mxf wrappers might be containing essences in the DV, DVCPRO50, DVCPROHD, or AVC-Intra codecs. MXFs can also be found on the Blu-ray optical discs Sony XDCAM HD camcorders shoot onto, although in this case, those MXFs are usually storing a variant of the MPEG-2 codec at a particular bit rate and with a particular structure to its sequence of video frames, commonly referred to as XDCAM HD in shorthand.

This may all sound a bit confusing, and there are literally hundreds if not thousands of wrapper/container format and codec combinations, but one point alone should be impressed upon you: Wrappers do not imply that only a single format of video is contained within them, and the different audio and video formats, or codecs, themselves can be wrapped with a number of different types of file containers. The container formats can usually be identified at least generally by what comes after the “dot” in a file-name. And while a .mxf file might be one of a handful of different variations of the MXF wrapper format, it at least gives you a good clue as to what wrapper format you’re dealing with. The inner codecs, however, may still be a mystery!

This all leads back to the situation I was faced with today, when one of my clients asked me about how to use a file they had received from another party they work with, within Final Cut Pro. The problem was that it wasn’t a “native” Final Cut Pro file, that is to say, not one of the handful of officially-compatible codec/container combinations Final Cut Pro is set up by default to handle editing. These files were essentially meaningless to FCP; without some help, it did not know what they were or how to edit them.

The files came from an Avid editing system, and were wrapped as .mxf, their current native format. The customer had heard they might be able to use the software product MXF4Mac to get these files to work within Final Cut, so they could finish editing the piece they needed to complete in short order.

My initial answer was, as you may have figured out by this point: Maybe MXF4Mac will work, maybe it won’t, because even though we know these are .mxf files dumped out of an Avid, you have not told me what actual codec the video essence is stored as. MXF4Mac is a software add-on, or component, for Quicktime, which tells QT-based media applications how to understand files that are wrapped with certain variations of the .mxf file wrapper format. But MXF4Mac does not tell Final Cut how to understand codecs that might be alien to it. MXF4Mac might be groovy if your MXF file contains a DVCPROHD essence within it, but will be useless, on its own, if the codec is, say, Avid’s DNxHD.

And, according to the customer, these particular files very likely were rendered out as the DNxHD codec, wrapped in an MXF container file. So this required yet another add-on component for Quicktime, this being Avid’s own bundle of codecs, which are available as a free download on their website. Included in these is a playback component for Quicktime for the DNxHD codec, allowing Final Cut and other applications to understand how to work with (literally, decompress) files encoded as DNxHD.

Between MXF4Mac to understand the MXF wrapper, and Avid’s playback codecs for Quicktime to understand the DNxHD at the core of the files, we had a solution on our hands that would allow native playback and editing of this alien media. But in order to have a true solution, we needed to address both the container and codec dimensions of the challenge.

Finally, it’s important to note that this solution still does not allow an editor to render out as an MXF-wrapped DNxHD file, directly from Final Cut Pro. These are playback (or import/decompress) Quicktime components only, and as such, my client would still have to drop the MXF-wrapped DNxHD files on, say, an Apple ProRes timeline, and render out as a .mov-wrapped ProRes file. Some wrappers and codecs that are alien to Final Cut can indeed be generated from within that application, with the help of a Quicktime component you install that is developed by a third-party. One example is a Windows Media 9 file wrapped as a WMV. However, in this particular client’s case, rendering as a .mov-wrapped ProRes or uncompressed file was fine, cheaper to accomplish, and easier to accomplish.

If you have any questions, fire me an email at nick@chesa.com any time!

About the Author:
Nick Gold is the Sales Manager & Director of Business Development for Chesapeake Systems Professional Services. An anime and techno music enthusiast, he also hates The Smoke Monster like any other Lost fan. On the other hand, he loves his new iPad 3G even more than he thought he would. Follow his work and play adventures on twitter.