转：视频压缩的基本概念(x264解压包)

第1页：前言——视频压缩无处不在
H.264 或者说 MPEG-4 AVC 是目前使用最广泛的高清视频编码标准，和上一代 MPEG-2、h.263/MPEG-4 Part4 相比，它的压缩率大为提高，例如和 MPEG-2 相比，同样的压缩后画面品质，h.264 的码率通常只需要一半，这意味着存储空间和网络传输时间/带宽大为节省。
h.264 是由 ITU-T Study Group 16 (VCEG) 和 ISO/IEC JTC 1 SC 29 / WG 11 (MPEG)这两个组织共同合作制定的，除了提供相应的技术文档外，他们还为业界提供了一个名为 JM Software 的 h.264 参考版编码/解码器，不过这个 JM Software 只是一个学术上的参考化实作（例如其他 h.264 编码器弄出来的视频流必须能被这个 JM Software 中的解码器正常解码出来），并非一个实用化的产品，所以无论是性能还是压缩效果都比较一般，更多的只是证明 h.264 是可行的。
h.264 虽然拥有诸多出色的特质，受到大家的欢迎，但是它存在的授权金问题倒是让不少厂商望而却步。直到 2010 年面对 WebM 等新标准竞争和一些口头威胁，MPEG 才正式宣布永远免收基于 Internet 的最终用户视频授权金，至此以后各个视频网站终于开始广泛接纳 h.264 作为最主要的网络视频编码标准。
对于许多人来说，视频编码或者说视频转码其实是息息相关的，视频聊天、网络视频共享无不和视频编码有关，当然这其中视频编码的动作可能会被软件巧妙的掩盖起来，让你不容易察觉。
在 2000 年科网股爆煲之前，就有不少网站开始大力推动网络视频，这时期的实时播放网络视频质量极差，很多时候只能看到人影晃动，连眼耳口鼻都分不清楚，体验极差。随着互联网和硬件技术的提升，现在的网络视频甚至可以做到 4K 级别，可以说对于习惯于上网的人来说，网络视频已经是不可或缺的普通消费品。
h.264 虽然是目前最流行的网络视频编码标准，但是它的运算复杂度一般要高于上一代的视频标准（例如 h.263 或者说 MPEG Part4），这意味着对处理器的性能要求更高。有见及此，几乎所有的嵌入式设备（例如手机等）中的处理器都会集成硬件化的 h.264 编解码器，获得性能/耗电上的平衡。
而在 PC 台式机上，视频编码在较长的一段时间里被认为是专业领域的事，这时期的视频编码器硬件化或者说硬件加速都是局限于一些专业采集卡或者非编卡上。随着网络速度的提升，人们的交流、分享意识已经不再局限于以往的文本、图片、声音，各个硬件厂商开始重视这个变得越来越热门的应用。

举个例子，Intel 这几年一直在推动的 WiDi 技术属于一种实时有损压缩无线显示连接技术，能够透过实时 h.264 压缩将主机处理后的画面透过 WiFi 无线网络发送到支持 WiDi 的显示器上。从市场角度而言，WiDi 当然算不上成功，但是它在利用视频压缩技术方面的确为我们提供了活生生的例子。 



NVIDIA 这边在 GTC 2012 上也展示了第二代的虚拟 GPU（VGX）技术，其中涉及到在 OSX、Android 等非 Windows 操作系统上提供 Windows 主机实时游戏画面的技术，显然就是利用了 Kepler 架构 GPU 中集成的 NVENC 硬件 h.264 编码器，才能实现低延迟传输画面。
h.264 提供了有损和无损两种压缩方式。其中的无损压缩虽说是无损，但是由于 h.264 的色彩空间主要是 YUV（当然 h.264 也"可以"提供 RGB 支持）而非显存中保存的 RGB 或者 sRGB 数据，这就涉及到色彩空间转换问题。也就是说，如果需要把 Fraps 保存的视频画面转换为 h.264 视频的话，很难做到真真意义上的无损。
此外，目前并没有支持无损压缩的 h.264 硬件编解码器，而且无损压缩方式的压缩率比有损方式低很多（一般需要每秒上百兆到数百兆的码率），因此目前的 h.264 实际应用普遍还是采用有损方式。
既然都是用有损压缩的话，那么衡量编码器高低指标除了速度以外，还必须兼顾压缩率，这里的压缩率当然是同码率下的压缩后画面品质，因为这事关网络带宽和画面呈现的延迟问题。
对于普通玩家来说，除了网络视频对话外，还有把自己平时生活、玩耍的经历制作成视频或者是把一些机顶盒录制的视频传输到网络上分享等常见用途，这时候如果编码器的压缩率更高的话，就意味着同样画质下的上传的时间更短。
如何在压缩性能和压缩品质之间取舍？我们尝试为大家进行一次量化的分析，希望能给各位带来一点参考。

 

第2页：常见编码器介绍——x264
常见编码器介绍——x264
虽然 Joint Video Team 做的 JM Software 是一个包含了编码器、解码器在内的免费源代码开放软件，但是由于速度实在惨不忍睹，所以在现实中没有人会将其用于实际的编码工作。
在 2003 年年底，法国人 Laurent Aimar 从零开始编写一个名为 x264 的开源 h.264 编码器。到了 2004 年年中，Laurent Aimar 被 ATEME 公司收编，自此以后，x264 的开发主导工作由 Loren Merritt 接管。如今 x264 的开发主要由 Loren Merritt、Jason Garrett-Glaser、Steven Walters、Anton Mitrofanov、Henrik Gramner 以及 Daniel Kang 进行，其中 Jason Garrett-Glaser 是 x264 的领衔开发者。
依照 Loren Merritt 在 2006 年发表的 x264 论文，当时的 x264 0.47.534 已经能在 5% 码率差别和 50 倍速度的情况下，提供和 JM 编码器 10.2 相当的 PSNR（一种最常使用的画面品质评价指标）。
凭借开源、免费的优势，目前 x264 已经成为各个压片组的唯一 h.264 编码器，大家在网络上能下载的各类 h.264 视频绝大部分都是由 x264 压制的。不过与之相比的是，x264 在商业中的应用并不多，只有极少数的蓝光节目视频是用 x264 编码，当然在现实中也许有不少“其他”编码器可能或多或少参考了 x264，只是我们还不得而知。
由于 x264 是开源软件，因此在这几年里一直都有不同的编译版本和修改版或者说分支，其中之一就是利用 OpenCL 这个 API 尝试实现在 GPU 这类处理器上实现海量线程并行加速。对 x264 使用 OpenCL 进行硬件加速的尝试有几个项目，而在“官方”这边，目前主要是针对 x264 中的 lookahead 操作模块做硬件加速。
Lookahead 操作属于 x264 中的一个复杂模块，作用是对主编码器模块尚未分析的帧进行编码成本估算。例如自适应 B 帧定齤位、显式权重预测、受限缓存码率控制（buffer-constrained ratecontrol）的位元分配等等，都会用到 lookahead 操作的结果。基于速度考量，x264 的 lookahead 是在一半分辨率上操作的，采用的是简化版运动向量预测和帧间分析。
按照 Jason Garrett-Glaser（x264 首席开发员）和 Steve Borho（Mulricore Ware 方案架构师）在 AMD Fusion Developer Summit 2012 上的介绍，当时的 x264 OpenCL 在 Tahita（RADEON HD 7970）上达到两倍性能，而画面品质和 C 语言版 x264 相当。
虽然 OpenCL x264 有一定的性能提升，但是 x264“官方”认为这个东西目前还有很多地方未完善。即使是同一个 GPU 厂商提供的 OpenCL 驱动，也会出现不同版本有差异性，从而导致 OpenCL 程序出现无法执行的问题，因此并未将这个“部件”加入到正式版中。

目前有名为 x264pro 的第三方插件为 Adobe 软件实现 x264 支持
x264 的官方版本是命令行执行文件，目前有许多其他的编码器前端都把 x264 打包在自己的软件包里，例如 MEncoder、MeGUI、MediaCoder 等，当然它们打包的方式不尽相同。
例如 MEncoder 是一个独立的执行文件，x264 就包裹在这个单一的执行文件中，而 MEncoder 本身不仅仅包含有 x264。
MeGUI 则是一个图形界面，x264 作为“工具”需要在安装 MeGUI 后透过互联网在线下载。
MediaCoder 也是一个图形界面，它的 x264 似乎是 MediaCoder 作者自己修改编译过的，x264 包含于 MediaCoder 安装包里。

 

第3页：常见编码器介绍——CUDA/NVENC
首先要说明，CUDA Encoder 和 NVENC 是两个不同的东西，前者是采用 GPU 的通用计算单元进行编码加速，后者则是增加了专门的硬线化编码电路作编码加速，不妨先回顾一下。
在 2008 年，一家名为 Elemental Technologies 的公司向业界推出了基于 CUDA 加速计算的视频编码器——Badaboom，可以在具备 Streaming Mulitprocessor 特性 1.1 的 NVIDIA GPU 上提供 h.264 编码加速。
到了 2009 年，NVIDIA 公司开始在驱动中集成视频编码加速模块，开发人员可以从 NVIDIA 开发者网站上免费下载相关的开发文档资料调用这个加速模块。
在这以后，软件市场上出现了一大票的 CUDA 视频加速软件，例如：MediaCoder、Cyberlink Media Espresso、MainConcept CUDA h.264/AVC Encoder、ArcSoft Media Converter、DVDFab Video Converter、Tipard Video Converter、Freemake Video Converter、WinAVI Video Converter、4Videosoft Video Converter、Expression Encoder 4 Pro SP1、Leawo Total Media Converter 等等，这就不一一列举了。
在今年发布的 Kepler 家族 GPU 中，NVIDIA 集成了专用的 h.264 硬件编码器——NVENC，这和之前的 CUDA 编码器有很大的不同，因为之前的 CUDA 编码器是由 GPU 的通用计算执行部分 h.264 算法来实现加速。而 NVENC 则主要由专门为 h.264 算法定制的硬件单元来执行编码操作，主要的好处是在进行编码操作的时候性能/耗电比要比 CUDA Encoder 高很多。
就目前所了解，NVENC 的细节资料并未完全公开，NVIDIA 只是告知大家 NVENC 能实现 4K 分辨率、支持 h.264 High Profile 4.1、3D 视频流压缩。
迄今为止，支持 NVENC 的编码器只有 Cyberlink 的 Media Espresso 转码器媒体测试专用版。

 

第4页：常见编码器介绍——Quicksync
NVIDIA CUDA Encoder 推出后曾经引起了不少的轰动，不过 Intel 方面倒是表现得很淡定，因为就他们的研发实力而言，完全有能力在下一代产品中推出具针对性的产品，回敬 CUDA Encoder 的答案就是在 Sandy Bridge 架构 CPU 中引入了的 MFX（Multi-Format Codec Engine，多格式编解码器引擎）视频处理引擎。
第一代 MFX 是从 Sandy Bridge 上引入的，现在的 Ivy Bridge 和下一代的 Haswell 也分别具备第二和第三代 MFX， Ivy Bridge 的第二代 MFX 主要是改进了性能，而 Haswell 的第三代 MFX 除了速度比 Ivy Bridge 更快外，在同码率画面品质方面也会有 11% 的改进。
MFX 包含了解码器、编码器和视频效果处理器三部分，其中编码器属于二工位混合式的硬件编码器。
Intel 将编码器的动作分为两组，即 ENC 和 PAK，其中 ENC 包括了码率控制、运动估算、帧间估算、模式抉择；而 PAK 包括了运动补偿、帧间预测、前向量化、像素重构、熵编码。
ENC 操作由 GPU 的可编程 EU 矩阵执行，PAK 则是 MFX 的硬件流水线执行，两组动作对不同的帧同时执行，可以藉此达到最高性能。
MFX 令人印象深刻的还有它的解码器性能。例如我们测试的 16 分钟 1080p 片段，在基于 GF110/GF104 的 GTX 580/GTX 560 Ti 上解码性能为 94.2 fps，基于GK104 的 GTX 680 是 158fps，而在 Sandy Bridge/ Ivy Bridge 的 i7-2600K/3770K 上解码性能居然分别高达让人瞪目乍舌的 460fps、606fps。
硬件解码性能的强大，除了说明 GPU 能应付更复杂的视频解码外，还意味着可以在转码的时候更多地解放 CPU 负荷。

 

第5页：各个测试软件及方法介绍
现在的情况可能还是有些尴尬，因为 NVIDIA 的 NVENC、AMD 的 VCE 目前都属于专用 API 阶段。换句话说，只有极少数签署了保密协议的软件厂商获得了软件开发资料。
故此，目前所见只有特定版本的 CyberLink Media Espresso、ArcSoft Media Converter 提供了 NVENC、VCE 支持，ArcSoft Media Converter 我们目前还无法获得，而支持 NVENC 的 CyberLink Media Espresso 版本还不支持 VCE。
实际上这些专用 API 对应的转码器目前基本没公开过，只是曾在 AMD 或者 NVIDIA 的 ftp 上提供下载，因此这次测试缺乏AMD的VCE 的对比。
不过随之而来的另一个问题是，我们这次要做的是量化测试，除了速度外，还包括画面品质。
Media Espresso 缺乏随意定制的码率设置，它只是依据分辨率提供几个“经验”上认为达到一定品质所需的几个码率选项。例如 1920x1080p24，最低码率是 6Mbps，然后是 8Mbps、10Mbps、13Mbps，缺乏足够的可定制性。
为了制作 RD （码率-失真度或者说率失真）曲线，我们需要可以自定义码率的编码器，不过能支持 NVIDIA NVENC 或者 AMD VCE 的软件目前都不具备此能力，因此 RD 曲线部分只能在 x264、CUDA encoder、Intel QuickSync 上提供。
我们使用 MeGUI 执行 x264、MediaCoder 执行 CUDA Encoder/Intel QuickSync 的编码结果来绘制 RD 曲线，测试片段为电影《飞砂风中转》中的一个 16 分钟片段，分辨率为 1920x1080p24，码率从 1000Kbps 到 9000Kbps，码率控制模式为恒定码率，步进为 1000Kbps（从实用角度而言 1000Kbps 步进是略显大了些，但是绘制 RD 曲线的话是足够的了）。

上图就是我们的 MeGUI 采用的 1PASS Max Speed 预配置（源自 Doom9.org 的 Sharktooth，你可以在这里：http://forum.doom9.org/showthread.php?t=139765 下载并导入到 MeGUI 内）。不过我们做了一些简单的更改，包括 AVC profile 设置为 High Profile、Level 设置为 4.1、Target Playback Device 为 DXVA，编码模式为 ABR（平均码率），而 x264 自身的预配置保持不变（即采用 Medium），启用了 CABAC，deblocking 各向设置为 0。
从画面品质角度考虑的话，这个设置对 x264 来说当然是暴敛天物（没能充分压榨 x264 的压缩率），但是我们在这里希望的是在尽可能快的速度下进行编码然后和 CUDA Encoder、Intel QuickSync 这类硬件加速的编码方案对比，所以速度在这里是我们必须考虑的。

我们为了方便探究一下在偏向画面品质较佳的情况下，x264 能做到什么样子，例如上图我们采用了 CRF=18 的 1pass fast 预设置压片，由于 CRF 模式是依据特殊的经验判别（这个操作被称作 RDO（率失真优化），在 JM 中是采用误差方差和（即 SSE）或者绝对误差和（即 SAD）等均方误差（即 MSE），x264 提供了 PSNR、SSIM 等多种导向优化模式）方式来判断每帧画面的码率，力求各帧画面的品质基本保持在同一水平，因此这个模式下的码率是不确定的。
根据我们的测试，在 CRF=18（CRF 值越小画面品质越高，0 的话对于 YUV 色彩空间视频来说相当于无损模式，但是从压缩率角度看，CRF 小于 18 基本上没有意义） 的时候，压出来的片段码率在 7.5Mbps 左右。
从专业角度而言，MeGUI 是一个出色的 x264 图形界面，但是因为涉及到 Avisynth 脚本，使用上需要有一定经验。
作为国产软件，MediaCoder 是第一个实现批量 CUDA 硬件加速编码的软件包，它有非常不错的图形界面，CUDA 硬件加速编码器的各种高级选项都能直接访问。

在今年三月份，MediaCoder 也实现了基于 Intel QuickSync 硬件编码的支持，界面同样非常友好，能直接支持 Sandy Bridge、Ivb Bridge 的硬件解码、编码模块实现转码加速。 


MediaCoder 兼具专业、易用性于一身，同时提供了最新技术的支持，是颇具使用价值的软件，我们希望 MediaCoder 能在 NVIDIA 年底的 NVENC SDK 发布后也一并提供相应的支持。
Cyberlink 的 Media Espresso 是常见的商业化编码器软件之一，提供了 CUDA Encoder、Intel QuickSync 等硬件加速支持，此外目前有特别的媒体版实现了 NVENC、VCE 支持，不过 VCE 版本目前尚未得见。

Media Espresso 虽然是商业软件，但是它有多个方面都存在不足，例如缺乏帧精确、全定制的码率设置、更深入的编码器参数设置，对于有一定经验的用户来说，它和许多开源软件相比是比较令人失望的。 

 

 

第6页：我们采用的画面量化判定指标
画面品质评价可以分为主观和客观两种，像单盲、双盲都是属于主观方式，不同人的感观和接受度都可能会得出不同的评价结果；而客观方式则是需要一些数学的手段来进行评估，只要算法、图片一样，拿到任何一台电脑上计算出来的指标都是一样的。
不过量化对比本身不是万能，它有一些缺陷。我们这里既然要进行画面品质的量化对比，自然需要借助一些工具和客观的指标。
目前评价画面品质的最常见保真度指标就是 PSNR 和 MSE，这里 PSNR 是峰值信噪比的英文首字母缩写，MSE 是均方差的英文首字母缩写，之所以这两个指标最常见是因为方程式比较简单，能快速计算。
但是 PSNR 是简单的基于对数据的逐个字节对比而不考虑这些数据呈现的是什么，对像素的空间关系完全没有判别能力，无法反映出人类视觉系统对复杂画面差别的感知

上图是一篇论文中的图片，它们的 PSNR 值都一样，但是以我们人类骤眼看来，图 A 的画面才是合理、正确的，图 B 则存在明显的瑕疵。如果仔细看的话，可以看到图 A 的水面噪点相对较多，类似这样的情况就是导致存在大块瑕疵的图 B 在 PSNR 值上和图 A 相当的原因。
简而言之，PSNR 值对我们人类来说有时候是不能反映主观视觉感观的，甚至完全不着边际，而且不同视频源、画面源的 PSNR 绝对值并不能对等地反映画面品质。例如不同画面源的处理后，画面PSNR值如果都是30dB ，并不代表视觉感官上它们的效果接受度都是一样的，可能一个较差，一个较好。
MSE 的情况类似，事实上它是 PSNR 的底子，所以对块状的敏齤感度不如噪点的敏齤感度高。也就是说，一张加上了少量噪点的处理后画面在 MSE 值上可能会低于有若干块状瑕疵的处理后画面，但是从人类的角度看，少量噪点的画面往往在感官上看上去比块状瑕疵的画面更好。
在 2004 年，Zhou Wang 等人提出了一种基于结构相似度的图像质量评价方式——SSIM，SSIM 认为光照对于物体结构来说是独立的，亮度和对比度的变化会造成光照的改变，因此可以将亮度和对比度从图像的结构信息中分离出来，然后结合结构信息对画面质量进行评估，就能得出接近于人类视觉系统的画面品质评价指标。
SSIM 值是一个固定范围内的小数，即 0 至 1，数值越高意味着画面质量越高，在画面质量相等的时候，SSIM=1，完全不相关的话，SSIM=0。SSIM 问世后，由于复杂度较低、具有很强的实用价值，引起了许多科研人员、开发者的关注，许多论文、应用都引入了 SSIM 或者变种。
我们这里说的图像质量评估方式都是在有参考图像的情况下进行的，和 PSNR 不同的是，SSIM 的绝对值相对 PSNR 来说更具参考意义，例如在视频画面质量评估中，一般认为 SSIM=0.95 意味着画面质量可接受，而 SSIM = 0.98 的话画面效果具有欣赏价值。
当然，因为 SSIM 值是基于参考图像的评估方式，有些时候并不能反映人类视觉对画面质量的主观感受，例如我们对画面做一些锐化之类的处理，从人类视觉系统角度而言处理后的画面可能会有时候差一点、有时候可能会好一点，但是 SSIM 值此时未必和我们的主观感受一样，这也是各种客观图像量化对比指标的缺点。
我们这里做的视频画面质量对比，在压缩的时候没有做除视频压缩外的后处理（例如我们的画面都是 1080p，不需要作反交错，也不需要做色彩空间转换），此时 SSIM 还是非常适于用这样的场合。
现在有多种现成的工具能实现视频画面的 SSIM 对比，例如 x264 本身内建了 SSIM 值计算、Avisynth 有 SSIM 插件、莫斯科国立大学（MSU）的 MSU Video Quality Measurement Tool 等。

依据 AVISynth 的 SSIM 插件能很方便的计算出某帧画面的 SSIM 值上图上半部分是片源（1080P），下半部分是 CUDA 1Mbps 压缩后画面我们对比的片段是电影《飞砂风中转》中的一个 16 分钟左右的片段全部画面（大概两万多张画面），而非单独的某帧画面，这就要求我们要做到帧精确的对比（否则的话会相当麻烦）。因此在对比前，我们都要对源视频和处理后的视频做索引化，除了 Media Espresso 压制出来的 Intel QuickSync 缺少后面的几帧画面外，都能实现 100% 的精确帧序对应。需要注意的是 Media Espresso 必须使用 .m2ts 封装才能实现正确的画面帧序，如果是 mp4 封装的话，前 100 帧画面会出现帧序不精确问题。