总是使用 -movflags faststart 参数有什么缺点吗？

Question

似乎像 YouTube 这样的许多网站都建议在文件的前面添加 moov atom（快速启动）。

ffmpeg 不会将此作为默认行为，但您可以使用-movflags faststart选项指定它。我想知道总是使用这个参数有什么缺点吗？

Answer 1

唯一的缺点是它可能需要多几秒钟

根据输入的大小，执行第二遍将moov原子移动到文件开头通常可能需要几秒钟。

重新混合 1 小时视频的示例：

没有 -movflags +faststart

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

和 -movflags +faststart

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

请注意，此选项仅适用于 MP4、M4A、M4V、MOV 输出。

Answer 2

我想这个线程需要更新。在最新的 ffmpeg (3.4.1) 上，我得到：

$ 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

结果一样。现在尝试一个真实的视频：

$ 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

大约 2% 的差异，这可能只是噪音。还需要注意“开始第二遍：将 moov 原子移动到文件的开头”阶段在 600Mb 输出文件上花费的时间不超过几秒钟。

Answer 3

正如您可能已经知道的那样，在整个文件被处理之后，编写 moov atom 甚至知道 moov atom 大小所需的信息是不可用的。

因此，在开始时使用 moov atom 的缺点，以及许多工具默认情况下不这样做的原因，都与这个事实有关。

如果以下对您来说都不是问题，那么您可以始终将 moov 放在开头并且没有任何缺点。

• 需要第二遍。这可能会使磁盘 I/O 的数量增加一倍，因为数据必须从输入读取，写入磁盘，然后从磁盘读取并重新写入。这在 I/O 速度非常慢的情况下是不切实际的，例如写入网络驱动器时。

  请注意，某些软件可能会通过在编码开始附近粗略估计 moov 原子所需的大小并在输出开始时保留这么多空间以及误差幅度来优化这一点。在许多情况下，这将消除回读和重写文件其余部分的需要，而是寻找开始并只覆盖一小部分，代价是为 moov 原子使用比必要的空间稍多一些。

• 输出不能通过管道传输到另一个命令或即时发送到标准输出，因为这些机制无法进行第二次传递或向后搜索。