H.264转码加速:NVENC大战Quick Sync

  GPU加速技术对普通消费者最直观的影响就是视频转码应用上了,NVIDIA.、AMD以及Intel都有自己的加速技术,而在新一代CPU和GPU架构上,三方都有更新的技术方案。<br><br>  NVIDIA在Kepler架构上引入了NVENC编码单元,实测画质与CUDA相当,但是速度更快,只不过在速度和功耗上依然比不过Intel的Quick
Sync,AMD的VCE因为缺少软件支持显得更悲剧。

  在GPU通用计算刚刚进入桌面平台时,NVIDIA以及AMD都把视频转码加速功能当作重点,因为这几乎是GPU计算带给普通消费者最直接、最有感触的功能了,比如MediaCoder、BadaBoom、MediaEspresso等软件都支持NVIDIA的CUDA加速以及AMD的Stream加速。

  GPU转码加速的好处是速度快,但是画质也低了,无法与单纯的CPU转码相媲美,随着技术的进步,GPU转码的画质才慢慢提升上来。再往后Intel也加入战场,SNB架构的GPU部分增加了专用的Quick
Sync
单元,无论转码速度还是画质都要比A/N两家的GPU加速效果要好。

  AMD在最新一代的GCN架构中增加了专用的VCE(Video Encodec Enigine)引擎,支持1080P
60fps视频转码,而且支持完整的H.264规范(前一代转码只支持H.264
Baseline),唯一的问题是软件支持度不够好,发布5个多月了才有MediaEspresso支持。


AMD的VCE引擎

  Ivy Bridge处理器中,Intel也将转码单元Quick Sync做了升级,虽然Intel官方资料中并没有提及具体的变化,但是我们之前也做过测试,发现转码速度变快了。此外,IVB的Quick
Sync也统一到了Media SDK API下。

  再有一个新选手就是NVIDIA的NVENC编码引擎了,它是Kepler架构新增的功能,按照NVIDIA给出的资料来看,NVENC比自家的CUDA编码还要优秀,因为它跟Quick
Sync一样属于是专用的编码加速单元,而CUDA加速则是比较通用的,速度上不如专用单元快。


NVENC编码加速功能

  早前我们也打算把NVENC编码加速专门测试一下,只是一直没能成行,不过首发测试中也做了MediaEspresso转码加速测试,GTX 680转码一段视频需要32秒,GTX 580HD 7970分别需要40、45秒,也就是在GPU计算性能更差的情况下,GTX 680的转码速度依然要高于GTX
580、HD 7970,NVENC功不可没。

  法国Hardware.fr网站最近做了详细的NVENC编码加速测试,并与Intel
Quick
Sync做了对比,虽然没能对比AMD的VCE编码引擎(软件支持是AMD的软肋啊),但是本文的测试方法和结果依然值得推荐,特别是画质对比方面专业得多,小编受益匪浅啊。

测试软件及方法:


MediaEspresso也有bug和限制,比如GOP 固定限制,对比测试并非以其为主要手段

  讯连科技的MediaEspresso 6.5软件支持Quick Sync以及NVENC加速。CPU为Core i5-3570K(HD
4000显卡),主板为华硕P8Z77 Pro-V。对比的显卡主要是GTX 670、GTX 680、GTX 480,虽然GTX
480是上上代的显卡了,不过CUDA编码加速实际上对显卡要求并不高,即便是GTX 450与高端显卡的差距也非常小。

  另外,软件编码使用的是Build 2197版本的H.264,分别测试了1-pass和2-pass。

画质对比

  画质对比值得着重说一下。平时我们做画质对比主要是用肉眼看,这种方法虽然直观一些,但是误差太大,而且不同的截图差别也不一样,不够有说服力。

  Hardware.fr用的是PSNR和SSIM数值,PSNR(Peak
signal-to-noise ratio,峰值信号噪点比例)是信号强度与噪点强度的比值,可以用来衡量有损压缩编码过程中的失真度。而SSIM(structural
similarity index,结构相似指数)也是用来衡量两张图片之间的相似度。

  有兴趣的可以参考上面的维基百科解释研究一下,总之,PSNR和SSIM是科学的测量方法,要比肉眼查看可靠得多,说服力也足够强。

  上面就是几种编码方案的PSNR和SSIM结果。

  虽然速度更快,但是NVENC引擎的转码画质与CUDA转码是一样的,丝毫没有降低。

  上面的计算只是基于平均状况,并不是全部内容,再来看一下500张逐帧截图中的SSIM指数吧。

  这里只是一张图片,推荐去原文看对比,因为他们做的是网页特效,下面的六个选项是可以点击选中或者取消的,方便对比任意几种编码方案的结果,鼠标指上去还会显示各个方案的具体SSIM数值,这是单一截图展示不了的。

  由于软件的Bug和限制,N卡和Quick
Sync转码的截图中每隔30帧就会出现一次剧烈波动(场景太复杂),0到187帧之间的场景容易压缩,因此SSIM比较稳定,188到243帧以及244到350帧之间波动就非常大,SSIM指下降的厉害。

  虽然Quick Sync在复杂场景中SSIM有所下降,但是依然要领先与NVIDIA显卡,H.264 1-pass编码依然有明显优势。

  那么实际画质是如何呢?来看一下317张截图的真实截图对比吧。

  这里依然去原文查看,因为他们作出了动态效果,最下面是各种编码方案的画质选择,点击左侧部分,转码后的截图就会出现在网页左边,右边则是另一种方案的画质截图,比如上图中我选择了原图与GTX
670(NVENC)编码,效果就是这个样子。

(ps,这里有点瑕疵,出现了两个GTX 670选项,实际上应该是一个GTX 670和一个GTX 680)

  结果是:NVIDIA GPU加速编码的画质损失依然是最严重的,而最新的H.264编码做的比较好,特别是2-pass画质十分接近原始画质。

转码速度及功耗

  使用的影片是720P分辨率的《阿凡达》,结果如下:

(说下表格的数据,第一列是转码时间,之后是待机功耗,第三列是转码时的功耗,最后一列是功耗差值)

  来看NVENC,其转码速度明显优于GTX 480,性能高了133%之多。功耗方面,固定转码单元的GTX 680比GTX
480只低了21W,从差值上看也只有11W,并没有表现出比预期更明显的优势。

  总的来看,Quick Sync依然是最好的编码加速方案,功耗和转码性能上都排名第一。另外,H.264
1-pass编码速度要比CPU还快,画质也高一些,而2-pass编码的速度不出意外地倒数第一,但是画质上傲视群雄。

  如果以W(功耗)/H(时间,小时)为基础来看(转码功耗乘以时间(s)再除以3600,上图中的法文符号","在英文中是".",也就是说上图中的数值是6.87、8.95这样的小数而非整数),Quick
Sync转码每小时消耗了0.83W电力,而GTX 670、GTX 680消耗的电力在3.10、3.24左右,其他方案消耗的就更高了,GTX
480效费比最差。

总结:

  原文的总结有三段,其实意思可以归纳为三句话:

  无论转码速度还是转码效率,Quick Sync依然是最佳的方案,NVIDIA的NVENC要胜过前代的CUDA方案,但还是比不过Intel。

  H.264软件转码中1-pass速度要超过CPU转码,2-pass虽然速度最慢,但是画质是最好的,适合对画质有较高要求的场合。

  至于AMD,技术上是好的,软件支持是杯具的。

H.264转码加速:NVENC大战Quick Sync,码迷,mamicode.com

时间: 2024-10-07 07:51:13

H.264转码加速:NVENC大战Quick Sync的相关文章

例程:如何使用PX2硬解码H.264裸码流 [CODE_PX2]Decode_RAW_H264_FILE

Rayeager PX2开发板具有非常强大的多媒体处理能力,如果需要调用硬件加速针对普通媒体文件/码流进行解码,只需按照安卓标准调用多媒体相关接口即可. 针对一些行业用户的特殊需求,Rayeager PX2实际上也开放了接口可以对H.264等裸码流进行解码. 这里提供一份代码即可实现H.264裸码流的解码,如果您具有一定的Android系统开发经验,很快就能理解并进行相关改写.使用方法: 在PX2的Android编译环境根目录下将代码解压,并进入ChipSPARK_PX2_H264_DECODE

视音频数据处理入门:H.264视频码流解析

前两篇文章介绍的YUV/RGB处理程序以及PCM处理程序都属于视音频原始数据的处理程序.从本文开始介绍视音频码流的处理程序.本文介绍的程序是视频码流处理程序.视频码流在视频播放器中的位置如下所示. 本文中的程序是一个H.264码流解析程序.该程序可以从H.264码流中分析得到它的基本单元NALU,并且可以简单解析NALU首部的字段.通过修改该程序可以实现不同的H.264码流处理功能. 原理 H.264原始码流(又称为"裸流")是由一个一个的NALU组成的.他们的结构如下图所示. 其中每

【视频编解码&#183;学习笔记】4. H.264的码流封装格式 &amp; 提取NAL有效数据

一.码流封装格式简单介绍: H.264的语法元素进行编码后,生成的输出数据都封装为NAL Unit进行传递,多个NAL Unit的数据组合在一起形成总的输出码流.对于不同的应用场景,NAL规定了一种通用的格式适应不同的传输封装类型. 通常NAL Unit的传输格式分两大类:字节流格式和RTP包格式 字节流格式: 大部分编码器的默认输出格式 每个NAL Unit以规定格式的起始码分割 起始码:0x 00 00 00 01 或 0x 00 00 01 RTP数据包格式: NAL Unit按照RTP数

H.264码流结构解析

大概前五六年之前写过的一个大体分析H.264格式,不是很详细,可以大致看看有哪些格式. H.264码流结构解析 那个时候上传的百度文库,以前记得有多积分,现在都不能下载了,还要充钱才可以.真是~~~ 1. H.264简介 MPEG(Moving Picture Experts Group)和VCEG(Video Coding Experts Group)已经联合开发了一个比早期研发的MPEG 和H.263性能更好的视频压缩编码标准,这就是被命名为AVC(Advanced Video Coding

H.264码流与帧结构

参考连接:http://blog.csdn.net/dxpqxb/article/details/7631304 H264以NALU(NAL unit)为单位来支持编码数据在基于分组交换技术网络中传输. NALU定义了可用于基于分组和基于比特流系统的基本格式,同时给出头信息,从而提供了视频编码和外部世界的接口. H264编码过程中的三种不同的数据形式: SODB 数据比特串-->最原始的编码数据,即VCL数据: RBSP 原始字节序列载荷-->在SODB的后面填加了结尾比特(RBSP trai

H.264码流打包分析

H.264码流打包分析 SODB 数据比特串-->最原始的编码数据 RBSP 原始字节序列载荷-->在SODB的后面填加了结尾比特(RBSP trailing bits 一个bit"1")若干比特"0",以便字节对齐. EBSP 扩展字节序列载荷-- >在RBSP基础上填加了仿校验字节(0X03)它的原因是: 在NALU加到Annexb上时,需要填加每组NALU之前的开始码 StartCodePrefix,如果该NALU对应的slice为一帧的开始

使用VideoToolbox硬编码H.264&lt;转&gt;

文/落影loyinglin(简书作者)原文链接:http://www.jianshu.com/p/37784e363b8a著作权归作者所有,转载请联系作者获得授权,并标注“简书作者”. =========================================== 使用VideoToolbox硬编码H.264 前言 H.264是目前很流行的编码层视频压缩格式,目前项目中的协议层有rtmp与http,但是视频的编码层都是使用的H.264.在熟悉H.264的过程中,为更好的了解H.264,尝

【H.264/AVC视频编解码技术详解】十一、H.264的Slice Header解析

<H.264/AVC视频编解码技术详解>视频教程已经在"CSDN学院"上线,视频中详述了H.264的背景.标准协议和实现,并通过一个实战工程的形式对H.264的标准进行解析和实现,欢迎观看! "纸上得来终觉浅,绝知此事要躬行",只有自己按照标准文档以代码的形式操作一遍,才能对视频压缩编码标准的思想和方法有足够深刻的理解和体会! 链接地址:H.264/AVC视频编解码技术详解 GitHub代码地址:点击这里 H.264中的条带(Slice) 1. Slic

H.264编码格式分析

H.264的重要性不再提了.本文主要记录一下H.264的编码格式.H.264官方文档:https://github.com/jiayayao/DataSheet/tree/master/encode-decode/h264. H.264从层次来看分为两层:视频编码层(VCL, Video Coding Layer)和网络提取层(NAL,Network Abstraction Layer).VCL输出的是原始数据比特流(SODB,String of data bits),表示H.264的语法元素编