VP9 或 H.265 的 6 个比较点(比较vp和vm并分析其差异的原因)
suiw9 2025-03-28 21:09 4 浏览 0 评论
直播很复杂。广播流和通过 Internet 传输流的整个过程涉及一系列可以采用多种格式的方法。一个重要的组件是用于媒体文件编码和解码的编解码器。编解码器还定义了可用于进行流式传输的工具类型。
大大简化流程;为了让视频在 Internet 上进行流式传输,它必须首先使用麦克风和摄像头捕获音频和视频。然后,必须将原始数据压缩(编码)到编解码器中,通过互联网连接广播(使用传输协议),发送到某种服务器端解决方案(通常是 CDN 或 Red5 Pro 等基于云的集群),并随后解压缩(解码)以供订阅者最终观看视频。
目前使用的编解码器有很多,包括 VP8/9、h.264 (AVC)、h.265 (HEVC) 和 AV1。
虽然这篇文章主要关注 VP9 与 h.265,但最重要的是什么是最好的编解码器。最后,我们将介绍为什么 h.264 目前是低延迟直播流媒体更有效的选择。
什么是VP9?
VP9 编解码器是由 Google 开发的免版税、开源的视频编码标准。作为 VP8 的后继产品,它最初用于压缩 YouTube 上的超高清内容,因为它提高了其前身的编码效率。原始 VPX 编解码器来自于 2010 年被 Google 收购的On2 Technologies。Google随后开源了该编解码器。
什么是 h.265?
h.265编解码器或高效视频编码 (HEVC) 是通过视频编码专家组 (VCEG) 和运动图像专家组 (MPEG) 的共同努力开发的。它于 2013 年 4 月被批准为 h.264 的官方继任者,也称为高级视频编码 (AVC)。它提高了 h.264 的压缩效率,将视频大小减少了约 50%。
什么是 h.264?
如上所述的h.264或 AVC 是目前最广泛采用的视频编解码器。截至 2019 年 9 月,91% 的视频行业开发人员都在使用它。与 h.265 一样,h.264 也是由运动图像专家组 (MPEG) 开发的,作为对以前标准的改进,旨在提供高效压缩的高质量互联网上的视频。
H.264 受许多专利保护,并由 MPEG-LA 组织授权。然而,思科系统公司在 2013 年向公众提供了一种广泛使用的免费开源编码器和解码器,称为openH264。换句话说,思科为我们所有人使用的专利许可付费。这反过来又创造了 h.264 编解码器的广泛采用,并且 openH264 的实现出现在所有 Web 浏览器中。
我们汇总了评估每个编解码器的 6 个关键因素的列表。
编码质量
VP9 和 h.265 在这个类别中没有太大区别。使用任一编解码器,视频看起来都不错。然而,h.265 略优于 VP9,当比特率较高时反之亦然。
为了判断图像质量,我们可以使用如下所示的SSIM(结构标准指数测量)指标。在互联网上广播流时,压缩和扩展(编码和解码)流中包含的视觉数据的过程可能会导致轻微失真,因为解码器会推断数据以显示它。因此,SSIM 本质上测量了传输的图像在编码和解码后的准确度。
1:比较libvpx(VP9)、x264(h.264) 和x265(HEVC) 的质量/比特率图。
然而,与 h.264 相比,差异更大一些。
VP9 和 h.265 能够增加压缩的部分方式是通过使用更大的宏块。宏块是图像或视频的处理单元,包含要显示的图像的像素。h.264 使用 16 x 16 宏块,而 VP9 和 h.265 使用 64x64 块。这些宏块经过称为“帧内预测方向”的计算系列,将这些宏块重建为相同的原始图像,只是在非关键区域的细节略少。这使得 VP9 和 h.265 能够提高效率,因为图像的天空或模糊背景等不太详细的区域不会被分解为更小的单元。这些区域中丢失的细节并不会显着降低图像的整体质量,因为重要部分的渲染更加详细。还应该注意的是,当您增加比特率时,
H.264 产生较差的图像,尤其是在较低比特率时。比较以相同比特率运行的图像时,VP9 和 h.265 都比使用 h.264 生成的图像更详细、更清晰。换句话说,为了产生与 VP9 或 h.265 相同质量的图像,h.264 需要以更高的比特率运行。然而,质量上的差异虽然是可感知的,但并不一定是一个彻头彻尾的问题。为了更客观地衡量这一点,我们可以看一下 SSIM 数字,它表明 h.264 的结果非常接近 VP9 和 h.265。因此,虽然 h.264 在图像质量方面可能没有那么好,但差异不足以克服下一节中详述的重大权衡。
我们还应该指出其他因素,例如改进的亚像素插值和运动矢量参考选择(运动估计)也可以提高图像质量。这是因为它们有助于预测电影中下一帧的样子。这些是非常复杂的概念,值得他们自己的文章,所以我们将保留它。
编码时间
为了达到更高的压缩率,VP9和h.265需要进行更多的处理。所有这些额外的处理意味着他们将需要更长的时间来编码视频。这会损害您的延迟,因为花费在处理上的所有额外时间都会延迟您的视频播放。除其他原因外,延迟对于确保您的实时视频流能够提供交互式体验非常重要。
图 2:编码时间作为比特率改进的一个因素,比较libvpx(VP9)、x264(AVC) 和x265(HEVC)。
那么上图究竟是什么意思呢?
此图在水平轴上显示以每帧秒为单位的编码时间。纵轴显示比特率改进,它将 SSIM 和比特率的组合与设置为 x264 @veryslow 的参考点进行比较。参考点是为什么 x264 不会超过 0%。
图表告诉我们什么?
VP9 和 h.265(如宣传的那样)比 h.264 好 50%,但它们也慢 10 到 20 倍。如果您遵循 x264 (AVC) 的蓝线,您会发现它在大多数比特率基准点上都低于其他两条线。不仅如此,绿色 (h.265) 和橙色 (VP9) 线在曲线的早期与 h.264 相交。这意味着每帧速率的秒数将开始急剧增加,并真正拖累您的流媒体性能。因此,虽然 VP9 和 h.265 显示出更好的压缩率,但它的编码时间成本非常高,这将大大增加延迟。可以在滑铁卢大学的这项研究中找到对编码时间和编解码器比较的更深入分析。
CPU 消耗
如上一节所述,VP9 和 h.265 都必须运行比 h.264 更多的压缩算法,这随后会增加它们的 CPU 使用率。即使完全优化,实时流媒体也是一个 CPU 密集型过程,因此增加已经很高的使用率将是一个问题。但是,有一些东西可以缓解这种情况:硬件支持。专用芯片组将减少 CPU 消耗。
h.265 目前享有更多硬件支持,包括 Windows 10(可下载或通过 Intel Kaby Lake 或更新的处理器)Apple (iOS 11) 和 Android (Android 5.0) 设备。虽然大多数移动设备支持 VP9,但大多数其他系统不支持。如果没有直接的硬件支持,VP9 编码过程将与 CPU 挂钩,消耗大量资源,降低电池寿命,并可能增加延迟。
正如我们将在下一节中介绍的那样,h.264 得到了广泛的支持,并且首先不会像 VP9 或 h.265 那样消耗 CPU。
采用和浏览器实施
为了使用编解码器,需要支持硬件或软件编码器。h.265 的采用率很低,这在很大程度上是由于专利许可。h.265 有四个与之相关的专利池:HEVC Advance、MPEG LA、Velos Media 和 Technicolor。这使得它更加昂贵,阻碍了更广泛的采用,从而将其限制在特定的硬件编码器和移动芯片组中。只有 Edge、Internet Explorer 和 Safari 支持 h.265,即使这样运行浏览器的设备仍需要支持 h.265 硬件编码。即使在具有正确实现的浏览器中支持 h.265,WebRTC 也往往无法正常工作。如果没有 WebRTC 支持,很难实现实时延迟。
VP9 是免版税和开源的,为更广泛的采用扫清了道路。它适用于主流浏览器 Chrome、Firefox 和 Edge 以及操作系统 Windows 10、Android 5.0、iOS 14 和 macOS BigSur。由于 WebRTC 支持 VP9,它也可以直接在浏览器中工作。也有传言称Safari 支持也可能即将到来。
尽管 h.264 拥有一项与之相关的专利,但正如我们之前提到的,2013 年思科开源了其 h.264实施并以免费二进制下载的形式发布。这极大地推动了 h.264 的广泛实施。因此,所有浏览器笔记本电脑和移动设备都支持 h.264。
节省带宽
提高压缩率和由此产生的更小的文件大小的最大优势是它在广播时消耗的带宽更少。这意味着互联网速度较慢的用户仍然可以流式传输高质量的视频流。
那么哪种编解码器可以产生更好的压缩效率来创建更小的视频呢?
根据 Netflix 进行的一项测试,h.265 的性能比 VP9 高出约 20%。尽管其他测试产生了不同的结果,但它们都得出结论认为 h.265 会创建更小的文件大小。根据所使用的客观指标,h.265比 VP9 节省0.6% 到 38.2% 的比特率。
然而,虽然消耗较少的带宽是有用的,但还应考虑其他因素。全球固定宽带连接的平均上传速度为42.63 Mbps,这意味着即使 h.264 要求的连接速度更高,大多数地方也可以支持 4K 流媒体。尽管移动设备的平均速度要低得多,为10.93 Mbps,但它们仍然可以支持 1080p 流。
Boxcast的这张图表显示,全球平均连接速度绝对能够满足所有分辨率级别的上传速度要求。注意:我们找不到比较所有三种编解码器的图表,但 VP9 将介于 h.264 和 h.265 之间。
此外,还有一些方法可以配置您的流媒体应用程序,以迎合互联网速度较慢的国家/地区的用户。您可以通过添加 ABR 和转码支持来做到这一点。ABR(自适应比特率)将修改比特率以提供最佳体验。转码将广播分成多种质量,因此客户端可以根据可用带宽请求最佳质量。
您可能会想“移动设备卡在 2 或 3G 连接上怎么办?”。幸运的现实是手掌大小的设备不需要流式传输最高分辨率来看起来不错。720 甚至 480 仍将显示良好的质量。
虽然带宽消耗对消费者来说可能并不重要,但必须承认,如果公司使用 VP9 或 h. 265. 节省来自较小的文件,这意味着他们不会为 CDN 或云网络上的更多数据流支付那么多费用。虽然这当然很好,但只有在真正的高分辨率设置(如 4K)下,数据消耗减半才会产生重大影响。
当然,无论规模多大,省钱肯定是一件重要的事情。这将我们带到了下一个点,它将展示两全其美;更好的压缩与相同的性能。
LCEVC 回避了整个论点
LCEVC(低复杂度增强视频编码)将所有编解码器的压缩率提高了约 40%。这是因为它是一个附加处理层,可与现有和未来版本的 MPEG 或其他编解码器(如 VP9 和 AV1)一起使用。正如我们在前一篇文章中所介绍的,LCEVC具有对视频流技术产生巨大影响的巨大潜力。无需更改所有当前协议的组成,LCEVC 就可以使它们本身更加高效。
从现在的情况来看,看起来内容提供商将能够使用支持 LCEVC 的软件或基于硬件的编码器与 Red5 Pro 跨云平台相结合,以解锁实时流媒体,尽管它们是处理密集型视频格式建于。根据使用的核心编解码器,这不仅适用于 4K,最终也适用于 8K UHD,还适用于为 360 度观看、虚拟现实和其他创新而设计的格式。
可能普遍采用 LCEVC 背后的驱动力是因为几乎任何设备都可以支持独立下载到观众设备或嵌入服务提供商应用程序播放器的瘦 LCEVC 客户端。通过其 HTML5 JavaScript 实现,LCEVC 还支持无插件浏览器支持。这意味着广泛的实施应该相当简单。
什么是实用的?
在考虑了此处概述的所有内容后,由于广泛采用和快速的编码速度,AVC/h.264 目前是最佳可用选项。尽管提高压缩率和视频质量是重要的考虑因素,但现在的权衡太严重了。具体来说,高编码时间和贪婪的 CPU 消耗对于实时流视频来说真的很糟糕。
也就是说,考虑到 VP9 是免费的并且还享有广泛的支持,一旦创建了更快的软件或硬件编码器,它将在不久的将来成为一个可行的选择。在遥远的将来,AV1 最终将取代 VP9,但考虑到它目前所遭受的天文数字般的高编码时间,在它准备好广泛使用之前需要进行大量精简。当然,LCEVC 可能会绕过更改编解码器以实现更好压缩的整个问题。也许它只是作为 h.264 和 AV1 之间的长期桥梁。
尽管如此,AV1 已准备好取代 h.264、h.265 和 VP8/9。随着视频消费量的增加,减少带宽限制将使发送用户正在寻找的高质量视频变得更加容易。对于远离有线连接、更依赖手机连接的发展中地区尤其如此。它背后的财团拥有所有主要参与者,并且是免版税的。现在阻碍 AV1 的是缺乏实时编码器。一旦这些变得广泛可用,AV1(尤其是与 LCEVC 配对时)将是前进的方向。
相关推荐
- 10款超实用JavaScript音频库(js播放音频代码)
-
HTML5提供了一种新的音频标签实现和规范用一个简单的HTML对象而无需音频插件来控制音频。这只是一个简单的整合这些新的HTML5音频特征及使用JavaScript来创建各种播放控制。下面将介绍10款...
- PROFINET转Modbus网关——工业协议融合的智能枢纽
-
三格电子SG-PNh750-MOD-221,无缝连接Profinet与Modbus,赋能工业物联产品概述...
- 简单实用的Modbus类库,支持从站和DTU
-
一、简介...
- [西门子PLC] S7-200 SMART PROFINET :通过GSD组态PLC设备
-
从S7-200SMARTV2.5版本开始,S7-200SMART开始支持做PROFINETIO通信的智能设备。从而,两个S7-200SMART之间可以进行PROFINETI...
- Modbus(RTU / TCP)有什么异同(modbus tcp和tcp)
-
Modbus是一种广泛使用的工业自动化通信协议,它支持设备之间的数据交换。Modbus协议有两个主要的变体:ModbusRTU(二进制模式)和ModbusTCP(基于TCP/IP网络的模式)。尽管...
- Modbus通信调试步骤详解(modbus调试工具怎么用)
-
Modbus通信调试步骤详解 Modbus通信分为串口和以太网,无论是串口还是以太网,只要是标准Modbus,就可以用Modbus模拟器进行调试。按以下几步进行调试。...
- 理解Intel手册汇编指令(intel 汇编指令手册)
-
指令格式...
- 「西门子PLC」S7-200 SMART的Modbus RTU通讯
-
S7-200SMART集成的RS485端口(端口0)以及SBCM01RS485/232信号板(端口1)两个通信端口可以同时做MODBUSRTU主站,或者一个做MODBUSRTU主站一个做MO...
- InfiniBand网络运维全指南:从驱动安装到故障排查
-
一、InfiniBand网络概述InfiniBand(直译为“无限带宽”技术,缩写为IB)是一种用于高性能计算的计算机网络通信标准,具有极高的吞吐量和极低的延迟,用于计算机与计算机之间的数据互连。它...
- 一加回归 OPPO,背后的秘密不可告人
-
有这样一个手机品牌,它诞生于互联网品牌。在大众群体看来,它的身世似乎模糊不清,许多人以为它是国外品牌。它的产品定位是极客群体,深受国内发烧友,甚至国外极客玩家喜爱。...
- [西门子PLC] S7-200SMART快速高效的完成Modbus通信程序的设计
-
一、导读Modbus通信是一种被广泛应用的通信协议,在变频器、智能仪表还有其他一些智能设备上都能见到它的身影。本文呢,就把S7-200SMART系列PLC当作Modbus主站,把...
- 狂肝10个月手搓GPU,他们在我的世界中玩起我的世界,梦想成真
-
梦晨衡宇萧箫发自凹非寺量子位|公众号QbitAI自从有人在《我的世界》里用红石电路造出CPU,就流传着一个梗:...
- [西门子PLC] 博途TIA portal SCL编程基础入门:1-点动与自锁
-
一、S7-SCL编程语言简介...
- 工作原理系列之:Modbus(modbus工作过程)
-
MODBUS是一种在自动化工业中广泛应用的高速串行通信协议。该协议是由Modion公司(现在由施耐德电气公司获得)于1979年为自己的可编程逻辑控制器开发的。该协议充当了PLCS和智能自动化设备之间的...
你 发表评论:
欢迎- 一周热门
-
-
Linux:Ubuntu22.04上安装python3.11,简单易上手
-
宝马阿布达比分公司推出独特M4升级套件,整套升级约在20万
-
MATLAB中图片保存的五种方法(一)(matlab中保存图片命令)
-
别再傻傻搞不清楚Workstation Player和Workstation Pro的区别了
-
Linux上使用tinyproxy快速搭建HTTP/HTTPS代理器
-
如何提取、修改、强刷A卡bios a卡刷bios工具
-
Element Plus 的 Dialog 组件实现点击遮罩层不关闭对话框
-
MacOS + AList + 访达,让各种云盘挂载到本地(建议收藏)
-
日本组合“岚”将于2020年12月31日停止团体活动
-
SpringCloud OpenFeign 使用 okhttp 发送 HTTP 请求与 HTTP/2 探索
-
- 最近发表
-
- 10款超实用JavaScript音频库(js播放音频代码)
- Howler.js,一款神奇的 JavaScript 开源网络音频工具库
- PROFINET转Modbus网关——工业协议融合的智能枢纽
- 简单实用的Modbus类库,支持从站和DTU
- [西门子PLC] S7-200 SMART PROFINET :通过GSD组态PLC设备
- Modbus(RTU / TCP)有什么异同(modbus tcp和tcp)
- Modbus通信调试步骤详解(modbus调试工具怎么用)
- 理解Intel手册汇编指令(intel 汇编指令手册)
- 「西门子PLC」S7-200 SMART的Modbus RTU通讯
- InfiniBand网络运维全指南:从驱动安装到故障排查
- 标签列表
-
- dialog.js (57)
- importnew (44)
- windows93网页版 (44)
- yii2框架的优缺点 (45)
- tinyeditor (45)
- qt5.5 (60)
- windowsserver2016镜像下载 (52)
- okhttputils (51)
- android-gif-drawable (53)
- 时间轴插件 (56)
- docker systemd (65)
- slider.js (47)
- android webview缓存 (46)
- pagination.js (59)
- loadjs (62)
- openssl1.0.2 (48)
- velocity模板引擎 (48)
- pcre library (47)
- zabbix微信报警脚本 (63)
- jnetpcap (49)
- pdfrenderer (43)
- fastutil (48)
- uinavigationcontroller (53)
- bitbucket.org (44)
- python websocket-client (47)