Ittiam优化VP9，turnaround时间大幅减少
Ittiam优化VP9，turnaround时间大幅减少
libvpx是Google开发的视频编解码器VP8和VP9的开源软件实现库。libvpx中包含了VP9视频编码算法，相比H.264/AVC，在高质量配置的2 pass编码模式下能提供40%多的 BD-rate增益。这使得libvpx（VP9）在OTT(Over The Top)视频传输服务中潜力巨大。
然而，与H.264/AVC编码器相比，libvpx编码速度较慢，会产生较长的turnaround时间。例如，使用libvpx 1.6.0版本，’good’-CPU-used= 1配置，在相同的硬件和相似的线程配置条件下2 pass编码的速度比x264编码器的’very sow’配置慢2倍。尽管性能增益很高，但速度差距可能成为VP9技术被采用的障碍。最近，Ittiam与Netflix和Google合作的一个项目旨在提高libvpx编码器的性能。通过高效的多线程实现，使得在没有质量损失的情况下速度提高了50-70%。与汇编级优化不同，多线程优化适用于任何多核处理器。作为其中的部分改进，多线程优化应用于以下三个libvpx 2 pass编码模式中表现较差的情况。
1. First pass stats collection process
First pass stats collection process在libvpx编码器中是单线程的。所有宏块（MB）在一帧内按光栅扫描顺序处理。这个过程可以用多线程实现，即处理不同的tile MB行的过程与在MB级上解决帧内预测时顶部像素的依赖性问题的同步过程保持并行。图1展示了基于行的多线程方法（MT），包括2个tile列和4个线程。线程1和3在tile 0列，线程2和4在tile1列。
图1 两tile列四线程的MT方法
处理过程如上所述，直到相关的tile列处理完成为止。如果当前tile列中没有要处理的tile MB行，则将线程分配给其他tile列，如图2所示。多线程实现使用一个job队列机制，其中每个job对应于一个tile MB行的处理。
图2 两tile列四线程下的线程再分配
2. Second pass encoding stage
在libvpx VP9编码器second pass的并行机制受以下因素限制：
- 1. 给定分辨率配置下的tile列的数目。例如，对于1080p分辨率，最大可能的tile列数为4，将编码器限制为最多4路并行。
- 2. 由于不同的tile列尺寸以及边界上的内容变化导致不同的线程处理时间，由此产生的损耗。
上述限制可以通过使用job队列机制来解决，如图1和图2所示，其中每个job对应于一个tile MB行。顶部同步需要在帧内和MV预测时予以保证。
3. ARNR滤波
在参考软件实现中，滤波过程是单线程的，一帧内所有MB都以光栅扫描顺序处理。这里使用类似于上述job队列机制的多线程方法。由于滤波过程没有任何空间依赖关系，所以不需要顶部同步过程。上面讨论的基于行的多线程方法确保了由于变化的线程处理时间而产生的损耗是最小的。当线程的数量超过tile列的数量时，这种方法会带来编码性能的改进。该方法对BD-rate的影响微乎其微。
表1 不同分辨率下基于行的多线程方法在2 pass模式下编码速度提升
（相同计算资源，Threads=Max column tiles）
表2 不同分辨率下基于行的多线程方法在2 pass模式下编码速度提升
（双倍计算资源，Threads=2 * Max column tiles）
从表1和表2中可以看出，这次改进在turnaround时间层面上有高达60-70%的提升，改进后的libvpx版本大幅减少了计算成本和turnaround时间。结合相比于H.264/AVC编码的带宽增益，优化后的VP9实现版本为在线视频流媒体应用编码HD和UHD/4K流提供了一个有效可行的的选择。