Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.
Sign up to join this community
It seems many sites like YouTube suggest moov atom at the front of the file (Fast Start).
ffmpeg does not make this a default behavior, but you can specify it with the -movflags faststart option. I'm wondering if there is any downside to always using this parameter?
Depending on the size of your input it can take a few more seconds usually to perform the second pass to move the moov atom to the beginning of the file.
Example of re-muxing a 1 hour video:
-movflags +faststartffmpeg -i input.mkv -c copy output.mp4
0m11.695s
-movflags +faststartffmpeg -i input.mkv -c copy -movflags +faststart output.mp4
0m12.252s
Note this option is only for MP4, M4A, M4V, MOV output.
-movflags faststart indeed (without the + sign). See: ffmpeg.org/ffmpeg-formats.html#Options-8
Dec 23 '18 at 14:59
+ or not.
.mkv output? I don't get an error, so does that mean it's simply being ignored?
Mar 9 '21 at 2:07
I guess this thread needs an update. On latest ffmpeg (3.4.1) I get:
$ time ffmpeg -y -f lavfi -i nullsrc=s=hd720:d=600 -preset ultrafast out.mp4
real 0m26.578s
$ time ffmpeg -y -f lavfi -i nullsrc=s=hd720:d=600 -movflags +faststart -preset ultrafast out.mp4
real 0m26.849s
Same results. Now try with a real video:
$ time ffmpeg -y -i Sintel.2010.1080p.mp4 -preset:v ultrafast out.mp4
real 3m38.829s
$ time ffmpeg -y -i Sintel.2010.1080p.mp4 -preset:v ultrafast -movflags +faststart out.mp4
real 3m43.674s
About 2% difference, that could be just noise. Also need to note that "Starting second pass: moving the moov atom to the beginning of the file" phase took no more than couple seconds on 600Mb output file.
As you may already know, the information required to write the moov atom or even to know the size of the moov atom isn't available until after the entire file is processed.
The drawbacks to having the moov atom at the start, and the reason many tools don't do it by default, are therefore all related to this fact.
If none of the following are a problem for you, then you can put the moov at the start all times and have no drawbacks.
A second pass is required. This potentially doubles the amount of disk I/O as data must be read from input, written to disk, then read from disk and re-written. This can be impractical where I/O speed is very slow, such as when writing to a network drive.
Note that some software may optimize this by roughly estimating the required size of the moov atom near the start of encoding and reserving this much space, plus a margin of error, at the start of the output. In many cases this would remove the need to read-back and re-write the rest of the file and instead seek to the start and overwrite just a small part, at the cost of using slightly more space for the moov atom than necessary.
Output cannot be piped to another command or sent to stdout on the fly, because those mechanisms have no way of doing a second pass or seeking backwards.
ffmpeg such a software?
-moov_size bytes option on the MP4 muxer to reserve a certain amount of bytes for the moov at the start of the file. I don't know exactly how it interacts with -movflags faststart. I would assume if you use just moov_size bytes, it should work like you want. But you'd need to test. Also, estimating the size of the moov atom yourself sounds a bit hit and miss.
Feb 19 '21 at 0:34