基于GPU的视频转码技术研究

黄 兴，宋建新

(南京邮电大学 图像处理与图像通信实验室，江苏 南京 210003)

随着多种视频压缩标准的广泛应用，以及接收终端和内容表现形式的多样化，不同系统和网络之间的交互则越发重要。在这种情况下，需要对已经编码的视频数据根据实际的应用需求进行相应的转换。最新提出的H.264/AVC标准在图像质量和压缩率方面都有了很大提高，该标准在视频压缩和网络传输方面具有广泛的应用。而MPEG－2是当前数字电视和DVD采用的压缩标准，因此本文所研究的从MPEG－2到H.264的视频转换极具研究价值。然而，视频转码是个复杂的过程，它需要对已经压缩过的视频流进行解码然后经过处理转换成满足信道传输特性和解码终端要求的目标码流。视频转码密集的运算量使得 CPU 承受着巨大的压力［1－2］。

近年来，低成本、高性能且可编程的图形处理器(GPU)不断推出并普及，使得GPU被越来越多地用在通用计算上，人们意识到可以将一些运算量巨大的工作通过GPU来完成。本文根据视频转码的要求和GPU的运算特点，提出了一种利用GPU强大的并行计算能力来帮助视频转码的方法，该方法将视频转码过程中耗时最多、最复杂的运动估计和模式选择转移到GPU上并行执行。在开发GPU并行计算能力时，该方法采用NVIDIA公司的CUDA(统一计算设备架构)计算平台，实现了在GPU上执行的并行帧间预测，有效地提高了视频转码的速度和效率［3－4］。

1 CUDA计算模型

CUDA是NVIDIA公司推出的开发图形处理器通用计算能力(GPGPU)并行计算模型。近年来计算机显卡运算单元的速度越来越快，在某些应用方面甚至已经大幅超越CPU，基于GPU的通用计算已成为一个新的研究领域，它主要研究在图形处理的范围之外如何利用GPU来进行更为广泛的应用计算。CUDA计算平台以C语言为基础，它使开发者无需学习特定的显示芯片的指令或其他3D API就可以写出在图形处理器上执行的程序，为开发GPU的通用计算能力提供了便捷的开发研究平台。

1.1 CUDA硬件模型

CUDA模型的计算核心由流处理器SP(Stream Multiprocessor)组成，SP是由GPU中的顶点渲染器和像素渲染器组成的统一计算单元。每8个SP组成1个流多处理器SM(Streaming Multi－processor)，每个SM含有4种不同的片上内存:本地寄存器、共享内存(shared memory)、只读常量存储器(constant cache)和纹理内存(texture memo-ry)。而且每个SM都是基于 SIMT(Single Instruction，Multiple Thread，单指令多线程)的指令架构，用相同的指令执行不同的线程。虽然SM之间不能直接交换数据，但每个SM都可以读取和修改设备内存(Device Memory)，所以SM之间可以通过设备内存来交换数据。但由于设备内存属于外部存储器，并且没有缓冲，以致于读取设备内存的速度延迟比片上内存大，因此在程序设计上要尽量避免从设备内存交换数据。另外，SM线程之间的同步是通过每个SM内的SP执行同步函数来实现。

1.2 CUDA线程执行模型

在进行CUDA并行程序设计时，可以将GPU看作真正并行执行很多个线程的计算设备，它作为CPU的协处理器(Co－processor)而运作。在CPU上执行的程序称为Host程序，而在GPU上执行的程序称为Device程序或Kernel程序。一般情况下，GPU与CPU协同工作，CPU负责进行逻辑性强的事务处理和串行计算，而GPU则专注于执行高度线程化的并行处理任务。通常，Host端程序会将数据准备好后复制到显卡内存中，由GPU执行完Kernel程序后，再由Host端程序将所需的结果从显卡内存中取回。数据在Host端和Device端传输使用高性能直接内存访问(DMA)引擎。

Kernel执行的最小单位是线程(Thread)，若干个线程组成线程块(Block)，1个线程块所包含的线程数目是有限的，本文用的GT240M中1个线程块最多可以容纳512个线程。1个线程块的所有线程都在1个SM(Streaming Multiprocessor)上执行，因此，同1个线程块中的线程可以通过共享内存来相互共享数据。在1个SM中处于执行状态的线程块称为活动块(Active)，每个活动块都划分到被称为线程束(Warp)的线程组中，其中每个Warp包含相同数量的线程，一般为32个，其通过SIMT的方式由SM执行，多个Warp分时复用SM。每个线程都有唯一的线程ID(Thread ID)作为标识，同样每个线程块也有唯一的ID(Block ID)，它们都处于全局状态供程序使用。CUDA线程块模型结构如图1所示，若干个线程组成线程块(Block)，数个线程块再组成1个网格(Grid)，具有相同维度和大小的块可以分批组合到1个块网格中。这样，单个内核可以启动的线程总数就将变得很大，大大提高了并行计算的能力［5］。

2 基于GPU的MPEG－2到H.264视频转码方法

2.1 视频转码架构

由于本文的重点是研究利用GPU的参与来加速视频转码，MPEG－2到H.264视频转码只完成格式间的转换，并未涉及分辨力的转换和目标码率的控制，因此转码器的框架采用级联式的像素域转码结构［6］。

图1 CUDA线程块模型结构图

在从MPEG－2到H.264的转码过程中，由于解码过程相对简单，大约只占10%的运算量，故解码过程仍由CPU来完成。而计算量较大的步骤如H.264编码过程中的运动估计和模式选择，占据着转码过程绝大部分的计算复杂度，所以在设计利用GPU来参与转码的方法时，首先考虑将运动估计和模式选择的过程转移到GPU上来加速实现。其他步骤诸如量化和反量化、VLC和VLD、DCT和IDCT仍然在CPU上完成。

整个转码过程采用级联式的像素域转码结构，转码框架图如图2所示。首先在对MPEG－2视频流经过熵解码、反量化、IDCT和运动补偿将其解码到像素域，然后GPU执行CUDA内核函数，完成并行运动估计和初步的模式选择，并将搜索得到的运动矢量和模式选择信息从显存上传送给主机，主机对收到的GPU的运动矢量进行精细化搜索并完成剩余的编码步骤［7］。

图2 MPEG－2到H.264的视频转码框架图

2.2 并行运动估计

2.2.1 算法介绍

帧间预测是为了消除视频序列之间的时间冗余而采用的时域压缩方法。在H.264标准中，帧间预测采用可变块的多种模式的运动估计来实现，比如亮度块的模式可分为P16×16，P16×8，P8×16和 P8×8这4种，而每个P8×8块又有4种子宏块模式:P8×4，P4×8和P4×4。除了这7种模式之外，H.264的帧间预测在P帧中还支持SKIP编码模式和I4×4，I16×16这2种帧内编码模式。SKIP模式是针对P16×16的宏块在运动矢量为(0，0)时采用的模式。

目前虽然有不少学者和研究人员提出了很多有效的快速运动估计算法，但这些算法并不适合于CUDA并行环境。所以本文设计了一种在CUDA并行环境中运行的并行运动估计算法，这里的并行通过两方面来实现:一是线程块中的线程各自独立的计算搜索位置的SAD(Sum of Absolute Difference);二是多个线程块并发的完成16×16块的运动搜索。该算法在GPU上采用全搜索来实现整数像素的运动搜索，然后在CPU上实行1/4像素的精细化［8］。

据统计，在P帧编码中，P16×16，P16×8，P8×16和P8×8这4种模式占7种模式的80%以上，所以在设计算法时考虑到算法的改进效率，只将P16×16，P16×8，P8×16和P8×8这4种模式放在GPU上执行，而将其余3种模式仍留在CPU上执行。

由于GPU上的运动估计是宏块级并行，所以该算法在运动搜索之前要将所需的参考帧和当前待编码帧一次传送到GPU显存，经过GPU运算得到4种模式的代价之后，再选择最佳模式并计算其运动矢量。当转码器的编码端收到GPU回传的运动矢量时，对其进行简单的精细化后即可利用其计算残差进行后续编码环节。算法流程如图3所示，具体实现步骤见2.2.2节所述［9］。

2.2.2 并行运动估计算法实现步骤

为了便于并行程序的设计和执行，该并行运动估计算法的并行粒度为宏块级，将CUDA线程块的大小设计为16×16=256，正好与1个宏块(MB)的大小相对应。该算法在GPU上进行整像素的全搜索和最佳宏块模式选择，将分数像素插值和1/4像素精细化搜索的过程放在GPU上进行，主要步骤为:

1)读入当前的参考帧，并对其进行边界扩展，以便于全搜索。边界扩展是在原参考帧图像的四周分别扩展32行和32列，扩展的像素值和边界处的像素值相等。

2)在显存上开辟全局内存，用于存储当前编码帧和经过边界扩展之后的参考帧。

3)将当前待编码的帧和经过边界扩展之后的参考帧从主机(CPU)拷贝到设备端(显存)，并绑定到显存的纹理内存(Texture Memory)。

4)根据转码视频的分辨力，在GPU上合理划分线程块和Grid，设置好传入GPU的参数和分配的Block数目以及Thread数目。这里初步将线程块的大小定为16×16=256，设定搜索范围的宽度为16，则线程块的数目即Grid网格的大小恰好为1帧中的宏块数。

5)在每个Block内部分配每个Thread都可以访问的共享内存。并且计算线程块中每1个8×8子块对应于搜索范围内每个位置的SAD。

6)利用上一步骤中计算得到的SAD值，根据子块位置的对应关系，以4个8×8块SAD为基础，直接求和得出P16×8，P8×16，P16×16等块的 SAD。然后分别以这些块的SAD作为根据，选择最小SAD对应的位置为运动矢量，并记下其最小的SAD值作为该子块模式的代价。

7)根据上一步骤中得到的各个模式的代价值，选择最小的作为最终模式，并将该模式对应的运动矢量写入到显存的全局内存并回传至主机。

2.2.3 SAD的计算

首先计算8×8块的SAD。8×8块SAD的计算由1个线程块(Block)中的256个线程并行完成，每个线程单独计算1个对应参考位置的SAD值，如图4所示。图中，坐标顶点(0，0)处为参考帧搜索范围的顶点，由线程块中的Thread 0来完成SAD值计算，依次类推，最后一个搜索点为(15，15)，由线程块中的Thread 255来计算SAD值。线程块中的所有线程各自独立完成计算，互不干扰和依赖。计算完成之后它们通过同步函数进入同步点挂起。

图4 8×8块SAD计算

当P8×8子块的SAD计算出来之后，其他模式比如P16×8，P8×16和P16×16的SAD都可以由相对应位置的8×8子块的SAD值相加得到，如图5所示。P16×8块的SAD分别由Ⅰ、Ⅱ块和Ⅲ、Ⅳ块的SAD之和组成;P8×16块的SAD则分别由Ⅰ、Ⅲ块和Ⅱ、Ⅳ块的SAD之和组成;而P16×16块的SAD则由4个8×8子块之和共同组成［10］。

图5 其它模式的SAD推算

2.3 模式选择

对于模式选择，由于在设计整个转码系统时只考虑将帧间预测转移到GPU上完成，而帧内编码仍然在CPU上执行，所以这里将模式选择分两步完成。第一步是在GPU上完成，负责完成帧间宏块如P16×16、P16×8等块的模式选择;第二步是在CPU上完成的，此步骤在分数像素精细化之后，主要负责将帧间模式选择的结果再与帧内模式如I16×16、14×4比较，选择代价最小的模式作为最终模式。模式选择流程图如图6所示，其中第一步比较在GPU上完成，后面两个步骤则在CPU上完成。

图6 模式选择过程

3 测试结果

为了验证该方法对视频转码的加速效果，本文对基于GPU的转码方法和传统的CPU转码方法分别进行性能测试。实验环境为Intel Core 2 Duo T6600 2.2G CPU+NVIDIA Geforce GTX280M。使用的测试视频为CIF格式的MPEG－2视频源mother－daughter.m2v和QCIF格式的视频源foreman.m2v，测试的转码视频长度均为30帧，测试结果如表1所示，该表记录的是两种转码方法分别转码30帧MPEG－2视频所需的时间。

表1 算法性能对比

由表1可以看出，采用GPU来帮助视频转码的方法比传统的CPU转码的方法在速度上提高了3～4倍。实验证明，利用GPU的通用计算能力来加快视频处理的设计思路是可行的。

4 小结

本文提出了使用GPU来加速视频转码的算法，并通过实验验证了基于CUDA的视频转码算法的可行性，且取得了较好的效果。在此基础上可以在以下两个方面进行深入研究:一是考虑将更多的模块转移到GPU上实现;二是设计另外一种框架，让GPU在执行帧间预测的同时，CPU也执行量化编码模块而不是被挂起。这样可以进一步改善转码器的性能。

［1］ AHMAD I，WEI Xiaohui，SUN Yu，et al.Video transcoding:an overview of various techniques and research issues［J］.IEEE Transactions on Multimedia，2005，7(5):793－804.

［2］程恺英，王宏远，樊淳标.数字视频转码技术综述［J］.电视技术，2005，29(4):13－16.

［3］NVIDIA Corporation.NVIDIA CUDA compute unified device architectureprogramming guide version 3.2［EB/OL］.［2010－08－10］.http://www.nvidia.cn.

［4］NVIDIA Corporation.NVIDIA CUDA compute unified device architecturebest practices guide version 3.2［EB/OL］.［2010－08－10］.http://www.nvidia.cn.

［5］张舒，褚艳利.GPU高性能运算之CUDA［M］.北京:中国水利水电出版社，2009.

［6］KALVA H，PETLJANSKI B，FURHT B.Complexity reduction tools for MPEG－2 to H.264 video transcoding［J］.WSEAS Transactions on Information Science ＆ Applications，2005，2(2):295－300.

［7］LIU Y，TANG C，CHIEN S.Coding mode analysis of MPEG－2 to H.264/AVC transcoding for digital TV applications［C］//Proc.ISCAS 2007.［S.l.］:IEEE Press，2007:1995－1998.

［8］CHEN W，HANG H.H.264/AVC motion estimation implementation on compute unified device archetecture(CUDA)［C］//Proc.ICME 2008.［S.l.］:IEEE Press，2008，17:697－700.

［9］RODRIGUEZ R，MARTINEZ J，FERNANDEZ E G，et al.Accelerating H.264 inter prediction in a GPU by using CUDA［C］//Proc.ICCE 2010.［S.l.］:IEEE Press，2010:463－464.

［10］CHEUNG N，FAN X，AU O，et al.Video coding on multicore graphics processors［J］.IEEE Signal Processing Magazine，2010，27(2):79－89.