网站怎么做长截图,威海医院网站制作,免费做h5的手机软件,国外域名注册做违法网站第1页#xff1a;前言——视频压缩无处不在H.264 或者说 MPEG-4 AVC 是目前使用最广泛的高清视频编码标准#xff0c;和上一代 MPEG-2、h.263/MPEG-4 Part4 相比#xff0c;它的压缩率大为提高#xff0c;例如和 MPEG-2 相比#xff0c;同样的压缩后画面品质#xff0c;h…第1页前言——视频压缩无处不在H.264 或者说 MPEG-4 AVC 是目前使用最广泛的高清视频编码标准和上一代 MPEG-2、h.263/MPEG-4 Part4 相比它的压缩率大为提高例如和 MPEG-2 相比同样的压缩后画面品质h.264 的码率通常只需要一半这意味着存储空间和网络传输时间/带宽大为节省。
h.264 是由 ITU-T Study Group 16 (VCEG) 和 ISO/IEC JTC 1 SC 29 / WG 11 (MPEG)这两个组织共同合作制定的除了提供相应的技术文档外他们还为业界提供了一个名为 JM Software 的 h.264 参考版编码/解码器不过这个 JM Software 只是一个学术上的参考化实作例如其他 h.264 编码器弄出来的视频流必须能被这个 JM Software 中的解码器正常解码出来并非一个实用化的产品所以无论是性能还是压缩效果都比较一般更多的只是证明 h.264 是可行的。
h.264 虽然拥有诸多出色的特质受到大家的欢迎但是它存在的授权金问题倒是让不少厂商望而却步。直到 2010 年面对 WebM 等新标准竞争和一些口头威胁MPEG 才正式宣布永远免收基于 Internet 的最终用户视频授权金至此以后各个视频网站终于开始广泛接纳 h.264 作为最主要的网络视频编码标准。
对于许多人来说视频编码或者说视频转码其实是息息相关的视频聊天、网络视频共享无不和视频编码有关当然这其中视频编码的动作可能会被软件巧妙的掩盖起来让你不容易察觉。
在 2000 年科网股爆煲之前就有不少网站开始大力推动网络视频这时期的实时播放网络视频质量极差很多时候只能看到人影晃动连眼耳口鼻都分不清楚体验极差。随着互联网和硬件技术的提升现在的网络视频甚至可以做到 4K 级别可以说对于习惯于上网的人来说网络视频已经是不可或缺的普通消费品。
h.264 虽然是目前最流行的网络视频编码标准但是它的运算复杂度一般要高于上一代的视频标准例如 h.263 或者说 MPEG Part4这意味着对处理器的性能要求更高。有见及此几乎所有的嵌入式设备例如手机等中的处理器都会集成硬件化的 h.264 编解码器获得性能/耗电上的平衡。
而在 PC 台式机上视频编码在较长的一段时间里被认为是专业领域的事这时期的视频编码器硬件化或者说硬件加速都是局限于一些专业采集卡或者非编卡上。随着网络速度的提升人们的交流、分享意识已经不再局限于以往的文本、图片、声音各个硬件厂商开始重视这个变得越来越热门的应用。 举个例子Intel 这几年一直在推动的 WiDi 技术属于一种实时有损压缩无线显示连接技术能够透过实时 h.264 压缩将主机处理后的画面透过 WiFi 无线网络发送到支持 WiDi 的显示器上。从市场角度而言WiDi 当然算不上成功但是它在利用视频压缩技术方面的确为我们提供了活生生的例子。 NVIDIA 这边在 GTC 2012 上也展示了第二代的虚拟 GPUVGX技术其中涉及到在 OSX、Android 等非 Windows 操作系统上提供 Windows 主机实时游戏画面的技术显然就是利用了 Kepler 架构 GPU 中集成的 NVENC 硬件 h.264 编码器才能实现低延迟传输画面。
h.264 提供了有损和无损两种压缩方式。其中的无损压缩虽说是无损但是由于 h.264 的色彩空间主要是 YUV当然 h.264 也可以提供 RGB 支持而非显存中保存的 RGB 或者 sRGB 数据这就涉及到色彩空间转换问题。也就是说如果需要把 Fraps 保存的视频画面转换为 h.264 视频的话很难做到真真意义上的无损。
此外目前并没有支持无损压缩的 h.264 硬件编解码器而且无损压缩方式的压缩率比有损方式低很多一般需要每秒上百兆到数百兆的码率因此目前的 h.264 实际应用普遍还是采用有损方式。
既然都是用有损压缩的话那么衡量编码器高低指标除了速度以外还必须兼顾压缩率这里的压缩率当然是同码率下的压缩后画面品质因为这事关网络带宽和画面呈现的延迟问题。
对于普通玩家来说除了网络视频对话外还有把自己平时生活、玩耍的经历制作成视频或者是把一些机顶盒录制的视频传输到网络上分享等常见用途这时候如果编码器的压缩率更高的话就意味着同样画质下的上传的时间更短。
如何在压缩性能和压缩品质之间取舍我们尝试为大家进行一次量化的分析希望能给各位带来一点参考。
第2页常见编码器介绍——x264常见编码器介绍——x264
虽然 Joint Video Team 做的 JM Software 是一个包含了编码器、解码器在内的免费源代码开放软件但是由于速度实在惨不忍睹所以在现实中没有人会将其用于实际的编码工作。
在 2003 年年底法国人 Laurent Aimar 从零开始编写一个名为 x264 的开源 h.264 编码器。到了 2004 年年中Laurent Aimar 被 ATEME 公司收编自此以后x264 的开发主导工作由 Loren Merritt 接管。如今 x264 的开发主要由 Loren Merritt、Jason Garrett-Glaser、Steven Walters、Anton Mitrofanov、Henrik Gramner 以及 Daniel Kang 进行其中 Jason Garrett-Glaser 是 x264 的领衔开发者。
依照 Loren Merritt 在 2006 年发表的 x264 论文当时的 x264 0.47.534 已经能在 5% 码率差别和 50 倍速度的情况下提供和 JM 编码器 10.2 相当的 PSNR一种最常使用的画面品质评价指标。
凭借开源、免费的优势目前 x264 已经成为各个压片组的唯一 h.264 编码器大家在网络上能下载的各类 h.264 视频绝大部分都是由 x264 压制的。不过与之相比的是x264 在商业中的应用并不多只有极少数的蓝光节目视频是用 x264 编码当然在现实中也许有不少“其他”编码器可能或多或少参考了 x264只是我们还不得而知。
由于 x264 是开源软件因此在这几年里一直都有不同的编译版本和修改版或者说分支其中之一就是利用 OpenCL 这个 API 尝试实现在 GPU 这类处理器上实现海量线程并行加速。对 x264 使用 OpenCL 进行硬件加速的尝试有几个项目而在“官方”这边目前主要是针对 x264 中的 lookahead 操作模块做硬件加速。
Lookahead 操作属于 x264 中的一个复杂模块作用是对主编码器模块尚未分析的帧进行编码成本估算。例如自适应 B 帧定位、显式权重预测、受限缓存码率控制buffer-constrained ratecontrol的位元分配等等都会用到 lookahead 操作的结果。基于速度考量x264 的 lookahead 是在一半分辨率上操作的采用的是简化版运动向量预测和帧间分析。
按照 Jason Garrett-Glaserx264 首席开发员和 Steve BorhoMulricore Ware 方案架构师在 AMD Fusion Developer Summit 2012 上的介绍当时的 x264 OpenCL 在 TahitaRADEON HD 7970上达到两倍性能而画面品质和 C 语言版 x264 相当。
虽然 OpenCL x264 有一定的性能提升但是 x264“官方”认为这个东西目前还有很多地方未完善。即使是同一个 GPU 厂商提供的 OpenCL 驱动也会出现不同版本有差异性从而导致 OpenCL 程序出现无法执行的问题因此并未将这个“部件”加入到正式版中。 目前有名为 x264pro 的第三方插件为 Adobe 软件实现 x264 支持
x264 的官方版本是命令行执行文件目前有许多其他的编码器前端都把 x264 打包在自己的软件包里例如 MEncoder、MeGUI、MediaCoder 等当然它们打包的方式不尽相同。
例如 MEncoder 是一个独立的执行文件x264 就包裹在这个单一的执行文件中而 MEncoder 本身不仅仅包含有 x264。
MeGUI 则是一个图形界面x264 作为“工具”需要在安装 MeGUI 后透过互联网在线下载。
MediaCoder 也是一个图形界面它的 x264 似乎是 MediaCoder 作者自己修改编译过的x264 包含于 MediaCoder 安装包里。
第3页常见编码器介绍——CUDA/NVENC首先要说明CUDA Encoder 和 NVENC 是两个不同的东西前者是采用 GPU 的通用计算单元进行编码加速后者则是增加了专门的硬线化编码电路作编码加速不妨先回顾一下。
在 2008 年一家名为 Elemental Technologies 的公司向业界推出了基于 CUDA 加速计算的视频编码器——Badaboom可以在具备 Streaming Mulitprocessor 特性 1.1 的 NVIDIA GPU 上提供 h.264 编码加速。
到了 2009 年NVIDIA 公司开始在驱动中集成视频编码加速模块开发人员可以从 NVIDIA 开发者网站上免费下载相关的开发文档资料调用这个加速模块。
在这以后软件市场上出现了一大票的 CUDA 视频加速软件例如MediaCoder、Cyberlink Media Espresso、MainConcept CUDA h.264/AVC Encoder、ArcSoft Media Converter、DVDFab Video Converter、Tipard Video Converter、Freemake Video Converter、WinAVI Video Converter、4Videosoft Video Converter、Expression Encoder 4 Pro SP1、Leawo Total Media Converter 等等这就不一一列举了。
在今年发布的 Kepler 家族 GPU 中NVIDIA 集成了专用的 h.264 硬件编码器——NVENC这和之前的 CUDA 编码器有很大的不同因为之前的 CUDA 编码器是由 GPU 的通用计算执行部分 h.264 算法来实现加速。而 NVENC 则主要由专门为 h.264 算法定制的硬件单元来执行编码操作主要的好处是在进行编码操作的时候性能/耗电比要比 CUDA Encoder 高很多。
就目前所了解NVENC 的细节资料并未完全公开NVIDIA 只是告知大家 NVENC 能实现 4K 分辨率、支持 h.264 High Profile 4.1、3D 视频流压缩。
迄今为止支持 NVENC 的编码器只有 Cyberlink 的 Media Espresso 转码器媒体测试专用版。
第4页常见编码器介绍——QuicksyncNVIDIA CUDA Encoder 推出后曾经引起了不少的轰动不过 Intel 方面倒是表现得很淡定因为就他们的研发实力而言完全有能力在下一代产品中推出具针对性的产品回敬 CUDA Encoder 的答案就是在 Sandy Bridge 架构 CPU 中引入了的 MFXMulti-Format Codec Engine多格式编解码器引擎视频处理引擎。
第一代 MFX 是从 Sandy Bridge 上引入的现在的 Ivy Bridge 和下一代的 Haswell 也分别具备第二和第三代 MFX Ivy Bridge 的第二代 MFX 主要是改进了性能而 Haswell 的第三代 MFX 除了速度比 Ivy Bridge 更快外在同码率画面品质方面也会有 11% 的改进。
MFX 包含了解码器、编码器和视频效果处理器三部分其中编码器属于二工位混合式的硬件编码器。
Intel 将编码器的动作分为两组即 ENC 和 PAK其中 ENC 包括了码率控制、运动估算、帧间估算、模式抉择而 PAK 包括了运动补偿、帧间预测、前向量化、像素重构、熵编码。
ENC 操作由 GPU 的可编程 EU 矩阵执行PAK 则是 MFX 的硬件流水线执行两组动作对不同的帧同时执行可以藉此达到最高性能。
MFX 令人印象深刻的还有它的解码器性能。例如我们测试的 16 分钟 1080p 片段在基于 GF110/GF104 的 GTX 580/GTX 560 Ti 上解码性能为 94.2 fps基于GK104 的 GTX 680 是 158fps而在 Sandy Bridge/ Ivy Bridge 的 i7-2600K/3770K 上解码性能居然分别高达让人瞪目乍舌的 460fps、606fps。
硬件解码性能的强大除了说明 GPU 能应付更复杂的视频解码外还意味着可以在转码的时候更多地解放 CPU 负荷。
第5页各个测试软件及方法介绍现在的情况可能还是有些尴尬因为 NVIDIA 的 NVENC、AMD 的 VCE 目前都属于专用 API 阶段。换句话说只有极少数签署了保密协议的软件厂商获得了软件开发资料。
故此目前所见只有特定版本的 CyberLink Media Espresso、ArcSoft Media Converter 提供了 NVENC、VCE 支持ArcSoft Media Converter 我们目前还无法获得而支持 NVENC 的 CyberLink Media Espresso 版本还不支持 VCE。
实际上这些专用 API 对应的转码器目前基本没公开过只是曾在 AMD 或者 NVIDIA 的 ftp 上提供下载因此这次测试缺乏AMD的VCE 的对比。
不过随之而来的另一个问题是我们这次要做的是量化测试除了速度外还包括画面品质。
Media Espresso 缺乏随意定制的码率设置它只是依据分辨率提供几个“经验”上认为达到一定品质所需的几个码率选项。例如 1920x1080p24最低码率是 6Mbps然后是 8Mbps、10Mbps、13Mbps缺乏足够的可定制性。
为了制作 RD 码率-失真度或者说率失真曲线我们需要可以自定义码率的编码器不过能支持 NVIDIA NVENC 或者 AMD VCE 的软件目前都不具备此能力因此 RD 曲线部分只能在 x264、CUDA encoder、Intel QuickSync 上提供。
我们使用 MeGUI 执行 x264、MediaCoder 执行 CUDA Encoder/Intel QuickSync 的编码结果来绘制 RD 曲线测试片段为电影《飞砂风中转》中的一个 16 分钟片段分辨率为 1920x1080p24码率从 1000Kbps 到 9000Kbps码率控制模式为恒定码率步进为 1000Kbps从实用角度而言 1000Kbps 步进是略显大了些但是绘制 RD 曲线的话是足够的了。 上图就是我们的 MeGUI 采用的 1PASS Max Speed 预配置源自 Doom9.org 的 Sharktooth你可以在这里http://forum.doom9.org/showthread.php?t139765 下载并导入到 MeGUI 内。不过我们做了一些简单的更改包括 AVC profile 设置为 High Profile、Level 设置为 4.1、Target Playback Device 为 DXVA编码模式为 ABR平均码率而 x264 自身的预配置保持不变即采用 Medium启用了 CABACdeblocking 各向设置为 0。
从画面品质角度考虑的话这个设置对 x264 来说当然是暴敛天物没能充分压榨 x264 的压缩率但是我们在这里希望的是在尽可能快的速度下进行编码然后和 CUDA Encoder、Intel QuickSync 这类硬件加速的编码方案对比所以速度在这里是我们必须考虑的。 我们为了方便探究一下在偏向画面品质较佳的情况下x264 能做到什么样子例如上图我们采用了 CRF18 的 1pass fast 预设置压片由于 CRF 模式是依据特殊的经验判别这个操作被称作 RDO率失真优化在 JM 中是采用误差方差和即 SSE或者绝对误差和即 SAD等均方误差即 MSEx264 提供了 PSNR、SSIM 等多种导向优化模式方式来判断每帧画面的码率力求各帧画面的品质基本保持在同一水平因此这个模式下的码率是不确定的。
根据我们的测试在 CRF18CRF 值越小画面品质越高0 的话对于 YUV 色彩空间视频来说相当于无损模式但是从压缩率角度看CRF 小于 18 基本上没有意义 的时候压出来的片段码率在 7.5Mbps 左右。
从专业角度而言MeGUI 是一个出色的 x264 图形界面但是因为涉及到 Avisynth 脚本使用上需要有一定经验。
作为国产软件MediaCoder 是第一个实现批量 CUDA 硬件加速编码的软件包它有非常不错的图形界面CUDA 硬件加速编码器的各种高级选项都能直接访问。 在今年三月份MediaCoder 也实现了基于 Intel QuickSync 硬件编码的支持界面同样非常友好能直接支持 Sandy Bridge、Ivb Bridge 的硬件解码、编码模块实现转码加速。 MediaCoder 兼具专业、易用性于一身同时提供了最新技术的支持是颇具使用价值的软件我们希望 MediaCoder 能在 NVIDIA 年底的 NVENC SDK 发布后也一并提供相应的支持。
Cyberlink 的 Media Espresso 是常见的商业化编码器软件之一提供了 CUDA Encoder、Intel QuickSync 等硬件加速支持此外目前有特别的媒体版实现了 NVENC、VCE 支持不过 VCE 版本目前尚未得见。 Media Espresso 虽然是商业软件但是它有多个方面都存在不足例如缺乏帧精确、全定制的码率设置、更深入的编码器参数设置对于有一定经验的用户来说它和许多开源软件相比是比较令人失望的。
第6页我们采用的画面量化判定指标画面品质评价可以分为主观和客观两种像单盲、双盲都是属于主观方式不同人的感观和接受度都可能会得出不同的评价结果而客观方式则是需要一些数学的手段来进行评估只要算法、图片一样拿到任何一台电脑上计算出来的指标都是一样的。
不过量化对比本身不是万能它有一些缺陷。我们这里既然要进行画面品质的量化对比自然需要借助一些工具和客观的指标。
目前评价画面品质的最常见保真度指标就是 PSNR 和 MSE这里 PSNR 是峰值信噪比的英文首字母缩写MSE 是均方差的英文首字母缩写之所以这两个指标最常见是因为方程式比较简单能快速计算。
但是 PSNR 是简单的基于对数据的逐个字节对比而不考虑这些数据呈现的是什么对像素的空间关系完全没有判别能力无法反映出人类视觉系统对复杂画面差别的感知。 上图是一篇论文中的图片它们的 PSNR 值都一样但是以我们人类骤眼看来图 A 的画面才是合理、正确的图 B 则存在明显的瑕疵。如果仔细看的话可以看到图 A 的水面噪点相对较多类似这样的情况就是导致存在大块瑕疵的图 B 在 PSNR 值上和图 A 相当的原因。
简而言之PSNR 值对我们人类来说有时候是不能反映主观视觉感观的甚至完全不着边际而且不同视频源、画面源的 PSNR 绝对值并不能对等地反映画面品质。例如不同画面源的处理后画面PSNR值如果都是30dB 并不代表视觉感官上它们的效果接受度都是一样的可能一个较差一个较好。
MSE 的情况类似事实上它是 PSNR 的底子所以对块状的敏感度不如噪点的敏感度高。也就是说一张加上了少量噪点的处理后画面在 MSE 值上可能会低于有若干块状瑕疵的处理后画面但是从人类的角度看少量噪点的画面往往在感官上看上去比块状瑕疵的画面更好。
在 2004 年Zhou Wang 等人提出了一种基于结构相似度的图像质量评价方式——SSIMSSIM 认为光照对于物体结构来说是独立的亮度和对比度的变化会造成光照的改变因此可以将亮度和对比度从图像的结构信息中分离出来然后结合结构信息对画面质量进行评估就能得出接近于人类视觉系统的画面品质评价指标。
SSIM 值是一个固定范围内的小数即 0 至 1数值越高意味着画面质量越高在画面质量相等的时候SSIM1完全不相关的话SSIM0。SSIM 问世后由于复杂度较低、具有很强的实用价值引起了许多科研人员、开发者的关注许多论文、应用都引入了 SSIM 或者变种。
我们这里说的图像质量评估方式都是在有参考图像的情况下进行的和 PSNR 不同的是SSIM 的绝对值相对 PSNR 来说更具参考意义例如在视频画面质量评估中一般认为 SSIM0.95 意味着画面质量可接受而 SSIM 0.98 的话画面效果具有欣赏价值。
当然因为 SSIM 值是基于参考图像的评估方式有些时候并不能反映人类视觉对画面质量的主观感受例如我们对画面做一些锐化之类的处理从人类视觉系统角度而言处理后的画面可能会有时候差一点、有时候可能会好一点但是 SSIM 值此时未必和我们的主观感受一样这也是各种客观图像量化对比指标的缺点。
我们这里做的视频画面质量对比在压缩的时候没有做除视频压缩外的后处理例如我们的画面都是 1080p不需要作反交错也不需要做色彩空间转换此时 SSIM 还是非常适于用这样的场合。
现在有多种现成的工具能实现视频画面的 SSIM 对比例如 x264 本身内建了 SSIM 值计算、Avisynth 有 SSIM 插件、莫斯科国立大学MSU的 MSU Video Quality Measurement Tool 等。 依据 AVISynth 的 SSIM 插件能很方便的计算出某帧画面的 SSIM 值 上图上半部分是片源1080P下半部分是 CUDA 1Mbps 压缩后画面
我们对比的片段是电影《飞砂风中转》中的一个 16 分钟左右的片段全部画面大概两万多张画面而非单独的某帧画面这就要求我们要做到帧精确的对比否则的话会相当麻烦。
因此在对比前我们都要对源视频和处理后的视频做索引化除了 Media Espresso 压制出来的 Intel QuickSync 缺少后面的几帧画面外都能实现 100% 的精确帧序对应。需要注意的是 Media Espresso 必须使用 .m2ts 封装才能实现正确的画面帧序如果是 mp4 封装的话前 100 帧画面会出现帧序不精确问题。
第7页MediaCoder NVIDIA CUDA恒码率模式人类在判断视频品质的时候往往对整段视频中极少量的低品质画面非常敏感 上图是我们用若干个百分位数绘制的分布图 百分位数是指将各帧依照 SSIM 值从大到小排列 然后统计在某个 SSIM 值上有百分几的帧是位于该值之下
可以看到基于 NVIDIA CUDA Encoder API 进行恒码率编码的 1000Kbps 画面品质最低达到了 SSIM0.56xx 的水平30% 的帧低于 SSIM0.95 可接受画面品质指数。
到了 2000Kbps 后SSIM0.95 的帧数下降到了大约 7% 以下但是依然有 80% 的帧低于具欣赏价值的 SSIM 0.98。
当码率达到 9000Kbps 后CUDA Encoder 压缩出来的帧有 12% 以下是不足 0.98 SSIM换句话说此时有 88% 左右的帧是具欣赏价值的。
需要多少码率才能做到 50% 的帧具有欣赏价值SSIM0.98呢从百分位比分布图可以看出答案是 5000Kbps。
第8页MediaCoder Intel QuickSync和 CUDA Encoder 相比基于 Intel MFX 引擎的 QuickSync 在低码率1000Kbps时的表现相对来说没有那么多的下探而且下探的幅度要小很多最低处的 SSIM 值为 0.8216较 CUDA Encoder 的 0.56xx 高出很多。
那么在最糟糕SSIM 值最低的情况下实际观感上和 CUDA Encoder 有怎样的区别呢先让我们用 CUDA Encoder 1000Kbps 下最糟糕帧序的画面来对比看看 上原片 中CUDA Encoder 1000Kbps 下Intel QuickSync 1000Kbps 如果你需要无损图片请将大图后缀名称修改为 png 即可
正如你所看到的那样在同一帧下 SSIM0.8733 的 Intel QuickSync 压缩效果要比 CUDA Encoder 好得多沥青路面的肌理、灰屑这个是什么灰看过电影的人应该很清楚表现都有相对不错的细节不过仍然存在一定的斑驳而且在色彩上存在明显偏红的情况。
现在再让我们来看看同样码率下 Intel QuickSync SSIM 值最低的帧第 18020 帧画面表现又如何。 上原片 中CUDA Encoder 1000Kbps 下Intel QuickSync 1000Kbps 如果你需要无损图片请将大图后缀名称修改为 png 即可
CUDA Encoder 画面中的纸人面目可辨认度基本上和 10 年前实时网络视频效果差不过——眼耳口鼻几乎都糊在一起了而中间偏上的红色物体则是 CUDA Encoder 似乎更好。如果从 SSIM 值来看CUDA Encoder 是略微高一些但是骤眼看上去的话我想不少人会说 Intel Quick Sync 效果要好一些这说明 SSIM 虽然在客观指标上的可信度已经比较高但是它毕竟不是完全基于人类视觉系统的画面品质评价指标有时候它的值并不能充分体现我们肉眼所见感观。
第9页MeGUI x264 Encoder和 Intel QuickSync 相比x264 采用 MeGUI 的 1pass Max Speed单次最高速压缩预设在低码率1000Kbps上的表现要好很多波动程度和 Intel QuickSync 2000Kbps 的时候相当。
如果从百分比数分布图来看x264 只有大约 3.5% 的帧是低于 SSIM 0.95而前面的 Intel QuickSync 是大约 5% 的帧低于 SSIM 0.95在这个档位之下的低品质帧数缩小对于人类欣赏一整段视频来说是有比较明显的感官差别。 上原片 中上CUDA Encoder 1000Kbps 中下Intel QuickSync 1000Kbps 下x264 1pass maxspeed 1000Kbps 如果你需要无损图片请将大图后缀名称修改为 png 即可
上图 x264MeGUI 1 Pass MaxSpeed 预配置1000Kbps 中最低 SSIM 值的截图以及和原图、CUDA、Quicksync 的对比。
从我个人的主观判断来看 Quicksync 和 x264 在细节度上的差别并不大但是 x264 存在偏红的问题如果从 U、VYUV 色彩空间的两个色度通道来看此外它的色度 SSIM 值不如 CUDACUDA 的色度通道 SSIM 值在这一帧中是最好的。
第10页三种编码器的码率-失真曲线对比从平均 RD码率-失真曲线来看表现最好的是 Intel Quicksync它在 1000Kbps 的低码率设置下就能做到 SSIM 0.97基本上都能比 x264 MeGUI 1pass max speed 预配置高 0.01 个 SSIM 值。
表现最糟糕的是 NVIDIA CUDA Encoder在 1000Kbps 低码率设置下它只能做到 0.95 些微高一点的 SSIM 值而且依据我们之前的百分位数来判定的话它有 30% 的帧是低于 0.95大约 8% 的帧是低于 SSIM 0.9。
从曲线趋势来看CUDA Encoder 需要不低于 4500Kbps 才能做到平均 SSIM 0.98而 Intel Quicksync 大概是 3200Kbpsx2641pass maxspeed preset大概是 3500Kbps。
这意味着什么说明如果你要上传压缩后的视频到网络上CUDA Encoder 需要比其他两个对手多 40% 以上的时间我们会在稍后对这个问题做更多的讨论。
第11页Media Espresso CUDA/NVENC/Quicksync目前只有 Media Espresso 的特殊版本能提供 NVIDIA Kepler 所集成的 NVENC 执行硬件编码加速但是这个软件缺乏任意定制的码率设置以及其他高级选项而且必须采用 mt2s 封装才能实现帧序精确。 这次的对比我们添加了采用 x264 MeGUI 1pass fast CRF18平均码率为 7.4Mbps的 SSIM 值曲线图来和 Media Espresso 采用各种硬件加速模式的曲线图作对比。
从对比图来看NVENC 的波动幅度和 x264 CRF18 接近那么它们的百分位数表现又是如何呢请继续往下看。
首先我们希望能找一个对比的基准例如一个这次测试中软件编码效果最佳的例子来做对比。
在 Media Espresso 和 MeGUI 中我们采用软件模式进行编码其中 Media Espresso 采用 6000Kbps 和 8000Kbps而 MeGUI 采用 1pass fast cf18 预配置统计录得的 SSIM 值百分位数1% 到 99.9% 区间结果如下。 x264 crf18 展现出了惊人的实力大约只有 2% 的帧是低于 0.98并且 1% 或者以上的帧 SSIM 值都高于 0.979可以说此时整段片段和原片相比都很难觉察到瑕疵而码率代价则是 7.4Mbps相较 Media Espreso 8Mbps 而言这样的压缩率当然是让人相当佩服的。
在使用 Core i7 2600K 设置为 3.8GHz 时 x264 1Pass fast CRF18 的压缩速率为 28.84 fpsavisynth 脚本中的原片 ffms 索引解码线程为 3 线程相当于 1.2 倍速的编码速度。 在硬件编码中百分位表现最好的是 NVENCNVIDIA Kepler 家族人手一份8000Kbps、6000Kbps 时候分别大约有 92.5%、89% 的帧是高于 SSIM 0.98而 Intel Quicksync 在这方面的数字则分别是 83%、79%CUDA 是 81%、68.5%。
NVENC 和 x264 CRF18 相比,在 35%左右以下的帧数是不敌的但是在这往后就显现出一些优势但是这些优势由于是在 SSIM 0.985 以上的肉眼很难察觉所以这也体现出了 x264 crf 模式在码率控制上的强大优势——也就是可以更智能地将码率作合理分配。
第12页测试总结分析在这次测试中我们尽可能地使用目前认为最佳的客观量化指标以及百分位数等统计手段来衡量来自 Intel、NVIDIA 以及开源社区目前最成功的编码器测试了多种 h.264 编码器前端部分由于软件功能等原因没有在文中给出例如 Mainconcept 的 TotalCode for Adobe Premiere Pro由于缺乏 NVENC 支持而且往往压出来的片段和设定的码率有很大出入、ArcSoft Media Converter功能上和 Media Espresso 几乎一样而且似乎存在兼容性问题等。
我们使用一段 16 分钟左右的 1080p 视频在不进行任何后处理的情况下进行视频压缩处理压出来的片段不下 50GB接近 50 段视频然后对各帧画面两万张以上 SSIM 指标进行统计、绘制曲线图依据整段视频中出现极少量的劣质画面也会严重影响欣赏体验的原则对全部帧进行排序统计出百分位为大家勾勒出各类编码器的客观画面品质体验指标。
从测试结果来看硬件编码器中在中级6000Kbps以上码率表现最好的是 NVIDIA NVENC其次是 Intel Quicksync最差的是 NVIDIA CUDA Encoder。
由于 NVIDIA 目前并未开放 NVENC 的软件开发包只有一家公司提供了基于 NVIDIA 专有协议的编码器前端Media Espresso而这个软件缺乏足够的定制性因此使得这次测试有些别扭无法实现绘制 NVENC 的 RD码率-失真关系曲线图。
按照我们在 MeGUI 和 MediaCoder 这两个前段压缩的 x264、CUDA、Intel Quicksync 片段 RD 曲线来看CUDA 需要比 Quicksync 多 40% 的码率才能让平均 SSIM 值达到相当的水平。
如果我们将 x264 1pass maxspeed 8Mbps 的画面品质设定为参考指标的话此时的 SSIM 平均值是 0.9845Quicksync 要达到同样的 SSIM 均值所需要的码率是 7.5Mbps而 CUDA 则同样是 8MbpsQuicksync 此时所需要的传输时间可以缩短 6.25%。
对于我们使用的测试片段Quicksync 7.5Mbps 的文件大小是 828MB 左右以 2Mbps 的家用光纤宽带上传可以在 3300 秒或者说 0.92 小时左右完成上传。
Intel Sandybridge 和 Ivybridge 架构搭载的 MFX 视频引擎在编码速度上是不同但是画面品质一样的后者的编码速度提高了 50%左右以我们采用 MediaCoder 为例2600K 的编码速率是 4.65 倍3770K 是 6.55 倍时间上衡量的话分别是 210 秒 和 150 秒。
假设是在 3770K 上采用 Quicksync 编码然后采用 2Mbps 光纤上传到互联网上所需要的全部时间则是 3510 秒左右即 0.975 小时。
而 CUDA 8Mbps 这边的编码上传时间是 3730 秒 224 秒 3954 秒或者说 1.098 小时比 Quicksync 多 12.6% 的时间。
NVENC 的画面品质比 Intel Quicksync 更出色一些不过速度方面需要比 Quicksync 多大概 50% 的时间Media Espresso 中同样的软件中 CUDA 需要的时间是 Quicksync 的两倍和 MediaCoder 中的速度差别有些不同。
总括而言这次测试表明 Quicksync 在画面品质和速度上目前取得了不错的平衡而 NVENC 如果能在 MediaCoder 这类编码器前端上或得支持NVIDIA 目前尚未公布 NVENC 的开发包的话应该也有不错的潜力。
x264 这边目前虽然有一个“半官方” OpenCL 的 lookahead 操作优化版但是毕竟 h.264 当初设计的时候对多线程加速执行各类操作欠缺考量实际的速度改变不会有硬件编码器这边那么明显更多的是一种尝试性质。
新的 h.265 虽然尚未出台正式规格但是依据目前的消息h.265 将会考虑到多线程的优化届时 OpenCL目前的 OpenCL 对许多开发人员来说还处于挑驱动的阶段也将更加成熟相信异构计算将会在 h.265 上展现出更多的优势。
