2020年3月16日
By 1月时特约编辑
专题文章

低延迟解决方案买家指南

低延迟是2019年的关键概念之一，在2020年同样重要. 在这份买家指南中, 我将讨论如何确定您需要什么样的延迟，以及确定可用的技术和在选择它们时要考虑的详细因素.

和所有的买家指南一样, 这里列出的产品和公司是有代表性的, 不详尽的, 所以如果你是潜在的买家, 以此为起点，进行你自己的研究. 如果你是一个没有被提及的供应商, 请随意在本文末尾的评论中添加您的产品.

开始之前, 记住直播流的延迟越低是很有用的, 流对带宽中断的弹性越小. 例如, 使用默认设置, HTTP实时流(HLS)流将通过15秒以上的中断带宽播放, 如果在这一点上恢复, 观众可能永远不会知道有问题. 相比之下，低延迟流在中断后几乎立即停止播放. 在这方面, 低延迟启动时间的好处总是需要与播放停止的负面影响相平衡. 如果您不是绝对需要低延迟，那么可能不值得牺牲弹性来获得它.

我需要低延迟吗?

从技术选择的角度来看，有三个级别的延迟. 第一个是“无所谓”,“这是一对多的展示，几乎没有互动——想想教堂服务或市议会会议，甚至是一场远程音乐会. 对于这样的应用程序, 将您的片段大小降低到2-4秒, 你可以将延迟时间减少到6到12秒，而且风险很小, 无开发成本, 最小的测试成本.

第二层是“剧透时间”,或者是在隔壁看电视的狂热球迷，在你看到进球前30秒就开始大喊(或者发推特). Most broadcast channels average about 5–6 seconds of latency; if you're a streaming service competing with broadcast streams, 您需要一种真正的低延迟技术才能使您的延迟达到相同的范围.

第三级延迟是“实时”,“这是赌博等交互式应用程序所要求的, 拍卖, 和游戏, 2秒都太长了. 如果您的应用程序是其中之一或类似的, 减小分段大小并不能解决问题, 而且你肯定需要一种低延迟技术.

可用的技术有哪些?

大多数低延迟解决方案使用以下三种技术之一:, HTTP自适应流, 或尚. 顾名思义, WebRTC是一个为每个观众提供直播流的协议, 点对点或服务器对点. 它是为浏览器到浏览器的通信而设计的，Android上所有主要的桌面浏览器都支持它, iOS, 铬操作系统, 火狐浏览器操作系统, Tizen 3.0, 和黑莓10, 因此，基于webbrtc的低延迟解决方案应该可以在任何这些平台上无需下载即可运行.

WebRTC通常是包含编码器的集成包的引擎, 球员, 以及交付基础设施. 基于webrtc的解决方案的例子有凤凰, 聚光灯下实时流，以及 Millicast 来自CoSMo软件和Influxis (图1). 您还可以访问WebRTC技术，在工具中构建您自己的解决方案 Wowza流媒体引擎, CoSMo软件, Red5 Pro服务器. 此类技术的延迟时间包括在500毫秒内交付给所有查看器的全局保证(凤凰)。, 在500毫秒内交货(Red5 Pro), 不到1秒(聚光灯下 Networks). Time to First Frame (TTFF) is also an important metric where technologies such as 凤凰 deliver TTFF of < 500ms for 71% of viewers 和 < 816ms second for 90% of viewers. 如果您需要低于2秒的延迟，Web-RTC是您应该考虑的选项.

WebRTC低延迟流

图1. 用于亚秒级延迟的大规模直播的基于Millicast webrtc的系统概述

HTTP自适应流有两个主要标准——hls和dash，并且有一个统一的容器格式, 通用媒体申请格式(CMAF). 一旦苹果宣布其低延迟HLS解决方案, 它立即取代了一些基层的努力，成为通过HLS传输低延迟流的首选技术. 尽管该规范仍在制定过程中, 它已经得到了像Wowza和WMS-Panel这样的技术供应商的支持，他们的产品是Nimble Streamer.

低延迟DASH有一个DVB标准, 该规范将于2020年初由DASH行业论坛提出. 根据这些规范, 编码器和播放器开发人员以及内容交付网络已经工作了好几年，以确保互操作性，以便所有DASH/CMAF低延迟应用程序都能开始运行. 举个例子，谐波和 Akamai 早在2017年NAB和IBC展会上，他们就共同展示了低延迟CMAF, 显示实时OTT传输，延迟低于5秒. 从那时起, 谐波将低延迟DASH功能集成到其基于家电的产品(Packager XOS和Electra XOS)和SaaS解决方案(VOS Cluster和VOS360)中。. 许多其他编码器和播放器供应商也做了同样的事情.

所有基于HLS/DASH/ cmaf的低延迟系统都以相同的基本方式工作，如下所示图2. 这是, 而不是等到一个完整的片段被编码, 这通常需要6到10秒(图2的顶部), 编码器会创建更短的数据块，这些数据块在完成后立即传输到CDN(图2底部)。.

谐波低延迟

图2. HLS/CMAF/DASH低延迟(来自谐波白皮书，标题为“DASH CMAF LLC将在实现低延迟视频流方面发挥关键作用")

举个例子，如果你的编码器产生了6秒的片段, 至少会有6秒的延迟. 如果你的编码器每200毫秒输出一个数据块, 然而, 播放器被配置为立即开始播放, 延迟应该很大, 少得多. One key benefit of this schema is backward compatibility; since segments are still being created, 与低延迟模式不兼容的玩家应该仍然能够播放片段, 尽管延迟要长得多. 这些片段也可以立即用于视频点播(VOD)演示.

WebSockets是一种实时协议，它在服务器和客户端之间创建并维护持久连接，任何一方都可以使用它来传输数据. 如果您的应用程序需要交互性，这种连接可用于支持视频传送和其他方便的通信. 比如WebRTC的实现, 使用WebSockets的服务通常作为包含播放器和CDN的服务提供, 你可以使用任何可以通过实时消息协议(RTMP)或WebRTC传输流到服务器的编码器. 例子包括 nanocosmos纳米流云和超低延迟的Wowza流云. Wowza声称其解决方案的延迟时间低于3秒, 而纳米宇宙只需要1秒, 玻璃对玻璃.

第四类产品最好称为“其他”，它们使用不同的技术来提供低延迟. 这个类别包括西奥科技高效流协议(HESP), 一个专有的HTTP自适应流协议，根据该公司, 提供低于100毫秒的延迟，同时与其他低延迟技术相比，带宽减少了约10%. HESP使用标准编码器和cdn，但需要在打包器和播放器中提供自定义支持(参见图3 在下一页). 有关HESP的更多信息，可从以下网址下载白皮书 go2sm.com/theohesp.

西奥HESP

图3. 西奥科技的高效流协议(HESP)是一种与大多数cdn兼容的专有协议.

建造还是购买?

如果你自己实现了这项技术, 在选择一项技术之前，请务必回答以下所有问题. 如果您正在选择服务提供商，请使用它们来比较不同的选项.

你是在选择标准还是合作伙伴?—我在本文前面概述了实现低延迟的不同技术, 但是服务提供者之间的实现是不同的. 在选择服务提供商时, 确定它是否能够满足您的技术和业务目标比确定它实现了哪种技术更为重要.

它能扩大规模吗?成本是多少?—基于http的技术的优点之一是，它们使用大多数cdn以标准定价进行扩展. 与此形成鲜明对比的是, 大多数基于webbrtc和基于websocket的技术需要由服务提供者实现的专用交付基础设施. 由于这个原因，非基于http的服务交付成本可能比HLS/DASH/CMAF更高. 在比较服务提供商时, 确定活动的全部成本, 包括入口, 代码转换, 带宽, VOD文件创建, 一次性或按事件配置, 诸如此类.

是否存在与实现相关的问题?—询问以下与实施和使用该技术相关的问题:

在与用户规模和地理分布相关的情况下，可实现的延迟是多少?
有质量限制吗? 某些技术可能限于某些最大分辨率或H.264年资料.
数据包会通过防火墙吗?
基于HTTP的系统使用对防火墙友好的HTTP协议. 其他使用用户数据报协议(UDP)，这可能不是. 如果是UDP，是否有任何反向通道传送到被阻塞的观众?
支持哪些平台? 大概是电脑和移动设备, 但是机顶盒呢, 软件狗, 奥特设备, 和智能电视?
它能规模化吗?? 系统是否能够满足你的目标观众数量? CDN基础设施是私有的吗, 如果是这样的话, 它能否传递给所有相关市场的所有相关观众? 扩展的预期成本是什么?
玩家呢?? 你可以使用自己的播放器，还是必须使用系统的播放器? 如果是你自己的，需要做什么改变，需要花多少钱?
移动播放需要什么? 流是在浏览器中播放，还是需要一个应用程序? 如果需要(或需要)一个应用程序，是否有软件开发工具包(sdk)可用?
系统可以使用哪种编码器? 大多数人应该使用任何可以支持RTMP连接到云转码器的编码器, 但检查一下是否需要其他协议.
内容是否可以被重新用于视频点播 需要重新编码? 这不是什么大问题，因为每小时的视频转码到合理的编码阶梯的成本约为20美元, 但对于频繁的广播来说，它可能会很昂贵.
有哪些冗余选项，成本是多少? 用于关键任务广播, 如果任何系统组件在事件期间发生故障，您将想知道如何复制编码/广播工作流. 是否支持这种冗余，成本是多少?

有哪些特性可用，在多大的规模上可用?—不同的供应商将提供各种各样的功能, 其中可能包括也可能不包括以下内容:

自适应比特率(ABR)流有多少流，是否有相关的比特率或分辨率限制?
DVR功能- - - - - -观众可以停止和重新开始播放而不丢失任何内容吗?
视频同步。系统能否将所有观众同步到流中的同一点? 流可以在位置和设备上漂移, 如果没有这种能力, 某些连接上的用户在拍卖或赌博方面可能具有优势.
内容保护,如果你是一个优质内容制作人，你可能需要真正的DRM. 其他人可以通过身份验证或其他类似的技术.
字幕-在某些广播节目中，字幕是法律要求的，但通常对所有人都是有益的.
广告或其他货币化技术/服务提供商是否支持这一点?

在一般情况下, 如果你是一个流媒体商店，寻求在5到6秒范围内达到或超过广播时间, 基于标准的HTTP技术可能是您的最佳选择, 因为它将最接近于支持您当前使用的相同功能集, 比如内容保护, 标题, 和货币化. 如果您的应用程序需要更低的延迟, 您可能需要基于webbrtc或基于websockets的解决方案或专有的HTTP技术. 无论哪种情况, 询问前面列出的问题应该有助于您确定最能满足您需求的技术和/或服务提供商.