作者 | Vitaly Suturikhin

翻译 | 徐鋆

低广播延迟已经成为任何关于建设源端站和CDN的招标和竞争中的必要特性。以前这种标准只适用于体育广播，但现在运营商要求每个领域的广播设备供应商提供低延迟，比如：广播新闻、音乐会、表演、采访、谈话节目、辩论、电子竞技等等。

什么是低延迟？

一般来说，延迟是指某一特定视频帧被设备（摄像机、播放机、编码器等）捕获的时间与该帧在终端用户显示器上播放的时间之间的时间差。

什么是低延迟视频流？

低延迟不应降低信号传输的质量，这意味着在编码和复用时使用最小的缓冲，同时在任何设备的屏幕上需要保持流畅和清晰的画面。另一个先决条件是保证传输：所有丢失的数据包都应该被恢复，以及在开放网络上的传输不应该引起任何问题。

越来越多的服务正在迁移到云端，以节省租用的场地、电力和硬件成本。这增加了对高RTT（Round Trip Time, 往返时间）下低延迟的要求。在播放高清和超清视频时，传输高比特率的情况尤其如此。比如如果云服务器位于美国，而内容消费者在欧洲的情况。

在这篇文章中，我们将分析目前市场上在低延迟广播方面提供的方案。

UDP

在现代电视广播中被广泛使用并与 "低延迟 "一词相关的第一项技术可能是通过UDP的MPEG TS流内容进行的组播。通常情况下，这种格式适合封闭的无负载网络，在这种情况下，丢包率是最小的。例如，从编码器到源端站调制器的广播（通常在同一个服务器机架内），或通过带有放大器和中继器的专用铜线或光纤线路的IPTV广播。

这种技术被普遍使用，并表现出良好的延迟特性。市场上的公司使用以太网实现的与编码、数据传输和解码相关的延迟，在每秒25帧的情况下不超过80ms。在更高的帧率下，这一延迟特性甚至更低。

图1. UDP广播延迟测量

图1上半部分显示了来自SDI采集卡的信号，下半部分展示经过编码、多路复用、广播、接收和解码阶段的信号。如图所示，第二个信号晚一帧到达（在这种情况下，因为信号是25fps，1帧是40毫秒）。在Confederations Cup 2017和FIFA World Cup 2018上使用了类似的解决方案，只有一个调制器、一个分布式DVB-C网络和一个作为终端设备的电视加入到架构链中，最终总延迟为220-240毫秒。

如果信号通过一个外部网络怎么办？有各种问题需要克服：干扰、整形、流量阻塞通道、硬件错误、电缆损坏和软件层面的问题。在这种情况下，不仅需要低延迟，还需要对丢失的数据包进行重传。

在UDP的情况下，带有冗余的前向纠错技术FEC（有额外的测试流量或开销）做得很好。同时，对网络吞吐率的要求随之增加，因此，延迟和冗余也会增加，这取决于预期丢失数据包的百分比。由于FEC能恢复的数据包的百分比总是有限的，而且在开放网络的传输过程中可能有很大的变化。因此，为了在长距离上可靠地传输大量数据，有必要在其中增加较多的多余流量。

TCP

接下来让我们看看基于TCP协议的技术（可靠交付）。如果收到的数据包的校验和不符合预期值（在TCP数据包头中设置），那么这个数据包就会被重新发送。而如果客户端和服务器端不支持选择性确认（SACK）规范，那么整个TCP数据包链（从丢失的数据包到一个以较低速率接收的数据包）就会被重新发送。

以前，当涉及到直播的低延迟时，通常会避免使用TCP协议，因为错误检查、数据包重发、三次握手、"慢启动 "和防止信道拥塞（TCP慢启动和拥塞避免阶段），延迟会增加。同时，即使信道很宽，传输开始前的延迟也可能达到RTT的五倍，而吞吐量的增加对延迟的影响非常小。

使用TCP广播的应用程序对协议本身没有任何控制（它的超时、重新广播的窗口大小），因为TCP传输是作为一个单一的连续流实现的，在错误发生之前，应用程序可能会无限期地 "冻结"。而且高层协议没有灵活配置TCP，以尽量减少广播问题的能力。

同时，有些协议即使在开放的网络和长距离的情况下也能通过UDP有效工作。

下面让我们来考虑和比较各种协议的实现。在基于TCP的协议和数据传输格式中，将会涉及RTMP、HLS和CMAF，而在基于UDP的协议和数据传输格式中，将会涉及WebRTC和SRT。

RTMP

RTMP是Macromedia公司的专有协议（现在归Adobe公司所有），在基于Flash的应用程序流行时非常流行。它有几个品种，支持TLS/SSL加密，甚至还有基于UDP的变种，即RTFMP（实时媒体流协议，用于点对点连接）。RTMP将数据流分割成片段，其大小可以动态变化。在通道内，与音频和视频有关的数据包可以交错和复用。

图2. RTMP广播实现用例

RTMP会构建几个虚拟通道，在这些通道上传输音频、视频、元数据等。大多数CDN不再支持RTMP作为向终端客户分配流量的协议。Nginx有自己的RTMP模块，支持普通的RTMP协议，它运行在TCP之上，使用默认的1935端口。Nginx可以作为一个RTMP服务器，分发它从RTMP流媒体接收的内容。RTMP仍然是向CDN交付流量的流行协议，但在未来，流量将使用其他协议进行传输。

目前，Flash技术已经过时，且不受支持：浏览器或是减少对它的支持，或是完全禁止使用。RTMP不支持HTML5，在浏览器中也难以使用（播放需要通过Adobe Flash插件）。为了绕过防火墙，他们使用RTMPT（封装到HTTP请求中，并使用标准的80/443而不是1935端口），但这大大影响了延迟和冗余（根据各种估计，RTT和整体延迟增加30%）。尽管如此，RTMP仍然很流行，例如，在YouTube上的广播或在社交媒体上（Facebook的RTMPS）。

RTMP的主要缺点是缺乏对HEVC/VP9/AV1编码器的支持，以及只允许两个音轨的限制。此外，RTMP在数据包头中不包含时间戳。RTMP只包含根据帧率计算的标签，因此解码器并不确切知道何时解码这个流。这就需要一个接收组件均匀地生成用于解码的样本，因此缓冲区必须按数据包抖动的大小来增加。

RTMP的另一个问题是重新发送丢失的TCP数据包，这在前文已经描述过。为了保持较低的回传流量，确认收到（ACK）并不直接到发件端。只有在收到数据包链后，才会向广播方发送ACKs或NACKs的确认信息。

根据各种估计，使用RTMP进行广播，通过完整的编码路径（RTMP编码器→RTMP服务器→RTMP客户端）的延迟至少是两秒。

CMAF

CMAF（Common Media Application Format，通用媒体应用格式）是由苹果和微软邀请MPEG开发的协议，用于在HTTP上进行自适应广播（具有根据整个网络带宽速率变化而变化的自适应比特率）。通常情况下，苹果公司的HTTP直播（HLS）使用MPEG TS流，而MPEG DASH使用片段式的MP4。2017年7月，CMAF标准被发布。在CMAF中，片段式的MP4片段（ISOBMFF）通过HTTP传输，同一内容有两个不同的播放列表，用于特定的播放器：iOS（HLS）或Android/Microsoft（MPEG DASH）。

默认情况下，CMAF（像HLS和MPEG DASH）不是为低延迟广播设计的。但行业对低延迟的和兴趣在不断增加，所以一些厂商提供了标准的扩展，例如低延迟CMAF。这种扩展假定广播方和接收方都支持两种方法：

    分块编码：将片段分成子片段（带有moof mdat mp4框的小片段，最终构成适合播放的整个片段），并在整个片段拼合之前发送。
  1. 分块传输编码：使用HTTP 1.1发送子片段到CDN（源）：每4秒只发送1次整个片段的HTTP POST请求（每秒25帧），此后在同一会话中可以发送100个小片段（每个片段有一帧）。播放器也可以尝试下载不完整的片段，而CDN则使用分块传输编码提供完成的部分，然后保持连接，直到新的片段被添加到正在下载的片段中。一旦整个片段在CDN一侧形成，向播放器传输的片段就会完成。

图3. 标准的分块CMAF

如果要在配置文件之间切换，则需要缓冲（至少2秒）。鉴于这一点以及有可能的分发问题，该标准的开发者声称延迟小于3秒。同时，诸如通过CDN与成千上万的同时客户端进行扩展、加密（连同通用加密支持）、HEVC和WebVTT（字幕）支持、保证交付和与不同播放器（苹果/微软）的兼容性等重要特征都得到了保留。在缺点方面，人们可能会注意到播放器方面强制性的LL CMAF支持（支持碎片化的片段和内部缓冲区的高级操作）。在不兼容的情况下，播放器仍然可以使用CMAF规范内的内容，具有HLS或DASH的标准延迟。

LL-HLS

2019年6月，苹果发布了低延迟HLS的规范。

它由以下部分组成：

    生成部分片段（片段式的MP4或TS），最小持续时间为200毫秒，甚至在由这些部分组成的整个片段完成之前就可以使用。过时的部分片段会定期从播放列表中删除； 服务器端可以使用HTTP/2推送模式，将更新的播放列表与新的片段一起发送。在2020年1月的一次规范修订中，这一建议被排除； 服务器的责任是保留请求（阻塞），直到包含新片段的播放列表版本可用。阻断播放列表的重新加载消除了轮询； 不发送完整的播放列表，而是发送播放列表的增量（默认的播放列表被保存，然后只在出现时发送增量，而不是发送完整的播放列表）；
  1. 服务器宣布即将出现的新的部分片段（预加载提示）；
  2. 关于播放列表的信息在相邻的配置文件中被同时加载，以加快切换。

图4. LL HLS的运行原理

在CDN和播放器完全支持该规范的情况下，预计延迟时间小于3秒。HLS由于其出色的可扩展性、加密和自适应比特率支持跨平台功能以及向后兼容，非常广泛地用于开放网络的广播，如果播放器不支持LL HLS，这一点很有用。

WebRTC

WebRTC（网络实时通信）是由谷歌在2011年开发的一个开源协议。它被用于Google Hangout、Slack、BigClueButton和YouTube Live。WebRTC是一套标准、协议和Javascript编程接口，并且使用DTLS-SRTP在点对点连接中实现了端到端的加密。此外，该技术不使用第三方插件或软件，可以在不损失质量和延迟的情况下通过防火墙（例如，在浏览器的视频会议期间）。在播放视频时，通常使用基于UDP的WebRTC实现。

该协议的工作原理如下：一台主机向要连接的对等客户发送一个连接请求。在对等客户之间的连接建立之前，它们通过第三方信号服务器相互通信。每个对等客户都向STUN服务器询问 "我是谁？" (如何从外面找到我？)。

同时，有公共的谷歌STUN服务器（例如stun.l.google.com:19302）。STUN服务器提供一个IP和端口的列表，通过这个列表可以到达当前的主机。ICE候选者是由这个列表形成的。第二个客户也进行相同的操作。ICE候选者通过信号服务器进行交换，正是在这个阶段建立了点对点的连接，即形成了一个点对点的网络。

如果不能建立直接连接，那么一个所谓的TURN服务器就充当中继/代理服务器，它也被列入ICE候选名单。

SCTP（应用数据）和SRTP（音频和视频数据）协议负责多路复用、发送、拥塞控制和可靠交付。对于“握手”交换和进一步的流量加密，使用了DTLS。

图5. WebRTC协议栈

使用Opus和VP8作为编解码器。最大支持的分辨率为720p，30fps，比特率最高到2Mbps。

WebRTC技术在安全方面的一个缺点是，即使在NAT后面和使用Tor网络或代理服务器时，也要定义一个真实的IP。由于连接结构的原因，WebRTC不适合大量同时观看的对等客户（难以扩展），而且目前CDN也很少支持它。WebRTC在编码质量和最大传输数据量方面不如其他协议。

WebRTC在Safari中不可用，在Bowser和Edge中部分不可用。谷歌声称其延迟不到一秒。同时，该协议不仅可用于视频会议，也可用于文件传输等应用。

SRT

SRT（Secure Reliable Transport，安全可靠传输）是由Haivision在2012年开发的一个协议。该协议在UDT（基于UDP的数据传输协议）和ARQ数据包恢复技术的基础上运行。它支持AES-128和AES-256加密。除了监听（服务器）模式，它还支持呼叫（客户端）和会合（当双方启动连接时）模式，这使得连接可以通过防火墙和NAT建立。SRT的“握手”过程是在现有的安全策略中进行的，因此允许外部连接，而不需要在防火墙中打开永久的外部端口。

SRT在每个数据包内都包含时间戳，这就允许以与流编码速率相等的速度播放，而不需要大量的缓冲，同时使抖动（不断变化的数据包到达率）和传入的比特率保持一致。与TCP中一个数据包的丢失可能会导致重新发送整个数据包链不同，从丢失的数据包开始，SRT通过其编号识别一个特定的数据包，并只重新发送这个数据包。这对延迟和冗余有积极作用。

重发的数据包比标准广播的优先级更高。与标准的UDT不同，SRT完全重新设计了重发数据包的架构，一旦数据包丢失，就立即做出反应。这项技术是选择性重复/拒绝ARQ的一个变种。值得注意的是，一个特定的丢失的数据包可能只被重新发送固定的次数。当数据包上的时间超过总时延的125%时，发送方会跳过该数据包。SRT支持FEC，用户自己决定使用这两种技术中的哪一种（或同时使用两种），以平衡最低延迟和最高传输可靠性。

图6. SRT在开放网络上的运行原理

SRT中的数据传输可以是双向的：两点都可以同时发送数据，也可以同时作为监听和发起连接的一方。当双方都需要建立连接时，可以使用会合模式。该协议有一个内部复用机制，允许将一个会话的几个流复用到使用一个UDP端口的一个连接中。SRT也适用于快速文件传输，这个应用在UDT中首次引入。

SRT有一个网络拥堵控制机制。每隔10毫秒，发送方就会收到关于RTT及其变化的最新数据、可用的缓冲区大小、数据包接收率和当前链接的大致大小。SRT对连续发送的两个数据包之间的最小延时有限制。如果它们不能及时送达，就会从队列中删除。

开发者声称，在封闭网络中短距离传输中设置缓冲区为最小，使用SRT可能实现的最小延迟是120毫秒。建议稳定广播的总延迟是3-4个RTT。此外，SRT在长距离（几千公里）和高比特率（10Mbps及以上）的传输方面比其竞争对手RTMP处理得更好。

图7. SRT广播延迟测试

在上面的例子中，实验室测量的SRT广播的延迟在25fps的条件下是3帧。也就是40ms*3=120ms。由此我们可以得出结论，在UDP广播中可以达到的0.1秒的超低延迟，在SRT广播中也是可以实现的。SRT的可扩展性与HLS或DASH/CMAF不在同一水平上，但SRT得到CDN和转发者(restreamer)的大力支持，也支持通过媒体服务器以监听模式直接广播给终端客户。

2017年，Haivision披露了SRT库的源代码，并创建了SRT联盟，该联盟包括350多个成员。

总结

作为总结，下表展示了各个协议的对比：

    不支持由CDN向终端用户传输。支持内容流向一英里，例如，流向CDN或restreamer。 在浏览器中不支持 Safari中不支持

目前，所有开源的、文档全面的东西都在迅速流行起来。可以认为，像WebRTC和SRT这样的格式在各自的应用范围内有一个长远的未来。在最低延迟方面，这些协议已经超过了HTTP上的自适应广播，同时保持可靠的传输，具有低冗余度，并支持加密（SRT的AES和WebRTC的DTLS/SRTP）。

最近SRT的“小兄弟”（根据协议的产生时间，而不是在功能和能力方面）RIST协议，正在获得普及，但这是另一个话题了。同时，RTMP正在积极地被新的竞争者挤出市场，而且由于浏览器缺乏原生支持，它难以很快被广泛使用。

原文标题 | Low Latency Streaming Protocols SRT, WebRTC, LL-HLS, UDP, TCP, RTMP Explained

原文链接 | https://ottverse.com/low-latency-streaming-srt-webrtc-ll-hls-udp-tcp-rtmp/0

本文转自公众号：

媒矿工厂 第一时间发布最新最有料的媒体技术资讯。倡导极客、创客精神，促进学术界、工业界以及开源社区共享信息、交流干货、发掘价值。 710篇原创内容公众号

扫描图中二维码或点击阅读原文

了解大会更多信息