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 some time to perform the second pass to move the moov atom to the beginning of the file.
-movflags +faststart$ time ffmpeg -y -f lavfi -i nullsrc=s=hd720:d=600 -preset ultrafast out.mp4
real 0m42.701s
-movflags +faststart$ time ffmpeg -y -f lavfi -i nullsrc=s=hd720:d=600 -movflags +faststart -preset ultrafast out.mp4
real 1m4.036s
You should use +faststart instead of just faststart, because it will be added to any default/other/existing flags instead of unsetting them (but I've never tested this).
Admittedly, using nullsrc was not the best input since it may not create a consistent output, but I was impatient and wanted something fast yet dynamic enough to provide a sizeable file (but I didn't want pure noise). Also, I only did one test per command so it's a low sample size. Regardless, the time difference is obvious.
-movflags faststart indeed (without the + sign). See: ffmpeg.org/ffmpeg-formats.html#Options-8
– Siu Ching Pong -Asuka Kenji-
Dec 23 '18 at 14:59
+ or not.
– llogan
Dec 26 '18 at 0:17
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.
real 0m30.676s. With faststart real 0m30.599s. My ffmpeg version is 4.2. I guess it's safe to say that this doesn't make a big difference anymore, if any at all.
– confetti
Oct 21 at 0:36
As you may already know, the information required to write the moov atom or even to know its size 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 front and have no drawbacks.
Second pass is required. This 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.
Output cannot be piped to another command / sent to stdout on the fly, because those mechanisms have no way of doing a second pass.
