MOV (QuickTime) — Apple's container format and the editorial-workflow standard

MOV — QuickTime File Format — is Apple's container format that originated in the early 1990s for QuickTime media playback. It's the ancestor of MP4 (the MP4 spec was derived from QuickTime), and the two formats are technically near-equivalent, with MOV typically being used in editorial and mastering workflows where MP4 is used in streaming and consumer delivery. ProRes content ships in MOV; DNxHR content typically ships in MOV; editorial software exports to MOV by default. This page is the engineering reference for what MOV actually is, when it's the right choice, and how it relates to MP4.

#What MOV is

QuickTime File Format (the official spec name; also called .mov from the file extension) is a multimedia container developed by Apple. The format dates from 1991 and was the foundation for QuickTime playback on Mac OS.

In 1998, the MPEG group adopted the QuickTime File Format as the basis for MP4 (formally ISO/IEC 14496-14). The two formats share the same fundamental box-based structure (called "atoms" in QuickTime terminology and "boxes" in MP4 terminology). They're mostly interchangeable; specific features differ.

The structure of a QuickTime MOV file:

ftyp (file type)
moov (movie atom)
├── mvhd (movie header)
├── trak (track) — one per video/audio/subtitle track
│   ├── tkhd (track header)
│   ├── edts (edit list)
│   ├── tref (track reference)
│   ├── mdia (media)
│   │   ├── mdhd (media header)
│   │   ├── hdlr (handler)
│   │   └── minf (media info)
│   │       └── stbl (sample table)
│   └── udta (user data)
└── udta (user data)
mdat (media data)

This structure is essentially identical to MP4. The difference is which atom types are recognized — MOV has some QuickTime-specific atoms; MP4 has some standardized atoms that QuickTime doesn't natively recognize. The differences are mostly in metadata and edit-list handling.

#MOV vs MP4 — what's actually different

The differences are subtle:

MOV-specific:

• Older edit-list features and timecode track support more thoroughly developed.
• QuickTime-specific metadata atoms (Apple's iTunes metadata, for example).
• Reference movies (small MOV files that point to media in other files) — used by some editorial workflows.
• Tween samples and other animation features (legacy QuickTime).

MP4-specific:

• CMAF profile constraints for streaming.
• Standardized box types (PSI, fragmented MP4, etc.).
• Specific subtitle box types (TX3G).

For most practical purposes, the two formats are interchangeable. The same ffmpeg demuxer (mov,mp4,m4a,3gp,3g2,mj2) handles both. Most software that reads MP4 also reads MOV.

The choice between MOV and MP4 is mostly conventional:

• MP4 for streaming, consumer delivery, anything web-served.
• MOV for editorial, mastering, ProRes/DNxHR delivery, anything originating in or destined for Apple's editorial ecosystem.

#MOV in editorial workflows

MOV is the dominant editorial container because:

• Apple's editorial tooling (Final Cut Pro, Motion, Compressor) defaults to MOV.
• ProRes ships in MOV. ProRes encoders write MOV; ProRes decoders expect MOV.
• DNxHR / DNxHD typically ship in MOV (also in MXF for some broadcast workflows).
• Cinema cameras (RED, ARRI, Blackmagic) often write to MOV.
• Mastering pipelines preserve MOV through editorial and color grading stages.

The editorial workflow:

1. Capture — cameras write to MOV (often with ProRes or RAW codec).
2. Editorial — Final Cut, Premiere Pro, DaVinci Resolve work with MOV intermediates.
3. Color grading — DaVinci Resolve, Baselight produce MOV outputs.
4. VFX pipeline — usually MOV intermediates with EXR/DPX image sequences for the actual frames.
5. Mastering — final master delivered as MOV with ProRes 4444 or similar.
6. Distribution preparation — MOV master is converted to MP4/CMAF for streaming, MPEG-TS for broadcast, etc.

For pipelines that ingest editorial-source content, MOV is the input format. The conversion to streaming containers happens at the encoding stage.

#ProRes in MOV

ProRes is Apple's professional intermediate codec. The full ProRes family:

• ProRes 4444 XQ — highest quality, 12-bit, 4:4:4. Mastering quality.
• ProRes 4444 — 12-bit, 4:4:4. Premium editorial.
• ProRes 422 HQ — 10-bit, 4:2:2. Standard high-quality editorial.
• ProRes 422 — 10-bit, 4:2:2. Standard editorial intermediate.
• ProRes 422 LT — 10-bit, 4:2:2. Lower bitrate editorial.
• ProRes Proxy — 10-bit, 4:2:2. Offline editing proxy.
• ProRes RAW — RAW codec from cinema cameras.

All ProRes variants are typically delivered in MOV. Encoding ProRes:

ffmpeg -i input.mov -c:v prores_ks -profile:v 3 -pix_fmt yuv422p10le output.mov

profile:v 3 is ProRes 422 HQ; profiles 0-5 map to the variants above (proxy, lt, standard, hq, 4444, 4444xq).

ProRes file sizes are large — orders of magnitude bigger than equivalent-resolution H.264. The trade is editorial quality and decode performance (ProRes decodes at high frame rates on modern CPUs without breaking sweat) for storage cost.

For streaming pipelines, ProRes-in-MOV is typically the input master. The pipeline converts to streaming codecs (HEVC, AV1, H.264) for delivery.

#DNxHR in MOV

DNxHR is Avid's professional codec, the modern successor to DNxHD. Variants:

• DNxHR 444 — 12-bit, 4:4:4. Mastering quality.
• DNxHR HQX — 12-bit, 4:2:2. Premium editorial.
• DNxHR HQ — 8-bit, 4:2:2. Standard high-quality.
• DNxHR SQ — 8-bit, 4:2:2. Standard quality.
• DNxHR LB — 8-bit, 4:2:2. Low-bitrate editorial.

DNxHR is commonly delivered in MOV (also in MXF for broadcast workflows). It's roughly equivalent in concept to ProRes — a professional intermediate codec optimized for editorial decode performance and quality.

For Avid Media Composer workflows, DNxHR is the native codec. Most other editorial software reads DNxHR but doesn't necessarily encode it natively.

#Edit lists

MOV has more thorough edit-list support than MP4. Edit lists are atoms within tracks that specify:

• Time offsets — start playback at a specific time within the media.
• Skip ranges — play one section, skip another, play another.
• Empty edits — pause for a duration before playback continues.
• Repeat edits — play a section, then play it again.

Editorial software uses edit lists to encode "this is the version with the edits applied" without rewriting the underlying media. The MOV file can have a 60-minute mdat but a 45-minute effective duration via edit lists.

For streaming delivery, edit lists are problematic — many players don't honor them correctly, and the discrepancy between mdat duration and effective duration causes manifest issues. Best practice for streaming pipeline ingest of editorial MOV: flatten the edit list (re-encode to apply the edits to the actual media) before downstream processing.

#Timecode tracks

MOV supports a dedicated timecode track type that carries SMPTE timecode (HH:MM:SS:FF) per frame. Used in:

• Broadcast contribution — timecode synchronization across feeds.
• Editorial workflows — frame-accurate edit references.
• Multi-camera shoots — synchronizing footage from multiple cameras.

MP4 has timecode capability but it's less standardized than MOV's.

For pipelines that ingest content with timecode tracks, timecode preservation through the pipeline can matter for downstream tooling (editorial systems, broadcast playout, multi-camera assembly). The timecode track is preserved if relevant, or stripped during conversion to streaming-format outputs.

#Apple ecosystem integration

MOV's integration with Apple tooling is the operational reason it's used:

• AVFoundation (Apple's media framework) handles MOV natively.
• AVPlayer plays MOV directly without conversion.
• iOS/macOS Photos and Camera record to MOV (.mov files from iPhone are QuickTime).
• Final Cut Pro, Motion, Compressor, Logic Pro all use MOV as their default container.
• macOS Preview plays MOV.

For pipelines targeting Apple-ecosystem editorial or playback, MOV is the natural format. For consumer delivery to Apple devices via streaming, MP4 (specifically CMAF + HLS) is what's used — MOV is not a streaming container.

#When to use MOV vs MP4

Use MOV when:

• Working with ProRes or DNxHR content.
• Editorial pipeline integration (Final Cut, Premiere, DaVinci).
• Apple-ecosystem mastering workflow.
• Camera-original content from cinema or pro cameras.
• Edit lists or timecode tracks needed.

Use MP4 when:

• Streaming delivery (HLS, DASH, CMAF).
• Web video (HTML5 native playback).
• Mobile delivery.
• Anything where storage size matters more than editorial features.
• Consumer file delivery (downloads, social media).

For most pipelines, MOV is an input format (editorial source) and MP4 is the output format (streaming/delivery). The pipeline's conversion stage handles the transition.

#Operational considerations

Things that matter for MOV in production:

• Edit list flattening — for streaming pipeline ingest, flatten edit lists to avoid downstream issues.
• Timecode preservation — if downstream tooling needs timecode, ensure the conversion preserves it.
• Codec compatibility — MOV supports codecs MP4 doesn't (older Apple codecs, some specialized codecs). Document codec choices for cross-tool compatibility.
• Quicktime atoms vs MP4 boxes — most tools handle both transparently, but custom processing code may need to be aware of the differences.
• File size — ProRes/DNxHR in MOV produces very large files. Storage and transfer planning matters.
• Color metadata — MOV's color information atoms must be preserved through processing for accurate downstream rendering, especially for HDR content.

#What MpegFlow does with MOV

MpegFlow's DAG runtime supports MOV as an input format for editorial-source content. An FfprobeExecutor stage runs first to characterize the source (codec, color metadata, timecode track, edit lists); cross-stage data flow wires that probe output into the downstream FfmpegExecutor encode stage's parameters. The partitioner persists each stage to job_stages with explicit dependency tracking; per-stage retry handles transient failures.

For pipelines ingesting from editorial workflows (post-production houses, in-house editorial teams, content acquisition from broadcast/cinema sources), MOV handling is essential. Edit lists are flattened during normalization; timecode tracks are preserved end-to-end through the pipeline via timestamp-preservation discipline at every stage boundary, and the timecode survives into downstream renditions for editorial-system delivery when the workflow requires it.

For output, MpegFlow produces MP4 (specifically CMAF) for streaming use cases by default. MOV outputs are configured for specific cases:

• Customer delivery to editorial systems that expect MOV.
• Mastering workflow outputs encoded with mezzanine codecs the pipeline supports — ProRes profiles (from Proxy through 4444 XQ) and DNxHD/DNxHR.
• Apple Mastering Specification deliveries.

The strict-broker security model handles MOV like any pipeline payload — workers carry no ambient credentials; content access flows through short-lived presigned URLs scoped per stage; access is disposed on completion.

For customers building broadcast-to-streaming pipelines, MOV ingest is the typical input. The conversion to MP4/CMAF for streaming is the standard pipeline path. We exercise the operational details (edit list flattening, color metadata preservation, codec normalization, timecode preservation) under regression discipline because mishandling these causes silent quality bugs in the streaming output.

The general direction: MOV is the editorial container; MP4 is the streaming container. Pipelines that bridge editorial and streaming (most premium streaming pipelines) handle both. The competence is in the conversion stage; both formats are well-understood once you know what you're doing.