这FFmpeg 维基说最好的压缩率是通过预设的“非常慢”来实现的。
但是当我用我的视频尝试时,预设veryfast
在我看来提供了最佳的压缩。
以下是我的示例的输出:
预设ultrafast
ffmpeg -y -threads 1 -i "D:\Video\PresentTest\Safari_Dolby_Digital_Plus.m2ts.mp4" -c:v libx264 -preset ultrafast -c:a aac -max_muxing_queue_size 1024 "D:\Video\PresentTest\Safari_Dolby_Digital_Plus-ultrafast.mp4"
frame= 2822
fps= 65
q=-1.0
Lsize=
239118kB
time=00:01:34.18
bitrate=20797.6kbits/s
speed=2.16x
预设superfast
ffmpeg -y -threads 1 -i "D:\Video\PresentTest\Safari_Dolby_Digital_Plus.m2ts.mp4" -c:v libx264 -preset superfast -c:a aac -max_muxing_queue_size 1024 "D:\Video\PresentTest\Safari_Dolby_Digital_Plus-superfast.mp4"
frame= 2822
fps= 63
q=-1.0
Lsize= 150252kB
time=00:01:34.18
bitrate=13068.3kbits/s
speed=2.09x
预设veryfast
ffmpeg -y -threads 1 -i "D:\Video\PresentTest\Safari_Dolby_Digital_Plus.m2ts.mp4" -c:v libx264 -preset veryfast -c:a aac -max_muxing_queue_size 1024 "D:\Video\PresentTest\Safari_Dolby_Digital_Plus-veryfast.mp4"
frame= 2822
fps= 62
q=-1.0
Lsize=
115997kB
time=00:01:34.18
bitrate=10089.0kbits/s
speed=2.08x
预设fast
ffmpeg -y -threads 1 -i "D:\Video\PresentTest\Safari_Dolby_Digital_Plus.m2ts.mp4" -c:v libx264 -preset fast -c:a aac -max_muxing_queue_size 1024 "D:\Video\PresentTest\Safari_Dolby_Digital_Plus-fast.mp4"
frame= 2822
fps= 52
q=-1.0
Lsize=
133773kB
time=00:01:34.18
bitrate=11635.1kbits/s
speed=1.72x
预设medium
ffmpeg -y -threads 1 -i "D:\Video\PresentTest\Safari_Dolby_Digital_Plus.m2ts.mp4" -c:v libx264 -preset medium -c:a aac -max_muxing_queue_size 1024 "D:\Video\PresentTest\Safari_Dolby_Digital_Plus-medium.mp4"
frame= 2822
fps= 43
q=-1.0
Lsize=
124154kB
time=00:01:34.18
bitrate=10798.4kbits/s
speed=1.42x
预设slow
ffmpeg -y -threads 1 -i "D:\Video\PresentTest\Safari_Dolby_Digital_Plus.m2ts.mp4" -c:v libx264 -preset slow -c:a aac -max_muxing_queue_size 1024 "D:\Video\PresentTest\Safari_Dolby_Digital_Plus-slow.mp4"
frame= 2822
fps= 27
q=-1.0
Lsize= 125262kB
time=00:01:34.18
bitrate=10894.8kbits/s
speed=0.886x
预设slower
ffmpeg -y -threads 1 -i "D:\Video\PresentTest\Safari_Dolby_Digital_Plus.m2ts.mp4" -c:v libx264 -preset slower -c:a aac -max_muxing_queue_size 1024 "D:\Video\PresentTest\Safari_Dolby_Digital_Plus-slower.mp4"
frame= 2822
fps= 14
q=-1.0
Lsize= 125061kB
time=00:01:34.18
bitrate=10877.3kbits/s
speed=0.465x
预设veryslow
ffmpeg -y -threads 1 -i "D:\Video\PresentTest\Safari_Dolby_Digital_Plus.m2ts.mp4" -c:v libx264 -preset veryslow -c:a aac -max_muxing_queue_size 1024 "D:\Video\PresentTest\Safari_Dolby_Digital_Plus-veryslow.mp4"
frame= 2822
fps=6.6
q=-1.0
Lsize= 118149kB
time=00:01:34.18
bitrate=10276.2kbits/s
speed=0.221x
为什么veryfast
与其他预设相比,预设会生成压缩程度最高的文件?
视频丢失是否与预设有关veryfast
?
答案1
有损压缩是比特率(文件大小)和质量之间的权衡,而不仅仅是获得最小的文件。 如果这就是您想要的,请使用-preset veryslow -crf 51
(并可选择缩小到 256x144)来获取一个非常小的文件,其中大部分只是没有细节的模糊斑点。
编码是 CPU 时间、质量和比特率的三方权衡,与无损压缩非常不同,在无损压缩zip
中,文件大小是衡量“最佳”压缩的方法,也是在两方权衡中与时间的权衡。1或3 方,如果压缩和解压缩速度是独立的...
-preset veryslow
为您提供 x264 可以提供的最佳权衡2,通过花费更多 CPU 时间来搜索以每比特表示更多细节的方法。(即最佳权衡每次失真率)。
这与速率控制基本正交,速率控制决定要花费多少总比特数。x264 的默认速率控制是 CRF 23 ( ffmpeg -crf 23
);如果您想要更小的文件,请使用-preset veryslow -crf 26
或 等来在相同复杂度下花费更少的比特数,从而导致更模糊。它是对数的,因此将 CRF 增加几个数字可以将比特率改变 2 倍。对于几乎透明的质量,-crf 18
或20
通常很好,但需要更多的比特率。
CRF 模式不是真正的恒定质量(SSIM、PSNR 或任何其他指标)。通过更快的编码预设,x264 使用更简单的决策过程来决定如何/在何处花费比特,从而导致相同 CRF 设置的比特率出现一些变化。
使用不同的搜索工具来查找冗余,正如@szatmary 解释的那样,更高的预设可能会找到一种更小的方式来编码看起来更差的东西。或者一种编码一些看起来更差的块的方法更好的但仅稍微大一点。 根据这些事情的平均走向,相同的 CRF 在不同的质量预设下将具有不同的质量和不同的比特率。
这就是为什么你无法以相同的质量获得越来越小的文件;-preset veryfast
通常在相同的 CRF 下看起来更糟。 -preset ultrafast
即使在高比特率/低 CRF 下通常也会明显很糟糕,但其他预设看起来可以和veryslow
你花费更多的比特率一样好。
文件越小并不意味着“压缩效果越好”。请记住,质量也是可变的。如果您曾经ffmpeg -i in.mp4 -ssim 1 -tune ssim -preset veryslow out.mkv
使用 libx264 来计算 SSIM 视觉质量指标,您会发现 veryslow 的比特率质量比 veryfast 更好。(如果您要对质量进行基准测试,请以固定比特率进行,即 2-pass 而不是 CRF。请参阅https://trac.ffmpeg.org/wiki/Encode/H.264)
请记住,使图像在人类眼中看起来更好的心理视觉优化(如-psy-rd=1.0:0.15
)可能会在某些质量指标上得分较低,因此在实际使用中不想要-tune ssim
。心理优化意味着在优化速率与失真权衡时考虑人类感知。AQ(自适应量化)是另一种心理优化,但同步同步信号足够复杂,可以被识别为有益的,不像简单的峰值信噪比质量指标。
如果高(空间)频率噪声规模较小,即使它与源图像中的细节不同,人类也倾向于将其视为细节。我们的眼睛喜欢细节而不是模糊。例如,如果量化 = 四舍五入 DCT 系数产生的边缘和振铃伪影很小,实际上看起来比仅仅模糊所有内容更好。当您暂停和放大时看起来更糟的东西可以在您正常观看时欺骗您的眼睛。(h.264 有一个循环内的去块滤波器,在显示帧并用作参考之前应用,因此它比早期的编解码器(如 DivX / h.263)更容易避免阻塞。将其调高只会在低比特率下模糊所有内容)。
这里的想法类似于 MP3 和其他高级音频编解码器对声音的作用,只是有更多的心理声学优化空间,因为大声音确实会阻止耳朵听到附近频率的安静声音。
如果你要编码一次以长时间保留结果,和/或通过互联网提供结果,请使用-preset veryslow
。或者至少 -preset medium
。您只需支付一次 CPU 成本,即可多次享受文件大小(给定质量)的节省。
但如果你只打算看一次编码,例如将视频放在移动设备上,看一次后就删除,那么-preset faster -crf 20
如果你有存储空间,这样做就很有意义。只需花费额外的空间即可。
脚注 1:在无损压缩中,您需要权衡文件大小与压缩和/或解压缩的速度(这可能有所不同;有些编解码器即使允许良好的慢速压缩,解压缩速度也非常快)。实际上,如果您想深入了解该级别的细节,RAM 使用率/缓存占用量也可能是一个变量。在无损压缩中,质量固定在“完美”,例如 x264-qp 0
H.264 解码性能会因参考帧数的不同而有所差异,参考帧数越多,内存占用越大,因此 CPU 解码器的缓存未命中率可能越高。但 H.264 通常由硬件解码。与许多无损压缩方案一样,解码性能的巨大变化只有在完全不同的编解码器(如 H.265)中才会发生,而同一编解码器的不同选项则不会发生。额外编码人们花费大量时间寻找对相同位进行编码的不同方法,但解码的方法只有一种方法。
是的,H.264 具有无损模式,作为Hi444PP 简介。不,您不想在互联网上使用它;除 FFmpeg 之外的许多解码器都不支持该特殊功能,并且比特率非常大,例如 1080p30 YUV 4:2:0 或 RGB 4:4:4 的比特率为 100 到 200 Mbit/s。 如何使用 FFMPEG 从一系列 1000 个 PNG 图像创建未压缩的 AVI有一些来自 Sintel 预告片的测试结果。
脚注2:其他编解码器(如 h.265(使用 x265 编码器)或 VP9)可以提供更好的速率失真权衡,但代价是很多编码需要更多的 CPU 时间。对于固定的编码时间,我不确定 x265 是否比 x264 有优势。但与 h.264 相比,h.265 的解码器兼容性要差得多。
H.264 解码兼容性非常好主要简介,希望现在也能采用高配置。(8x8 DCT 最适用于高分辨率,如 1080p,尤其是 4k。)x264 的默认配置是高配置。一些过时的移动设备可能只有 h.264 基线配置文件的硬件解码,但每个比特率的质量明显更差(没有 B 帧,也没有 CABAC,只有效率较低的 CAVLC 用于将结构无损编码为比特流的最后一步。)
答案2
预设不控制编码速度。它们启用或禁用压缩功能(通常称为“工具”)。使用较慢的预设时,会启用更多工具。但由于每个视频都不同,因此不可能每次都为每个视频实现完美的平衡。
对于您的特定内容,其中一个工具会占用更多的 CPU 和更多的比特,但它将生成更高质量的视频,同时仍适合比特率范围。
答案3
压缩是以下两者之间的权衡:
- 品质(最大化)
- 比特率(最小化)
- 编码时间(最小化)
编码时间对于实时流媒体来说最重要,而比特率和质量对于长期存储来说更为重要。
较慢的编码时间(即预设)往往会提供更好的质量与比特率权衡曲線。
4K 超高清视频中各种 H.265 预设的质量与比特率 |
---|
对于给定的目标质量水平,较慢的预设更能降低速率。 此图是使用以下方法构建的:此代码通过结合“军事空军vs CRF” 和 “比特率 vs CRF” 图来自此来源。 |
该图显示:
veryslow
,,提供出色的压缩效果slower
。slow
medium
(默认)是压缩和编码时间之间的良好折衷。fast
,,,faster
通常veryfast
是superfast
相似的。ultrafast
在低比特率时总是最差的。