Case Study I
将一个35Mbps码率的H.264视频转码为相同格式、7Mbps码率的视频。原视频片长约5分钟，分辨率为1920×1080p，30fps。视频中包含几个不同复杂性的场景，从密集空间细节到大量平面区域，从不规则运动到静态镜头。转码中涉及将原文件全解码并用新编码参数对其进行重新编码。
转码的采用的计算机平台配置如表8-3所示。
表8-3 案例I转码采用的计算机平台配置
| System Parameter | Configuration |
|---|---|
| 处理器 | 4th-gen. Core i5 |
| 核数 | 4 |
| CPU主频 | 2.9 GHz |
| CPU睿频 | 3.6 GHz |
| 热设计功耗 | 65 W |
| 缓存大小 | 6 MB |
| 显卡 | Intel (R) HD Graphics (TM) 4600 |
| GPU最大频率 | 1.15 GHz |
| 嵌入式DRAM | Yes |
| 内存 | 4 GB双通道 |
| 内存频率 | 1333 MHz |
转码采用了两种方式：仅运行在CPU上的软件转码器，和经过GPU加速的转码器（大多数计算密集型任务在专用硬件单元中完成）。这两种实现方式不同地优化了参数，但两者都提供了三种性能质量权衡的输出模式：最佳质量模式，平衡模式和最佳速度模式。
GPU加速的实现只提供了少量外部可设置的参数，而仅CPU上的转码有更多的可调参数，我们尽力使这些参数在各自的实现方式下尽可能接近。当然，两种实现方式的模式调整的确切参数存在差异，但也存在一些共性。表8-4总结了常用参数。
表8-4 两种转码方案的常用的配置
| 参数 | 最佳质量模式 | 均衡模式 | 最佳速度模式 |
|---|---|---|---|
| 运动估计和模型决策算法 | 算法1 | 算法2 | 算法3（早期版本中？） |
| 局部运动补偿 | 八分之一像素 | 四分之一像素 | 无 |
| 参考帧 | 多 | 少 | 1 |
| 自适应搜索 | 有 | 无 | 无 |
| 运动搜索范围 | 大 | 中 | 小 |
| 加权预测 | 有 | 有 | 无 |
| 多B帧？ | 有 | 有 | 无 |
| 子宏块分区 | 全部 | 部分 | 无 |
| 场景变化检测 | 有 | 有 | 无 |
| 比特率控制的前向分析 | 多数帧 | 少数帧 | 无 |
请注意，这两种实现方式中使用的参数略有不同，因此也不会产生完全相同的视频质量。另外，GPU加速实现的重点是在不损失太多视觉质量的情况下获得更高的性能，因此在此实现中只有少数参数的调整是从最佳质量到最佳速度。 另一方面，仅CPU转码器中难以获得更高的性能，因此在该实现方式的最佳速度模式下更激进的关闭了几个功能（相比GPU加速转码器而言）。
以FPS来衡量两种转码器实现的三种操作模式的下的性能。注意，为获得性能质量的平衡，三种模式都调整了编码参数。 图8-5显示了仅CPU转码和GPU加速转码两种实现之间的性能比较，同时图中还显示了不同模式下的比率。
图8-5. 不同转码模式的性能对比
从图8-5可以看出，这两种实现都在速度方面进行了缩放，速度范围从最佳质量到平衡模式再到最佳速度模式。例如，GPU加速将编码从一种模式加速到另一种模式，速度提高了大约2倍。但是，由于对编码参数进行了更积极的调整，仅CPU的方式从最佳质量缩放到了平衡模式，并且利用表8-5中的优化措施实现了7.45倍的加速。类似的，从平衡模式到最佳速度模式，可获得额外的4.2倍加速。
表8-5. 不同模式下，仅利用CPU的优化方法
| 参数 | 最佳质量 | 平衡 | 最快速度 |
|---|---|---|---|
| Motion estimation method | Uneven multihexagon search | Hexagonal search with radius 2 | Diamond search with radius 1 |
| Maximum motion vector range | 24 | 16 | 16 |
| Sub-pixel motion estimation | Yes | Yes | No |
| Partitions | All (p8x8, p4x4, b8x8, i8x8, i4x4) | p8x8, b8x8, i8x8, i4x4 | No sub-macroblock partitions |
| Use trellis for mode decisions | Yes | No | No |
| Adaptive quantization | Yes, with auto-variance | Yes | No |
| R-D mode decision | All picture types | I-picture and P-picture only | None |
| Max number of reference pictures | 16 | 2 | 1 |
| Number of references for weighted prediction for P-pictures | 2 | 1 | None |
| Number of frames to look-ahead | 60 | 30 | None |
| Max number of adaptive B-pictures | 8 | 2 | None |
| CABAC | Yes | Yes | No |
| In-loop deblocking | Yes | Yes | No |
| 8×8 DCT | Yes | Yes | No |
| Scene change detection | Yes | Yes | No |
显然，如上的优化影响了视觉质量。图8-6显示了两种实现方式的视频质量的比较。从最佳质量到最佳速度，未利用GPU加速的方式的PSNR平均损失约5 dB，而文件大小的减少则不到0.1％。另一方面，在保持视觉质量的同时提高性能的焦点上，GPU加速的方式从最佳质量到最佳速度模式下仅平均损失了~0.6 dB的PSNR。但是，与最佳质量模式相比，采用最佳速度模式时，GPU加速的模式会导致文件大小增加〜1.25％，从而折衷了所获得的压缩量。
图8-6. 是否采用GPU加速模式的质量对比
从图8-5和图8-6还可以发现：就三种性能模式的速度而言，采用GPU加速比仅采用CPU时分别快约33倍、9倍、4倍。这也显示了两种实现之间在参数调整方面的对比。尽管GPU加速的实现在最佳质量模式下的性能要好得多，但与仅用CPU的最佳质量模式相比，它的PSNR平均降低了1.76 dB，文件大小增加了约1.5％。因此，GPU加速的方式已经在通过牺牲视觉质量而支持性能。此外，由于某些算法是在固定功能硬件单元实现的，因此，GPU加速的实现在更改算法的能力方面缺乏灵活性。尽管如此，在最佳速度模式下，GPU加速方式的PSNR平均高出约2.8 dB，但与纯CPU实现相比，文件大小却增大了约2.9％。这些结果证明了这两种实现中所固有的性能-质量折衷。
图8-7显示了本节的案例研究的编码视频质量与编码速度之间的关系。 对于CPU-only和GPU加速的不同模式下的质量/速度存在明显的缩放，但是两种实现方式的缩放率却是不同的。
图8-7. Case Study I 的质量和速度的比较