FFmpegX264编码参数Word格式文档下载.docx
《FFmpegX264编码参数Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《FFmpegX264编码参数Word格式文档下载.docx（31页珍藏版）》请在冰豆网上搜索。
为提高ssim做了优化的参数；
fastdecode：
可以快速解码的参数；
zerolatency：
零延迟，用在需要非常低的延迟的情况下，比如电视电话会议的编码。
3.一些编码建议
编码延时
降低x264的延时是可能的，但是会降低质量。
若需零延时，设置--tunezerolatency。
若你可以接受一点儿小延时（如小于1秒），最好还是允许延时。
下列步骤可以降低延迟，当延迟足够小时，就别再进行后续步骤了：
1.从初始值开始
2.关闭sync-lookahead（设置用于线程预测的帧缓存大小。
最大值是250.在第二遍及更多遍编码或基于分片线程时自动关闭）
3.降低rc-lookahead，但别小于10（设定mb-tree位元率控制和vbv-lookahead使用的帧数）
4.降低threads（比如从12降到6）
5.使用切片线程（slicedthreads）
6.禁用rc-lookahead
7.禁用b-frames
8.实在不行，就用--tunezerolatency
param->
rc.i_lookahead=0;
i_sync_lookahead=0;
param->
i_bframe=0;
b_sliced_threads=1;
b_vfr_input=0;
rc.b_mb_tree=0;
（使用宏块树位元率控制会改善整体压缩率）
x264线程
x264起多少个线程比较好？
建议线程数：
1、2、4、8
测试结论：
1、更多的线程会消耗更多总CPU时间片，因此在长期满载的机器上不宜使用多线程。
2、获得的时间收益随线程增多呈递减趋势，8线程以后尤为明显。
3、PNSR下降随线程数增加呈抛物递增趋势，16线程增加到24线程PSNR时下降了0.6之巨。
4、设置threads=auto时，线程数为逻辑CPU个数的1.5倍。
x264各类型帧的大小及编码耗时
注：
作参考，未必属实。
I帧、B帧、P帧都极大地受编码参数的影响。
通常情况下：
h264编码的帧由大到小依次为：
I>
P>
B
（互相之间约有5倍的差距）
x264的编码耗时由长到短依次为：
P>
B>
I
通常而言，较小的帧因为帧内压缩计算量（deblock、cabac等）小，所以耗时相对短。
P帧的编码耗时长是因为帧间压缩（宏块寻找、运动补偿等）耗时长所以提高了总体耗时。
另外：
可以修改x264中的x264_slices_write函数来测量不同类型帧的编码耗时。
4.ffmpeg编码参数和x264参数对照
下面表中涉及的参数直接在AVCodecContext结构中设置：
FFmpegoption
x264option
Code
Console
gop_size
-g<
frames>
–keyint
i_keyint_max
bit_rate
-b<
bitspersecond>
–bitrate
rc.i_bitrate
rc_buffer_size
-bufsize<
bits>
–vbv-bufsize
rc.i_vbv_buffer_size
rc_max_rate
-maxrate<
–vbv-maxrate
rc.i_vbv_max_bitrate
max_b_frames
-bf<
int>
–bframes
i_bframe
keyint_min
-keyint_min<
–min-keyint
i_keyint_min
scenechange_threshold
-sc_threshold<
–scenecut
i_scenecut_threshold
qmin
-qmin<
–qpmin
rc.i_qp_min
qmax
-qmax<
–qpmax
rc.i_qp_max
max_qdiff
-qdiff<
–qpstep
rc.i_qp_step
qcompress
-qcomp<
float>
–qcomp
rc.f_qcompress
qblur
-qblur<
–qblur
rc.f_qblur
Refs
-refs<
–ref
i_frame_reference
me_method
-me_method<
epzs,hex,umh,full>
–me
analyse.i_me_method
merange
-me_range<
–merange
analyse.i_me_range
me_subpel_quality
-subq<
–subme
analyse.i_subpel_refine
trellis
-trellis<
0,1,2>
–trellis
analyse.i_trellis
noise_reduction
-nr<
–nr
analyse.i_noise_reduction
level
-level<
–level
i_level_idc
bit_rate_tolerance
-bt<
–ratetol=-bt/-b
rc.f_rate_tolerance
rc_initial_buffer_occupancy
-rc_init_occupancy<
–vbv-init=-rc_init_occupancy/-bufsize
rc.f_vbv_buffer_init
b_quant_factor
-b_qfactor<
–pbratio
rc.f_pb_factor
chromaoffset
-chromaoffset<
–chroma-qp-offset
analyse.i_chroma_qp_offset
thread_count
-threads<
–threads
i_threads
me_cmp
-cmp<
-chroma/+chroma>
chroma-me
analyse.b_chroma_me
thread_type
sliced_threads
b_sliced_threads
AVCodecContext结构中priv_data可设置的参数见下表：
priv_data（即X264Contextoption）
preset
tune
profile
fastfirstpass
stats
wpredp
x264opts
crf
crf_max
cqp
aq_mode
aq_strength
psy
psy_rd
rc_lookahead
weightb
weightp
ssim
intra_refresh
b_bias
b_pyramid
mixed_refs
dct8x8
fast_pskip
aud
mbtree
deblock
cplxblur
partitions
direct_pred
slice_max_size
nal_hrd
x264_params
其余x264参数设置，见下面格式，多个参数用冒号（:
）隔开：
av_opt_set（AVCodecContext->
priv_data,"
x264opts"
"
sync-lookahead=0:
sliced-threads"
0）;
5.x264参数说明
下面说明不是最新版本，最新版本请参考x264--fullhelp
预设
为了减少使用者花费时间和精力在命令列上而设计的一套系统。
这些设定切换了什么选项可以从x264--fullhelp的说明里得知。
预设值：
无
限制输出资料流的profile。
如果指定了profile，它会覆写所有其他的设定。
所以如果指定了profile，将会保证得到一个相容的资料流。
如果设了此选项，将会无法使用无失真（lossless）编码（--qp0或--crf0）。
如果播放装置仅支援某个profile，则应该设此选项。
大多数解码器都支援Highprofile，所以没有设定的必要。
可用的值：
baseline,main,high
medium
变更选项，以权衡压缩效率和编码速度。
如果指定了预设，变更的选项将会在套用所有其他的参数之前套用。
通常应该将此设为所能忍受的最慢一个选项。
ultrafast,superfast,veryfast,faster,fast,medium,slow,slower,veryslow,placebo
ultrafast
--no-8x8dct--aq-mode0--b-adapt0
--bframes0--no-cabac--no-deblock
--no-mbtree--media--no-mixed-refs
--partitionsnone--rc-lookahead0--ref1
--scenecut0--subme0--trellis0
--no-weightb--weightp0
Superfast
--no-mbtree--media--no-mixed-refs
--partitionsi8x8,i4x4--rc-lookahead0--ref1
--subme1--trellis0--weightp1
analyse.inter=X264_ANALYSE_I8x8|X264_ANALYSE_I4x4;
analyse.i_me_method=X264_ME_DIA;
analyse.i_subpel_refine=1;
i_frame_reference=1;
analyse.b_mixed_references=0;
analyse.i_trellis=0;
analyse.i_weighted_pred=X264_WEIGHTP_SIMPLE;
调整选项，以进一步最佳化为视讯的内容。
如果指定了tune，变更的选项将会在--preset之后，但所有其他的参数之前套用。
如果视讯的内容符合其中一个可用的调整值，则可以使用此选项，否则不要使用。
film,animation,grain,stillimage,psnr,ssim,fastdecode,zerolatency
slow-firstpass
使用--pass1会在解析命令列的最后套用以下设定：
--ref1
--no-8x8dct
--partitionsi4x4（如果最初有启用，否则为无）
--media
--submeMIN（2,subme）
--trellis0
可以使用--slow-firstpass来停用此功能。
注意，使用--presetplacebo也会启用slow-firstpass。
参阅：
--pass
帧类型选项
keyint
250
设定x264输出的资料流之最大IDR帧（亦称为关键帧）间隔。
可以指定infinite让x264永远不要插入非场景变更的IDR帧。
IDR帧是资料流的“分隔符号”，所有帧都无法从IDR帧的另一边参照资料。
因此，IDR帧也是I帧，所以它们不从任何其他帧参照资料。
这意味着它们可以用作视讯的搜寻点（seekpoints）。
注意，I帧通常明显大于P/B帧（在低动态场景通常为10倍大或更多），所以当它们与极低的VBV设定合并使用时会打乱位元率控制。
在这些情况下，研究--intra-refresh。
预设值对于大多数视讯没啥问题。
在为蓝光、广播、即时资料流或某些其他特殊情况编码时，可能需要更小的GOP长度（通常等于帧率）。
--min-keyint,--scenecut,--intra-refresh
min-keyint
自动（MIN（--keyint/10,--fps））
设定IDR帧之间的最小长度。
IDR帧的说明可以参阅--keyint。
过小的keyint范围会导致“不正确的”IDR帧位置（例如闪屏场景）。
此选项限制在每个IDR帧之后，要有多少帧才可以再有另一个IDR帧的最小长度。
min-keyint的最大允许值是--keyint/2+1。
建议：
预设值，或者等于帧率
--keyint,--scenecut
no-scenecut
完全停用弹性I帧决策（adaptiveI-framedecision）。
--scenecut
scenecut
40
设定I/IDR帧位置的阈值（场景变更侦测）。
x264为每一帧计算一个度量值，来估计与前一帧的不同程度。
如果该值低于scenecut，则算侦测到一个“场景变更”。
如果此时与最近一个IDR帧的距离低于--min-keyint，则放置一个I帧，否则放置一个IDR帧。
越大的scenecut值会增加侦测到场景变更的数目。
场景变更是如何比较的详细资讯可以参阅http:
//forum.doom9.org/showthread.php?
t=121116。
将scenecut设为0相当于设定--no-scenecut。
预设值
--keyint,--min-keyint,--no-scenecut
intra-refresh
停用IDR帧，作为替代x264会为每隔--keyint的帧的每个巨集区块（macroblock）使用内部编码（intracoding）。
区块是以一个水平卷动的行刷新，称为刷新波（refreshwave）。
这有利于低延迟的资料流，使它有可能比标准的IDR帧达到更加固定的帧大小。
它也增强了视讯资料流对封包遗失的恢复能力。
此选项会降低压缩效率，因此必要时才使用。
有趣的事：
第一帧仍然是IDR帧。
内部区块（Intra-blocks）仅处于P帧里，刷新波在一或多个B帧后的第一个P帧更广泛。
压缩效率的损失主要来自于在刷新波上左侧（新）的巨集区块无法参照右侧（旧）的资料。
bframes
3
设定x264可以使用的最大并行B帧数。
没有B帧时，一个典型的x264资料流有着像这样的帧类型：
IPPPPP...PI。
当设了--bframes2时，最多两个连续的P帧可以被B帧取代，就像：
IBPBBPBPPPB...PI。
B帧类似于P帧，除了B帧还能从它之后的帧做动态预测（motionprediction）。
就压缩比来说效率会大幅提高。
它们的平均品质是由--pbratio所控制。
x264还区分两种不同种类的B帧。
"
B"
是代表一个被其他帧作为参照帧的B帧（参阅--b-pyramid），而"
b"
则代表一个不被其他帧作为参照帧的B帧。
如果看到一段混合的"
和"
，原因通常与上述有关。
当差别并不重要时，通常就以"
代表所有B帧。
x264是如何为每个候选帧选定为P帧或B帧的详细资讯可以参阅http:
//article.gmane.org/p.video.ffmpeg.devel/29064。
在此情况下，帧类型看起来会像这样（假设--bframes3）：
IBBBPBBBPBPI。
--b-bias,--b-pyramid,--ref,--pbratio,--partitions,--weightb
b-adapt
1
设定弹性B帧位置决策演算法。
此设定控制x264如何决定要放置P帧或B帧。
0：
停用，总是挑选B帧。
这与旧的no-b-adapt设定相同作用。
1：
“快速”演算法，较快，越大的--bframes值会稍微提高速度。
当使用此模式时，基本上建议搭配--bframes16使用。
2：
“最佳”演算法，较慢，越大的--bframes值会大幅降低速度。
注意：
对于多重阶段（multi-pass）编码，仅在第一阶段（firstpass）才需要此选项，因为帧类型在此时已经决定完了。
b-bias
0
控制使用B帧而不使用P帧的可能性。
大于0的值增加偏向B帧的加权，而小于0的值则相反。
范围是从-100到100。
100并不保证全是B帧（要全是B帧该使用--b-adapt0），而-100也不保证全是P帧。
仅在你认为能比x264做出更好的位元率控制决策时才使用此选项。
--bframes,--ipratio
b-pyramid
normal
允许B帧作为其他帧的参照帧。
没有此设定时，帧只能参照I/P帧。
虽然I/P帧因其较高的品质作为参照帧更有价值，但B帧也是很有用的。
作为参照帧的B帧会得到一个介于P帧和普通B帧之间的量化值。
b-pyramid需要至少两个以上的--bframes才会运作。
如果是在为蓝光编码，须使用none或strict。
none：
不允许B帧作为参照帧。
strict：
每minigop允许一个B帧作为参照帧，这是蓝光标准强制执行的限制。
normal：
每minigop允许多个B帧作为参照帧。
--bframes,--refs,--no-mixed-refs
open-gop
none
open-gop是一个提高效率的编码技术。
有三种模式：
停用open-gop。
启用open-gop。
bluray：
一个效率较低的open-gop版本，因为normal模式无法用于蓝光编码。
某些解码器不完全支援open-gop资料流，这就是为什么此选项并未预设为启用。
如果想启用open-gop，应该先测试所有可能用来拨放的解码器。
open-gop的说明可以参阅http:
p=1300124#post1300124。
no-cabac
停用弹性内容的二进位算数编码（CABAC：
ContextAdaptiveBinaryArithmeticCoder）资料流压缩，切换回效率较低的弹性内容的可变长度编码（CAVLC：
ContextAdaptiveVariableLengthCoder）系统。
大幅降低压缩效率（通常10~20%）和解码的硬体需求。
ref
控制解码图片缓冲（DPB：
DecodedPictureBuffer）的大小。
范围是从0到16。
总之，此值是每个P帧可以使用先前多少帧作为参照帧的数目（B帧可以使用的数目要少一或两个，取决于它们是否作为参照帧）。
可以被参照的最小ref数是1。
还要注意的是，H.264规格限制了每个level的DPB大小。
如果遵守Level4.1规格，720p和1080p视讯的最大ref数分别是9和4。
--b-pyramid,--no-mixed-refs,--level
no-deblock
完全停用循环筛选（loopfilter）。
不建议。
--deblock
0:
控制循环筛选（亦称为持续循环去区块（inloopdeblocker）），这是H.264标准的一部分。
就性价比来说非常有效率。
可以在http:
t=109747找到loop滤镜的参数是如何运作的说明（参阅第一个帖子和akupenguin的回复）。
升级会员 