Is there a downside to putting the MOOV atom at the beginning of an MP4 file?

Question

I see tons of questions about relocating the moov atom from the end of a MP4 video container to the beginning, to make the video "web optimized" or easier to stream. It seems like most tools require an explicit option to do this when first encoding the video, if it's available at all.

If placing the atom at the beginning makes streaming work better, and it's costly to do it after-the-fact, why would I ever want to encode video with the atom at the end? What's the benefit?

Solution 1

Encoding the MOOV at the end of the file is usually a default operation for video encoders because they tend to operate by writing the output file in one-pass, and the exact contents and size of the MOOV atom can only be known after having written audio and video data entirely, because it contains absolute file sizes.

FFmpeg allows you to do a second pass and move the atom to the beginning with -movflags +faststart.

Having the MOOV atom at the end has no special benefit, it is just not as inconvenient in local playback situations where seeking at end-of-file before playback is not as costly as in progressive download delivery.

Solution 2

You will always want to put the index information at the beginning of the file, there is no hidden cost for this layout except the only one: while doing capture/transcoding you might be unable to tell in advance how much space you need for that MOOV atom at the beginning, and its data is not yet well available as well. So you normally write the payload directly into file and they complete the write by adding MOOV and updating the rest of the file.

Comments

[Coderer]

It's just hard to imagine that, in the scope of taking 30 minutes, or an hour, or ten, to create an encoded movie, anyone would notice the extra minute or two it takes to write out the MOOV atom then copy over the rest of the finished data segments. Surely the I/O cost is dwarfed by the computation required to do the encoding in the first place?

[SirDarius]

I suppose it depends on the encoding software, but ffmpeg is alas generic enough that "rewriting the file after the fact" needs major refactoring in the current state of things. There is a similar problem with FLV files and metadata, so that there are software like flvtool or flvmeta that are needed to properly inject them after encoding. One must also realize that video encoders don't always write data to seekable streams (network streams for instance), where going back is not possible at all.

[Sagar Pilkhwal]

I know this is offtopic but i'm still going to ask; android's video element can play mp4 files only, so even if the moov element is at the end still it play's video via http stream without any issue. how is that possible ?how does android handle's the video without moov atom?

[SirDarius]

@SagarPilkhwal my bet would be that this is achieved by using partial HTTP requests. Once the total file size is known, the client can make an HTTP request with a byte-range that encompasses the MOOV atom, and then resume file loading from the beginning

[Sagar Pilkhwal]

Yes, I guess so I found this link which talks about the issue i mentioned fabiensanglard.net/mobile_progressive_playback/index.php