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

低延迟解决方案买家指南

低延迟是2019年的关键概念之一，在2020年同样重要. 在这份买家指南中, I'll discuss how to determine what kind of latency you need as well as identify the available technologies 和 detail factors to consider when choosing among them.

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

开始之前, 记住直播流的延迟越低是很有用的, 流对带宽中断的弹性越小. 例如, 使用默认设置, HTTP实时流(HLS)流将通过15秒以上的中断带宽播放, 如果在这一点上恢复, 观众可能永远不会知道有问题. 相比之下，低延迟流在中断后几乎立即停止播放. 在这方面, the benefit of low-latency startup time always needs to be balanced against the negative of playback stoppages. 如果您不是绝对需要低延迟，那么可能不值得牺牲弹性来获得它.

我需要低延迟吗?

从技术选择的角度来看，有三个级别的延迟. 第一个是“无所谓”," which is a one-to-many presentation with little interaction—think a church service or a city council meeting or even a remote concert. 对于这样的应用程序, 将您的片段大小降低到2-4秒, 你可以将延迟时间减少到6到12秒，而且风险很小, 无开发成本, 最小的测试成本.

第二层是“剧透时间”," or the proverbial enthusiast who is watching TV next door 和 starts shouting (和 tweeting) about a goal 30 seconds before you see it. Most broadcast channels average about 5–6 seconds of latency; if you're a streaming service competing with broadcast streams, 您需要一种真正的低延迟技术才能使您的延迟达到相同的范围.

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

可用的技术有哪些?

大多数低延迟解决方案使用以下三种技术之一:, HTTP自适应流, 或尚. 顾名思义, WebRTC是一个为每个观众提供直播流的协议, 点对点或服务器对点. It was formulated for browser-to-browser communications 和 is supported by all major desktop browsers on Android, iOS, 铬操作系统, 火狐浏览器操作系统, Tizen 3.0, 和黑莓10, 因此，基于webbrtc的低延迟解决方案应该可以在任何这些平台上无需下载即可运行.

WebRTC通常是包含编码器的集成包的引擎, 球员, 以及交付基础设施. 基于webrtc的解决方案的例子有凤凰, 聚光灯下实时流，以及 Millicast 来自CoSMo软件和Influxis (图1). 您还可以访问WebRTC技术，在工具中构建您自己的解决方案 Wowza流媒体引擎, CoSMo软件, Red5 Pro服务器. Latency times for technologies in this class include a global guarantee for delivery to all viewers in under 500 milliseconds (凤凰), 在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. System overview of the Millicast WebRTC-based system for large-scale live streaming with sub-second latency

There are two major st和ards for HTTP自适应流—HLS 和 DASH—和 there's a unifying container format, 通用媒体申请格式(CMAF). 一旦苹果宣布其低延迟HLS解决方案, it instantly displaced several grassroots efforts 和 became the technology of choice for delivering low-latency streams via HLS. 尽管该规范仍在制定过程中, it's already supported by technology providers like Wowza 和 WMSPanel with its Nimble Streamer product.

低延迟DASH有一个DVB标准, 该规范将于2020年初由DASH行业论坛提出. 根据这些规范, encoder 和球员 developers 和 content delivery networks have been working for several years to ensure interoperability so that all DASH/CMAF low-latency applications should hit the ground running. 举个例子，谐波和 Akamai 早在2017年NAB和IBC展会上，他们就共同展示了低延迟CMAF, 显示实时OTT传输，延迟低于5秒. 从那时起, 谐波 has integrated low-latency DASH functionality into its appliance-based products (Packager XOS 和 Electra XOS) 和 SaaS solutions (VOS Cluster 和 VOS360). 许多其他编码器和播放器供应商也做了同样的事情.

所有基于HLS/DASH/ cmaf的低延迟系统都以相同的基本方式工作，如下所示图2. 这是, 而不是等到一个完整的片段被编码, 这通常需要6到10秒(图2的顶部), the encoder creates much shorter chunks that are transferred to the CDN as soon as they are complete (bottom of 图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, 球员s that are not compatible with the low-latency schema should still be able to play the segments, 尽管延迟要长得多. These segments are also instantly available for video-on-dem和 (VOD) presentations from the live stream.

WebSockets is a real-time protocol that creates 和 maintains a persistent connection between a server 和 client that either party can use to transmit data. This connection can be used to support both video delivery 和 other communications that are convenient if your application needs interactivity. 比如WebRTC的实现, 使用WebSockets的服务通常作为包含播放器和CDN的服务提供, you can use any encoder that can transport streams to the server via Real-Time Messaging Protocol (RTMP) or WebRTC. 例子包括 nanocosmos纳米流云和超低延迟的Wowza流云. Wowza声称其解决方案的延迟时间低于3秒, 而纳米宇宙只需要1秒, 玻璃对玻璃.

There is a fourth category of products best called "other" that use different technologies to provide low latency. 这个类别包括西奥科技高效流协议(HESP), 一个专有的HTTP自适应流协议，根据该公司, delivers sub-100-millisecond latency while reducing 带宽 by about 10% as compared to other low-latency technologies. HESP uses st和ard encoders 和 CDNs but requires custom support in the packager 和球员 (see 图3 在下一页). 有关HESP的更多信息，可从以下网址下载白皮书 go2sm.com/theohesp.

西奥HESP

图3. 西奥科技高效流协议(HESP) is a proprietary protocol compatible with most CDNs.

建造还是购买?

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

你是在选择标准还是合作伙伴?—我在本文前面概述了实现低延迟的不同技术, 但是服务提供者之间的实现是不同的. 在选择服务提供商时, it's more important to determine if it can meet your technological 和 business goals than which technology it implements.

它能扩大规模吗?成本是多少?—One of the advantages of HTTP-based technologies is that they scale at st和ard pricing using most CDNs. 与此形成鲜明对比的是, most WebRTC-based 和 WebSocket-based technologies require a dedicated delivery infrastructure implemented by the service provider. 由于这个原因，非基于http的服务交付成本可能比HLS/DASH/CMAF更高. 在比较服务提供商时, 确定活动的全部成本, 包括入口, 代码转换, 带宽, VOD文件创建, 一次性或按事件配置, 诸如此类.

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

What's the latency achievable at a scale relevant to your audience size 和 geographic distribution?
有质量限制吗? 某些技术可能限于某些最大分辨率或H.264年资料.
数据包会通过防火墙吗?
基于HTTP的系统使用对防火墙友好的HTTP协议. 其他使用用户数据报协议(UDP)，这可能不是. 如果是UDP，是否有任何反向通道传送到被阻塞的观众?
支持哪些平台? 大概是电脑和移动设备, 但是机顶盒呢, 软件狗, 奥特设备, 和智能电视?
它能规模化吗?? 系统是否能够满足你的目标观众数量? CDN基础设施是私有的吗, 如果是这样的话, 它能否传递给所有相关市场的所有相关观众? 扩展的预期成本是什么?
玩家呢?? 你可以使用自己的播放器，还是必须使用系统的播放器? 如果是你自己的，需要做什么改变，需要花多少钱?
移动播放需要什么? 流是在浏览器中播放，还是需要一个应用程序? 如果需要(或需要)一个应用程序，是否有软件开发工具包(sdk)可用?
系统可以使用哪种编码器? 大多数人应该使用任何可以支持RTMP连接到云转码器的编码器, 但检查一下是否需要其他协议.
内容是否可以被重新用于视频点播 需要重新编码? This isn't a huge deal since it costs about $20 per hour of video to transcode to a reasonable encoding ladder, 但对于频繁的广播来说，它可能会很昂贵.
有哪些冗余选项，成本是多少? 用于关键任务广播, you'll want to know how to duplicate the encoding/broadcast workflow should any system component go down during the event. 是否支持这种冗余，成本是多少?

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

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

在一般情况下, 如果你是一个流媒体商店，寻求在5到6秒范围内达到或超过广播时间, 基于标准的HTTP技术可能是您的最佳选择, 因为它将最接近于支持您当前使用的相同功能集, 比如内容保护, 标题, 和货币化. 如果您的应用程序需要更低的延迟, you'll probably need a WebRTC-based 或尚-based solution or a proprietary HTTP technology. 无论哪种情况, asking the previously listed questions should help you identify the technology 和/or service provider that best meets your needs.