MOV File Documentation

Summary

A QuickTime Movie is Apple’s video container format, introduced with QuickTime in 1991 and the default for video recorded on iPhone, iPad and Mac. The .mov file wraps video, audio, timecode and subtitle tracks in a tree of “atoms”, with the MIME type video/quicktime. Its structure became the basis of MP4, so the two convert with a fast, usually lossless remux. VLC plays any .mov on any system.

Technical details

FeatureValue
Full nameApple QuickTime Movie
File extension.mov
MIME typevideo/quicktime
Format typeMultimedia container, atom/box-based binary
Base formatQuickTime File Format (QTFF); basis of ISO Base Media File Format
DeveloperApple Inc.
Introduced1991 (QuickTime 1.0)
Open standardNo (published Apple specification, proprietary)
Byte orderBig-endian
Magic number (hex)66 74 79 70 71 74 20 20 (ftypqt  ) at offset 4
Major brandqt   (0x71 74 20 20); some old files start with moov/mdat
Video codecsH.264/AVC, H.265/HEVC, Apple ProRes, MPEG-4 Part 2
Audio codecsAAC (usual), Linear PCM, ALAC
Optional tracksTimecode, subtitles/captions, chapters, metadata
Top-level atomsftyp, moov, mdat, wide, free, skip
Relationship to MP4Near-identical structure; remux is usually lossless
Related extensions.mp4, .m4v, .qt, .m4a, .3gp
Specificationdeveloper.apple.com/documentation/quicktime-file-format
File signature (magic bytes)
.. .. .. .. 66 74 79 70 71 74 20 20

A modern QuickTime file opens with an ftyp atom, so the ASCII ftyp (66 74 79 70) sits at offset 4, not 0: bytes 0–3 are the atom’s size. The four bytes that follow are the major brand, and for QuickTime it is qt   (71 74 20 20, note the two trailing spaces). Because MP4, .m4v, .m4a and .3gp share the same ISO Base Media File Format that grew out of QTFF, they use the same ftyp marker at offset 4, differing only in brand. Some older .mov files predate ftyp (added ~2004) and instead begin directly with a moov or mdat atom, so a .mov without ftyp is classic QuickTime, not a corrupt file.

What is a MOV file?

A QuickTime Movie is Apple’s multimedia container, introduced with QuickTime in 1991. It is a container, not a codec: a .mov wraps one or more timed tracks (video, audio, timecode, subtitles) whose actual samples are compressed by some codec, and records the metadata a player needs to find, decode and synchronise them. Consumer clips are usually H.264 or H.265 video with AAC audio; professional workflows use Apple ProRes with Linear PCM audio.

The QuickTime File Format (QTFF) was influential enough that the MPEG group adopted it as the basis of the ISO Base Media File Format, and therefore of MP4. That shared ancestry is the most important practical fact about .mov: a MOV and an MP4 are close cousins built from the same box model, which is why converting between them is often a fast remux rather than a re-encode. Everything below is about how QTFF encodes a movie, atom by atom.

The atom: QuickTime’s building block

A QuickTime file is a flat sequence of nested atoms (the ISO term, used in MP4, is “boxes”). Every atom begins with the same 8-byte header, and atoms contain other atoms, so a parser can walk the whole tree without knowing any specific atom type in advance.

Atom header:
  size : uint32  bytes 0-3  total atom length incl. this header
  type : uint32  bytes 4-7  four-character code, e.g. 'moov'
  // if size == 1, a 64-bit 'largesize' follows the type
  // if size == 0, the atom runs to end of file (last atom only)
  // payload follows

The first field is a 32-bit big-endian size giving the atom’s total length including the header; the second is a 32-bit type, four printable ASCII characters such as ftyp, moov or mdat. Two escape values matter. A size of 1 means a 64-bit largesize follows the type, which is how an mdat exceeds 4 GB. A size of 0 means the atom runs to the end of the file, valid only for the last atom. Because each atom carries its own length, an unknown atom is trivially skipped: read size, jump size bytes, continue. All multi-byte integers are big-endian.

Two more top-level atoms are peculiar to QuickTime housekeeping. A free or skip atom is padding a reader ignores, and a wide atom reserves 8 bytes in front of an mdat so the mdat can later be promoted to a 64-bit size without shifting the media. Seeing wide just before mdat is a common QuickTime signature.

ftyp and the ‘qt ’ brand

A modern QuickTime file opens with an ftyp (file-type) atom, which is why the ASCII ftyp appears at byte offset 4 rather than 0: bytes 0–3 are its size. Its payload declares which specifications the file conforms to.

ftyp
  major_brand        : 'qt  '   (0x71 74 20 20, two trailing spaces)
  minor_version      : uint32
  compatible_brands[]: list of four-char codes to end of atom

The major_brand qt   identifies QuickTime specifically, distinguishing a .mov from an MP4 whose brand would be mp42 or isom. The ftyp atom was only introduced around 2004 with the ISO base media format, so files authored by older tools may have no ftyp at all and begin directly with moov or mdat. Such a file is classic QuickTime, not damaged; a parser identifies it by finding a valid top-level moov rather than by the missing brand.

The moov atom: movie and track headers

The moov atom is the movie atom, the “brain” of the file: it holds all metadata and no coded media. It contains one mvhd movie header plus one trak atom per track, and each track’s tree drills down to a sample table.

moov
 ├─ mvhd                movie header: time scale, duration, next track ID
 ├─ trak                one track (e.g. video)
 │   ├─ tkhd            track header: track ID, flags, width, height, matrix
 │   └─ mdia            media for this track
 │       ├─ mdhd        media header: this track's time scale + duration
 │       ├─ hdlr        handler: 'vide' / 'soun' / 'text' / 'tmcd'
 │       └─ minf        media information
 │           ├─ vmhd/smhd  video or sound media header
 │           ├─ dinf/dref   where the media data lives
 │           └─ stbl        the SAMPLE TABLE
 └─ trak                another track (e.g. audio)

The mvhd carries the movie-level time scale, the number of time units per second against which duration is expressed, plus the total duration and next_track_ID. Each trak opens with tkhd, holding the track’s ID, enabled flags, a 3×3 display matrix (which encodes rotation, so a portrait iPhone clip is often a landscape frame plus a 90° matrix), and for video the display width and height as 16.16 fixed-point. Inside mdia, the hdlr handler type names the track kind: vide, soun, text for subtitles, or tmcd for timecode. Below that, minf leads to stbl, where the real indexing lives.

The sample table: stsd, stts, stsc, stsz, stco

Everything needed to locate, time and decode an individual sample is packed into the stbl (sample table) as a set of parallel tables. A sample is one coded unit: one video frame, or one AAC audio frame. Splitting the data across tables keeps each compact, and a reader cross-references them to rebuild the timeline.

stbl
 ├─ stsd   sample descriptions: codec + config per entry
 ├─ stts   time-to-sample: sample durations (run-length coded)
 ├─ ctts   composition offsets: PTS - DTS for reordered frames
 ├─ stsc   sample-to-chunk: how many samples per chunk
 ├─ stsz   sample sizes in bytes
 ├─ stco   chunk offsets into the file (co64 for 64-bit)
 └─ stss   sync sample table: which samples are keyframes

The stsd atom is where the codec is actually named: a video entry typed avc1 nests an avcC configuration (the H.264 SPS/PPS), hvc1 nests hvcC for HEVC, and Apple ProRes appears as apcn, apch and related types. Without stsd a decoder cannot be initialised. stts maps sample number to duration with run-length entries, so constant-frame-rate video needs a single entry. ctts adds a per-sample composition offset because B-frames decode out of display order. stsc groups samples into chunks, stsz lists each sample’s byte size, and stco (or 64-bit co64) gives each chunk’s absolute file offset. stss lists the keyframes for seeking; if it is absent, every sample is a keyframe.

mdat: locating a sample by offset, size and time

The mdat atom is a single opaque blob of interleaved coded samples, typically occupying almost the entire file. Nothing inside it is self-describing; it is meaningless without the sample tables pointing into it. To fetch sample n, a reader combines four tables: stsc says which chunk holds it and its position within that chunk, stco/co64 gives that chunk’s file offset, the stsz sizes of preceding samples in the chunk are summed to reach the sample’s start, and stsz gives its length. That is the exact byte range. Decode time comes from accumulating stts durations; presentation time adds the ctts offset. Seeking runs the same logic in reverse from the nearest stss keyframe.

The separation of index (moov) from media (mdat) has one important consequence for streaming. Encoders often write moov after mdat, because final sample sizes are known only when encoding finishes, which over HTTP forces a client to download the whole file before playback. Rewriting the file so moov precedes mdat (a “fast start” pass) lets playback begin from the first bytes, but every offset in stco/co64 must be recomputed because the media has moved.

MOV versus MP4, and ProRes versus HEVC

Because MP4 is built on the ISO base media format that descended from QTFF, a MOV and an MP4 share the same atom model. When the coded tracks are MP4-legal (H.264 video, AAC audio), converting .mov to .mp4 is a container remux: the samples are copied unchanged and only the surrounding atoms are rewritten, so it is fast and lossless (ffmpeg -i in.mov -c copy out.mp4). The same is true of .m4v, Apple’s MP4 variant, which shares the structure and differs mainly in brand and DRM conventions.

This layering also explains the classic “my .mov won’t play” problem. The atom tree almost always parses fine; what a player lacks is a decoder for the codec that stsd names. On Windows that is usually HEVC (iPhone footage since iOS 11 in 2017) or Apple ProRes (editing masters), neither of which ships with every system. The fix is a player that carries its own decoders, such as VLC, rather than treating the file as broken. A ProRes master, being intra-frame and high-bitrate, is large and often needs a genuine re-encode (not a remux) to become a shareable H.264 MP4.

FAQ

Why won’t my MOV file play on Windows?

Almost always a missing codec for the video inside, not a broken file. iPhone clips are often HEVC and editing masters are Apple ProRes, and neither is guaranteed on Windows. Open the file in VLC, which bundles its own decoders and plays nearly every .mov. Do not install Apple’s old QuickTime for Windows, unpatched since 2016.

What is the difference between MOV and MP4?

MOV is Apple’s QuickTime container; MP4 is the cross-platform standard derived from it. They are structurally almost identical and convert easily, often as a lossless remux. MOV is the default on Apple devices; MP4 is the safer choice for sharing everywhere.

Why is video from my iPhone a MOV file?

iPhone and iPad cameras record in QuickTime .mov (H.264, or HEVC since iOS 11 in 2017). It plays perfectly on Apple gear; convert to MP4 if a Windows app, Android phone or website rejects it.

References