2019年10月25日
By Jan Ozer 特约编辑
专题文章

对速度的需求:对低延迟流媒体的需求很高

根据Bitmovin的“2019年视频开发者报告”,54%的调查参与者担心延迟. 深入研究数字, 随后的问题显示，近50%的调查参与者计划在未来1-2年内实现低延迟技术, 超过50%的搜索延迟低于5秒，30%的搜索延迟低于1秒(Figure 1).

所有这些都是关于低延迟选项的好兆头，你不觉得吗? 我将首先列出关于低延迟技术需要了解的一些事情, 然后提供一个选择的考虑因素列表.

Figure 1. Bitmovin《百家乐app下载》中的延迟计划和预期

WebRTC

大多数低延迟解决方案使用以下三种技术之一:WebRTC, HTTP自适应流(HAS), 或尚. 根据WebRTC.org FAQ页面, “WebRTC是一个开放的网络框架，可以在浏览器中实现实时通信.” WebRTC达到万维网联盟(W3C)标准组织的候选推荐阶段还没有最终通过. Still, 根据维基百科, Android上所有主要的桌面浏览器都支持WebRTC, iOS, 铬操作系统, 火狐浏览器操作系统, Tizen 3.0和黑莓10. 这意味着它应该在没有下载的情况下运行任何这些平台.

在设计上，WebRTC是为浏览器到浏览器的通信而制定的. 顾名思义, 它是一种为每个观众提供直播流的协议, 点对点或服务器对点. 与此形成鲜明对比的是, 基于ha的解决方案将流分成多个块供客户端下载和播放. 用于大规模流媒体, WebRTC通常是包含编码器的集成包的引擎, player, 以及交付基础设施.

基于webrtc的大规模流媒体解决方案包括凤凰城实时报道, Limelight实时流媒体, and Millicast 来自CoSMo Software和Influxis. 你也可以在工具中使用WebRTC技术，比如 Wowza流媒体引擎或者来自 CoSMO软件，尽管您必须为大规模应用程序创建可扩展的分发系统. 此类技术的延迟时间范围为0.71%的流(实时)5秒到1秒以下(Limelight实时流).

基础的解决方案

有来自多个供应商的多个基于has的解决方案, 尽管它们以不同的方式运作. 它们都部署了一种分块编码形式，将典型的2 - 6秒片段分解成可以下载的块，而无需等待片段的其余部分完成编码. 这些块显示在底部 Figure 2，这是从一个 Akamai博客文章威尔·劳.

Figure 2. 分块编码(来自Akamai)

除了分块编码, 这些系统调整清单文件以通知块的可用性, 通过HTTP 1推送到原始服务器.1 .分块传输编码. 在预期的延迟方面, 劳的后期状态, “如果分销发生在开放的互联网上(特别是在最后一英里移动网络上，快速的吞吐量波动是常态)。, 目前的概念验证显示了更可持续的体验质量(QoE)，玻璃到玻璃的延迟在3秒范围内, 其中1.5s-2s驻留在玩家缓冲区中.”

围绕这些模式以及块编码和HTTP 1之外的一些标准进行了许多联合开发工作.1 .分块传输编码，这早已成为标准. 一个开发集群是围绕低延迟HLS和 hls.Js开源播放器，其中包括来自Mux、JW Player、AWS Elemental和MistServer的贡献. 还有一个数字视频广播(DVB)规范低延迟DASH，有低延迟的指导方针来自DASH行业论坛. 很明显, 每个规格只适用于指定的技术, 因此，您必须同时实现这两个功能，以便为HTTP 在线直播。 (HLS)和DASH客户端提供低延迟.

还有通用媒体应用程序格式(Common Media Application Format, CMAF)块编码的解决方案，允许从一组文件同时传送到HLS和DASH客户端. 基于cmaf的低延迟方法有许多优点，包括对传统播放器的支持. That is, 如果玩家不具备低延迟能力, 它将简单地检索并播放具有正常延迟的片段. 除了, 由于文件格式是基于标准的, 当前的DRM技术, 字幕, 并且广告插入应该正常工作, HTTP段应该是可缓存的，并且对防火墙没有问题.

在很大程度上, 像这样基于标准的方法提供了最大的生态系统灵活性, 允许您选择编码器, packager, CDN, 和普通延迟传输一样.

WebSockets-Based方法

第三种方法通常基于WebSockets之类的实时协议, 它创建并维护一个持久连接在服务器和客户端之间，任何一方都可以使用它来传输数据. 这种连接可用于支持视频传输和其他通信, 如果您的应用程序需要交互性，哪一种更方便.

比如WebRTC的实现, 那些使用WebSockets的通常是作为包括播放器和CDN的服务提供的, 你可以使用任何可以通过RTMP或WebRTC将流传输到服务器的编码器. 例子包括纳米宇宙的纳米流云和Wowza 流云与超低延迟. Wowza声称其解决方案的延迟时间低于3秒, 而纳米宇宙大约需要1秒, 玻璃对玻璃.

Figure 3 显示了我在HP笔记本上通过OBS进行编码的NanoStream云的测试(右窗口), 将流发送到Nanocosmos服务器, 并在H5Live Player中播放. 我拿着一个运行着计时器的iPhone，延迟在1.3范围内. 请注意，iphone本身不支持WebSockets, 因此，纳米宇宙创建了一个独特的低延迟HLS协议，以尽量减少延迟.

Figure 3. Nanocosmos基于websockets的服务显示了sub-1.延时5秒.

延迟目标很大程度上决定了技术的选择

对于直播，有三个因素需要平衡:质量、延迟和健壮性. 你可以在一个活动中得到任意两个，但你不可能得到全部三个. 举个例子, 现成的HLS有大约18秒延迟的原因是因为每个片段是6秒长，苹果默认播放器在开始播放前缓冲了三个片段. 这样做的好处是，在看到任何性能下降之前，观看者将不得不忍受持续的带宽事件. 如果你通过任何方式将延迟减少到3秒, 只需要很短的带宽波动就可以停止流.

从技术选择的角度来看，有三个级别的延迟. 第一个是“无所谓”,，这是一种一对多的展示方式，几乎没有互动，也没有直播. 想想教堂礼拜、市议会会议，甚至是一场偏远的音乐会. 对于这样的应用程序, 将您的片段大小降低到2-4秒, 你可以将延迟时间减少到6-12秒，而且风险很小, 无开发成本, 最小的测试成本. 如果不是绝对需要，低延迟并不总是更好.

第二层是“剧透时间”,或者隔壁看电视的狂热者，在你看到触地得分前30秒就开始大喊(并发推特). Most broadcast channels average about 5–10 seconds of latency; most of the latency estimates for HTTP-based technologies are in the 2–5-second range, 哪一种应该能轻松满足这一要求, 如果不提供流媒体比广播明显的优势.

第三个层次是“实时”,，就像赌博和拍卖等互动应用所要求的那样，在这些应用中，2秒都太长了. 至少在短期内是这样, 基于http的技术可能无法大规模地实现这一点, 所以你会看到一个基于webbrtc或websockets的解决方案.

如果你是一名播音员, 虽然1秒的延迟听起来很棒, 基于webbrtc和websockets的解决方案可能有几个关键的限制. 首先，你需要字幕和广告支持，很少有服务能提供这些. Second, you may need DRM; although several non-HAS services offer content protection, 法医水印可能很快就可用了, 这与DASH使用的基于ccn的drm是完全不同的解决方案, HLS, or CMAF. Third, 与HAS相比，给定比特率下的视频质量可能会受到某些编码限制的影响, 但并非全部, WebRTC编码器.

Finally, 低延迟HAS服务生成的内容既可以向后兼容不支持低延迟的播放器，又可以立即用于DVR或视频点播(VOD)传输. 基于webbrtc和websockets的系统可以在直播后立即提供视频点播, 而传统的自适应比特率(ABR)格式不需要转码. 如果你一个月只播一小时, the cost to convert the stream for HAS-based VOD (if desired) is negligible; if you’re producing 200 channels of TV each hour, 它加起来很快.

HAS市场正在迅速发展

如前所述, 有多个小组致力于开发DASH或基于hls的低延迟解决方案. 苹果公司(Apple)在宣布其低延迟HLS初步规范，一般称为LL-HLS. 该规范与之前的工作在两个关键方面有所不同. First, 它可以传输流块和碎片化的MP4文件, 而DASH只支持后者(技术上), DASH在规范中支持传输流，尽管很少, if ever, used). 如果您使用传输流块将低延迟视频传输到HLS, 你需要一个单独的流，使用碎片化的MP4文件来支持DASH低延迟输出.

下一个页面