您的位置：首页 > 其它

MediaCoder CUDA H.264 编码器测试报告

2012-04-07 14:00 120 查看

“MediaCoder 拥有目前其他 CUDA Encoder 无法比拟的优势，能导入几乎所有的编码、具备丰俭由人的编码设置、批量化任务安排、并能以多种文件封装格式导出编码的文件。”

MediaCoder CUDA H.264 编码器测试报告

异构运算是指系统内不同的运算部件负责各自擅长的计算，从而达到最佳的运算效率，这是一个非常广泛并由来已久的概念，而在最近几年，被讨论的最多异构运算话题就是 CPU+GPU 的协作运算。

在 2002 年，后来正式加入 NVIDIA 公司的 Mark Harris 认识到 GPU 在非图形应用上的潜力，首先提出了 GPGPU 这个术语并于同年创办了 GPGPU.org 网站，自此以后，人们一般把使用 GPU 做通用计算称作 GPGPU。

在这个领域最早付诸实际行动的是 ATI 公司，他们在推出 R520 的时候就着手进行这方面的工作，当 R580 推出的时候，ATI 公司也向业界公布了名为 Close To the Metal 的底层编程界面。遗憾的是，由于 CTM 正如其名称一样，太靠近 GPU 的底层，绝大多数的编程人员无从入手，基本上只有院校中的教授、研究生可以有空对其进行研究，得出了一些非常零碎的研究成果。

到了 2007 年，NVIDIA 正式向业界公布了 CUDA 的编程指南，这个基于 G80（Tesla）架构的编程模型由于完全使用 C 语言进行编写，程序员只需要稍微熟习 CUDA 的内存、线程层级，就能完成 CUDA 程序的开发，生产率远比 CTM 这类底层界面高得多，加上 NVIDIA 大力推广，并在推广过程中获得非常宝贵的反馈得以对 CUDA 进行充分的完善。

现在 CUDA 已经取得了初步的成功，包括业界目前正在推动的 Compute Shader、OpenCL 这两个 GPGPU API 都基本上是全盘采用了 CUDA 的架构和编程模型，可以说熟习 CUDA 其实就是 Compute Shader、OpenCL 的快速入门之道。

相比之下，已经收购了 ATI 的 AMD 公司在看到 CUDA 后也深感 CTM 的严重不足，只好全盘推翻了 CTM，另起炉灶推动 Stream，并在此过程中引入了 IL、Brook+ 等工具，无奈的是这番折腾消耗不少时间，当初大家在 CTM 上搞的东西统统作废。故此虽然 AMD 在 GPGPU 上虽然是最早涉足，但是却未能做到捷足先登，要怪就只能怪当初自己在高级语言上的准备不足缺乏前瞻性了。

取得实际先机的 NVIDIA 公司一直希望可以尽快向业界证明 CUDA 的实用性，这就需要寻找一些突破口或者所谓的 killer application，而最先进入视野的主要是 HPC 应用、数字视频和图形处理应用。HPC 就是高性能计算，在这个领域传统上都是大型机的天下，由于其特殊性，这些大型机的使用者都对编程非常熟悉，只要 CUDA 能提供非常可观的性能提升并有完善的开发工具和支持，他们一般会比较乐意尝试。

而在消费应用领域，目前需要有密集运算能力并且是热门的通用计算应用，首推的显然是数字视频、图片处理，一方面这是因为 GPU 本身就比较适合图形计算，另一方面这个领域对普通消费者来说看上去并不那么高深，数字多媒体的应用在宣传上已经有长期的积累，是 CUDA 这类异构运算的最佳消费应用领域切入点。

在这样的思路下，NVIDIA 开始大力推动 CUDA 在视频领域方面的应用推广，大家相继看到了 Badaboom、PowerDirector、MediaShow Espresso、TMPGEnc XPress、Nero Moveit、vReveal、Ikena、Super LoiLoScope 等多个编码、画面增强软件提供了 CUDA 加速的支持。

不过这些软件都是收费的，即使提供了试用版，仍然存在一些限制，例如 Badaboom 的试用版就在左下方有一个小 logo，PowerDirector、MediaShow Espresso 在文件格式、音频、码率设置方面存在严重的不足，适用性较低。

在今年 6 月 8 日，MediaCoder 的作者黄轶纯发布了版本号为 0.71 build 4430 的新版 MediaCoder，其中最为特别的地方之一就是引入了 CUDA H.264 编码加速的支持，由于这个软件是免费软件并且能支持众多的文件格式、编码标准来作为输入、输出，因此这个软件对于 NVIDIA 的用户来说是非常有意义的。

不过由于 MediaCoder 在此后一段时间受到一些授权的困扰，在一段时间里 CUDA H.264 Encoder 被关闭起来，而在此期间，黄轶纯开始更加重视版权方面的问题，例如把一些受争议的第三方编码器从***中去掉，修改了软件的发布方式，使其版权争议可以告一段落，现在 MediaCoder 的最新版本为 0.71 build 4475，大家可以在这里下载：

http://www.mediacoderhq.com/dlfull.htm

在安装过程中可以选择是否安装 CUDA 加速组件
安装完成后，执行程序主界面如下：

2009-8-13 14:33 上传
下载附件(163.42
KB)

</IGNORE_JS_OP nodeIndex="25">

2009-8-13 14:33 上传
下载附件(134.58
KB)

</IGNORE_JS_OP nodeIndex="29">

如上图，切换到视频标签页面，去掉编码器-自动选择前面的剔号，选择列表中的 CUDA Encoder。

选择好编码器后，就可以在右侧的编码器设置那里对 CUDA Encoder 进行设置，例如 profile、level 等。

2009-8-13 14:33 上传
下载附件(38.83
KB)

</IGNORE_JS_OP nodeIndex="38">

点选编码器属性设置的“高级”按钮，还可以对 CUDA Encoder 进行更高阶的属性设置。

具体的各个选项设置以及流程我在这里就不阐述了，大家有兴趣的话，可以直接到下面的这个连接参考：

http://wiki.broadintel.com/MediaCoder:Basics/zh

编码器性能测试结果

在这次测试中，我们采用 x264+MeGUI DXVA-SD Fast profile 修改为 1 PASS ABR High Profile Level 4.1 模式、Badaboom 1.1.1 1Pass VBR CABAC Main Profile Level 4.1、MediaCoder 0.71 Build 4470 cudaH264Enc.exe 1Pass High profile Level 4.1 进行测试。

测试的片段是我们截取自叶问蓝光版的一个片段，该片段我们用 TMPGEnc 重新编码为一段 720x480P24 的逐行视频，而后提供给这三个编码器进行编码测试，这主要是我们觉得大家要是进行自己编码的话，可能一般都是进行 SD 级别分辨率的编码。

我们将测试分为性能和品质两部分，之所以有这样的安排，是因为现在三个编码器（x264、Badaboom、MediaCoder CUDA H.264 Encoder）只有一个能实现 lossless 模式编码达到真正和片源完全的一致画面，在现实中三个编码器都或多或少存在画面质量的差别，单纯依靠速度或者画面对比都不可能将其实质表现完全展现出来。

故此我们这次测试一方面提供了性能方面的数据，一方面也提供了数字量化的客观对比作为画面品质的参考依据，下面就让我们先看看速度上的表现吧。

测试片段采用逐行视频也有利于我们进行画面品质对比。

x264+MeGUI 的编码设置我们采用了 STx264 的 x264 DXVA-SD-Fast 设置，但是将其 2 PASS 的设置修改为 ABR 1 Pass，Level 也从 3.1 修改为 4.1，其余保持不变：

与 x264 配合的 .avs 也尽可能的简单：

DGDecode_mpeg2source("I:\Karaoke\VIDEO_TS\benchmark\480p24.d2v", info=3)

ColorMatrix(hints=true, threads=0)

#deinterlace

#crop

#resize

#denoise

ETI Badaboom 是目前采用 CUDA 技术实现转码效果较好的产品，我们在这次测试中采取了如下的设置：

需要注意的是，我们的片段只包括了视频，不包括音频，因此转码过程并不涉及到音频转码。

测试平台：

Windows Vista x64 SP1

Core i7 920 2.66GHz 4.8GT/s

3GB 1DDR3-1333

GeForce GTX 260+ 896MB Forceware 185.65

从测试结果来看，MediaCoder 的 CUDA H.264 Encoder 要比 Badaboom 快了大约 1.6 倍，这可能是得益于 Core i7 920 搭配上 MediaCoder 的多线程软件解码性能较 GPU 内建的 VP2 更快（就播放视频而言，GPU 整合的硬件解码器本身速度只需要达到一定水平即可，而且是固定的），使得 GPU 获取资料的速度更多从而让整体的转码较硬件解码更快，异构运算特点和优势在这里得到了一定的体现。

编码画面品质测试结果

我们测试的视频片段有 2256 帧画面，由于现代的视频编码器有非常先进的算法以及编码率的关系，因此即使是同一个编码器在不同的帧能达到的画面品质都并不一定保持同样的质素，除非使用的是 lossless 模式。

单纯拉出某帧画面的截图来做对比在一定程度上是比较直观的，但是对于整段视频来说这样的方式就不够全面。

要达致比较公平的对比，最好的办法是除了主观的画面截图评定外，还需要一些数学模型来对画面质量进行评估，实现量化的客观对比。

在业界有不少数字影像、视频量化对比的测量指标，例如 PSNR，问题是 PSNR 的绝对值在一定程度上是不具备什么意义的，例如两个 PSNR 同样为 40 的视频画面，其中可能一个比较毛糙，另一个却比较干净，这就和对比用的源视频和算法类型有关了。

此外一些在我们现实观看的时候毫不起眼的小瑕疵例如整体画面的像素略有偏移、些微的滤镜处理，都会让 PSNR 值产生巨大的波动。

我们最终决定选择 SSIM 作为这次画面品质评定的指标，原因在于 SSIM 的数值可以比较精确地反映画面的主观视觉品质。

SSIM 是一个数值区间为 0~1 的指数，0 代表和参考源完全不相干，1 表示和参考源完全一致，SSIM 值越高，与参考源的一致性就越高。

由于目前的编码大都采用了 4:2:0 的 YUV 数据比例来压缩，Y 通道的信息是最丰富的而且是其他通道数据还原的重要基础，因此我们这次测试使用的 SSIM 值是取自 Y 通道的，你可以称之为 Y-SSIM。

正如你所看到的，和 Badaboom 相比，MediaCoder CUDA H.264 Encoder 的画面品质其实非常类似于 Badaboom，只是有些微的差别，低码率下略好一点，高码率 Badaboom 有细微的优势，但是可以认为两者的整体画面品质是非常接近的。

和 x264+MeGUI DXVA-SD Fast 1 Pass 相比，两个 CUDA 编码器都需要大约 1.5 倍的码率才能达到相当的画面品质。

测试总结

要进行视频编码器的对比绝非一件容易的事情，因为人们由于各自的喜好，往往有不同的参数设置，这会导致速度、画面品质上的不少差别

，不同的编码器之间有各自独特的实作取向。

2009-8-13 14:33 上传
下载附件(168.9
KB)

</IGNORE_JS_OP nodeIndex="92">

x264 已经历经了上千个 build，有许多深谙视频编码技术的高手使用高度优化的汇编代码为其实现了上千个不同的功能模块，具有高度的成熟度。

而目前的 CUDA Encoder 主要的模块实际上是由 NVIDIA 自己编写的，在签署保密授权协议后，透过 API 的方式把这些模块提供给诸如 Cyberlink、ETI、Nero、BIT 等公司完成产品级的实作，因此 CUDA Encoder 的品质和速度大家应该是非常接近的。

特别的是，MediaCoder 提供了采用第三方软件解码器，加上高度多线程的解码优化，配合起来后实现了较其他 CUDA 编码器软件更快的转码性能。

在功能方面，MediaCoder 拥有目前其他 CUDA Encoder 无法比拟的优势，能导入几乎所有的编码、具备丰俭由人的编码设置、批量化任务安排、并能以多种文件封装格式导出编码的文件。

据我们所了解到的最新消息是，NVIDIA 现在开发新版本的 CUDA Encoder，有可能引入 2 Pass 编码模式，这对提高压缩品质理论上是有一定好处的。

mediacoder_interface_video_cuda_setting-s.png
(168.9 KB, 下载次数: 9)

2009-8-13 14:33 上传
下载次数: 9

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航