作者 | 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框的小片段，最终构成适合播放的整个片段），并在整个片段拼合之前发送。
- 分块传输编码：使用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月的最后一次规范修订中，这一建议被排除；
- 服务器的责任是保留请求（阻塞），直到包含新片段的播放列表版本可用。阻断播放列表的重新加载消除了轮询；
- 不发送完整的播放列表，而是发送播放列表的增量（默认的播放列表被保存，然后只在出现时发送增量，而不是发送完整的播放列表）；
- 服务器宣布即将出现的新的部分片段（预加载提示）；
- 关于播放列表的信息在相邻的配置文件中被同时加载，以加快切换。
