视频压缩资料摘录

1、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 是可行的。

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

3、由于 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 程序出现无法执行的问题，因此并未将这个“部件”加入到正式版中。

4、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 高很多。

5、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。

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 等。

转自http://www.cnblogs.com/jhj117/p/5455966.html