Video Containers Explained: MP4, MOV and MXF

A video file is not one thing. It is a wrapper holding several things: one or more video streams, a handful of audio tracks, perhaps captions or subtitles, timecode, and metadata that tells a player or an edit system how all of it fits together. That wrapper is the container, and the three you will meet most often in professional work are the subject of this guide. Understanding MP4, MOV and MXF video containers, and how they differ from the codecs that compress the pictures inside them, is the difference between a delivery that is accepted on the first try and one that bounces back from a broadcaster, a streaming platform or a client's IT department two days before launch.

This matters to anyone who commissions, edits or distributes video: marketing teams sending a campaign to a TV station and to social platforms in the same week, in-house producers archiving masters, agencies juggling files from several camera systems, and editors who have been handed a delivery specification full of acronyms. The container decides what can travel together in one file, which tools can open it, and whether a playout server will ingest it at all.

Rather than list definitions, this article follows one project from brief to delivery. The project is an illustrative example, a composite built to show typical decisions, not a real client job. Every number in it is a realistic planning figure rather than a measured result. Along the way we explain why each container was chosen, where rewrapping saved time, and which traps the team deliberately avoided.

The Illustrative Brief: One Film, Four Destinations

The fictional client is a mid-sized manufacturer launching a new product line. They commissioned a 60-second brand film, with a 30-second cutdown, and they needed it in four places: a regional broadcast TV slot, their own website, two social platforms, and a long-term archive their marketing team could come back to for future edits. The footage came from two cameras: a cinema camera recording Apple ProRes 422 HQ in MOV files, and a second mirrorless body recording H.264 in MP4 files. Some drone shots arrived as H.265 in MP4.

That mix is ordinary, and it is exactly where container confusion starts. The client's marketing lead reasonably asked, "Can't we just send everyone the MP4?" The honest answer was no, and the rest of the project explains why.

The deliverables list, once the team had gathered every specification, looked like this:

• Broadcast: the station required an MXF OP1a file carrying XDCAM HD422 video (MPEG-2 4:2:2 Long GOP at 50 Mb/s), 1920x1080 interlaced, with 24-bit, 48 kHz PCM audio on separate mono tracks, program loudness at the station's target, and start timecode at a specified value.
• Website: an MP4 with H.264 video and AAC audio, progressive, optimized for streaming so that playback can start before the whole file downloads, plus a WebVTT caption file.
• Social: MP4 files at the platforms' recommended dimensions, including a vertical cut, with burned-in captions on one version and a sidecar caption file on another.
• Archive: a ProRes 422 HQ master in MOV, with separate stems for dialogue, music and effects, and a textless version for future localization.

Four destinations, three different containers, and at least four different codecs. The first decision was to stop talking about "formats" loosely and separate the two questions every delivery spec actually asks: what wrapper, and what compression inside it.

Containers Versus Codecs: The Distinction That Shaped Every Decision

A codec is the method used to compress and decompress the video or audio: H.264, H.265 (HEVC), AV1, ProRes, DNxHR, MPEG-2, AAC, PCM. A container is the file structure that stores those compressed streams alongside each other and records how they synchronize. The file extension, whether .mp4, .mov or .mxf, names the container, not the codec. MDN Web Docs' guide to media container formats makes the same distinction for web media and lists which codecs each web container can carry.

The practical consequence is that "send me an MP4" is an incomplete request. An MP4 can hold H.264, H.265 or AV1 video; a MOV can hold ProRes, H.264, or uncompressed video; an MXF can hold MPEG-2, AVC-Intra, XAVC, DNxHD or JPEG 2000. Two files with the same extension can behave completely differently on the same playback device. If you want a fuller treatment of the compression side, our guide to video codecs and compression covers how the codec choice affects quality and file size.

What each container is built for

MP4 (formally MPEG-4 Part 14) is the standard container for web and consumer delivery. It is built on the ISO base media file format, which itself descends from Apple's QuickTime structure. Browsers, phones, smart TVs and every major video platform read it. Its strength is universality; its limits are in professional features such as multiple mono audio tracks and rich timecode handling, which many consumer players ignore even when the file carries them.

MOV is Apple's QuickTime container. It is common for ProRes, which is the most widely used intermediate codec in editing, and it handles timecode tracks, multiple audio tracks and a wide range of codecs well. Nearly every editing system reads it. It is a production and mastering container more than a distribution one, although web players can play MOV files that contain web-friendly codecs.

MXF (Material Exchange Format) is a SMPTE-standardized container common in broadcast. The SMPTE MXF standards define not just the file structure but "operational patterns" that describe how the essence (the video and audio) is organized. OP1a, a single file with interleaved video and audio, is what most broadcasters request. OP-Atom, where each track sits in its own file, is how some editing systems store media internally. MXF carries rich metadata, frame-accurate timecode, and many discrete audio channels, which is why playout servers and broadcast archives rely on it.

the deliverables list with two columns for every item, one for container and one for codec, plus separate lines for audio format, channel layout, captions and timecode. That single change removed most of the ambiguity before any file was exported.

Project Timeline From Ingest to Final Delivery

With the requirements pinned down, the team built a schedule that put container decisions at the stages where they are cheapest to get right. Rather than treat delivery as a final export, they planned the file path from the first day of ingest.

The shape of this timeline matters more than the exact days. Inspection happens at the start, a single master sits at the center, and every deliverable is derived from that master rather than from each other. That structure is what makes the container choices at the end straightforward.

Ingest: Reading What the Cameras Actually Recorded

The first practical step was to find out what was really inside each file. Camera menus, filenames and even the file extension can mislead. A clip named .mp4 from a mirrorless camera might contain H.264 at 8-bit 4:2:0, or H.265 at 10-bit 4:2:2, depending on the recording mode. A drone's MP4 might have variable frame rate. None of that is visible from the extension.

The team used two tools. MediaInfo, a free inspector, reports the container, codec, profile, bit depth, chroma subsampling, frame rate mode, timecode and audio layout for each file. FFprobe, part of the FFmpeg project, whose formats documentation lists the muxers and demuxers it supports, gives the same information in a scriptable form, which is useful when you have hundreds of clips. A typical inspection command is ffprobe -v error -show_streams -show_format clip.mp4, although the output is best read in a spreadsheet when the clip count grows.

What the inspection found

In this illustrative project, the inspection turned up three issues that would have caused trouble later if nobody had looked:

• The drone clips were recorded with variable frame rate. Many editing systems handle variable frame rate poorly, producing audio drift or stuttering. These clips needed a constant-frame-rate transcode before editing.
• The mirrorless camera recorded its audio as a single stereo AAC track, while the cinema camera recorded four channels of 24-bit PCM, including two lavalier channels. Anyone assuming "the audio is on the clip" would have missed that the lav channels existed only on the cinema camera files.
• Timecode on the mirrorless camera had not been jammed to the cinema camera, so it could not be used for sync. Sync would rely on audio waveform matching.

None of these are container problems as such, but the container is where the evidence lives. Reading the container metadata carefully is the cheapest quality check in the whole workflow.

Choosing an Intermediate: Why the Edit Ran on ProRes in MOV

Long-GOP codecs such as H.264 and H.265 compress by storing full frames only occasionally and describing the frames in between as changes. That is efficient for delivery but heavy for editing, because scrubbing to any frame requires the computer to reconstruct it from its neighbors. Intra-frame intermediate codecs, such as ProRes and DNxHR, store each frame independently. They produce much larger files but decode quickly and survive repeated rendering with little visible loss.

The team chose ProRes 422 HQ because the cinema camera already recorded it, the finishing workstation handled it natively, and the grade would benefit from 10-bit 4:2:2 source material. The natural container for ProRes is MOV. DNxHR in MXF OP-Atom would have been a sensible alternative on an Avid-based workflow, and DNxHR in MOV works in most systems too. The rule the team followed was simple: pick the intermediate the finishing system handles best, and keep it in that codec's most common container so every tool in the chain opens it without fuss.

Transcoding versus rewrapping at ingest

The H.264 and H.265 clips needed a true transcode, meaning they were decoded and re-encoded as ProRes, because the goal was to change the codec. Transcoding cannot add quality that was not captured; an 8-bit 4:2:0 source stays 8-bit 4:2:0 in substance even inside a 10-bit ProRes file. What it adds is editing performance and a single consistent format for the timeline. Our guide to video bit depth explains why that distinction matters for grading.

The camera ProRes MOV files, by contrast, needed nothing. They went straight into the project. Re-encoding them would have cost hours of processing and a small generation loss for no benefit.

Building the Master: One File to Derive Everything From

After picture lock, grade and mix, the team exported a single master. This is the file every other deliverable would be made from, so its container and contents had to carry everything any destination might need.

The master was a ProRes 422 HQ MOV at 1920x1080, at the project frame rate, with the following audio layout, documented in a track sheet that traveled with the file:

Track	Content	Format
A1-A2	Full stereo mix, left and right	24-bit PCM, 48 kHz
A3	Dialogue stem (mono)	24-bit PCM, 48 kHz
A4	Music stem (mono sum)	24-bit PCM, 48 kHz
A5-A6	Effects stem, stereo	24-bit PCM, 48 kHz
A7-A8	Music and effects mix without dialogue, stereo	24-bit PCM, 48 kHz

MOV handled this cleanly: a timecode track starting at the agreed value, one video track, and eight discrete audio channels. A separate textless master held the same picture without on-screen titles, so future versions in other languages would not require a re-grade.

Why not make the master an MP4? Because MP4 players and many platforms assume a small number of audio tracks, and although the MP4 specification can carry more, support for multiple discrete PCM tracks and timecode varies widely between tools. The master's job is fidelity and completeness, not compatibility with phones. MXF would also have worked as a master container, and many broadcast facilities master in MXF, but MOV suited this team's finishing tools and the client's future editors.

The team exported the master at a data rate of roughly 220 Mb/s, which is Apple's published target for ProRes 422 HQ at 1080p and 29.97 frames per second. For a 60-second film that works out to about 1.65 GB of video, a size that is trivial for an archive and impractical for a website, which is precisely why the master and the web file must be different things.

Broadcast Delivery: Building the MXF OP1a File

The broadcast deliverable was the strictest. The station's specification named the container (MXF OP1a), the codec (XDCAM HD422 at 50 Mb/s), the raster and scan (1920x1080 interlaced), the audio layout (eight mono PCM tracks with the stereo mix on tracks 1 and 2), the loudness target, the start timecode, and the required slate and black before program. Our guide to getting video delivery specifications right explains how to read a document like this line by line.

Because the codec had to change from ProRes to MPEG-2, this was a full transcode, not a rewrap. The team used their finishing system's broadcast export preset, then checked the result rather than trusting the preset. Presets are a starting point; they cannot know a particular station's track layout or start timecode.

Interlacing and frame rate

The film was edited progressive. The station required an interlaced deliverable at its broadcast frame rate. Where the project frame rate matched, the progressive frames were carried in an interlaced stream, a common and clean approach that avoids motion artifacts. Had the frame rates not matched, a proper standards conversion would have been needed, which is a separate and more delicate job than a container change.

Audio mapping and loudness

The single most common reason broadcast files are rejected is audio, not video. MXF OP1a deliveries usually carry each channel as its own mono track, and stations specify exactly which content goes on which track. The team mapped the stereo mix to tracks 1 and 2, the music-and-effects mix to 3 and 4 as the spec requested, and silence on the remaining tracks. Loudness was measured over the full program and adjusted to the station's target. Our practical guide to audio loudness standards covers how those targets differ between broadcast regions and online platforms.

tracks during conversion. A quick export tool would have produced an MXF with one stereo pair. It would have played fine on the editor's desktop and then failed the station's automated check for eight channels. The team confirmed the track count and content on every channel before sending.

Web and Social Delivery: When MP4 Is the Right Answer

For the website and social platforms, MP4 was the obvious choice. It is what browsers and platforms expect, and every device plays it. The codec inside was H.264 with AAC audio, still the most broadly compatible combination. The team considered AV1 for the website, because it compresses more efficiently, but the client's video player and some target devices did not support it yet, so H.264 remained the safe default with AV1 as a possible future addition. Our pieces on H.264 encoding done properly and on AV1 describe those trade-offs in detail.

Fast start and streaming

An MP4 stores an index of where every frame sits (the "moov" atom). If that index is written at the end of the file, a browser must download the whole file before it can start playback. Moving it to the beginning, often called fast start or web optimization, lets playback begin almost immediately. In FFmpeg this is the -movflags +faststart option; most export tools have a checkbox labeled something like "optimize for web" or "fast start." It is a container-level setting, not a codec setting, and it changes nothing about picture quality.

Captions for the web

MP4 can carry an embedded text track, but web players and platforms generally expect captions as a separate sidecar file, most often WebVTT for websites and SRT or the platform's own upload for social. The team authored captions once, against the master's timecode, then exported them in each format needed. The social version with burned-in captions was a separate render, because burned-in text is part of the picture and cannot be switched off.

For publishing decisions beyond the file itself, such as thumbnails, upload timing and platform settings, see our guide to publishing and scheduling video.

Notice that the last row is a rewrap, which leads to one of the most useful and underused techniques in delivery work.

Rewrapping: Changing the Container Without Re-Encoding

Midway through the delivery stage, the client asked for the master to be handed to a partner agency that edits on a system preferring MXF media. The codec, ProRes 422 HQ, was already acceptable to them. Only the wrapper needed to change.

That is a rewrap, sometimes called remuxing. The compressed video and audio data are copied bit for bit into a new container; nothing is decoded or re-encoded. The benefits are significant: there is no generation loss, the process takes a fraction of the time of a transcode (often limited only by disk speed), and the picture is guaranteed identical. In FFmpeg, the stream-copy option does this: ffmpeg -i master.mov -map 0 -c copy output.mxf, where -map 0 keeps every stream rather than only the first video and audio track, and -c copy copies without re-encoding. Whether a given codec can go into a given container depends on what each container supports, and the tool will refuse or warn if the combination is invalid.

When a rewrap is possible and when it is not

• Possible: H.264 from MOV to MP4, or MP4 to MOV; ProRes from MOV to MXF where the target tools support ProRes in MXF; DNxHD between MXF and MOV; changing MP4 to fast start.
• Not possible: when the destination requires a different codec (ProRes to MPEG-2 for the station), a different frame rate, a different resolution, a different bit depth, or burned-in graphics. All of these change the picture and require a transcode.
• Possible with care: when the destination container has different rules for audio, such as requiring mono tracks rather than an interleaved stereo pair. The audio can often be re-mapped into the new layout without re-encoding the video.

In the illustrative project, the agency handoff took minutes rather than the better part of an hour a transcode would have taken on the same machine, and the agency received exactly the pixels the colorist had approved.

, ask "does the codec, frame rate, resolution or picture content need to change?" If the answer is no to all four, rewrap. If the answer to any is yes, transcode from the master, never from another derivative.

A warning follows naturally from this. Renaming a file's extension is not rewrapping. Changing film.mov to film.mp4 in a file browser leaves the internal QuickTime structure intact. Some players will cope because MP4 and MOV share ancestry; others, and most ingest systems that validate files, will reject it or behave unpredictably. Keep file extensions accurate so they describe what is actually inside.

Quality Control: Checking Every File Against Its Specification

Every deliverable was checked before it left, not by opening it in the editing system that created it, but with tools that read the file independently. A file that plays in the program that made it proves very little. Our guide to video quality control done properly covers the full process; the container-related checks the team ran are below.

In this example, QC caught one issue: the first social export had inherited the master's eight audio channels, and one platform's uploader only used the first two while displaying a warning. The file was re-exported with a single stereo AAC track. It was a small fix, but the kind that is embarrassing if the client finds it first.

Checking after every conversion, including rewraps

Rewraps are safe for picture, but they are not automatically safe for everything else. A container change can drop a timecode track, lose caption data the new container does not support, or collapse multiple audio tracks if the tool only maps the first one by default. The team treated every converted file, including rewraps, as a new file that needed its audio and caption tracks checked.

What the Project Teaches About MP4, MOV and MXF Video Containers

Stepping back from the illustrative project, a few principles explain why it went smoothly, and they apply to jobs of any size, from a recruitment video delivered to a careers site to a broadcast campaign across several regions.

Choose containers by destination, not by habit

MP4 for browsers, apps, social platforms and consumer devices. MOV for editing, finishing and mastering in most non-broadcast workflows, particularly with ProRes. MXF when a broadcaster, playout system or broadcast archive asks for it, and in the exact operational pattern and codec they name. Sending MXF to a web platform is a common mistake: most social and video hosting platforms either reject it or handle it inconsistently, and even where upload succeeds, the file is far larger than necessary.

Keep one master and derive everything from it

Making the web file from the broadcast file, or the social file from the web file, stacks compression losses and inherits errors. A single high-quality master, documented with a track sheet, keeps every derivative one generation from the finished picture.

Follow the delivery specification exactly

Specifications are written for automated ingest systems as much as for people. "Close enough" is often rejected by software that checks track counts, timecode and container structure without human judgment. If a line in the spec is unclear, ask the recipient before exporting.

Common misunderstandings worth correcting

Three misunderstandings came up during the project and come up constantly elsewhere. First, that MOV is "an Apple-only format": MOV files play in nearly every professional tool on every operating system, although some consumer players are less reliable with it than with MP4. Second, that MXF is inherently higher quality: MXF is a container, and the quality depends entirely on the codec and bit rate inside it. An MXF holding a low-bit-rate codec can look worse than a well-encoded MP4. Third, that converting to a larger container or codec improves quality: nothing added after capture can recover detail that was never recorded.

Planning Your Own Delivery and Knowing When to Get Help

If you are planning a project with several destinations, the illustrative workflow above adapts directly. Start by collecting every specification before the edit, not after it. Build a deliverables table with separate columns for container, codec, audio layout, captions and timecode. Decide on an intermediate that suits your finishing system. Export one master with complete audio, then create each deliverable from it, rewrapping where only the container changes and transcoding where anything in the picture or codec must change. Check every file independently before it leaves.

The effort involved scales with the number of destinations rather than the length of the film. A 30-second spot for broadcast, web and social can take longer to deliver properly than a 10-minute web-only film, because each broadcast deliverable has its own specification and its own ways to fail. That is worth factoring into schedules, particularly for recurring work such as a planned video series, where a standard deliverables template saves time on every episode.

Signs you should bring in help

Bring in help when deliveries are rejected for format reasons, especially more than once. Repeated rejections usually point to a gap in tools or knowledge, such as missing broadcast export capability, uncertainty about operational patterns, audio mapping confusion, or no independent QC step, rather than a one-off slip. Other signs include a new destination with an unfamiliar specification, a large volume of legacy files in mixed containers that need to be normalized for an archive, or a deadline too tight to learn broadcast delivery under pressure.

A post-production team that handles delivery routinely will have the export profiles, inspection tools and checklists already in place. Our video editing and production services include mastering and multi-destination delivery, and the same principles apply whether the job is a single web film or a campaign across broadcast and social.

Where this comes from

• MDN Web Docs — Media container formats
• SMPTE — MXF standards
• FFmpeg — Formats documentation

The figures and practices above come from the sources listed.

Working on something like this?

We take on Video Editing & Production work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.

Where to go next

• Bitrate and Rate Control, Done Properly
• How to Get HLS Streaming Right