有奖小调查

3 分钟回答 几 个小问题,让内容更符合你的 WebRTC 学习与开发期望。
每个月最后一天会随机抽出 5 名获奖者,并通过邮件联系送上奖品。
填写问卷

低延迟流媒体对高速的大量需求(一)

根据Bitmovin发布的《2019年视频开发人员报告》,有54%的受访者关心延迟问题。 深入调查后发现,将近50%的调受访者计划在未来1-2年内使用低延迟技术,其中50%以上的受访者寻求不到5秒的延迟,30%寻求不到1秒的延迟。(图1)。

综上所示,是时候有一篇低延迟选项的文章供大家参考了,不是吗? 在本文中,我首先会讲一些低延迟技术的基础知识,然后是一些选择技术的注意事项。

图1 Bitmovin公司《2019年视频开发人员报告》中的展示的延迟计划和未来展望

WebRTC

低延迟解决方案常用以下三种技术之一:WebRTC,HTTP自适应流(HAS)或WebSockets。在WebRTC.org常见问题解答页面上我们可以看到,“ WebRTC是用于在浏览器中启用实时通信的Web开放框架。” WebRTC目前进入了万维网联合会(W3C)标准组织的候选推荐阶段,还未得到最终批准。不过据Wikipedia称,Android,iOS,Chrome OS,Firefox OS,Tizen 3.0和BlackBerry 10系统中的所有主流桌面浏览器都已支持使用WebRTC。这意味着在这些平台上,WebRTC都无需下载即可运行。

WebRTC是为浏览器间的通信而设计的。顾名思义,它是一种用于向每个浏览者(点对点或服务器对点)传递实时流的协议。与WebRTC相反,基于HAS的解决方案将流分成多个块,以供客户端下载和播放。而正如大规模流式传输中所采用的方式,WebRTC通常是包含编码器,播放器和交付基础结构的集成软件包的引擎。

基于HAS的解决方案

有很多来自不同供应商的HAS解决方案,他们以不同的方式运行,但是都部署了一种分块编码的形式。该编码过程将典型的2–6秒段分成多个块,使用户无需等待该段的其余部分完成编码就可以下载这些块。 这些块如图2(来自Will Law的Akamai博客文章)底部所示。

图2 块编码(来自Akamai)

除了分块编码之外,这些系统还可以整理出清单文件中哪些分块可用,然后这些分块通过HTTP 1.1分块传输编码会被推送到原始服务器。在预期延迟方面,Law在文章中指出:“如果分发是通过开放式Internet进行的(尤其是在最后一英里的移动网络上且吞吐量快速波动的情况下进行),则当前的概念验证显示了更具可持续性的体验质量(QoE)为:延迟时长控制在3s内,其中1.5s-2s在播放器缓冲区。”

除了这些已成为标准的分块编码和HTTP 1.1分块传输编码以外,围绕这些模式以及标准也进行了许多联合开发工作。其中一个开发集群是有关低延迟HLS和hls.js开源播放器的,Mux,JW Player,AWS Elemental和MistServer都对此有所贡献。此外,还有针对低延迟DASH的数字视频广播(DVB)规范,以及DASH行业论坛的低延迟指南。显然,每个规范仅适用于指定的技术。因此您必须同时实现这两个规范,才能为HTTP Live Streaming(HLS)和DASH客户端提供低延迟。

文章来源:https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=134873

原文作者:Jan Ozer

填写常用邮箱,接收社区更新

WebRTC 中文社区由

运营