What Is an MP4 File? A Box Container for Video, and Why Some Files Will Not Play

1 What Is an MP4 File? A box container for video and audio, saved as .mp4

ISO/IEC 14496-14 defines the MP4 file format. Its abstract says the format is derived from the ISO Base Media File format.

The current edition is the third, published on 27 January 2020, and it replaced the 2018 edition, which ISO lists as withdrawn.

Wikipedia says MP4 followed in 2003 and that it is based on the QuickTime file format.

Sources differ on the first year. Wikipedia names 2001 for the first MPEG-4 file format, and MDN names 1999, so we print both. They agree that Part 14 came in 2003. FileInfo gives 2001 for the first release and 2003 for version 2.

The ending .mp4 and its relatives

Wikipedia says .mp4 is the only ending that the standard defines. The others are habits. Audio only files use .m4a, audiobooks use .m4b, protected audio uses .m4p, ringtones use .m4r and some video files use .m4v.

PRONOM, the format registry of the UK National Archives, lists mp4, m4v, m4a, f4v, f4a and m4b in one record named MPEG-4 Media File.

We renamed our sample MP4 file to .mov, .mkv, .m4a, .txt and .dat. FFmpeg and the file command read the same file every time, and the SHA256 hash stayed the same. The check part shows the result. An ending that does not match the content can still hide a good MP4 file from your player.

Container and codec

A container is the box. A codec is the method that squeezes video or sound inside it. The MP4 file format stores squeezed data and an index to it, and it leaves the squeezing to the codec.

MDN lists H.264, AV1, H.263, MPEG-4 Part 2 and VP9 for video in MP4 files. It lists AAC, FLAC, MP3 and Opus for audio.

So an MP4 file can play on one device and fail on another, with the same ending and the same container. The codecs part shows our test. Chromium 141 played an MP4 file with AV1 and Opus and refused one with H.264 and AAC.

Where our MP4 files come from

We worked with three sets of MP4 files. We built 4 test MP4 files with FFmpeg 6.1.1. All are 10 second clips of 640 by 360 pixels with a sine tone.

One has H.264 and AAC with moov first, one is the same clip with moov last and one is fragmented. The fourth has AV1 and Opus. The second set is 132 damaged copies of those 4 MP4 files.

The third set is 231 public MP4 files from test folders of Chromium and Firefox, 153 from the first and 78 from the second. They add up to 50,907,584 bytes, and the largest has 7,839,097 bytes.

We read them with FFmpeg 6.1.1, with MediaInfo through pymediainfo 7.0.1, with the file command 5.45, with Python 3.13 and with our own scripts. We opened the AV1 file and its copies in Chromium 141 through Playwright on Linux.

We did not watch or listen to any file. We compared decoded frames and audio with hashes. We did not test VLC, Windows Media Player, QuickTime, desktop Chrome, Edge, Firefox, Safari or a phone. What we say about those programs comes from their makers’ pages, and we say so every time.

MP4 file facts at a glance

Wrong page? Look at the FLV page for Flash video, the GIF page for animated pictures or the SRT page for subtitles.

4 What Do 231 Public MP4 Files Contain? 13 brands, 84 fragmented files and 78 unfragmented files with moov last

These are test MP4 files that engineers wrote to check players, so some are damaged on purpose. They add up to 50,907,584 bytes, and the largest has 7,839,097 bytes. They are not a sample of the web. Read them as a picture of what tools write and of what a reader does with it.

The names are simple. 224 end in .mp4, 3 in .m4a, 2 in .mov, 1 in .3gp and 1 in .m4s. The brand in the ftyp box shows more than the ending does. The table lists every brand with the text that the file command printed.

The position of moov in the public MP4 files

84 MP4 files are fragmented, and 82 of those have moov first. 95 MP4 files are not fragmented, with one moov and one mdat. Of those, 78 keep moov at the end and 17 keep it in front.

51 MP4 files have a moov and no data, which are the start of a stream or a test of a reader. One file has no moov at all.

So most unfragmented public MP4 files have moov last. That says how test MP4 files are made, because many tools write moov last unless you ask for faststart. It does not say how common the layout is on the web. The moov part shows what the position costs when an MP4 file is cut.

The PRONOM signature and our MP4 files

PRONOM’s record gives the pattern {4}ftyp{0-64}(mp42|mp41|isom|iso2)*moov for MPEG-4 Media File. RFC 4337 and the Library of Congress list no magic number at all. We tested the PRONOM pattern as we read it on the 231 MP4 files.

It matched 185 of 231. It missed 46 MP4 files. They are 36 MP4 files with the brand iso5 and no isom family brand, and 6 with the brand qt.

One has no ftyp, one has ccff, one has iso6 and one is an isom file that has no moov. So the pattern fits files with the brands it names.

It does not fit every MP4 file, and a file that does not match can still play.

Where our script and FFmpeg disagree

Our script reads boxes and offsets and decodes nothing, so it cannot see a codec problem. FFmpeg reads the codec data and cannot see a box that no one needs. Both tools miss what the other sees, and the damaged copies below show the same split.

The 132 damaged copies

We took the 4 MP4 files that we built. The first has H.264 and AAC with moov first, with 639,131 bytes. The second is the same clip with moov last and has the same size.

The third is fragmented, with 637,057 bytes. The fourth has AV1 and Opus and 685,182 bytes. We damaged every file in 19 ways and made 33 copies of every file.

A kind that picks a random place got more copies, so the kinds have 4, 8, 12 or 20 copies. We seed the random choice with the MP4 file, kind and copy number, so anyone can make the same copies. We changed one thing at a time and left every other byte alone.

The public MP4 files show what tools write. Built files give us a known good original, and with it we can say for every copy whether the decoded video and audio changed. The next part has the results.

5 What Happens When an MP4 File Is Damaged? 132 copies, and 17 that got no flag from our two checks

We sorted the 19 kinds into four groups. They cover headers at the start, cuts and extra bytes, the index in moov and media data in mdat.

We read every copy with our 70 line script, with the FFmpeg decode check, with ffprobe, with MediaInfo and with the file command. We opened the 33 copies of the AV1 file in Chromium 141.

Changed means the decoded frames or the decoded audio differ from the original. A flag is any line that a check printed.

The decode check is ffmpeg -v error -i copy.mp4 -f null -, and it flags a copy when it prints anything.

A name like k13 in a code box is a copy of kind 13 in the figure.

Green means the copy changed and a check flagged it. Blue means it stayed the same and a check still flagged it. Red means it changed and nobody said anything. Gray means it stayed the same and got no flag. The last two columns count flags from our script and from FFmpeg.

Silent damage in an MP4 file

17 copies got no flag from either check. 14 of them have one changed byte or 1 KiB of zeros in mdat.

The other 3 are one flipped byte in moov, one changed sample size and one copy of the fragmented file with the mdat size set to 0.

In that copy the box then swallowed 225 of the 250 frames and nothing complained.

$ python3 mp4_check.py k16.mp4
no problem found
$ ffmpeg -v error -i k16.mp4 -f null - | wc -l
0
$ cmp -l sample.mp4 k16.mp4 | wc -l
1
$ diff of the frame hashes: lines that differ
25

The script says no problem found, and FFmpeg prints nothing. The cmp command finds one byte that differs, and the frame hashes show 25 frames that differ.

A byte in mdat is a byte of picture data, so a good MP4 file and a damaged file have the same boxes. In the 20 copies of this kind, the changed byte altered between 0 and 217 of the 250 frames.

The 0 is a copy where only the audio changed.

Only a hash of the good MP4 file shows this damage for sure. That is why the check steps starts with a hash and ends with a comparison against a copy you trust.

Damage in the index of an MP4 file

The index kinds are 11 to 15. One changed chunk offset gave 8 of 8 copies that decoded differently. FFmpeg flagged all 8, and our script flagged none, because an offset that moves a little stays inside mdat. One changed sample size changed 7 of 8 copies and FFmpeg flagged all 7.

$ python3 mp4_check.py k13.mp4
no problem found
$ ffmpeg -v error -i k13.mp4 -f null -
[NULL @ 0x55b3819a5fc0] Invalid NAL unit size (531718461 > 1339).
[NULL @ 0x55b3819a5fc0] missing picture in access unit with size 1343
[h264 @ 0x55b381a51140] Invalid NAL unit size (531718461 > 1339).

A moov box renamed to free gave a surprise. Our script flagged all 4 copies, and FFmpeg printed a warning on all 4, yet 3 of 4 decoded the same frames.

FFmpeg finds the index in a free box and goes on, and ffprobe says it detected moov in a free or hoov atom. It failed only on the fragmented copy. A movie timescale of 0 did the same, with 4 flags and 4 copies that played the same.

$ python3 mp4_check.py k11.mp4
no moov box
$ ffprobe -v error -show_entries stream=codec_name -of csv=p=0 k11.mp4
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x5599a26aba00] Detected moov in a free or hoov atom.
h264
aac

One flipped byte in moov was the mixed case. 9 of 12 copies decoded differently. Our script flagged 5 of them, FFmpeg flagged 5 and 1 got no flag. It depends on which byte moved. A byte in a time stamp changes little, and a byte in a size or an offset breaks the picture.

Damage at the start of an MP4 file

A changed brand changed nothing. All 4 copies decoded the same and nobody flagged them. The file command is the only reader that noticed. It prints ISO Media and drops the words MP4 Base Media. Players use codecs and the index, and they do not use the brand to decide.

$ file k01.mp4
k01.mp4: ISO Media
$ file sample.mp4
sample.mp4: ISO Media, MP4 Base Media v1 [ISO 14496-12:2003]
$ python3 mp4_check.py k01.mp4
no problem found

A removed ftyp box changed 3 of 4 copies, and the fragmented copy still played. The file command printed Apple QuickTime movie for 3 of the 4 and data for the moov last copy.

A moov size field raised by 16 changed 1 of 4 copies, the fragmented one, and our script flagged all 4. A size field of 20 on ftyp broke all 4 copies in every reader.

Cuts and extra bytes in an MP4 file

Cuts at 90, 50 and 10 percent changed all 12 copies, and both checks flagged all 12. 100 junk bytes at the end changed nothing in 8 copies, and our script flagged all 8, so they count as alarms.

1 MiB of zeros at the end changed nothing and got no flag. Players read the boxes they need and stop. Bytes after the last box do not hurt them.

$ python3 mp4_check.py k09.mp4
box with a bad name at 639131 has size 2971753348 and the file ends at 639231
$ ffmpeg -v error -i k09.mp4 -f null -
exit code 0

The moov part covers the cuts. The result there depends on which side of mdat the index is on.

Damage in the data of an MP4 file

The data kinds are 16 to 19. One byte inserted at the start of mdat is the harshest. The MP4 file grows by 1 byte, every box still fits, and our script says no problem found. Every offset in moov now points 1 byte too early.

6 of 8 copies gave no frames at all. The 2 fragmented copies gave 225 frames, and all 225 differ. FFmpeg printed 2,458 lines for the first copy.

$ python3 mp4_check.py k18.mp4
no problem found
$ ffmpeg -v error -i k18.mp4 -f null - | wc -l
2458
$ wc -c < sample.mp4 ; wc -c < k18.mp4
639131
639132

The last 10 percent of mdat set to zeros changed all 4 copies. 1 KiB of zeros inside mdat changed all 20, and FFmpeg flagged 14 of them. 6 of those 20 got no flag from either check, and their pixels still differ from the original.

What every reader said

Chromium stopped with an error for 4 copies before the first frame and for 12 after it had shown from 21 to 216 frames.

The 6 that played to the end include copies where a byte in mdat or in the index changed. A player that shows 250 frames does not prove that the frames are right.

What the groups show

6 Where Should the Moov Box Be in an MP4 File? What a cut file gives, and how faststart moves the index

Every player must find moov before it can play a frame. The standard lets the box come before or after mdat, and many tools write it last because they only know the sizes when the encode ends.

We cut all four of our MP4 files at three points, and the figure shows the result for the two files that differ only in where moov is.

The fragmented file, which has a small moov in front, gave 225, 125 and 25 frames. The AV1 file, with moov first, gave 222, 123 and 21. The moov last file gave 0 at every cut, and FFmpeg said moov atom not found. Cutting removed the only index, and the data that remained had no map.

$ python3 mp4_check.py k06a.mp4
box mdat at 9731 has size 629400 and the file ends at 575217
chunk offset 9739 is outside every mdat
chunk offset 18372 is outside every mdat
the movie lists samples and there is no mdat box
$ python3 mp4_check.py k06b.mp4
box mdat at 40 has size 629400 and the file ends at 575217
no moov box
$ ffprobe -v error k06b.mp4
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x5614418417c0] moov atom not found
k06b.mp4: Invalid data found when processing input

Move moov to the front with faststart

FFmpeg’s format notes describes the faststart option as a second pass that moves the index to the front. It says the pass can take a while and that it does not work with fragmented output. We used it on our moov last file with stream copy, so no video was encoded again.

$ ffmpeg -v error -y -i sample-moovend.mp4 -c copy -movflags +faststart fast.mp4
$ python3 mp4_boxes.py fast.mp4
        0  ftyp         32  brand isom, also isom iso2 avc1 mp41
       32  moov       9691  
     9723  free          8  
     9731  mdat     629400  
639131 bytes, 0 left over
$ sha256sum sample.mp4 fast.mp4
84639aba53ff09604c97c7a39ec8e11145783f29eff38c162f46f6fe9d81a97f  sample.mp4
84639aba53ff09604c97c7a39ec8e11145783f29eff38c162f46f6fe9d81a97f  fast.mp4

The new file has the same SHA256 hash as our moov first sample. Every byte matches, so the decoded frames match. A faststart pass only reorders the boxes and rewrites the offsets in moov. It is the only fix on this page that loses nothing.

Rescue the frames of a cut file

A copy cut at 90 percent still has its moov and most of its data. We copied its streams into a new MP4 file with -c copy.

FFmpeg warned about a partial file, and the new file is complete, with a valid index and 223 frames. Our script found no problem in it. The last 27 frames are gone for good.

$ ffmpeg -v error -i k06a.mp4 -c copy fixed06.mp4
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x5590dd930fc0] stream 1, offset 0x8c7a6: partial file
$ python3 mp4_check.py fixed06.mp4
no problem found
$ ffprobe -count_frames on the video stream of fixed06.mp4
223

The moov last copy cut at 90 percent gave no file at all, because FFmpeg could not find the index. A recovery tool that rebuilds an index from the data needs a good MP4 file of the same camera or encoder as a guide. We did not test such a tool, and we name none.

What Chromium did with the cut AV1 copies

The AV1 file has moov first, so Chromium 141 could start the three cut copies. The copy cut at 90 percent played to the end of its data and showed 222 of 250 frames with no error.

The copy cut at 50 percent showed 123 frames and then stopped with a decode error at 4.7 seconds. The copy cut at 10 percent showed 21 frames and stopped at 0.6 seconds. We did not test a moov last file in Chromium.

We also did not measure how long a player waits for moov on a slow link. Our test only shows that the position decides what is left after a cut. If you save or send video that others will stream, write moov first or fragment the MP4 file, and keep a copy of the original.

7 What Does Our Expert Say About MP4 Files? A note from Neeraj Singh on keeping the original and its hash

Expert insight

An MP4 file is a map and a pile of data, and most damage hides in the pile. In our test one byte inserted at the start of the data gave no frames for 6 of 8 copies. Keep the original, write down its hash and write the index in front.

Neeraj Singh Manager, Tech Support & Operations · 19+ years fixing Windows and system errors

Why an MP4 file needs a hash

A video looks fine until you play it to the end. Players hide small damage, and our Chromium test showed 6 changed copies that played all 250 frames with no error. A hash of the original answers the question in one line, whether the MP4 file is the same or not.

Write the SHA256 hash when you save the MP4 file, and keep it in a text file next to your video. When you copy or send the MP4 file, hash the copy and compare. If the hashes differ, this copy is not the original, and no player can show how much is wrong.

Frequently Asked Questions About MP4 Files