视频代码转换是指从一种压缩视频格式转换为另一种压缩视频格式，通常先要把某种格式解码为原始视频帧，然后用新的格式重新编码。在许多应用中高效的代码转换至关重要。例如，为了支持视频点播数据流，视频数据要以某种主流格式存储起来以节省空间，但必须支持众多不同的观看设备和解码器。为了做到这一点，需要在数据发送前以实时或者快于实时的速度进行代码转换。在视频节目制作阶段进行视频编辑时，也必须对视频数据进行解码、修改和重新编码。在普通家庭，为了能在家用视频服务器上使用视频，视频数据可能也需要转换才能适应服务器支持的格式。

        支持高清视频点播要求高性能的代码转换。RapidMind公司开发的软件开发平台利用统一的并行编程模型充分发挥各种多内核处理器的性能。通过在RapidMind平台上建立代码转换器，应用程序如今能运行在多种处理器上，包括CPU、GPU和Cell BE，并且还能通过扩展适应未来多内核(和众内核)处理器环境。

        代码转换器自然需要支持各种视频压缩格式。然而，许多格式在实现它们所需的运算类型方面有很多相似性。另外，编码器通常要比解码器贵得多。一般一种视频标准仅规定了压缩数据流中存储什么类型的数据以及解码器该怎样译码，并不规定编码器如何从原始输入数据流中提取需要的信息。

        通常一种压缩视频格式不仅要求实现对单帧的压缩，而且要求使用视频序列中的相邻帧实现对中间帧的预测。为了能从传输产生的任何错误中恢复数据，并允许用户从视频序列中间位置开始解压缩，有些帧是在不参考其它帧的情况下进行压缩的。

单帧压缩

        单帧压缩有点类似于普通的图像压缩，通常包含了到不同基础帧的转换，如使用不同频率和方向的余弦变换(离散余弦变换或DCT)，或小波变换。这种转换通常作用于块，并且从数学上可精简到块中像素上的一组点积(虽然一些基本函数允许理论上更快的因数分解)。转换后的系数再经过量化删除那些对图像可视无用的信息，形成一幅近似的图像，最后使用编码器编码去除数据中任何残留的冗余性。

        上述转换的目的不仅是通过将图像中的能量集中为更小的一组数字而使代码器变得更有效率，而且允许量化器显著地去除感知上不那么重要的信息。例如，DCT就会对图像的高频和低频成分进行分析。由于人眼对高频时的量化误差不甚敏感，因此这些频率的量化可以粗放一些。另外，在上述压缩步骤之前通常先要从亮度中分离出色度(颜色)和将色度欠采样到较低分辨率，因为人眼对亮度边缘较敏感，但对色度边缘不太敏感。

        一些较复杂的压缩格式还支持根据空间相邻的块对一些图像块作出预测。选择哪个块用于预测极具挑战性，而且支持解码器中的必要排序在并行系统中也相当复杂。然而，如果块的内容能够被准确预测，那么对该块压缩时只需编码预测值和实际值之间的(少量)差异。

        如此详细地介绍单帧图像压缩的原因是，实际上作为编码过程的一部分，无论是块还是单帧压缩/解压缩都有必要。特别是中间帧(数据流中的大部分帧)估计，它是通过融合和混合数据流前后发生的帧、然后从输入数据中减去这个融合后的帧、最后压缩差异图像(一般使用类似于单帧编码器的编码器)实现的。对这种融合的估计被称为运动估计，是编码过程中运算量最大的步骤之一。

        然而在解码器中，原始的源数据帧是没有的，只有解压缩后的帧。因此，这种融合要求图像能在解码器之前还原。因此它们不仅必须在编码器中压缩，而且需要被解压缩。这种对前面压缩的数据进行解压缩的需求将导致数据的依赖性，并影响到在具有不同存储器系统的处理器之间如何并行使用和分配编码器。

        视频序列中的图像组(GOP)中的一些帧(I，帧内编码帧)使用单帧压缩算法进行编码，但基于运动估计的帧间预测被用来改进帧内帧间(双向预测编码帧B，前向预测编码帧P)的压缩。只有预测帧和实际帧之间的差异值需要被压缩。由于B帧和P帧是根据I帧的解压缩版本预测出来的，因此有必要作为编码过程的一部分对I帧进行压缩和解压缩。

图1：RapidMind是一个开发和运行时间平台，它支持能充分利用多内核处理器的单线程可管理应用程序。开发人员可以用标准的C++语言编写代码，RapidMind平台则可以将这些代码在多个内核间“并行利用”。

运动估计

         运动估计是很有价值的。一般需要发现将像素从输入图像中的一个位置挎贝到融合后的图像上的这种融合，以便融合后的图像与该帧实际图像间的差异尽可能小。首先，像素块之间的相似性指标需要被定义，通常是SSD(差值平方和)或SSA(绝对差值和)。然后使用这种相似性指标测试各个候选源块的位置，以确定良好的匹配。

         有两点需要注意。第一，如果有较强的运算能力，那么可以测试较多的候选位置，从而可能找到更好的匹配，并提高压缩率。可以用运算能力的增强来降低带宽要求，反之亦然。其次，相似性指标是非线性的。这意味着使用多分辨率等技巧来加快相似性匹配速度是不合适的。低分辨率时的最佳匹配不一定是高分辨率时的最佳匹配。

         这里有两个基本点：数据位置和并行体系。首先，GPU是具有很高性能的处理器，但目前位于PCI Express卡上，这些卡有自己的存储器。因此为了压缩视频流，数据需要传送到视频卡上的存储器中，然后将压缩结果传回来。这一过程需要以流的形式完成，而这种流式处理与运算随时交叠，因此数据传送不会成为瓶颈。RapidMind平台正常情况下可自动管理数据，而且(能在内部硬件API支持的地方)提供深层分析功能来管理这种重叠式流处理。GPU存储器架构的其它意义还在于互相依赖的一系列步骤应尽可能保持在相同的存储器空间中。

最大程度的加速

        通常在考虑一个应用是否能被加速时，人们首先会分析应用程序的各个单元，判断每个单元上需花多长时间，并利用阿姆达尔定律估计可能的加速程度。

        举例来说，考虑到某个应用程序在单元A上要花10%的时间，在单元B上要花75%的时间，单元C上花5%的时间，单元D上花10%的时间。该应用程序的流程是A运行一次，然后B和C轮流多次反复运行(取决于彼此关系)，最后才是运行D。

同时假设单元A估计能加速1.5倍，B能加速20倍，C能加速2倍，D不能做任何加速。

这样理论上的最大时间缩短值是：

0.1/1.5+0.75/20+0.05/2+0.1/1=0.23

        相当于加速1/0.23(正好超过4)倍。值得注意的是，虽然单元B(75%的运行时间)的加速系数达到了很大的20，但只有使所有加速步骤对总运行时间的影响比较接近的情况下才能取得最好的效果。

事实上，如果只是以B为目标，并设法使之无限加速，但总的性能仍将受限于其余单元。

使用GPU

        进一步考虑使用GPU。大家可以看到B和C是反复进行的。如果只是在GPU上加速B，而让C留在主机上，那么需要不断地从主机那儿来回传送数据，从而严重影响性能。因此，即使单元C的加速幅度很小，但根据阿姆达尔定律，它对总的加速效果影响也很小。事实上，我们可能也想把C移动到GPU上以避免这些传送。

       这正是视频编码所面临的境况。即使运动估计是视频压缩中最昂贵的成分，我们也不能忽略其它因素，尤其是单帧压缩和解压缩，因为运动估计的其它阶段还需要这些结果。在考虑这些因素后，阶段优化工作量就需要正比于它对总体性能的影响程度。

RapidMind平台

        RapidMind平台能够用来快速实现和测试算法，并将算法应用于GPU或实际上多内核的CPU。如果有大量依附于数据的算法单元，Rapid实现就相当重要，因为所有单元必须移动到加速器的存储空间，以避免出现上述数据搬移问题。然而，根据它们的总体影响，优化所有这些单元可能不具成本效益，或没有太大作用。优化工作容易使代码复杂化，并且更难维护。

        RapidMind通过公共特性集向所有支持的硬件目标提供可移植性。仅使用这组公共特性也可能获得优异的性能。然而，RapidMind还提供了深层机制来访问特殊硬件特性，这种深层机制对优化可能有用，但也会影响可移植性。因此推荐的做法是软件项目首先只用公共特性实现所有必要的单元，然后(在实现完整功能后)对单元进行剖析以确定瓶颈及最有可能的改进之处，最后调整特殊单元，可能的话调整应保持在内核可移植功能集中。如果有必要进行特殊硬件的深层分析，使用RapidMind的提取功能可以隔离它的影响，原始的内核特性参考实现也可以用于实现可移植性。