H264的基本概念

迷南。 2022-08-27 10:45 1320阅读 0赞

# [详解H.264的型和级][H.264] #

转自  [http://blog.csdn.net/nonmarking/article/details/21242689][H.264]

H.264有四种画质级别,分别是BP、EP、MP、HP：

1、BP-Baseline Profile：基本画质。支持I/P 帧，只支持无交错（Progressive）和CAVLC；  
　　2、EP-Extended profile：进阶画质。支持I/P/B/SP/SI 帧，只支持无交错（Progressive）和CAVLC；  
　　3、MP-Main profile：主流画质。提供I/P/B 帧，支持无交错（Progressive）和交错（Interlaced），  
　　　 也支持CAVLC 和CABAC 的支持；  
　　4、HP-High profile：高级画质。在main Profile 的基础上增加了8x8内部预测、自定义量化、 无损视频编码和更多的YUV 格式；

想要说明H.264 HP与H.264 MP的区别就要讲到H.264的技术发展了。JVT于2003年完成H.264基本部分标准制定工作，包含Baseline profile、Extended profile和Main profile，分别包括不同的编码工具。之后JVT又完成了H.264 FRExt（即：Fidelity Range Extensions）扩展部分（Amendment）的制定工作，包括High profile（HP）、High 10 profile（Hi10P）、High 4:2:2 profile（Hi422P）、High 4:4:4 profile（Hi444P）4个profile。

H.264 Baseline profile、Extended profile和Main profile都是针对8位样本数据、4:2:0格式的视频序列，FRExt将其扩展到8～12位样本数据，视频格式可以为4:2:0、4:2:2、4:4:4，设立了High profile（HP）、High 10 profile（Hi10P）、High 4:2:2 profile（Hi422P）、High 4:4:4 profile（Hi444P） 4个profile，这4个profile都以Main profile为基础。

在相同配置情况下，High profile（HP）可以比Main profile（MP）节省10%的码流量，比MPEG-2 MP节省60%的码流量，具有更好的编码性能。根据应用领域的不同，Baseline profile多应用于实时通信领域，Main profile多应用于流媒体领域，High profile则多应用于广电和存储领域。

H.264 Baseline Profile对应MPEG-4 SP   
H.264 Main Profile对应MPEG-4 ASP   
H.264 Extended Profile对应MPEG-4 ARTS or FGS   
H.264 Baseline Profile对应MPEG-4 Studio。

# #

以下是反映H.264 Profile、Level、Encoder之间关系的三张简图

h.264 profile

![20100309_d233c0489c46697c323bt7nwz7f4Vv7D.jpg][]  
  
 级别（Level）是用来约束 分辨率、帧率 和 码率 的。详细信息请看表格——

![20100309_b50b9fe60841fbf4572daJBgHsqARRa8.jpg][]

Max macroblocks：最大宏块数。注：宏块尺寸是16x16的。

per second：每秒（的最大宏块数）。可用于约束帧率。

per frame：每帧（的最大宏块数）。可用于约束分辨率。

Max video bit rate (kbit/s)：最大视频码率。不同档次（Profile）下会有区别。

BP：Baseline Profile，基线档次。

XP：Extended Profile，进阶档次。

MP：Main Profile，主要档次。

HiP：High Profile，高级档次。

Hi10P：High 10 Profile，高级10位档次。

Hi422P：High 4:2:2 Profile，高级4:2:2档次。

Hi444PP：High 4:4:4 Predictive Profile，高级4:4:4（实验性？）档次。

Examples for high resolution @ frame rate (max stored frames)：范例：高分辨率@帧率(最大存储帧数)。

h.264 software encoder

![20100309_eaf6c4bfcb9eec9331f7mrmHRMOZ9ZEJ.jpg][]

对于H.264（MPEG-4 AVC）而言，级别（Level）是与档次（Profile）同等重要的参数。但很多文章说的很简略，只是说标清视频一般用3.1，高清用4，具体含义语焉不详。

在视频压制时，码率的挑选是很容易判断的。而分辨率与帧率 和 级别 的关系，就没那么明显了。所以我们需要找到计算方法。

首先看看常见视频分辨率所配套的级别——

480P（800x480）：若帧率低于13.5用2.2，若帧率在13.5至27之间就用3，帧率高于27时用3.1。

720P（1280x720）：一般为3.1。

1080P（1920x1080）：一般为4。

可以看到480P（800x480）有点特殊，所以我以它为例来讲解如何推算分辨率与帧率。

因宏块尺寸是16x16的，我们根据此信息计算出 水平宏块数（PicWidthInMbs） 和 垂直宏块数（FrameHeightInMbs）——

水平宏块数 = ceil(视频宽度 / 16) = ceil(800 / 16) = ceil(50.0) = 50

垂直宏块数 = ceil(视频高度 / 16) = ceil(480 / 16) = ceil(30.0) = 30

注：ceil(x)是向顶舍入函数，返回的是大于等于x的最小整数。

然后计算每帧宏块数（macroblocks per frame）——

每帧宏块数 = 水平宏块数 \* 垂直宏块数 = 50 \* 30 = 1500

查上面的级别详表，可知支持 每帧宏块数1500 的最低级别是2.2。

级别2.2所允许的 每秒最大宏块数（Max macroblocks per second） 是 20250。20250 / 1500 = 13.5。即最高支持每秒13.5帧。

提高一个级别，级别3所允许的 每秒最大宏块数 是 40500。40500 / 1500 = 27。即最高支持每秒27帧。

再提高一个级别，级别3.1所允许的 每秒最大宏块数 是 108000。108000 / 1500 = 72。即最高支持每秒72帧，够用了。

当宏块数超过级别的约束时，x264会显示这样的警告信息——

x264 \[warning\]: frame MB size (120x68) > level limit (5120)

在前面的级别详表中，还有一个神秘的字段——最大存储帧数（max stored frames）。它是从何而来的呢？

最大存储帧数与DPB有关——DPB：decoded picture buffer，解码图片缓存区。在做视频解码时，需要将最近的若干幅参考帧缓存起来，这个缓冲区就叫做DPB。所以最大存储帧数也是最大参考帧数（ref）。DPB一般以宏块数为单位（DpbMbs），计算公式为——

DpbMbs = ref（参考帧数） \* PicWidthInMbs（水平宏块数） \* FrameHeightInMbs（垂直宏块数）

在不同的级别（Level）下，最大的解码图片缓存区宏块数（MaxDpbMbs）是不同的——

<table style="color:rgb(51,51,51); font-size:14px; line-height:26px; border:1px solid silver; border-collapse:collapse; font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; width:155px">     
 <tbody> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> Level</td> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> MaxDpbMbs</td> 
  </tr> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 1</td> 
   <td align="right" style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 396</td> 
  </tr> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 1b</td> 
   <td align="right" style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 396</td> 
  </tr> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 1.1</td> 
   <td align="right" style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 900</td> 
  </tr> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 1.2</td> 
   <td align="right" style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 2,376</td> 
  </tr> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 1.3</td> 
   <td align="right" style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 2,376</td> 
  </tr> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 2</td> 
   <td align="right" style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 2,376</td> 
  </tr> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 2.1</td> 
   <td align="right" style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 4,752</td> 
  </tr> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 2.2</td> 
   <td align="right" style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 8,100</td> 
  </tr> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 3</td> 
   <td align="right" style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 8,100</td> 
  </tr> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 3.1</td> 
   <td align="right" style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 18,000</td> 
  </tr> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 3.2</td> 
   <td align="right" style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 20,480</td> 
  </tr> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 4</td> 
   <td align="right" style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 32,768</td> 
  </tr> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 4.1</td> 
   <td align="right" style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 32,768</td> 
  </tr> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 4.2</td> 
   <td align="right" style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 34,816</td> 
  </tr> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 5</td> 
   <td align="right" style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 110,400</td> 
  </tr> 
  <tr> 
   <td style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 5.1</td> 
   <td align="right" style="font-family:Verdana,Geneva,Arial,Helvetica,sans-serif; border:1px solid silver; border-collapse:collapse; padding:3px"> 184,320</td> 
  </tr> 
 </tbody> 
</table>

我们可根据 MaxDpbMbs约束 倒推出 最大的参考帧数——

max\_ref = min(floor(MaxDpbMbs / (PicWidthInMbs \* FrameHeightInMbs)), 16)

注1：floor(x)是向底舍入函数，返回的是小于等于x的最大整数。

注2：因参考帧数（ref）最大只能为16。

转载地址：http://www.cnblogs.com/zyl910/archive/2011/12/08/h264\_level.html

http://xcshen.blog.51cto.com/2835389/552669

=========================================================================================================

# [MP跟B帧有关系的。AVC/H.264定义了4种不同的Profile(类):Baseline ,Main, Extended][MP_B_AVC_H.264_4_Profile_Baseline _Main_ Extended] #

转自 [http://www.hzlitai.com.cn/article/ARM11/CPhelp/1772.html][MP_B_AVC_H.264_4_Profile_Baseline _Main_ Extended]

H.264标准三个框架   
  
H.264的编解码框架与以前提出的标准如H.261、H.263及MPEG-1/2/4并无显著变化，也是基于混合编码的方案：以运动矢量代表图象序列各帧的运动内容，使用前面已解码帧对其进行运动估计和补偿或使用帧内预测技术，所得的图象参差值要经过变换、量化、熵编码等部分的处理。所以，新标准的性能提升在于各个部分的技术方案的改进及新算法的应用。新标准在提高图象传输的容错性方面做了大量工作，重新定义了适于图像的结构划分。在编码时，图象帧各部分被划分到多个slice结构中去，每个slice都可以被独立解码不受其它部分的影响。Slice由图象最基本的结构——宏块组成，每个宏块包含一个16×16的亮度块和两个8×8的色度块。为进一步提高鲁棒性，整个 系统被划分为 视频编码层和网络抽象层。视频编码层主要描述要传输的视频数据所承载的  
视频内容。而网络抽象层则是考虑不同的应用，如视频会议通信、H.32X连续包的视频传输或RTP/UDP/IP的通信。   
  
H.264标准分成三个框架(profile)：Baseline、Main及X，代表了针对不同应用的算法集及技术限定。其中，Baseline主要包含了低复杂度、低延时的技术特征；主要是针对交互式的应用；考虑到了恶劣环境下的容错性，Baseline的内容基本都被其它更高级别的profile所包含。而Main profile是针对更高编码效率的应用，如视频广播。X profile 的设计主要针对流媒体的应用，在这一框架中所有容错技术和对比特流的灵活访问及切换技术都将包括其中。  
Baseline profile的主要技术特征   
  
⑴ Baseline的解码器只对I slice及P slice进行操作。对于帧间预测，相比以前的标  
准，为了更精确的对图象的运动内容进行预测补偿，新标准允许宏块更进一步划分为16×16、16×8、8×16、8×8、8×4、4×8、4×4的子块；运动估计精确到经由6-tap滤波器得到的1/4象素位置；运动矢量由相邻块预测得到，其预测的差值被编码传输。H.264支持多参考帧的预测，规定运动估计使用的参考帧数最多可达15帧，多参考帧的使用大大提高了对图像传输的容错性，抑制了错误在空间和 时间上的蔓延。对于所有的slice编码类型，H.264支持两类帧内编码：4x4与16x16编码模式。对于4x4模式，每一个亮度4x4块有8种不同方向上的预测模式及DC预测模式。对于16x16模式，每个16x16亮度块有4种帧内预测模式。而对于宏块的8x8色度采样，采用与亮度16x16几乎相同的预测模式。为了保证slice的编码独立性，帧内预测是不允许跨越slice边界的。对于变换、量化部分。不同于以前标准对预测参差值的变换编码使用DCT变换，H.264使用了简单的整数变换。这种变换与DCT相比压缩性能几乎相同且有许多优势，其核心变换的计算只使用加减、移位运算，避免了精度的损失。对变换参差系数的量化使用了52级步长的量化器，而H.263标准只有31级。量化步长以12.5％递增，量化步长范围的扩大似的编码器能够更灵活和精确的进行控制，在比特率和图象质量之间达到折中。对熵编码部分。对于要传输的量化变换系数，若使用基于上下文的变长编码（CAVLC），它是根据前面已编码传输的量化变换系数值的大小来选择接下来系数编码要使用的变长编码表。由于变长编码表的设计是基于相应的统计条件，所以其性能要优于使用单一变长编码表。而对其它数据如头信息等，使用一种单一的变长编码表(Exp-Golomb code)。新标准仍然使用基于块的预测及重构方式，为了去除由此产生的影响图象主观质量的方块效应，H.264使用了去块效应滤波器。其主要思想是当块边界上两边差较小则使用滤波器使差别“平滑”掉,若边界上图象特征明显就不使用滤波。这样既为减弱“块效应”的影响又避免滤掉图象的客观特征。同时在相同主观质量下使得比特率减少5－10％。   
  
另外，对图象数据的组织及传输。在H.264标准中的图象宏块可以灵活的宏块组织顺序(FMO)划分为多个slice group；slice之间是相互独立的可以任意的顺序传输到解码端(ASO)。而且在比特流中slice可以使用重复的方式(RS)传输，这在slice数据出错的情况下可用来进行恢复，增强了图象传输的鲁棒性。同时slice间的相互独立性抑制了错误的空间传播，因此提高了比特流的容错性。 ⑵ Main profile的技术特征 Main profile包含Baseline profile的所有算法并具有额外的技术特征，但它并不支持FMO、ASO及RS等技术。只支持对I、P、B slice的处理操作。在此框架内提出了适配块划分尺寸的变换(ABT)的概念。此概念是针对帧间编码的，其主要思想是将对预测参差进行变换编码的块尺寸与用来进行运动补偿的块尺寸联系起来。这样就尽可能的利用最大的 信号长度进行变换编码。但是由于复杂度的原因，进行变换的最大块尺寸被限制在8×8以下。对熵编码部分，为更高效的进行编码，这里使用了基于上下文的算术编码（CABAC）使熵编码的性能进一步提高。相比较CAVLC，在相同图象质量下编码电视信号使用CABAC将会使比特率减少10-15％。另，Main profile不支持多个slice group的划分。  
  
⑶ 相关的编码 问题如何对已提出的预测模式进行选择(mode decision)和使用运动估计策略(ME)历来都视频编码实现的重点研究课题。在H.263标准的实现 软件中对模式的选择是简单的基于对阀值的比较。在新标准的测试软件中使用了拉格朗日率失真优化策略，它是基于使用每种图象块尺寸和每种预测模式而产生的参差及其传输的码率。这样，模式选择可以取得优化的率失真性能但这是以提高运算复杂度为代价的。此优化操作是对下面拉各朗日函数的最小化： J ＝ SATD + λ?R 其中，R为对应传输的各部分的比特率；λ为优化参数，其与量化参数有很强的相关性。SATD为经过哈德曼变换的4×4块的预测参差绝对值总和。对于所有帧内、帧间宏块编码模式及多参考帧的选择都通过对拉各朗日函数的最小化来实现。通常，视频标准只是包括解码规范，而模式选择的技术研究是属于编码端的范畴，所以不列在标准之内。

AVC/H.264 Profile   
  
AVC/H.264定义了4种不同的Profile(类)：Baseline(基线类), Main(主要类), Extended(扩展类)和High Profile(高端类)（它们各自下分成许多个层）：   
  
\- Baseline Profile 提供I/P帧，仅支持progressive(逐行扫描)和CAVLC   
\- Extended Profile 提供I/P/B/SP/SI帧，仅支持progressive(逐行扫描)和CAVLC   
\- Main Profile 提供I/P/B帧，支持progressive(逐行扫描)和interlaced(隔行扫描)，提供CAVLC或CABAC   
\- High Profile （也就是FRExt）在Main Profile基础上新增：8x8 intra prediction(8x8 帧内预测), custom quant(自定义量化), lossless video coding(无损视频编码), 更多的yuv格式（4:4:4...）   
  
下面这个网址介绍得很详细， [http://www.tfcc.cn/dvdrip/2006-6-15\_14-13-02\_2528.html][http_www.tfcc.cn_dvdrip_2006-6-15_14-13-02_2528.html]

================================================================================================

# MPEG-4 AVC/H.264 信息 #

转自 [http://www.tfcc.cn/dvdrip/2006-6-15\_14-13-02\_2528.html][http_www.tfcc.cn_dvdrip_2006-6-15_14-13-02_2528.html]

本FAQ系列由（haibara）翻译，期间受到kaito\_mkid（pcicp）帮助，在此感谢，由于Newbie的关系，如有翻译错误，还请各位指出， [由Doom9的bond编撰的原文][Doom9_bond]。

译者注：基本专业名称我都以小括号形式加以解释，详细信息请自行查阅资料。

什么是MPEG-4？

MPEG-4（ISO 14496）是由制定了我们熟知的MPEG-1（MP3, VCD）和MPEG-2（DVD, SVCD）标准，并力于使各种音频/视频压缩格式和更多内容标准化的国际标准化组织(International Organization for Standardization/ISO)的工作组，即运动图像专家组(Moving Picture Experts Group/MPEG)发展的广泛的开放标准。

本质上MPEG-4标准不仅把目标定为标准化某些有发展前途的产品（例如达到DVD性能），而且含盖了一个能让产品供应商根据需要选择适当标准去执行的广泛的次级标准。

MPEG-4标准，如上所说，被分成许多不同的次级标准，在Doom9里我们使用者可能最感兴趣的部分如下：

\-  [ISO 14496-1（Systems/系统）][ISO 14496-1_Systems] ，动画/交互性（类DVD菜单）

\-  [ISO 14496-2（Video/视频）][ISO 14496-2_Video] ，如Advanced Simple Profile(ASP/高级简单类)，由XviD, DivX5, 3ivx...执行

\-  [ISO 14496-3（Audio/音频）][ISO 14496-3_Audio] ，Advanced Audio Coding(AAC/先进音频编码)

\-  [ISO 14496-10（Video/视频）][ISO 14496-10_Video] ，Advanced Video Coding(AVC/进阶视频编码)，著名有H.264

\-  [ISO 14496-14（Container/容器）][ISO 14496-1_Systems] ，MP4容器格式（使用.mp4作扩展名）

\-  [ISO 14496-17（Subtitles/字幕）][ISO 14496-1_Systems] ，MPEG-4时标文本字幕格式

这些信息页面正力于提供这些标准的大部分有用的信息，尤其是作为焦点的MPEG-4 ASP和AVC/H.264。

与封闭格式如Micro$oft的Windows Media相比，象MPEG-4一样的开放标准有什么可能的优势？

开放标准的一个好处是当创建产品时允许 *向所有人开放* 并遵循它。因此我们已经有许多不同的符合MPEG-4标准并可互相兼容的产品。

其次是 *互通性* 和 *大范围的产品* 选择性，一个开放标准导致 *竞争* ，对顾客而言这意味着产品在竞争市场中能更好地提高 *品质* ，更少的 *价格* 和更关注顾客 *需求* 。

但不要忘记这也许对我们来说最重要的一点：

一个开放标准允许 *开源发展* ，例如我们熟知的XviD。

**ISO 14496-10 (Video) - 进阶视频编码(Advanced Video Coding/AVC)**

有着AVC/H.264的MPEG-4标准定义了一个拥有最新，最高技术的实用的，充满尖端科技的视频编码格式。

2003年，ISO的MPEG(Moving Pictures Experts Group/运动图像专家组)与联合国(United Nations/UNO)下设的ITU(International Telecommunication Union/国际电信联盟)的VCEG(Video Coding Experts Group/视频编码专家组)这2大组织最终完成并共同规定了AVC/H.264视频编码标准，其中后者曾标准化H.263格式（现主用于视频会议）。

AVC/H.264标准它自身是由MPEG和VCEG的专家构成的Joint Video Team(JVT/联合视频组)发展的。

由MPEG来看，该标准被叫做MPEG-4 Part 10（ISO 14496-10）；由ITU来看，它叫做H.264（ITU的公文号） 其中作为后者已广泛流传开来。

新标准选择Advanced Video Coding(AVC/进阶视频编码)作为“官方”名 - 因为对应视频的音频格式是Advanced Audio Coding(AAC/先进音频编码)。

AVC/H.264 Profile

AVC/H.264定义了4种不同的Profile(类)：Baseline(基线类), Main(主要类), Extended(扩展类)和High Profile(高端类)（它们各自下分成许多个 [层][Link 1] ）：

\-  *Baseline Profile*  提供I/P帧，仅支持progressive(逐行扫描)和CAVLC

\-  *Extended Profile*  提供I/P/B/SP/SI帧，仅支持progressive(逐行扫描)和CAVLC

\-  *Main Profile*  提供I/P/B帧，支持progressive(逐行扫描)和interlaced(隔行扫描)，提供CAVLC或CABAC

\-  *High Profile*  （也就是FRExt）在Main Profile基础上新增：8x8 intra prediction(8x8 帧内预测), custom quant(自定义量化), lossless video coding(无损视频编码), 更多的yuv格式（4:4:4...）

只有未来会告诉我们哪一种框架和工具最可能被用于DVD备份，但是我猜想会是有着以下的工具大力帮助的Main和/或High Profile（同样请核实 [MPEG-4 ASP][ISO 14496-2_Video] 的工具描述，除了GMC，所有的工具在AVC下都是可用的）：

CAVLC/CABAC：

AVC/H.264定义了2种先进的重构数据流（包括macroblock-type(宏块), motionvectors(运动矢量) + reference-index(参考索引)...）的熵编码工具，一举超越MPEG-4 ASP：

Context-Adaptive Variable Length Coding(CAVLC/上下文自适应变长编码)和 Context-Adaptive Binary Arithmetic Coding(CABAC/上下文自适应二进制算术编码)

CABAC，与AVC/H.264中只是默认算法的CAVLC（也叫UVLC）相比，是个压缩率更强大的算法，据说能额外降低10-15%的比特率（特别在高码率）。CABAC（同CAVLC一样）是一种无损算法，因此不会降低质量，但会减缓编码和解码速度。

Loop/Deblocking Filter(循环/去块滤波器)：

与预处理滤波器（例如通过avisynth作用于输入端），或后处理滤波器（通过解码器作用于最终输出端）相反，循环滤波器在编码过程中对每桢进行滤波，编码完成后被用于下一桢的参考。它能消除块效应，尤其在低码率时，但同样会减缓编码和解码速度。

Variable Block Sizes/Macroblock Partitions(块大小可变/宏块划分)：

与MPEG-4 ASP（仅Inter4V/4MV能作16x16和8x8块变换）相比，AVC/H.264把动态搜寻精度(Motion Search Precision)提高到4x4（包含的步骤有8x4...）。子块大小是自适应/可变的，一个优秀的编码器应能对每个宏块明智地作出最恰当的划分大小决定。

Multiple Reference Frames(多重参考桢)：

与MPEG-4 ASP（仅允许当前桢的前一桢作为参考桢）相比，AVC/H.264使用帧间搜索方式并提供成倍的参考桢选择，它意味着AVC/H.264编码能决定是否只是简单地参考前一桢或甚至参考比前桢更过去的桢。因此（例如某个P桢能参考最近I桢前的某桢）不得不提出一种新型桢型：IDR桢，是种其后的桢不允许参考其前的桢的I桢。使用多重参考桢会减慢编码和解码速度并且可能导致只能在IDR桢剪切。

Weighted Prediction(加权预测)：

有了加权预测就能对参考桢进行加权（例如你能测量前一幅图象的亮度程度）。它特别有助于在那些随时可能淡入或淡出的场景中前后图象极为相似，只是画面变暗的图象的处理。WP对于同时出现淡入及淡出的图象没有效果（例如当图象从一个场景转到另一个场景就会同时出现淡入及淡出）。

Rate Distortion Optimisation(RDO/码率-失真/损耗最佳化)：

只要编码器不得不在众多选择中作出绝择时，RDO允许选择最有效的编码方式（例如面临采用桢间/桢内的动态搜寻的决定...）

RDO不是AVC/H.264本身定义的工具，它是第一个由H.264参考软件引入的工具，可谓一种新的途径。其他的编码也能利用RDO，如XviD'的VHQ模式能使用RDO

AVC/H.264与其他流行的视频编码格式的比较测评：

![2006-6-15_14-08-55.png][]

现有的AVC/H.264编码

可用于终端用户的AVC/H.264执行者有 [x264][] ,  [Nero][] ,  [Apple][] ,  [Sorenson][] ,  [Elecard][] ,  [Moonlight][] ,  [VSS][] ,  [mpegable][] ,  [Envivio][] ,  [Hdot264][] ( [binary][] ),  [DSPR][] ,  [JM][]  (参考软件) ( [binary][] ),  [ffmpeg][] ,  [Philips][] ,  [FastVDO][] ,  [Skal][] ,  [Sony][] 和 [更多][Link 2]

编码器

\-  x264 ：第一个公开的可使用High Profile的编码器，开源（GPL）（ [源码][Link 3] ），使用VFW的有： [x264vfw][] ,  [ffdshow][] （输出.avi），命令行的： [x264cli][x264vfw] （输出raw的.mp4）,  [mencoder][] （输出raw的.avi）（Doom9的 [MeGUI][] ）或 [ffmpeg][]

x264支持2pass, CABAC, 循环滤波, 多重B帧, 双向参考(B-Reference), 多重参考桢, 4x4 P帧块变换, 8x8 B帧块划分, 失真信号化(anamorphic signalling)和High Profile：8x8 dtc(离散余弦变换)与帧内预测, 无损视频编码和自定义无损量化矩阵(custom quant matrix)

\-  NeroDigital AVC ： [Nero Recode2][] 内含，输出为.mp4

ND AVC支持2pass, CABAC, 自适应循环滤波, 多重B帧, 多重参考桢, 加权预测, 8x8 B帧块划分, 16x16 B帧块划分, 自适应量化（高度Psy）

\-  Sorenson ： [Sorenson Squeeze 4][] 内含，输出.mp4,

Sorenson支持2pass, 最大2连续B帧, 双向参考, 循环滤波和多重Slice

\-  Apple ： [Quicktime 7][Apple] 内含，输出.mp4, .3gp和.mov，编码速度很慢

支持2pass, 最大1连续B帧, 循环滤波(0,0), 8x8 P帧块变换, 8x8 B帧块变换, 4x4 I帧块变换, 自适应量化, 5级Slice, 没有CABAC, 没有加权预测, 没有多重参考桢

\-  JM ：此AVC参考软件v9.3版提供Main和High Profile：B/SP帧, CABAC, 循环滤波器, 4x4 块划分, 多重参考桢, 自适应量化, 差错修复(Error Resilience), RDO, 无损视频编码, 自定义量化), 比率控制(Rate Control)等...

\-  Hdot264 ：由doom9会员charact3r发展的开源（GPL）的VFW版参考软件，仍然以很老的参考软件（JM 4.0c）为基础

\-  VSS ：免费的VFW编码器（可预览5天），以参考编码器为基础

\-  Elecard ：  [Elecard Mobile Converter][] 内含，输出.mp4，  [MainConcept's v2 encoder][MainConcept_s v2 encoder] 也内含，输出.264和.mpg PS/TS

不再公开的：

\-  Moonlight ：Moonlight的 [OneClick Compressor v1.1][] 和CyberLink的 [PowerEncoder][] 内含，输出.mpg

Moonlight支持1pass（VBR/CBR/预设 量化）, CABAC, 循环滤波, 最大2连续B帧, 8x8 B帧块划分, 自适应量化, 自动调整PAR(Pixel Aspect Ratio/象素纵横比), 隔行扫描

\-  MainConcept ：免费的编码器（有水印），输出.264和.mpg PS/TS

1pass（CBR/VBR/预设 量化）, P帧重排(P-Frame Reorder), CABAC, 循环滤波, 多重B-Vops(Bidirectional Video Object Planes/双向视频对象平面), 多重参考桢, 4x4 P帧块划分), PAR, RDO

\-  mpegable ：提供试用有限的免费VFW编码器（不以参考软件为基础），不支持YV12

mpegable支持仅限P帧的1pass（预设量化）, 8x8 P帧块划分, 只支持CAVLC, 循环滤波

\-  Envivio ： [4Coder][] 内含，输出.mp4

解码器  ( [比较测评][Link 4] )

\-  ffmpeg ：开源（LGPL），包含在 [ffdshow][] （VFW和DShow编码器),  [mplayer][] 和 [VideoLAN][] 等

支持B帧, 双向参考, CABAC, 循环滤波, 加权预测和High Profile (8x8 dct与帧内预测, 无损视频编码)

\-  Apple ：Quicktime 7支持AVC解码，支持.mp4/.mov，解码速度很慢

仅支持最大1连续B帧, CABAC, 不作后帧参考的循环滤波, 多重B帧和隔行扫描

\-  NeroDigital AVC ：Recode2附带DShow解码器和.mp4 Parser

支持Main和High Profile

\-  VSS ：VFW解码器 (预览5天) 和 [DShow解码器][DShow]  (限制30天)

VSS DShow支持.avi (支持VSSH和H264 fourcc), CABAC, 循环滤波, B帧

\-  Elecard ： [Elecard's MPEG Player v4.0][Elecard_s MPEG Player v4.0] 和 [MainConcept's v2 encoder][MainConcept_s v2 encoder] 内含

\-  Envivio ：有个名叫EnvivioTV的非免费AVC DShow解码器，（从2.0版开始，当前版本为2-1-181）支持混合AVC的.mp4

\-  Philips ： [AVC Alliance][Philips] 播放器内含免费的DShow AVC解码器（只支持raw AVC）

\-  FastVDO ：有时间限制（每个视频文件5分钟）的High Profile DShow解码器

\-  Pegasus ： [这里][Link 5] 有发展不成熟的DShow AVC解码器

\-  Basic AVC Decoder 用C编写，是一所大学的工程，见 [这里][Link 6]

不再公开的：

\-  Moonlight ：DShow解码器/Parser支持混合AVC的.mpg, .mp4和.264 Moonlight's MPEG Player v3.0内含

支持Main和High Profile

\-  MainConcept ：v1预览版提供免费DShow AVC解码器（有水印) 并且Parser支持AVC和.mpg PS/TS

\-  mpegable ：提供试用有限的VFW解码器 (可用于DShow)，支持.avi (支持 DAVC fourcc)

预览样本

NeroDigital： [mp4][] ,  [mp4][mp4 1]

Sorenson： [mp4][mp4 1]

AVC Alliance： [raw][]

Moonlight： [raw/中码率][raw 1] ,  [raw/低码率][raw 2] ,  [raw][mp4 1] ,  [mpg][]

FastVDO： [raw/high profile][FastVDO]

Apple： [mov][]

Videosoft:  [avi][] ,  [avi/新][mp4 1] ,  [avi/老][avi 1]

Lead： [ogm][]

当前AVC/H.264的争论

\- 互通性：大多数执行者支持多种容器格式：

.mp4：由MPEG-4标准（ISO 14496-15）定义的AVC容器，Apple, Nero, Sorenson, Envivio, Elecard/Moonlight和x264都支持

.mpg PS/TS：由MPEG-2标准（ISO 13818-1, AMD3）定义的AVC容器，Mainconcept和Elecard/Moonlight支持

.avi：采取AVC-in-AVI的方式非标准，因此会造成不兼容问题。 [AVI和VFW的局限][AVI_VFW] （如关于B帧或任意帧的编码顺序），混合这两种格式混合会完全阻碍AVC提供的所有可能特性的执行，因此可能降低质量，或至少降低处理速度和互通性，其竞争性也因此下降。当前VSS和x264（mencoder 和vfw）支持使用AVI

.264/.h264：未混合入容器的原始数据流。JM参考软件, x264cli, mencoder和mainconcept都可输出

\- 速度：当前一些执行者编码器速度不敢恭维，依然只有x264和NeroDigital's AVC的编码器看上去能提供不俗的速度与品质。但这不会改变AVC是种先进的视频编码方式的事实。所以老的CPU编解码AVC会非常耗时

MPEG-4 AVC/H.264的硬件应用化 - HD-DVD/蓝光(Blu-ray)

DVD论坛(DVD Forum)和蓝光光盘协会(Blu-ray Disc Association)正在讨论能支持高清晰(High Definition)内容（存储容量完全超过当前的DVD）下一代DVD格式的继承人选：HD-DVD和BD-ROM

据 [这里][Link 7] 报道HD-DVD会强制采用MPEG-4 AVC/H.264，而蓝光支持老早被MPEG-4 AVC/H.264 High Profile纳入- [这里][Link 8]

因此AVC/H.264极有可能成为下一代视频格式，会被广泛地使用和支持，就象今天MPEG-2（用于DVD)的情形一样

更多的文档

阅读更多关于MPEG-4 AVC/H.264的文档：详细说明- [这里][Link 9] ，摘要信息- [这里][Link 10] 或 [这里][Link 11] ，

[执行者清单][Link 12]

AVC的测试结论参看 [这里][Link 13]

下载完整的AVC/H.264标准详述 [这里][Link 14] （Draft from the 7-14 March 2003)

蓝光的技术信息参看 [这里][Link 15]

===========================================================================================

# [H.26L中的Access unit结构分析][H.26L_Access unit] #

转自 [http://blueben-chong.blog.sohu.com/128200567.html][http_blueben-chong.blog.sohu.com_128200567.html]

一帧图像就是一个Access unit，一个图像序列由几个Access unit组成。其中第一个Access unit就是IDR帧，其他的Access unit是非IDR帧（B帧或者P 帧）。I帧的Access unit包括的SEI nalu可以被一个序列的其他p帧或者B帧access unit共享。一组非参数集NALU被称为一个接入单元（Access Unit），delimiter定界后加上定时信息（SEI），后面紧跟基本编码图像（PCP，primary coded picture）。PCP后面是冗余编码图像（CRP，corresponding redundant picture），用于解码中PCP丢失情况下恢复信息。冗余分片允许编码器把在同一个码流中添加同一MB的一个或更多冗余表示。需要注意的是这些冗余片的编码参数与非冗余片的编码参数不同，例如主片可用低QP（高质量）来编码，而冗余信息中能用一个高QP（低质量）的方式来编码，这样质量粗糙一些但码率更低。解码器在重构时，首先使用主片，如果它可用就抛弃冗余片；而如主片丢失（比如因为包的丢失）冗余片也能被用于重构。冗余片主要用于支持高误码的移动环境。 冗余编码图像的计数器redundant\_pic\_cnt是递增的。序列结束nalu标志着一个Access unit的结束。Nalu type=0,12,19~31不能出现在PCP前面。

一个primary coded picture结束以后，如果紧接着出现了下列Nalu之一则标志着新的一个Access unit开始了：

1．  access unit delimiter，这是access unit的第一个nalu，一个access unit只能有一个access unit delimiter定界nalu  
2．  序列参数集  
3．  图像参数集  
4．  定时信息SEI，SEI出现于primary之前。如果SEI包含缓冲期的消息，则应该出现在第一个SEI nalu包的第一个消息。  
5．  类型为13~18的Nalu  
6．  另一个primary coded picture的第一个VCL nalu，如何判断PCP中的第一个VCL nalu请看下文。

一个PCP 包括一个或者几个slice，第一个VCL nalu有如下特征：  
1．  Slice header中的frame\_num不一样  
2．  使用的pic\_parameter\_set\_id不一样  
3．  field\_pic\_flag不一样  
4．  bottom\_field\_flag不一样  
5．  nal\_ref\_idc不一样，其中一个nal\_ref\_idc=0  
6．  pic\_order\_cnt\_type=0：pic\_order\_cnt\_lsb不一样，或者delta\_pic\_order\_cnt\_bottom不一样  
7．  pic\_order\_cnt\_type：delta\_pic\_order\_cnt\[ 0 \]不一样，或者delta\_pic\_order\_cnt\[ 1 \]不一样  
8．  nal\_unit\_type不一样，其中一个nal\_unit\_type=5  
9．  nal\_unit\_type=5：idr\_pic\_i不一样

一幅图像由若干片组成，每片包含一系列的宏块（MB）。MB的排列可按光栅扫描顺序，也可不按扫描顺序。每个片独立解码，不同片的宏块不能用于自身片中作预测参考。因此，片的设置不会造成误码扩散。灵活的宏块排序FMO是H.264的一大特色，适用于H.264的基本档次和扩展档次的应用。图像内部预测机制，例如帧内预测或运动矢量预测，仅允许用同一片组里的空间相邻的宏块。FMO通过宏块分配映射技术，把每个宏块分配到不按扫描顺序的片中。FMO模式划分图像的模式各种各样，重要的有棋盘模式、矩形模式等。当然FMO模式也可以使一帧中的宏块顺序分割，使得分割后的片的大小小于无线网络的MTU尺寸，经过FMO模式分割后的图像数据分开进行传输。使用FMO的代价是稍微降低了编码效率（因为它打破了原先非邻居MB之间的预测），而且在高度优化的环境中，有较高的时延。

通常情况下，一个宏块的数据是存放在一起而组成片的，数据划分使得一个片中的宏块数据重新组合，把宏块语义相关的数据组成一个划分，由划分来组装片。H.264视频编码标准使用了三种不同类型的数据分割：  
1．  A型分割 ：A型分割是头信息划分，包括宏块类型、量化参数和运动矢量，这个信息是最重要的。  
2．  B型分割 ：B型分割是帧内信息划分，包括帧内CBPs和帧内系数。帧内信息可以阻止错误的传播，该型数据分割要求给定分片的A型分割有效，相对于帧间信息，帧内信息能更好地阻止漂移效应，因此它比帧间分割更为重要。  
3．  C型分割：C型分割是帧间信息划分，包括帧间CBPs和帧间系数，一般情况下它是编码分片的最大分区。帧间分割是最不重要的，它的使用要求A型分割有效。

当使用数据分割时，源编码器把不同类型的分割安排在3个不同的缓冲器中，同时分片的尺寸必须进行调整以保证小于MTU长度，因此是编码器而不是NAL来实现数据分割。在解码器上，所有分割用于信息重建。这样，如果帧内或帧间信息丢失了，有效的帧头信息仍然能用来提高错误隐藏效率，即有效的宏块类型和运动矢量，保留了宏块的基本特征，从而仍可获得一个相当高的信息重构质量，而仅仅丢失了细节信息。

如果profile/level中规定允许乱序slice(FMO)，则I帧可以随意顺序(棋盘模式、矩形模式等等)传输，而B、P帧中的coded slice以及A分割slice data可以随意顺序传输。相同slice\_id的A分割slice data优先于B分割，而B分割又优先于C分割。

如果profile/level中规定不允许乱序slice(FMO)，则I帧的VCL nalu顺序应该按照MB地址递增（光栅扫描）的顺序进行传输。B、P帧的coded以及A分割slice data按照MB地址递增（光栅扫描）顺序传输。同样的，相同slice\_id的A分割slice data优先于B分割，而B分割又优先于C分割。

==========================================================================================

# [AVC/H264编码教程][AVC_H264] #

转自[ http://blog.csdn.net/scarlettsp/article/details/4010651][AVC_H264]

AVC/H264编码教程

原作：DeathTheSheep  
翻译：Tenlix

编码次数（应当选择何种编码模式）

如果你想要得到一个确定的文件体积，我推荐采用二次编码的模式。例如，你希望你生成的文件体积为精确的170.00MB，那么你就需要采用二次或三次编码。严格地说，一次编码针对的是那些严重缺乏时间或者并不期望得到高质量输出的人。二次编码能够满足大部分人的需要，它可以生成高质量的文件和确切的文件体积。然而，单次编码模式有时候会被用于恒定质量的输出。如果你想要编码得到的是一个统一的、恒定质量的视频而并不在意文件的体积，那么可以参见下面的“恒定量化和恒定质量模式”部分。

恒定量化和恒定编码模式

如果你并不需要你的视频得到一个固定的、明确的体积，或者想让编码器来决定分配多大的文件体积来获得最佳的质量，那么可以考虑一下通过“单次编码 - 量化（Single Pass - Quantizer）”或“恒定质量（Constant Quality）”模式来进行固定质量的编码。这两种模式的不同之处在于“恒定质量”模式采用了更为先进的比率控制算法，能够在复杂度较高而人眼不太注重细节的场景下降低比特率。这就意味着即使质量针对人眼的视觉效果进行了动态分配，它看起来也仍然是恒定的。很多人可能会因为恒定质量模式的这种设计而认为该模式要更胜一筹，但是如果你编码的是比特率很低的动画视频，量化也许是个更好的选择。

*  确定你在编码选择菜单(A.)中选择了“单次编码 - 量化”或者“恒定质量”模式。
 *  记住更高的量化值或“质量”模式(B.)将会使视频的实际质量更低，而文件体积会更小。“质量”和量化值相近，但是被乘以了10。
 *  除非你是为了存档(收藏)或再现(原来的)品质，否则请不要使用15(或150)以下的量化值。
 *  同样地，也不要使该值大于40(或400)：即使最终的文件体积会小到难以置信，这种编码的质量也会使人难以接受，除非你编码的视频具有极其锐利的画质和反差极大的边缘表现。
 *  对大多数热衷于高质量视频的人来说，比较好的估计值是在20(或200)（最高质量）到30(或300)（相对较低的质量）的范围内，根据个人的偏好和硬盘为编码文件所预备的空间来进行具体选择。
 *  对于卡通动画之类几乎没有什么复杂纹理的视频可以考虑使用比较高一些的量化值。
 *  对于现实的题材，特别是那种具有很多晦暗的场景和重要而精细的纹路的视频，应当考虑将量化值降低一个较大的幅度。
 *  继续在其他的选项卡中设定余下的参数。
 *  在恒定质量模式中，“量化压缩（Quantizer compression）”用以控制在复杂的和高运动量的场景中的质量波动，可以参考下面的标题“高速度，高质量”中的描述。
 *  在其他的选项卡中进行其余的设定。
 *  在编码类型菜单(A.)中选择“多次编码 - 第一次编码（Multipass – First Pass）”或者“多次编码 - 第一次编码（快速）（Multipass – First Pass (Fast)）”。由于人们热衷于使用三次编码来获得最理想的质量，所以可以考虑使用“快速”的第一次编码模式。对于二次编码，我建议使用标准的第一次编码模式。虽然在第一次编码中，使用快速模式来替代标准模式在大部分的标准中并不会造成任何大的损失，但我还是推荐在二次编码中使用标准模式，以保证对大多数视频及编码的情况取得最佳的质量。
 *  以“千比特/秒（kbps）”为单位的“目标比特率（Target Bitrate）”(B.)是分配给视频的数据码率。这个码率越高，可视信息被压缩的就越少，从而可以获得更好的质量、更清晰的图像、更少的人为编码因素以及更多的细节保留。可以考虑使用比特率计算器来计算决定视频所采用的比特率以达到所需的体积大小（你可以通过在Doom9的论坛狩猎来找到这些，但请不要在那里误杀任何“sheep“）。我建议对高质量的视频使用500到900的比特率，但正如我所说的那样，这完全取决于你希望得到的文件大小。对一部电影来说，根据视频的长度和复杂性的不同，合理的文件体积限制是500、700或1400MB（大量的细节和高度的运动是导致高复杂度的主要原因）。
 *  比特率变量（Bitrate Variance）：对指定的比特率所允许的波动范围（用百分比表示）。给编解码器一个围绕目标比特率的波动余地，以备在某些情况下应付额外数据的需要。基本上需要比较接近你所选择的比特率而保持一个较低的数值，从1%到4%。
 *  “量化压缩（Quantizer compression）”控制在复杂的和运动量较大的场景中的质量波动。参见下面的标题“高速度，高质量”中的描述。
 *  继续在其他的选项卡中设定余下的参数。
 *  在进行了满意的设定和第一次编码之后，重新输入和你刚才相同的编解码器参数设定并在编码类型菜单中选择“多次编码 - 第N次编码（Multipass – Nth Pass）”，保持其他所有的选项和它们在第一次编码中相同的设定。如果你希望进行三次编码，再重复一次这个步骤。

编码：高速度，高质量

这一部分介绍达到编码质量和编码速度的最佳组合的必要步骤。以下是在将编码速度提升到最高的情况下，制作最高质量的AVC编码的推荐设置。

*  “关键帧增益（%）（Keyframe boost (%)）”(A.)控制关键帧（I帧、节点帧、转场帧(I-frames, intra frames, the “scene-changer” frames)）超出其他P帧而被增益的质量多少。增益会给这些关键帧一些外加的质量，因此从这些帧中预算出的帧也会具有较高的质量，即获得更好的视觉效果。另外，关键帧经常会给一些静止的场景提供背景基础，在这些场景中，很多静止的元素会在画面上持续停留一段时间（特别是在一些慢节奏的动画中），这样，提升这些关键帧就显得非常重要。保持这个数值在50到0之间（数值是0的话会获得一个更一致的质量，所有的帧都被同样地对待处理）以便达到一个可以被普遍接受的一致结果。对全局来说，40是一个推荐值；然而，在个别情况下，进行少许的增减可能会得到更好的效果（在低比特率/低质量的动画编码中增加该值，在现实题材的视频或明亮的、背景经常变化或移动的连续快速运动的视频中减少该值）。然而，在大多数的普遍情况下，只要你的片源不是太过特别——例如使用了大量的渐变场景转换或者过于发灰或者发亮，抑或是发暗（在这种情况下你可能会想要调整它）——最好是不用过多地担心这个选项。
 *  “B帧缩减（%）（B-frames reduction (%)）”（B.或者在比特率选项卡）控制B帧相对于其他的P帧所减少的量化值（质量）。对人类的视觉系统来说，这种在B帧的比特率上的减少很难被注意到，因为B帧是不显著地用于其他的P帧之间来更有效地重构视频的运动。将这个值设定地低一些可以从本质上增加压缩率，但是你就可能会遭致视频的运动出现过多的人工计算因素和不协调地细节再现效果的惩罚。对高比特率和低量化值的现实题材的视频，你可能想要将该值下降到略微低于30的推荐值，也许是25或者20，以此来保证一个更一致的细节质量、运动效果和视频整体。对于动画的内容（卡通、动画等），你可以将这个值设定到50，对某些动画的题材甚至可以到60，这是由动画在运动的效果和细节变换的精确性上先天的局限性所决定的。
 *  量化压缩（%）（Quantizer compression(%)）”(C.)，也被理解为“比特率变动（Bitrate Variability）”，控制x264在你所指定的比特率所确定的量化值（质量）的范围内的波动幅度。这个选项设定得越低，量化（质量）的变化就会更趋于飘忽和不稳定。例如说，将该值设定为0会允许x264在每一帧中剧烈地改变它的质量：缺点是一些“简单”的帧（低细节、低运动量）会在你所选择的比特率下显示出惊人的效果，而其他“复杂”的帧（高细节、高运动量）显示效果就会相当糟糕，因为x264可能会剧烈地降低它的质量来维持所需的比特率，以获得一个比较稳定的、恒定的比特率。然而，这个设定越高，质量就会趋于相等，从而获得一个具有更加稳定的质量的视频。例如，将该值设定为100会强迫x264对所有的帧使用相同的质量（无波动），因此从理论上讲，它可能给某一帧分配10kbps而另一帧是1000来保持两者之间相同的质量（纯VBR）；所以从全局上看，所有的帧都会被一致地量化，按照质量波动的限制来处理同样的质量，即使比特率可能会剧烈地波动。
 *  从这个角度来考虑：这个选项的功能正如其名称所说。你将这个“比特率变动”设定得越小，从一个场景到下一个场景之间的比特率的变动就越少，但是其质量会显得更为恒定。
 *  这个选项的设定和个人的偏好有关，如果你不是特别明确地想要进行一个CBR的编码（对数据流之类，在这种情况下你可以设定为0）或者是等质量下的VBR编码（在这种情况下你可以设定为100），我强烈建议你保持默认值60不变以获得最佳的质量。
 *  当然，比特率变动的控制只是在一个比特率可以被控制的模式中可用，例如多次编码或者“单次编码 – 比特率”模式（这里我们将不讨论这个模式），对于恒定量化的模式是不可用的，因为它在质量上已经恒定了。
 *  D.,E.和F.的焦点集中在所谓的量化限制上，同样是只能用在比特率可控的模式中。对于大多数的编码来说，你无需接触到其中的任何一个。“最小QP（Min QP）”(D.)设定你的视频在任意一点所能达到的最小量化值（最高质量）。如果你不是打算要在一个低分辨率的视频上实现超高比特率的编码，我的建议值是从10到15。类似地，设定你的视频所能达到的最高量化值（最低质量）。这个设定甚至会更加困难，所以我推荐保持原来的数值而不必更改（默认值51），让x264去决定每个场景的量化。51的最大值看起来虽然有些过度，但是帧的相对复杂度在可控比特率的量化过程中已经被纳入了考虑范围，而x264知道在这种条件下采取最好的处理方式。“最大QP间距（Max QP Step）”控制x264在两个量化（质量）等级之间的变换速率。将这个值设定地过低会强迫编解码器缓慢地变换质量等级，对那些可能突然地需要一个较低的量化值以维持相似的视觉效果的特定场景可能会造成一个毁灭性地打击，而将这个值设定得过高可能会导致质量上的显著跳变。
 *  “场景切换阈值（Scene Cut Threshold）”(G.)在x264决定一次场景转换之前，确定一帧所需要变化的程度（因此也会引入一个关键帧）。40是默认的推荐值，但是在每个视频或每次编码时稍作改变会对精确检测场景变换大有裨益。对于昏暗、夜晚、洞穴、水下等等视频，你可以减少这个值以使x264更精确地确定场景的变换。更一般的原则是，具有更精细的场景变换的视频需要一个更高的场景切换阈值（例如45到50），而对那些明亮的、高对比度且具有显著的场景变换的视频，事实上则有理由尝试设定一个较低的阈值（例如35）。同样，需要认识到更短的关键帧间距最好工作在较低等级的关键帧增益下。
 *  “最小IDR帧间距（Min IDR-frame interval）”(H.)设定在x264应用一个关键帧之前所需经过的最小帧数。通常来说，你所编码的视频的帧率即可用于该参数，以通过限制在一秒之内两帧之间的帧数插入来有效地控制x264的帧数插入能力。如果这个值设定得过高，在x264没有确定一个场景变换和实现必要的关键帧之前会浪费太多的时间，同样也会导致点击进度滑块的滞后。而设定得过低将会导致比特率的浪费以及产生闪烁现象：在过短的时间内经过了过多的帧数，对人眼来说便无法识别分布在它们之间的附加细节。正如之前所说，需要认识到更短的关键帧间距最好工作在较低等级的关键帧增益下。
 *  “最大IDR帧间距（Max IDR-frame interval）”(I.) 设定在x264应用一个关键帧之前所需经过的最大帧数。通常地，将这个值设定为你所编码的视频的帧率乘以10，即如果在10秒的时间内没有确定场景变换，将会强制插入一个关键帧。将该值设定得过低将会导致关键帧的过饱和并可能产生闪烁现象，以及全面的比特率浪费，降低全局质量。将这个值设定得过高则会导致进度条的问题，而且在两个关键帧之间的时间段内，任何人为的、编码的瑕疵都会在屏幕上存在得更久。然而，如果你不介意进度滑块的拖动问题，尤其是你将场景切换阈值设定得足够低以诱导产生有益的关键帧流入时，我相信将这个值设定到1000甚至是更高都是安全的。
 *  VBV设定（未显示）和数据率峰值以及变化的比特率有关。这些值是特定针对硬件解码应用和AVC等级的，因此，如果你不是确切地知道在每一栏内应该填些什么，就不要改变原有的默认值（0，0，90）。

下一个选项卡：体积与帧（MBs&Frames）

*  区块的搜索和确定被“区块（Partitions）”标题之下在框格J中的选项所控制。该选项通过增加精度来提升编解码器的质量和压缩效率，获得更高的质量输出。作为普遍的规则，编解码器在可视信息上进行的搜索类型越多，它就能够更精确、更有效率地预算和编码，所以我推荐勾选它们全部。然而，有一个特殊的情况需要了解，这将在下一条中提到。
 *  “8×8变换（8x8 Transform）”特性是一个非常强大的压缩技术，它作用于更大的可视信息块，并且可以开启使用一些其他高质量的区块选项，例如“8×8节点内搜寻（8x8 Intra search）”(L)，它在不使用8×8变换时是不可用的。这两个选项都能够有效地提升质量，但8×8变换的使用会使得你的视频成为“High Profile AVC”，破坏编码视频“Main Profile AVC”的兼容性。如果没有这项兼容，你的视频可能无法在某些不支持“High Profile AVC”的解码器上播放。目前，大多数主流或高端的桌面解码器都支持high profit，所以采用这个特性（的视频）在你的台式机上播放是安全的。参照下面的“兼容性”部分以获得更多关于设备兼容性的信息。
 *  x264在一行中可以使用的最大B帧数量由选项M所控制。B帧是在两个P帧（由I帧或关键帧预算出来的标准帧）之间的高压缩的帧，作为一种高效率的预算模式。它们会非常有效地提升压缩率而带来的视觉影响却极其微小，即使它们相对于其他的帧来说通常会被分配一个较高的量化值（可参考上面的B选项）。只要选项P（“Adaptive”复选框）被选中，我建议你将这个限制提高到3或更高，那样的话x264就可以在保持最佳质量的情况下自主地决定所采用的最佳B帧数量。
 *  B帧“偏差（Bias）”(N)用于改变x264对B帧的使用。这个数值越高，x264就会越频繁地插入B帧。例如将这个数值设定为100会强制x264使用由框格M所指定的最大数量的B帧；然而，这个结果可以由简单地去掉勾选“Adaptive”(P)来得到。将这个值设定为-100则意味着几乎不使用任何B帧——实际上，对大多数情况来说就是一帧都不使用。对大多数视频来说，理想的B帧使用量在选择偏差值为0的时候往往是最好的，我也推荐保持这一数值。
 *  X264编解码器可以通过“使用B帧作为参考帧（Use \[B-frames\] as references）”(O)来使用B-frame pyramid特性。对其他连续的B帧来使用B帧作为参考帧可以提高少许的质量，因为这些B帧可以从另一个B帧预算出来而不是被限制在使用它附近的P帧进行预算。B-pyramid在搭配使用最大3帧连续B帧的设定(M)时是最有效的。我推荐开启这个选项，因为它可以提高一些质量而几乎不会降低速度。
 *  “加权B帧预算（Weighted biprediction）”(Q)被选择时可以允许B帧在预算时相对P帧或另一个帧获得更大的权重。其结果是获得更加准确和有效的B帧，从而提升质量。我强烈推荐勾选该项。
 *  “双向运动帧对照（Bidirectional ME）”(R)是一个新的特性，允许x264参照所要预算的B帧之前和之后的运动帧预算出一些B帧，以提升质量。勾选使用。
 *  B帧指导模式（Direct B-frame mode）(S)可以使B帧使用“预算运动向量（predicted motion vectors）”来代替实际上的每一帧的运动编码，以有效地节省空间和提升压缩率。我建议将其设定为“Auto”，尤其是在还未明确运动的不一致的存在的二次编码的情况下。如果是在恒定量化编码的模式中，而Auto出现了问题，那么我建议对动画和现实题材视频的所有比特范围均使用Spatial，但是由于极低比特率或者极高量化值的现实题材所具有的运动重构的流动性，需要对其使用Temporal。

下一个选项卡：其他（More...）

*  “分块检测（Partition Decision）”(A)，也可以理解为“Subpixel Refinement Quality”，是一个控制x264关于运动估算的范围的重要特性。选择菜单包含了一个具有7个选项的选单，依次从最低的质量“1（Fastest）”到最高的质量“6b（RDO on B-frames）”。要记住使用质量较高的选项会导致x264在运算确定方面“思考”得更多，从而降低更多的速度。由于这是在x264的质量（和速度）上起决定因素的选项，所以请将其确定在一个合适的范围内。我建议将该值设定为不低于‘5’。‘5’是一个可以允许使用“色度动态预测（Chroma ME）”（参见下面F的说明）的速度很快的选项。然而看起来比较可怕的“6（RDO）”对编码的质量则大有裨益，因为它采用了比率失真优化（rate distortion optimization）（RDO），这是一个以花费更多编码时间为代价来大幅提升分块检测质量（以及由此带来的压缩品质的提升）的特性。但是在我看来，使用比率失真优化（即‘6’）所带来的大幅质量提升并不足以弥补其在编码阶段所大幅降低的速度，因此，除非你的CPU非常之快，我才会推荐采用6。‘7’被称作“Insane（精神错乱的）”可谓名副其实，因为（和6相比）它几乎没有提升多少质量而在速度方面的下降却是一点儿也不含糊。
 *  'RDO for B-frames'对B帧也使用了比率失真优化，尽管使得编码速度略有下降，但是给B帧带来了较大的质量提升。我推荐选择对B帧使用比率失真优化的参数。
 *  运动估算“方法（Method）”选项(B)可以让用户选择x264如何检索画面的运动。这个方法越好，x264找到并且准确地记录运动的可能性就越高，从而提升压缩质量和效率。我建议对较慢的机器和缺乏时间的人群使用“正六边形检索（Hexagonal search）”（水平、垂直和对角检索），而此外则是使用“可变半径六边形检索（Uneven Multi-Hexagon）”（通过复数的六边形二进制组进行检索）比较有优势，由于其更加精确和具有扩展性的算法，将能够带来更佳的质量，编码时间也会随之提升。我不推荐使用“全面检索（Exhaustive Search）”（强制一个像素一个像素地进行检索）；它并不会显著地优于“ Uneven Multi-Hexagon”，而且会剧烈地降低速度，（一旦选择了该选项，）如果你的编码能够在一周之内完成，算你走运。它看起来仅仅是为了调试的目的来使用（编写编解码器的程序）而并非实际编码。
 *  注意在使用“可变半径六边形检索（Uneven Multi-Hexagon）”或“全面检索（Exhaustive Search）”（请勿使用）时，用户可以在框格(C)中指定搜索“半径（Range）”。将其保持在16：这是优化算法的取值，通常会带来最佳的速度和质量。但是，如果你有一个高分辨率的视频而其帧率却很低（小于15），可以考虑将该值稍微提高一点，可以是24或32（最大值）。同理，如果你有一个低分辨率的视频而其帧率却非常之高（大于60），你可以考虑降低该值至12或8以节约时间。
 *  你可以通过“最大参考帧数（Max Ref. Frames）”选项(D)来设定x264可以使用的参考帧数。AVC可以通过参考它之前编码的相似帧来有效地编码出新的帧。这个选项用于设置可以被参考的最大帧数。这个值设定得越高，编码质量会越好，而编码速度则会降低。对于现实题材，在大多数保持较高编码速度的情况下，3到5便足够了。对于动画的题材，或者带有冗余的重复运动的题材，更多的参考帧可以带来质量的显著提高，因此在这里我建议无论何时都在勾选“混合参考帧（Mixed Refs）”(G)的前提下采用5到10的设定值，混合参考帧可以使得x264拥有更大的自由来制定参考帧的子帧级别。
 *  “快速P帧跳过（Fast Pskip）”(E)被使用以后，x264会加速其编码过程，但有时候会导致在单调的场景或精细的渐变画面中产生人为编码的痕迹。如果你很在意这些问题和现象，不勾选“快速P帧跳过”会有一定的帮助。禁止该选项（强制编解码器彻底地检测每一个区块）之后，对全局的质量会产生及其微小的提升，以及一个细微却很明显的速度下降。因此我建议如果不是十分必要的话，勾选该选项。然而，如果你使用Trellis量化，你可能会想要取消勾选该项以追求最高的质量。这样做可以使得Trellis在信息的扬弃不与其他选项冲突的情况下成为量化的决定因素。
 *  “DCT精简（DCT Decimation）”(R)是指由x264来决定什么时候可以忽略向数据流中写入特定的DCT数据块。也就是说，当x264确定不需要进行某个数据块变换的时候，程序会允许x264直接跳过对其的编码，以节约那些原本有可能被浪费在x264认为是无用的信息上的比特率。从这方面看，DCT精简和快速P帧跳过以及Trellis量化有相似之处，即由x264来判断可以忽略的信息。然而，在当前的情况下，我推荐尽可能地勾选该项，因为禁止它会导致在恒定量化下的更大的文件体积，而相对于编码的比特率来说，质量的提升几乎感觉不到。
 *  “色度动态预测（Chroma ME）”(F)的工作原理是测定在运动估算期间视频的色度，以提高运动估算的精度和视觉质量。这一般会带来品质的重要提升，尤其是对动画的题材。我建议总是勾选该项。
 *  “采样高宽比（Sample AR）”(H)处理视频外观的高宽比——如果你不了解其作用，可以无需接触它。
 *  “线程（Threads）”(I)用以设定x264分配给编码进程的线程数。你可用的线程数应当与你电脑处理器的核心数相适应。需要记住每个支持超线程（HT）的处理器按两个线程计算。如果你不知道你的CPU的核心数，或者其是否具有超线程（hyper threading），比较保险的办法是将其设定为1。设定多核心的优点仅仅是在多核心的机器上编码的处理速度会快一些。
 *  调试记录（Debug logging）(J)：记录编码过程的相关信息。将其设定为Error——它不会对一般水平的使用者提供（他们所需要的）更多的调试信息。
 *  x264生成的AVI文件的FourCC(K)是其中（指AVI容器中）的视频流的标识符。如果没有特别指定，Xvid生成的AVI文件具有“XVID”的FourCC。对AVC文件来说，H264是一个可以被广泛接受和支持的FourCC，依照AVC 1.1标准所建议，你最好保持其默认的H264。
 *  CABAC，即双向适应二进制算法编码(L)，是x264的main profile中的一项能够允许视频流的构成基础参照之前和之后来进行预算的关键特性。它主要是用以在品质无损耗的前提下提升压缩效率（依具体视频和比特率的不同在10%～15%之间波动），而解码速度会有轻微的下降（通常高比特率和低量化值会导致复杂的CABAC解码）。如果将其禁止，x264会采用较低品质的CAVLC，同时你也就会失去使用Trellis量化特性的机会。我强烈建议你勾选该选项，除非你想要获得一个尽可能快的解码速度（Xbox、掌上电脑等等）。
 *  “Trellis”(M)是一个通过选取在压缩过程中存在于编码文件中的数据来提升编码的视觉品质的高级特性。它看上去像是提高了比特率的利用率，但是由于当你选择一直开启该选项（框格呈灰色并被选中）时会造成约10%的速度下降（即CLI中trellis 1和trellis 2的区别），而相对（正常选择状态）提升的品质比较有限，我建议将该选项置于正常选取状态，而当你知道它将会造成问题时，完全取消勾选该项。
 *  “交错编码（Interlacing）”(S)是一个可以使得x264对视频源文件进行简单的固定交错编码的特性。如果你的视频源文件不是隔行的，或者你不知道这个选项的作用，最好是敬而远之。反之，如果你确切地知道你的视频源文件是隔行的，则勾选该项。注意：你必须取消勾选Trellis (M)并设定最大连续B帧（max consecutive B-frames，在“体积与帧（MBs&Frames）”选项卡下）为0。
 *  “降噪（Noise Reduction）”(O)：如果你的视频源文件有很多噪点（比如带有很多类似电影的斑点或者录像/抓取视频时的静电干扰），你可以在这里设定一个降噪值。如果你没有其他的降噪操作，这就是一个很好的预处理特性。范围从0（关闭）到100（极大程度的降噪）。我通常将其设为0，然而，这是在我事先知道我的视频源文件看起来是我想要的那样的前提下。如果我的目的是很低的比特率，由于降噪可以去除那些难以（被通过编码的方式）压缩的噪点，它就会对品质和比特率有所助益。
 *  参照下面的“去马赛克教程”来获得有关如何正确设置使用“去块插件（Deblocking Filter）”(N)的相关信息。

去马赛克教程（Deblocking Guide）

AVC格式内置了一个极其实用的特性，它可以消除马赛克和其他人为编码的瑕疵，而这些问题曾经使得AVC之前的那些格式饱受困扰。它在AVC的编码中相当实用，由于AVC是构筑在这个滤镜之上的事实以及你可能经历到的在视频中存在过多的马赛克以及人为编码的瑕疵（糟糕的片源），一般来说在正常情况下不要禁止这个去块插件。然而，因为它会占用大量的解码时间，如果解码器又不支持在播放时手动关闭它，你可能会考虑（在编码时）禁止掉它以获得尽可能快的解码速度（Xbox、掌上电脑等等）。  
应该有这样的认识：即由于人类的视觉系统（human visual system (HVS)）在空间上比较复杂的场景中往往会把瑕疵和马赛克当作该场景的固有细节，因此去块插件的使用在原则上常常会存在争议。因为x264会默认地除去这些人为编码的痕迹，人类的视觉系统便会以为这是“损失了细节”，即使从技术角度来讲，x264的细节处理其实相当精确——甚至在相近的比特率之下的表现有过之而无不及。事实上，已经有共识认为（Doom9论坛的编解码器性能对比也很好地支持这一观点）x264确实是在致力于比ASP（未去马赛克的）编解码器在相近的比特率之下更精确地保持更多的细节。然而，去块插件对人为编码瑕疵的去除仍然为人类的视觉系统所干涉并认为它移除了本该存在的画面细节，而存在这些虚假的“细节”的画面正是人们在不使用去块插件的情况下所习惯了的。对于那些认为在编码视频中的噪点可以得到一个更为柔和和舒服的画面的人们来说，去块插件对这些噪点的去除也并不讨巧。这些偏好依据各人的情况是有所不同的，所以请努力地发现什么样的设定对你的眼睛和需求来说是最合适的。  
Alpha去块阈值“strength”（P）帮助决定需要多强的去块效果来除去马赛克。Beta去块阈值“threshold”（见上图的Q）确定有多少马赛克需要去除。这个值设定得越高，x264就会将越多的视频部分理解为马赛克（如果设定得过高，会将过多的视频部分判断为马赛克），因而会进行更多的去块操作。当然，如果你对原材料“清洗”（比喻去块）得不够，在那些没有被清洗到的地方就会有污渍（比喻马赛克）残留下来——就这样按照清洗衬衫的方法来考虑它——而如果你清洗的强度不够，有些污渍便不会完全消失。然而，如果你洗得过多，力量过强，你就会毁掉这件衬衫而不是清洗污渍了——会有很难看的褪色，并且纹理和细节都被抹掉了。

*  
 *  两个滑动条的初始设置都是0，这是为什么呢？这是能够在去块和细节保留之间取得计量平衡以产生最高质量的标准值。然而，如果你对默认的0,0编码的结果不满意，可以参考下面的意见：
 *  不要超过-3到2的范围（对两个滑动条来说都是如此）。一般地说，超过2会使解码的结果过于模糊，而低于-3会使结果看起来有点过于锐利——感觉也不会好，因为所有的掩盖都被去除了，细节的缺乏只会显得更加突出。
 *  如果你在编码一个动画类的视频源文件，推荐使用比较强的去块（将两个滑动条都设置为1）以尽可能地去除所有的马赛克。这是由于动画视频内容的边缘具有很高的反差对比，需要去除的马赛克之类会具有较高的抵抗力。从另一个方面说，如果你在编码一个现实题材的视频，尤其是具有复杂的纹理和较低的亮度的那种，则应该考虑降低去块的强度以保持这些细节，以免出现过度的模糊。
 *  努力在这两个设定之间保持一种确定的关系。即如果你想要进行更强力的去块，那么就要确定你同时也提升了阈值以便于使更多的部分得到去块处理，反之亦然（如1,1;2,2;-1,-1;等）。回忆一下那个洗衣服的比方：你不会想要只是很强力地去清洗一小块地方而其他的部分都没有被清洗到（对于一件普通的待清洗衣物来说），这样的话没有清洗到的部分会显得突出而生硬，带来很糟糕的视觉效果。
 *  在高比特率下，为了尽可能保持最多的细节，我建议对两个设置尝试采取-1的设定（阈值可达-2）。然而，根据视频源文件的情况（梯度、纹理和对比度）、采用的比特率以及个人偏好，对其中之一或全部两个设置来说，0可能仍然是最理想的设置。

欢迎来到DeathTheSheep的AVC VfW编码教程，这个内容丰富而易用的教程将会在AVC编码中最大限度地帮助您。不论您是新手还是想要在编码细节方面增进理解的专家，都可以在本教程中学到相应的知识。基本上，您可以用本教程替代任何有关Xvid/Divx的设置教程。下面就让我们前进吧！

然而，我们首先需要提出一些术语。为了充分利用本教程，我们最好对这些编码相关的词汇及其用法有一个了解。

1.编解码器(Codec)：压缩器(Compressor)/解压缩器(Decompressor)。这里，x264是一个编解码器，也被称作“编码器（encoder）”。Divx是一个编解码器，Xvid也是一个编解码器。如果你下载了DTS\_x264的程序包，你会得到一个编码器（压缩视频的部分）和一个被称为“解码器（decoder）”的解压缩器（使你能够播放你制作或者“编码”的视频的那一部分）。由于你可能并不需要调整解码软件，这个教程便没有提及这方面的内容。值得注意的是，“编解码器（Codec）”同“标准（Standard）”是有区别的：H.264是x264所基于的标准，MPEG4-ASP是Xvid和Divx所基于的标准。MPEG4既不是编解码器，也不是MP3，而是一个标准。

2.比特率(码率、Bitrate)：这和你编码生成的最终文件的大小(“filesize”)有关。比特率越高，文件质量就越高，而文件体积也会越大。它通常用（数据量/时间）的单位形式来表示，例如“千比特/秒（KB/sec）”或者kbps。在视频中，有大量运动的场景通常需要较高的比特率来将画面质量维持在一个可以接受的水准；因为运动量越大，编解码器就需要将更多的数据储存在文件中。

3.量化(Quantizer)：编解码器决定质量的基础单位。注意较高的量化值会产生较低的质量和比特率。

4.Pass：对输入的源文件进行一轮完整的处理。根据你所选择的模式不同，编解码器会对文件进行特定次数的全局处理。第一次的全局处理("Pass 1" 或 "First Pass")通常是用来对源视频文件有一个总体的了解，编解码器同时会将这些结果写入到一个被称作pass file的文件中，该文件会（作为参考）用来对视频文件进行第二次或者第三次的处理，以决定如何对视频文件分配比特率和量化值，从而达到（在给定条件下）它所能达到的最好质量。需要注意的是在恒定质量或恒定量化的模式中，由于编解码器已经知道了采用怎样的质量进行编码，所以只会用one pass（一次编码）的方式，而这个质量值是由使用者设定的。同时它的比特率也是独立的，编解码器会以一种简单的方式尽可能多地调用它所需的比特率来达到给定的质量。

5.编码速度(Encoding Speed)：其定义为：“在任意特定的时间点内，编码器处理/编码整个文件所需要的时间，用帧/秒（frames/sec、fps）来表示”。意思是在编码过程中，会有一个全局的或平均的编码速度（根据从开始到完成所花费的时间）和一个在每个视频场景改变时的瞬时编码速度。在处理运动变化较为激烈的场景时，编码速度会趋向于更慢。

[H.264]: http://blog.csdn.net/nonmarking/article/details/21242689
[20100309_d233c0489c46697c323bt7nwz7f4Vv7D.jpg]: http://www.61ic.com/code/attachments/month_1003/20100309_d233c0489c46697c323bt7nwz7f4Vv7D.jpg
[20100309_b50b9fe60841fbf4572daJBgHsqARRa8.jpg]: http://www.61ic.com/code/attachments/month_1003/20100309_b50b9fe60841fbf4572daJBgHsqARRa8.jpg
[20100309_eaf6c4bfcb9eec9331f7mrmHRMOZ9ZEJ.jpg]: http://www.61ic.com/code/attachments/month_1003/20100309_eaf6c4bfcb9eec9331f7mrmHRMOZ9ZEJ.jpg
[MP_B_AVC_H.264_4_Profile_Baseline _Main_ Extended]: http://www.hzlitai.com.cn/article/ARM11/CPhelp/1772.html
[http_www.tfcc.cn_dvdrip_2006-6-15_14-13-02_2528.html]: http://www.tfcc.cn/dvdrip/2006-6-15_14-13-02_2528.html
[Doom9_bond]: http://forum.doom9.org/showthread.php?t=96059
[ISO 14496-1_Systems]: http://forum.doom9.org/showthread.php?s=&threadid=62723
[ISO 14496-2_Video]: http://forum.doom9.org/showthread.php?s=&threadid=73022#post461587
[ISO 14496-3_Audio]: http://forum.doom9.org/showthread.php?s=&threadid=68300#post424070
[ISO 14496-10_Video]: http://forum.doom9.org/showthread.php?p=674815#post674819
[Link 1]: http://forum.doom9.org/showthread.php?p=678891#post678891
[2006-6-15_14-08-55.png]: /images/20220824/8d97ee6469c8432fb261428ca0084224.png
[x264]: http://www.videolan.org/x264.html
[Nero]: http://www.nerodigital.com/
[Apple]: http://www.apple.com/quicktime/
[Sorenson]: http://www.sorenson.com/
[Elecard]: http://www.elecard.com/
[Moonlight]: http://moonlight.co.il/
[VSS]: http://www.videosoftinc.com/codecs.html
[mpegable]: http://www.mpegable.com/show/mpegableavc.html
[Envivio]: http://www.envivio.com/products/h264.html
[Hdot264]: http://sourceforge.net/projects/hdot264/
[binary]: http://www.rarewares.org/mp4.html
[DSPR]: http://www.dspr.com/www/support/download/video_download.htm
[JM]: http://iphome.hhi.de/suehring/tml/
[ffmpeg]: http://ffmpeg.sourceforge.net/
[Philips]: http://www.avc-alliance.org/downloads.htm
[FastVDO]: http://www.fastvdo.com/H.264.html
[Skal]: http://skal.planet-d.net/coding/mpeg4codec.html
[Sony]: http://www.jp.sonystyle.com/Nws/Software_dl/Pc/Software/Haa/2105710489100.html
[Link 2]: http://forum.doom9.org/showthread.php?t=95939
[Link 3]: http://trac.videolan.org/x264/browser/trunk/
[x264vfw]: http://forum.doom9.org/showthread.php?s=&threadid=89979
[ffdshow]: http://ffdshow.sourceforge.net/
[mencoder]: http://mplayerhq.hu/DOCS/man/en/mplayer.1.html
[MeGUI]: http://forum.doom9.org/showthread.php?s=&threadid=87567
[Nero Recode2]: http://www.nero.com/en/index.html
[Sorenson Squeeze 4]: http://www.sorenson.com/solutions/prod/mpg4_win.php
[Elecard Mobile Converter]: http://www.elecard.com/products/mobile_convert.shtml
[MainConcept_s v2 encoder]: http://www.mainconcept.com/h264_encoder.shtml
[OneClick Compressor v1.1]: http://www.moonlight.co.il/cons_oneclick.php
[PowerEncoder]: http://www.gocyberlink.com/english/products/powerencoder/index.jsp
[4Coder]: http://www.envivio.com/products/4coder_se.html
[Link 4]: http://forum.doom9.org/showthread.php?t=99402
[mplayer]: http://www.mplayerhq.hu/
[VideoLAN]: http://www.videolan.org/
[DShow]: http://www.vsofts.com/h264/decoders.html
[Elecard_s MPEG Player v4.0]: http://www.elecard.com/products/mpeg2player.shtml
[Link 5]: http://www.h-264.com/downloads.htm
[Link 6]: http://www-user.tu-chemnitz.de/~mfie/stuff/SA/
[mp4]: http://trailer.nerodigital.com/enu/index.html
[mp4 1]: http://www.heise.de/ct/05/10/146/testsequenzen.shtml
[raw]: http://www.avc-alliance.nl/main/downloads.htm
[raw 1]: http://www.moonlight.co.il/download/clips/trailers/
[raw 2]: http://www.moonlight.co.il/download/clips/mobiles/
[mpg]: http://www.moonlight.co.il/download/clips/avc/
[mov]: http://www.apple.com/quicktime/guide/hd/
[avi]: http://www.videosoftinc.com/videoclips.html
[avi 1]: http://www.heise.de/ct/03/10/146/testsequenzen.shtml
[ogm]: http://www.leadcodecs.com/Download/H264-Videos.htm
[AVI_VFW]: http://forum.doom9.org/showthread.php?s=&threadid=80430
[Link 7]: http://www.dvdforum.org/25scmtg-resolution.htm
[Link 8]: http://www.blu-raydisc.com/assets/downloadablefile/040901b-12817.pdf
[Link 9]: http://www.vcodex.com/h264.html
[Link 10]: http://www.moonlight.co.il/tech_h264.php
[Link 11]: http://www.dspr.com/www/technology/technology.htm
[Link 12]: http://radio.irt.de/docs/codecs.html
[Link 13]: http://www.chiariglione.org/mpeg/working_documents/mpeg-04/avc/avc_vt.zip
[Link 14]: http://www.dspr.com/www/technology/JVT-G050.pdf
[Link 15]: http://www.blu-raydisc.com/Section-13628/Index.html
[H.26L_Access unit]: http://blog.csdn.net/bingqingsuimeng/article/details/9987733
[http_blueben-chong.blog.sohu.com_128200567.html]: http://blueben-chong.blog.sohu.com/128200567.html
[AVC_H264]: http://blog.csdn.net/scarlettsp/article/details/4010651