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 实际应用普遍还是采用有损方式。
既然都是用有损压缩的话，那么衡量编码器高低指标除了速度以外，还必须兼顾压缩率，这里的压缩率当然是同码率下的压缩后画面品质，因为这事关网络带宽和画面呈现的延迟问题。
对于普通玩家来说，除了网络视频对话外，还有把自己平时生活、玩耍的经历制作成视频或者是把一些机顶盒录制的视频传输到网络上分享等常见用途，这时候如果编码器的压缩率更高的话，就意味着同样画质下的上传的时间更短。
如何在压缩性能和压缩品质之间取舍？我们尝试为大家进行一次量化的分析，希望能给各位带来一点参考。
常见编码器介绍——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 安装包里。
首先要说明，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 转码器媒体测试专用版。
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 负荷。
现在的情况可能还是有些尴尬，因为 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 虽然是商业软件，但是它有多个方面都存在不足，例如缺乏帧精确、全定制的码率设置、更深入的编码器参数设置，对于有一定经验的用户来说，它和许多开源软件相比是比较令人失望的。
画面品质评价可以分为主观和客观两种，像单盲、双盲都是属于主观方式，不同人的感观和接受度都可能会得出不同的评价结果；而客观方式则是需要一些数学的手段来进行评估，只要算法、图片一样，拿到任何一台电脑上计算出来的指标都是一样的。
不过量化对比本身不是万能，它有一些缺陷。我们这里既然要进行画面品质的量化对比，自然需要借助一些工具和客观的指标。
目前评价画面品质的最常见保真度指标就是 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 帧画面会出现帧序不精确问题。
人类在判断视频品质的时候往往对整段视频中极少量的低品质画面非常敏感
上图是我们用若干个百分位数绘制的分布图
百分位数是指将各帧依照 SSIM 值从大到小排列
然后统计在某个 SSIM 值上有百分几的帧是位于该值之下
可以看到，基于 NVIDIA CUDA Encoder API 进行恒码率编码的 1000Kbps 画面品质最低，达到了 SSIM=0.56xx 的水平，30% 的帧低于 SSIM=0.95 可接受画面品质指数。
到了 2000Kbps 后，SSIM<0.95 的帧数下降到了大约 7% 以下，但是依然有 80% 的帧低于具欣赏价值的 SSIM 0.98。
当码率达到 9000Kbps 后，CUDA Encoder 压缩出来的帧有 12% 以下是不足 0.98 SSIM，换句话说，此时有 88% 左右的帧是具欣赏价值的。
需要多少码率才能做到 50% 的帧具有欣赏价值（SSIM>=0.98）呢？从百分位比分布图可以看出，答案是 5000Kbps。
和 CUDA Encoder 相比，基于 Intel MFX 引擎的 QuickSync 在低码率（1000Kbps）时的表现相对来说没有那么多的下探，而且下探的幅度要小很多（最低处的 SSIM 值为 0.8216，较 CUDA Encoder 的 0.56xx 高出很多）。
那么在最糟糕（SSIM 值最低）的情况下，实际观感上和 CUDA Encoder 有怎样的区别呢？先让我们用 CUDA Encoder 1000Kbps 下最糟糕帧序的画面来对比看看：
上：原片
中：CUDA Encoder 1000Kbps
下：Intel QuickSync 1000Kbps
如果你需要无损图片，请将大图后缀名称修改为 png 即可
正如你所看到的那样，在同一帧下 SSIM=0.8733 的 Intel QuickSync 压缩效果要比 CUDA Encoder 好得多，沥青路面的肌理、灰屑（这个是什么灰？看过电影的人应该很清楚）表现都有相对不错的细节，不过仍然存在一定的斑驳，而且在色彩上存在明显偏红的情况。
现在再让我们来看看同样码率下 Intel QuickSync SSIM 值最低的帧（第 18020 帧）画面表现又如何。
上：原片
中：CUDA Encoder 1000Kbps
下：Intel QuickSync 1000Kbps
如果你需要无损图片，请将大图后缀名称修改为 png 即可
CUDA Encoder 画面中的纸人面目可辨认度基本上和 10 年前实时网络视频效果差不过——眼耳口鼻几乎都糊在一起了，而中间偏上的红色物体则是 CUDA Encoder 似乎更好。如果从 SSIM 值来看，CUDA Encoder 是略微高一些，但是骤眼看上去的话，我想不少人会说 Intel Quick Sync 效果要好一些，这说明 SSIM 虽然在客观指标上的可信度已经比较高，但是它毕竟不是完全基于人类视觉系统的画面品质评价指标，有时候它的值并不能充分体现我们肉眼所见感观。
和 Intel QuickSync 相比，x264 采用 MeGUI 的 1pass Max Speed（单次最高速）压缩预设在低码率（1000Kbps）上的表现要好很多，波动程度和 Intel QuickSync 2000Kbps 的时候相当。
如果从百分比数分布图来看，x264 只有大约 3.5% 的帧是低于 SSIM 0.95，而前面的 Intel QuickSync 是大约 5% 的帧低于 SSIM 0.95，在这个档位之下的低品质帧数缩小对于人类欣赏一整段视频来说是有比较明显的感官差别。
上：原片
中上：CUDA Encoder 1000Kbps
中下：Intel QuickSync 1000Kbps
下：x264 1pass maxspeed 1000Kbps
如果你需要无损图片，请将大图后缀名称修改为 png 即可
上图 x264（MeGUI 1 Pass MaxSpeed 预配置）1000Kbps 中最低 SSIM 值的截图以及和原图、CUDA、Quicksync 的对比。
从我个人的主观判断来看 Quicksync 和 x264 在细节度上的差别并不大，但是 x264 存在偏红的问题，如果从 U、V（YUV 色彩空间的两个色度）通道来看，此外它的色度 SSIM 值不如 CUDA（CUDA 的色度通道 SSIM 值在这一帧中是最好的）。
从平均 RD（码率-失真）曲线来看，表现最好的是 Intel Quicksync，它在 1000Kbps 的低码率设置下就能做到 SSIM >0.97，基本上都能比 x264 + MeGUI 1pass max speed 预配置高 0.01 个 SSIM 值。
表现最糟糕的是 NVIDIA CUDA Encoder，在 1000Kbps 低码率设置下，它只能做到 0.95 些微高一点的 SSIM 值，而且依据我们之前的百分位数来判定的话，它有 30% 的帧是低于 0.95，大约 8% 的帧是低于 SSIM 0.9。
从曲线趋势来看，CUDA Encoder 需要不低于 4500Kbps 才能做到平均 SSIM 0.98，而 Intel Quicksync 大概是 3200Kbps，x264（1pass maxspeed preset）大概是 3500Kbps。
这意味着什么？说明如果你要上传压缩后的视频到网络上，CUDA Encoder 需要比其他两个对手多 40% 以上的时间（我们会在稍后对这个问题做更多的讨论）。
目前只有 Media Espresso 的特殊版本能提供 NVIDIA Kepler 所集成的 NVENC 执行硬件编码加速，但是这个软件缺乏任意定制的码率设置以及其他高级选项，而且必须采用 mt2s 封装才能实现帧序精确。
这次的对比我们添加了采用 x264 + MeGUI 1pass fast CRF=18（平均码率为 7.4Mbps）的 SSIM 值曲线图来和 Media Espresso 采用各种硬件加速模式的曲线图作对比。
从对比图来看，NVENC 的波动幅度和 x264 CRF=18 接近，那么它们的百分位数表现又是如何呢？请继续往下看。
首先，我们希望能找一个对比的基准，例如一个这次测试中软件编码效果最佳的例子来做对比。
在 Media Espresso 和 MeGUI 中我们采用软件模式进行编码，其中 Media Espresso 采用 6000Kbps 和 8000Kbps，而 MeGUI 采用 1pass fast cf=18 预配置，统计录得的 SSIM 值百分位数（1% 到 99.9% 区间）结果如下。
x264 crf=18 展现出了惊人的实力，大约只有 2% 的帧是低于 0.98，并且 1% 或者以上的帧 SSIM 值都高于 0.979，可以说此时整段片段和原片相比都很难觉察到瑕疵，而码率代价则是 7.4Mbps，相较 Media Espreso 8Mbps 而言，这样的压缩率当然是让人相当佩服的。
在使用 Core i7 2600K 设置为 3.8GHz 时， x264 1Pass fast CRF18 的压缩速率为 28.84 fps（avisynth 脚本中的原片 ffms 索引+解码线程为 3 线程），相当于 1.2 倍速的编码速度。
在硬件编码中，百分位表现最好的是 NVENC（NVIDIA Kepler 家族人手一份），8000Kbps、6000Kbps 时候分别大约有 92.5%、89% 的帧是高于 SSIM 0.98，而 Intel Quicksync 在这方面的数字则分别是 83%、79%，CUDA 是 81%、68.5%。
NVENC 和 x264 CRF18 相比,在 35%左右以下的帧数是不敌的，但是在这往后就显现出一些优势，但是这些优势由于是在 SSIM 0.985 以上的，肉眼很难察觉，所以这也体现出了 x264 crf 模式在码率控制上的强大优势——也就是可以更智能地将码率作合理分配。
在这次测试中，我们尽可能地使用目前认为最佳的客观量化指标以及百分位数等统计手段，来衡量来自 Intel、NVIDIA 以及开源社区目前最成功的编码器，测试了多种 h.264 编码器前端，部分由于软件功能等原因没有在文中给出，例如 Mainconcept 的 TotalCode for Adobe Premiere Pro（由于缺乏 NVENC 支持而且往往压出来的片段和设定的码率有很大出入）、ArcSoft Media Converter（功能上和 Media Espresso 几乎一样，而且似乎存在兼容性问题）等。
我们使用一段 16 分钟左右的 1080p 视频在不进行任何后处理的情况下进行视频压缩处理（压出来的片段不下 50GB，接近 50 段视频），然后对各帧画面（两万张以上） SSIM 指标进行统计、绘制曲线图，依据整段视频中出现极少量的劣质画面也会严重影响欣赏体验的原则，对全部帧进行排序统计出百分位，为大家勾勒出各类编码器的客观画面品质体验指标。
从测试结果来看，硬件编码器中，在中级（6000Kbps）以上码率表现最好的是 NVIDIA NVENC，其次是 Intel Quicksync，最差的是 NVIDIA CUDA Encoder。
由于 NVIDIA 目前并未开放 NVENC 的软件开发包，只有一家公司提供了基于 NVIDIA 专有协议的编码器前端（Media Espresso），而这个软件缺乏足够的定制性，因此使得这次测试有些别扭，无法实现绘制 NVENC 的 RD（码率-失真关系）曲线图。
按照我们在 MeGUI 和 MediaCoder 这两个前段压缩的 x264、CUDA、Intel Quicksync 片段 RD 曲线来看，CUDA 需要比 Quicksync 多 40% 的码率才能让平均 SSIM 值达到相当的水平。
如果我们将 x264 1pass maxspeed 8Mbps 的画面品质设定为参考指标的话，此时的 SSIM 平均值是 0.9845，Quicksync 要达到同样的 SSIM 均值所需要的码率是 7.5Mbps，而 CUDA 则同样是 8Mbps，Quicksync 此时所需要的传输时间可以缩短 6.25%。
对于我们使用的测试片段，Quicksync 7.5Mbps 的文件大小是 828MB 左右，以 2Mbps 的家用光纤宽带上传，可以在 3300 秒或者说 0.92 小时左右完成上传。
Intel Sandybridge 和 Ivybridge 架构搭载的 MFX 视频引擎在编码速度上是不同（但是画面品质一样）的，后者的编码速度提高了 50%左右，以我们采用 MediaCoder 为例，2600K 的编码速率是 4.65 倍，3770K 是 6.55 倍，时间上衡量的话，分别是 210 秒 和 150 秒。
假设是在 3770K 上采用 Quicksync 编码然后采用 2Mbps 光纤上传到互联网上，所需要的全部时间则是 3510 秒左右，即 0.975 小时。
而 CUDA 8Mbps 这边的编码+上传时间是 3730 秒 + 224 秒 = 3954 秒，或者说 1.098 小时，比 Quicksync 多 12.6% 的时间。
NVENC 的画面品质比 Intel Quicksync 更出色一些，不过速度方面需要比 Quicksync 多大概 50% 的时间（Media Espresso 中，同样的软件中 CUDA 需要的时间是 Quicksync 的两倍，和 MediaCoder 中的速度差别有些不同）。
总括而言，这次测试表明 Quicksync 在画面品质和速度上目前取得了不错的平衡，而 NVENC 如果能在 MediaCoder 这类编码器前端上或得支持（NVIDIA 目前尚未公布 NVENC 的开发包）的话，应该也有不错的潜力。
x264 这边目前虽然有一个“半官方” OpenCL 的 lookahead 操作优化版，但是毕竟 h.264 当初设计的时候对多线程加速执行各类操作欠缺考量，实际的速度改变不会有硬件编码器这边那么明显，更多的是一种尝试性质。
新的 h.265 虽然尚未出台正式规格，但是依据目前的消息，h.265 将会考虑到多线程的优化，届时 OpenCL（目前的 OpenCL 对许多开发人员来说还处于挑驱动的阶段）也将更加成熟，相信异构计算将会在 h.265 上展现出更多的优势。
