FCPXML vs EDL vs OTIO: which cut format should VFX use?

The job the cut file has to do

For VFX, an interchange file is not a delivery - it is a description of the shot list. It has to tell you which clips are in the cut, where each one sits on the timeline, how long it is, what it is called, and at what frame rate the whole thing runs. Get any of those wrong and every downstream number - handle length, frame count, version - is wrong with it. The three formats you will actually be handed are the CMX3600 EDL, OpenTimelineIO, and FCPXML. They are not interchangeable in fidelity.

CMX3600 EDL: the lowest common denominator

The EDL is a plain-text list of events from a linear-editing era, and it is still everywhere precisely because it is so simple. Every NLE can write one and everything can read one. Each event has a source and record timecode, a transition, and - by convention, not by spec - a * FROM CLIP NAME: comment line that carries the clip name VFX actually keys on.

Its weaknesses are the flip side of that simplicity. An EDL flattens the timeline to a single video track, so a multi-layer comp reference or a split-screen is lost. It is timecode-based with no explicit frame rate - the FCM line only says drop-frame or non-drop, so you must confirm the fps separately or risk misreading every duration. Clip names live in free-text comments that different systems format differently. It is a fine shot list for a single-track offline that finishes in Avid or Premiere, and a poor one for anything with mixed rates or layered structure. Our CMX3600 EDL explainer walks the exact anatomy.

OpenTimelineIO: the pipeline-native option

OTIO is an open format from Pixar built specifically for exchanging editorial timelines between tools without losing structure. Unlike the EDL it is track-aware, carries explicit rational frame rates (as a numerator/denominator so 23.976 is exact, not a rounded 23.98), keeps clip names as first-class metadata, and has a plug-in adapter model that reads and writes EDL, FCPXML, AAF and more. It is JSON under the hood, so it is easy to parse and diff.

The catch is adoption: OTIO is common in facilities with a pipeline team and rarer coming straight out of an edit suite, because most editors export whatever their NLE offers by default. When you can get it, it is the most faithful of the three. When you cannot, its adapters mean the EDL or FCPXML you do get can often be normalised into the same shape.

FCPXML: the format Resolve finishing speaks

FCPXML is Apple's XML interchange, originally for Final Cut Pro - but the reason it matters far beyond Final Cut is that DaVinci Resolve reads and writes it as a full-fidelity round-trip. For the large and growing number of shows that offline and online in Resolve, FCPXML is the format that describes the cut the way the editor actually built it: explicit rates, mixed-rate timelines, multiple video tracks, and clean clip names all survive where an EDL would flatten and rename them.

That makes FCPXML the practical answer for a lot of small-studio work. Resolve is cheap and ubiquitous, Final Cut has a loyal editorial base, and both hand you an FCPXML that a VFX shot list can trust on frame rate - the single most common silent corruptor of frame counts. It is more verbose than an EDL and its schema has versioned over time, so a reader has to be tolerant of version differences, but the payoff is a cut description you do not have to second-guess.

Side by side

Why Cutlist reads all three

Because you rarely get to choose. Editorial sends what their NLE exports, and across a slate that means EDLs from one show, FCPXML from a Resolve finish, and the occasional OTIO from a facility that has a pipeline. Cutlist Tracker parses CMX3600 EDL, OpenTimelineIO and FCPXML into the same internal shot list, normalising frame rate and clip names, so whichever one lands in your inbox becomes the shot list and feeds the same conform check, cut diff and department matrix. The format stops being a decision you have to win.