FFmpeg 1.0实际使用的备忘单和预设设置?


28

尝试过其他地方提供的许多“备忘单”,但它们几乎都已过时,根本无法在最新版本的FFMpeg上使用。

谁能指出我将用于最新FFMpeg的设置?

我主要对以下编解码器感兴趣

H.264,低中和高质量预设

以及

ProRes,低中和高质量预设

Answers:


49

FFmpeg不再包含针对libx264的基于文本文件的预设和配置文件,即该-vpre选项所使用的内容。这些已经贬值,除去赞成访问实际X264预置,型材(和曲调)用的-preset-profile:v-tune选项。旧的文本文件仅模拟官方的x264预设和配置文件,并且由于一些限制而无法提供新系统提供的全部功能。它也易于维护。

此外,许多编码器都有自己的单独选项。也称为“私人期权”。您将必须查看FFmpeg联机文档中常见编解码器的音频视频编码器选项,或者检查的输出以ffmpeg -h full获取受支持选项的完整列表。例如,x264 libx264 AVOptions在完整的帮助输出中列出了其选项。

如果您的ffmpeg支持,-preset则不应使用任何文本文件预设,并且FFmpeg不再附带某些非标准iPod预设。一个普遍的误解是,文本预设可以简单地从任何地方复制并与任何ffmpeg一起使用。这是不正确的,会导致破裂。


基本上,这些预设使您可以执行以下操作:

控制品质

通过-b:v(对于视频)或-b:a(对于音频)指定比特率,或通过指定编解码器可能支持的任何其他编码方法,来控制质量。

对于x264,存在多种编码方法,其中“ 恒定速率因子”方法最为复杂。它可以产生可变的比特率,但是一次可以得到总体良好的质量。CRF值的范围从0到51,但理智的值介于19到26之间,具体取决于您的来源和所需的质量。默认值为23,因此您可以选择“ 18”(高品质)和28(“低品质”)。

ffmpeg -i input.mp4 -c:v libx264 -crf 23 output.mp4

x264 也具有其他编码方法,但这不在本文讨论范围之内。

限制H.264配置文件

这些配置文件定义了编码器可用来匹配某个解码器功能的功能集。最近的FFmpeg,请使用以下语法来指定一个配置文件,其中配置文件可能是baselinemainhigh

ffmpeg -i input.mp4 -c:v libx264 -profile:v baseline output.mp4

有关更多信息以及何时应使用哪个配置文件,请参阅:H.264配置文件之间有什么区别?

选择一个x264编码 preset

这些预设会影响编码速度。使用较慢的预设可为您提供更好的压缩率或每个文件大小的质量,而较快的预设可为您提供更差的压缩率。通常,您应该使用可以承受的预设。预设可以ultrafastsuperfastveryfastfasterfastmedium(默认值),slowveryslow。这是一个例子:

ffmpeg -i input.mp4 -c:v libx264 -preset slow output.mp4

编码无损视频

可以通过将CRF指定为0来实现,因此只需使用-crf 0

ffmpeg -i input.mp4 -c:v libx264 -crf 0 output.mp4

最后,让我们快速谈谈ProRes。ProRes可以使用接受固定的比特率-b:v,也可以指定配置文件,配置文件的值介于0到3之间,其中根据配置文件选择比特率。越高意味着越好:

ffmpeg -i input.mp4 -c:v prores -profile:v 0 output.mov

ffmbc维基表明,型材的名称可以使用-然而,这未能在FFmpeg的1.0。


我应该怎么做才能减少转换失败的可能性,它是随机发生的,有时却没有发生
FlyingAtom

@FlyingAtom我还没有听说过“转换失败”。如果您有一个可重现的特定问题,请提出一个新问题:superuser.com/questions/ask
slhck

那么,如果您提供的全部是,您将最终得到ffmpeg -i input.mp4 -c:v libx264 output.mp4什么呢?crf:23和预设:中?
Drazen Bjelovuk '16

1
@Drazen是的,是的。
slhck '16

干杯! -------
Drazen Bjelovuk '16

20

我进行了一项测试,其中我使用.mp4了一系列CRF值(18、21、24 和27)上的所有预设值(安慰剂除外)对Sony便携式摄像机的高质量视频进行了转码(使用libx264编码)。 )。我想知道什么能给我编码速度,输出质量和文件大小的最佳组合。

对于每个CRF值,我给每个转码操作都给出了其编码时间的分数(例如,对于CRF = 18,预设值ultrafast的时间为5.7秒获得了1.0的分数,非常慢的162秒的时间得到了0,所有其他分数则介于两者之间)。我也以类似方式计算了输出文件的大小得分,当然,最小的文件也得到了最好的得分。然后,我将两个分数相加,得出“综合”速度/大小分数。

对于这四个CRF值中的每一个,“非常快”的预设值都是不容置疑的获胜者,几乎完美的得分分别为1.94(对于CRF 18和21),1.96(CRF 24)和1.97(CRF 27)。我很好奇“ veryfast” 每次产生的文件大小几乎都是最小的,仅输给“ veryslow”,并且从未丢失过太多。

我确实注意到的各种预设值之间的差异是,操作系统(Windows 7)将为我提供不同的缩略图。更快的预设将在视频中显示几秒钟的缩略图,而较慢的预设的缩略图将反映视频的开始帧。对我来说那并不重要;我了解到,“快速预设”似乎是一个容易的选择。

这是我的结果(作为Excel电子表格的快照图像):
Excel快照

这是Excel电子表格的csv文本:

CRF,Preset,Seconds,score,MB,score,totalscore
18,1_ultrafast,5.7,1.00,59.5,0.09,1.09
18,2_superfast,8.4,0.98,62.3,0.00,0.98
18,3_veryfast,10.8,0.97,30.9,0.98,1.94
18,4_faster,16.0,0.93,33.5,0.89,1.83
18,5_fast,24.0,0.88,36.8,0.79,1.68
18,6_medium,29.1,0.85,34.9,0.85,1.70
18,7_slow,48.1,0.73,33.9,0.88,1.61
18,8_slower,84.9,0.49,33.0,0.91,1.40
18,9_veryslow,162.0,0.00,30.1,1.00,1.00
21,1_ultrafast,5.7,1.00,38.0,0.00,1.00
21,2_superfast,7.9,0.98,35.0,0.15,1.14
21,3_veryfast,10.0,0.97,19.0,0.97,1.94
21,4_faster,14.2,0.94,21.0,0.87,1.80
21,5_fast,19.9,0.89,23.0,0.77,1.66
21,6_medium,24.6,0.86,22.0,0.82,1.67
21,7_slow,43.1,0.72,21.0,0.87,1.58
21,8_slower,69.8,0.51,20.5,0.89,1.41
21,9_veryslow,137.3,0.00,18.4,1.00,1.00
24,1_ultrafast,5.5,1.00,24.9,0.00,1.00
24,2_superfast,7.5,0.98,21.4,0.27,1.25
24,3_veryfast,9.3,0.97,12.0,0.99,1.96
24,4_faster,13.2,0.93,14.0,0.84,1.77
24,5_fast,17.4,0.90,15.0,0.76,1.66
24,6_medium,21.0,0.87,14.4,0.81,1.67
24,7_slow,37.3,0.72,14.0,0.84,1.56
24,8_slower,62.2,0.51,13.0,0.92,1.42
24,9_veryslow,121.1,0.00,11.9,1.00,1.00
27,1_ultrafast,5.5,1.00,16.8,0.00,1.00
27,2_superfast,7.4,0.98,13.6,0.38,1.36
27,3_veryfast,9.0,0.97,8.4,1.00,1.97
27,4_faster,12.6,0.93,10.1,0.80,1.73
27,5_fast,15.8,0.90,10.4,0.76,1.66
27,6_medium,18.8,0.87,10.0,0.81,1.68
27,7_slow,34.1,0.73,9.8,0.83,1.56
27,8_slower,59.6,0.48,9.0,0.93,1.41
27,9_veryslow,109.7,0.00,8.4,1.00,1.00

3
我知道超级用户的格式设置选项中等,但是如果将数据发布为文本,则可能会有所帮助-可能使用代码格式设置。
斯科特,

1
迷人。在我的机器上也更快。谢谢!
joeytwiddle

1
我必须承认我怀疑地查看了您的结果,但是我重复了测试并获得了类似的结果,在2分钟的1080p电影剪辑上使用ffmpeg版本3.3.2-1。实际上,fastfast会在60%的时间内生成最小的文件大小,而40%的时间会排在第二到非常慢的位置(但不是很多)。从现在开始,我将对所有编码使用非常快的CRF值(18、19、20),因为CRF较低的值与较高的CRF值相比,fastfast只会稍慢一些。谢谢您为我节省了很多时间。原始数据和脚本在下面的注释中。
mattst

1
继续上面的评论...这是我的原始数据-CRF 18至27和我为运行编码而编写的Linux / UNIX bash脚本(以防有人希望运行类似的测试)。
mattst

1
这是一些关于该主题的出色博客文章,针对x264x265进行了测试(结果是,每个结果都有很大不同)
forresthopkinsa
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.