37

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?

Ƭᴇcʜιᴇ007
  • 112,807
Sun
  • 6,318

3 Answers3

34

Only downside is it can take a few more seconds

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:

Without -movflags +faststart

ffmpeg -i input.mkv -c copy output.mp4
0m11.695s

With -movflags +faststart

ffmpeg -i input.mkv -c copy -movflags +faststart output.mp4
0m12.252s

Note this option is only for MP4, M4A, M4V, MOV output.

llogan
  • 59,497
  • 5
    In the latest version of ffmpeg (3.x+ or 4.x+), the correct syntax is -movflags faststart indeed (without the + sign). See: https://ffmpeg.org/ffmpeg-formats.html#Options-8 – Siu Ching Pong -Asuka Kenji- Dec 23 '18 at 14:59
  • 1
    @SiuChingPong-AsukaKenji- It doesn't really matter if you include the + or not. – llogan Dec 26 '18 at 00:17
  • So it doesn't apply to .mkv output? I don't get an error, so does that mean it's simply being ignored? – Hashim Aziz Mar 09 '21 at 02:07
  • 2
    @HashimAziz This option is only for the MOV family such as MP4, M4A, M4V, MOV. It will get ignored for anything else. – llogan Mar 09 '21 at 20:30
  • 2
    @HashimAziz As far as I know, there is no global-metadata block in MKV, so no need to move it to the start of the file. In MKV, metadata such as time-index is attached to each chunk of the file, which means skipping to a desired time-index is more or less a game of guessing a byte-offset first, and verifying the nearest time-index. Of course, this is an imprecise and slow process, and it would be quite similar for MP4 without "faststart" optimization (there are subtle differences, though). – Robin479 Feb 13 '22 at 12:37
  • -movflags faststart sets the flags to exactly faststart; -movflags +faststart adds faststart to whatever the preexisting list of flags is. (Similarly, -faststart would remove faststart from the flags list.) – BallpointBen Mar 19 '24 at 18:57
21

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.

thomasrutter
  • 1,938
  • You wrote: "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". Is ffmpeg such a software? – Totor Feb 18 '21 at 23:00
  • 2
    Ffmpeg looks like it has a -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. – thomasrutter Feb 19 '21 at 00:34
  • 1
    You can't pipe a non-faststart MP4 either (unless the reader reads the whole file into a buffer and then plays it). Without the moov atom, the reader can't even start demuxing / decoding, even if it doesn't want to seek. You need a format like MKV to pipe into a video player, like ffmpeg -i ... -c copy -f matroska - | mpv -. If you try with -f mov or -f mp4, you get the error muxer does not support non seekable output (with or without +faststart). – Peter Cordes Jan 05 '24 at 04:58
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.

Alex Svetkin
  • 279
  • 2
  • 4
  • "About 2% difference, that could be just noise." Could be. One can tell whether it's noise by repeating it and seeing if the difference happens again without having varied the parameters. Here, both times the fast start is slower, so I would be inclined to say that it's still slower (not just noise) even if not noticeable on the scale of 12 seconds as in the accepted answer. What would be interesting is whether it's exponential, since it's 2.2% in the ~3.7 minutes example and only 1% in the 27s example. A 1-hour video being 100% slower would be kind of annoying. – Luc Jan 08 '23 at 09:42
  • Note that when file sizes get large (tens/hundreds of gigabytes), the difference is no longer "just noise". -movflags faststart could take 3x the time which is a significant difference. See this discussion: https://github.com/mifi/lossless-cut/issues/1654 – Mikael Finstad Jul 11 '23 at 15:41
  • Basically we are talking about encoding speed and input-output speed here. Simple plain encoding takes time to read (input), encode and write (output). With -movflags faststart it takes to read, encode, write, then read and write again (omit modifying the moov atom, it is negligible). So one extra read and write with -movflags faststart. – Alex Svetkin Jul 11 '23 at 20:41
  • 1
    For larger files one extra read/write of course will take more time. But note that a larger file often implies a longer duration, so encoding would also require more time. Overall, my guess is that there are no noticeable drawbacks in using -movflags faststart in most use cases. But YMMV. – Alex Svetkin Jul 11 '23 at 20:58
  • Just for the record, never use x264's -preset ultrafast except with lossless encodes (-qp 0). It's only a tiny bit faster than superfast, but a lot worse quality because it doesn't do any sub-pixel motion estimation and mode-decision. You get noticeable blocking artifacts even when you give it plenty of bitrate, like -crf 18. (I haven't actually tried ultrafast + overriding subme=1, perhaps the actual reason is one of the other settings like --partitions none, but it disables CABAC and B-frames as well; the massive quality sacrifice isn't worth the tiny speed increase.) – Peter Cordes Jan 05 '24 at 04:45
  • But yes, rewriting the file after an encode (not transcode) is almost always a small fraction of the time to actually encode, unless you have special circumstances like slow I/O. For small files that are still hot in disk cache, it's totally negligible, especially if 2 copies fit in RAM so the first one doesn't have to get written to disk. – Peter Cordes Jan 05 '24 at 04:49
  • If you do need to minimize I/O, or avoid a burst at the end, there are other formats like .mkv that don't have this problem. MKV also lets you preview your encode while its encoding, since the partially-written file is playable. (With a player like MPV on an OS like Linux where reading files that are being written isn't a problem. IDK if Windows is still annoyingly over-cautious about not letting programs read a file that's being appended, or if MPV for Windows can work around that to play partially downloaded or encoded files.) – Peter Cordes Jan 05 '24 at 04:51