The MXF file (.mxf)

MXF is the file format of professional video. Broadcast and cinema cameras record to it, editing systems store media in it, and TV networks and streaming services take programmes delivered in it. It was developed from 1999 by the Pro-MPEG Forum, with backing from SMPTE and the EBU, to replace tapes with files that every vendor's equipment could exchange. SMPTE published it as a standard in 2004.

Like MOV and MP4, MXF is a container: the picture and sound inside are compressed with a separate codec such as MPEG-2, H.264, DNxHD or JPEG 2000. What sets MXF apart is how much it carries besides the media: timecode, detailed descriptions of each track, unique material identifiers (UMIDs) that link a clip to its source, and optional descriptive metadata such as titles, shot locations and people.

MXF shares its data model with AAF, the Advanced Authoring Format used to exchange edit projects. MXF uses a subset of AAF's objects, stored in a simpler form that can be streamed, and an edit project exchanged as AAF can point to media in MXF files.

Everything in an MXF file, from metadata to video frames, is a KLV triplet, the coding defined in SMPTE ST 336:

• Key: 16 bytes, a SMPTE Universal Label starting 06 0E 2B 34. Labels come from public registers kept by SMPTE, so a key means the same thing in every file.
• Length: BER-coded. A single byte below 0x80 is the length itself; otherwise the low bits say how many bytes of length follow. Writers often use a fixed 4-byte form (83 xx xx xx) even for small values, so the length can be filled in later without moving anything.
• Value: the data: a partition pack, a metadata set, a frame of video.

Because each item says what it is and how long it is, a reader can skip anything it doesn't need, and vendors can add their own items ("dark" metadata, in MXF terms) without breaking other software. The cost is overhead: every frame of video carries at least 17 bytes of key and length, and metadata sets are verbose.

• Partitions. A file has a header partition, optional body partitions and usually a footer. Each starts with a partition pack and can repeat the header metadata. Repeating it lets a file be read while it's still being written or sent, and helps recover a file that was cut short.
• Packages. The Material Package is the output timeline: what plays, in what order. A File (or Source) Package describes the essence as stored. An OP1a file has one of each; more complex patterns use several.
• Frame wrapping or clip wrapping. In a frame-wrapped file, each frame's picture and sound are separate KLV items stored side by side, frame after frame, like a tape. In a clip-wrapped file, the whole clip's essence is one huge KLV item, usually one track per file. Cameras mostly frame-wrap; OP-Atom files are typically clip-wrapped.
• Index tables. Map frame numbers to byte offsets. Codecs with frames of fixed size need just one entry; long-GOP codecs such as MPEG-2 and H.264 need one per frame.
• The random index pack. A list of partition offsets at the very end of the file, used to find everything quickly.

These choices are why two valid MXF files can behave very differently in the same software: one may open instantly and scrub smoothly, the other may need to be scanned first, or may not open at all.

An operational pattern describes how complicated a file's structure is: how many items play in sequence (1 = a single item, 2 = a playlist, 3 = edited items) and how packages relate (a = one package, b = several played together, c = alternatives). Most of the nine combinations are rare. Two matter in practice:

The pattern is recorded in the partition packs and the Preface, and ffprobe file.mxf shows it as operational_pattern_ul: OP1a labels contain 0d010201.0101 (FFmpeg's own files show …0d010201.01010900), and OP-Atom labels contain 0d010201.10.

• Sony: XDCAM HD and XDCAM EX recordings (MPEG-2) and XAVC (H.264) use MXF OP1a; Sony's older IMX recorders wrote MPEG-2 in MXF too.
• Panasonic: P2 cameras record DV, DVCPRO and AVC-Intra in MXF, as OP-Atom or OP1b.
• Canon: professional camcorders and Cinema EOS cameras record XF-AVC, which is H.264 in MXF.
• ARRI: the ALEXA Mini LF and ALEXA 35 record ARRIRAW wrapped in MXF; the mapping is documented as SMPTE RDD 54.
• Avid: Media Composer stores its media as OP-Atom MXF, one file per track, in an Avid MediaFiles/MXF folder, usually with DNxHD or DNxHR video.

MXF is also the basis of several delivery and distribution formats, each a set of rules on top of it:

• No support at all. Browsers don't play MXF; the file downloads. The players built into Windows and macOS don't open most MXF files without extra software either.
• Professional codecs. Even when the container is understood, the codec may not be: JPEG 2000, DNxHD, AVC-Intra or ARRIRAW need professional software or FFmpeg.
• Half a clip. In OP-Atom, picture and sound are separate files. Open the video file alone and there's no sound; open an audio file and there's no picture. Editors combine them using the metadata.
• Many mono tracks. Broadcast files often carry 4, 8 or 16 separate mono audio tracks. A simple player may play only the first, so you hear one channel or none.
• Interlaced video. Broadcast HD is often interlaced (1080i). Players that don't deinterlace show combing on moving edges.
• Size. Production codecs run at tens or hundreds of megabits per second, so a few minutes can be several gigabytes.

• Edit: DaVinci Resolve, Premiere Pro and Avid Media Composer import camera MXF directly; Final Cut Pro opens it on Macs with Apple's Pro Video Formats installed. Resolve and Premiere can also export MXF.
• Just watch: VLC opens most OP1a files on Windows, macOS and Linux. mpv and IINA work too, since they use FFmpeg.
• Inspect: ffprobe file.mxf lists the streams, the operational pattern and the timecode; MediaInfo shows the same, including the essence container and wrapping.
• Convert for sharing: FFmpeg or HandBrake to H.264 MP4, as below.

# check what's inside: codecs, tracks, operational pattern
ffprobe input.mxf

# MXF to MP4: H.264 + AAC from the first audio track
ffmpeg -i input.mxf -map 0:v:0 -map 0:a:0 -c:v libx264 -crf 20 \
  -pix_fmt yuv420p -c:a aac -movflags +faststart output.mp4

# two mono tracks (left, right) combined into stereo
ffmpeg -i input.mxf -filter_complex "[0:a:0][0:a:1]amerge=inputs=2[a]" \
  -map 0:v:0 -map "[a]" -c:v libx264 -crf 20 -pix_fmt yuv420p \
  -c:a aac output.mp4

For interlaced sources, add a deinterlacer such as -vf yadif before the output name. -pix_fmt yuv420p matters because professional files are usually 4:2:2, which many players can't show in H.264.