本文来自Elecard，作者是Vitaly Suturikhin，担任Elecard集成和技术支持部主管，主题是“低广播延迟及实现协议”。
在构建前端站和CDN的任何招标和竞赛中，低广播延迟已成为强制性要求。以前，此类标准仅适用于体育广播，但是现在，运营商要求广播设备供应商在各个领域提供低延迟：广播新闻，音乐会，表演，访谈，脱口秀，辩论，电子竞技和赌博。
一般而言，延迟是指设备捕获特定视频帧（相机，播放器，编码器等）的时间与在最终用户的显示器上播放该帧的时间之间的时间差。
低延迟不会降低信号传输的质量，这意味着在编码和多路复用时需要最小的缓冲，同时在任何设备的屏幕上保持平滑清晰的图像。另一个前提条件是保证传递：所有丢失的数据包都应该被恢复，并且在开放网络上的传输不会造成任何问题。
越来越多的服务正在迁移到云中，以节省租金，电费和硬件成本。这增加了对具有高RTT（往返时间）的低延迟的要求。当在高清和超高清视频的广播过程中传输高比特率时尤其如此，例如，如果云服务器位于美国，而内容消费者位于欧洲。
本篇文章将分析低延迟广播方面的当前市场报价。作为摘要，提供了以下协议比较表。
注：
1 CDN不支持将其交付给最终用户。支持将内容传输到最后一英里，例如传输到CDN或restreamer。
2 浏览器不支持
3 Safari中不可用
时至今日，所有开源的和有据可查的文档都在迅速普及。可以假设诸如WebRTC和SRT之类的格式在其各自的应用领域中具有长期的未来。在最小延迟方面，这些协议已经超过了HTTP上的自适应广播，同时保持了可靠的传递，具有低冗余并支持加密（SRT中的AES和WebRTC中的DTLS /SRTP）。同样，最近SRT的“小弟”（根据协议的年代，但是就功能和能力而言，并非如此），RIST协议正变得越来越流行，但这是一个单独的主题。同时，新竞争者正将RTMP积极地挤出市场，并且由于缺乏浏览器的本机支持，在不久的将来不太可能广泛使用RTMP。
UDP协议
在现代电视广播中广泛使用，并与术语“低延迟”相关联的第一项技术可能就是通过UDP传输MPEG传输流内容的多播广播。通常，在封闭的空载网络中选择这种格式，在这种网络中，丢失数据包的可能性最小。例如，在前端站（通常在同一服务器机架内）从编码器广播到调制器，或者在带有放大器和转发器的专用铜线或光纤线上进行IPTV广播。该技术被普遍使用，并显示出出色的延迟。在我们的市场中，国内公司使用不超过80毫秒，每秒25帧的以太网实现了与编码，数据传输和解码相关的延迟。帧速率越高，该特性就越小。
图1.实验室中的UDP广播延迟测量
第一张图片显示了来自SDI采集卡的信号。第二张图片说明了经过编码，复用，广播，接收和解码阶段的信号。如图所见，第二个信号在一个单位之后到达（在这种情况下，为1帧，即40毫秒，因为每秒有25帧）。在2017年联合会杯和2018年FIFA世界杯中使用了类似的解决方案，仅将调制器，分布式DVB-C网络和作为最终设备的电视添加到整个架构链中。总等待时间为220–240毫秒。
如果信号通过外部网络怎么办？有许多问题需要克服：干扰，调整，流量拥塞通道，硬件错误，电缆损坏和软件问题。在这种情况下，不仅需要低等待时间，而且还需要重传丢失的数据包。对于UDP，具有冗余功能（带有额外的测试流量或开销）的前向纠错技术可以很好地完成工作。同时，对网络吞吐率的要求不可避免地会增加，因此，延迟和冗余级别也会随之增加，具体取决于丢失数据包的预期百分比。由于FEC而恢复的数据包百分比始终受到限制，并且在通过开放网络传输期间可能会发生很大变化。因此，为了在远距离上可靠地传输大量数据就需要考虑TCP协议。
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）不会直接发送给发件人，以保持低流量。仅在收到数据包链后，才向广播方发送肯定（ACK）或否定（NACK）确认。
根据各种估计，使用完整的编码路径（RTMP编码器→RTMP服务器→RTMP客户端），使用RTMP广播的延迟至少为两秒钟。
CMAF
通用媒体应用格式（CMAF）是由Apple和Microsoft委托的MPEG（运动图像专家组）开发的协议，用于通过HTTP进行自适应广播（自适应比特率根据整个网络的带宽速率的变化而变化）。通常，Apple的HTTP Live Streaming（HLS）使用MPEG传输流，而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秒（每秒25帧）仅发送1个整个段的HTTP POST请求，此后可能会出现100个小片段（每帧一帧）在同一会话中发送。播放器还可能尝试下载不完整的片段，而CDN依次使用分块传输编码提供完成的部分，然后保持连接，直到将新片段添加到要下载的片段中为止。一旦在CDN端形成（开始）整个段，就将完成向播放器的段传输。
图3.标准和分段的CMAF
要在配置文件之间切换，需要缓冲（最少2秒）。考虑到这一点以及潜在的交付问题，该标准的开发者声称潜在延迟少于3秒。同时，这样的杀手级功能包括：通过CDN与成千上万的同时客户端进行扩展，加密（与Common Encryption支持一起），HEVC和WebVTT（字幕）支持，保证的交付以及与不同播放器（Apple / Microsoft）的兼容性。在缺点中，可能会注意到玩家一侧的强制性LL CMAF支持（支持分段的片段和带有内部缓冲区的高级操作）。但是，在不兼容的情况下，播放器仍可以使用CMAF规范内的内容，并且具有HLS或DASH典型的标准延迟时间。
低延迟HLS
苹果在2019年6月发布了低延迟HLS规范。它包含以下组件：
1、生成最小持续时间最短为200毫秒的部分片段（片段MP4或TS），甚至在由此类部分（x部分）组成的整个片段（块）完成之前也可用。过时的部分片段会定期从播放列表中删除。
2、服务器端可以使用HTTP / 2推送模式来发送更新的播放列表以及新的片段（或片段）。但是，在2020年1月的规范的最新修订版中，此建议被排除在外。
3、服务器的责任是保留请求（阻止），直到包含新片段的播放列表版本可用为止。阻止播放列表重新加载消除了轮询。
4、完整的播放列表被发送播放列表中的差异（也称为增量）替代（保存默认播放列表，然后在出现时仅发送增量差异/增量（x跳过），而不是发送完整的播放列表）。
5、服务器宣布即将推出新的部分段（预加载提示）。
6、有关播放列表的信息会并行加载到相邻的配置文件中（信誉报告），以加快切换速度。
图4.LL HLS操作原理
CDN和播放器完全支持此规范的预期延迟不到3秒。HLS具有出色的可扩展性，加密和自适应比特率支持跨平台功能，并且向后兼容，因此在开放网络中的广播中得到了广泛的使用，这在播放器不支持LL HLS时非常有用。
WebRTC
Web Real Time Communications（WebRTC）是Google于2011年开发的一种开放源协议。它在Google Hangout，Slack，BigClueButton和YouTube Live中使用。WebRTC是一组标准，协议和JavaScript编程接口，它们由于对等连接中的DTLS-SRTP而实现了端到端加密。而且，该技术不使用第三方插件或软件，而是通过防火墙而不会损失质量和延迟（例如，在浏览器中的视频会议期间）。广播视频时，通常使用基于UDP的WebRTC实现。
该协议的工作方式如下：主机将连接请求发送到要连接的对等方。在对等方之间建立连接之前，它们将通过第三方（信号服务器）相互通信。然后，每个对等方通过查询“我是谁”来接近STUN服务器。（如何从外面找我？）。同时，有公共的Google STUN服务器（例如stun.l.google.com:19302）。STUN服务器提供了可以访问当前主机的IP和端口的列表。ICE候选者就是从这个名单中形成的。第二面也一样。ICE候选者通过信号服务器进行交换，并且在此阶段建立对等连接，即，形成对等网络。
如果无法建立直接连接，则所谓的TURN服务器充当中继/代理服务器，这也包括在ICE候选列表中。
SCTP（应用程序数据）和SRTP（音频和视频数据）协议负责多路复用，发送，拥塞控制和可靠传递。为了进行“握手”交换和进一步的流量加密，使用了DTLS。
图5.WebRTC协议栈
Opus和VP8用作编解码器。支持的最大分辨率：720p，每秒30帧，比特率最高为2Mbps。
WebRTC技术在安全性方面的缺点是，即使在NAT之后以及使用Tor网络或代理服务器时，也要定义真实IP。由于连接体系结构，WebRTC不适用于大量同时查看的对等体（很难扩展），并且CDN目前很少支持它。最后，WebRTC在编码质量和最大传输数据量方面不如其他协议。
WebRTC在Safari中不可用，在Bowser和Edge中部分不可用。Google声称的延迟时间不到一秒钟。同时，该协议不仅可以用于视频会议，而且可以用于例如文件传输。
SRT
安全可靠传输（SRT）是Haivision在2012年开发的协议。该协议基于UDT（基于UDP的数据传输协议）和ARQ数据包恢复技术进行操作。它支持AES-128和AES-256加密。除了侦听器（服务器）模式外，它还支持呼叫者（客户端）和会合（双方发起连接时）模式，该模式允许通过防火墙和NAT建立连接。SRT中的“握手”过程在现有的安全策略内执行，因此允许外部连接而无需在防火墙中打开永久的外部端口。
SRT在每个数据包内部都包含时间戳，从而允许以等于流编码率的速率播放，而无需进行大的缓冲，同时使抖动（不断变化的数据包到达率）和传入的比特率对齐。与TCP不同，TCP丢失一个数据包可能导致重新发送整个数据包链，从丢失的数据包开始，SRT通过其编号识别特定的数据包，然后仅重新发送该数据包。这对延迟和冗余有积极影响。重新发送数据包的优先级高于标准广播。与标准UDT不同，SRT完全重新设计了用于重新发送数据包的体系结构，以便在数据包丢失时立即做出响应。该技术是选择性重复/拒绝ARQ的变体。值得注意的是，特定丢失的数据包只能重发固定次数。当数据包上的时间超过总延迟的125％时，发送方将跳过该数据包。SRT支持FEC，用户自己决定使用（或同时使用）这两种技术中的哪一种，以在最低的延迟和最高的交付可靠性之间取得平衡。
图6.开放网络中的SRT操作原理
SRT中的数据传输可以是双向的：两个点都可以同时发送数据，并且还可以充当侦听器（侦听器）和发起连接的一方（呼叫者）。当双方都需要建立连接时，可以使用交会模式。该协议具有内部复用机制，该机制允许使用一个UDP端口将一个会话的多个流复用到一个连接中。SRT还适用于快速文件传输，这是UDT中首次引入的。
SRT具有网络拥塞控制机制。发送方每10毫秒接收一次有关RTT（往返时间）的最新数据及其更改，可用缓冲区大小，数据包接收速率和当前链路的近似大小。对连续发送的两个数据包之间的最小增量有限制。如果无法及时交付，则将它们从队列中删除。
开发人员声称，使用SRT可以实现的最小等待时间为120 ms，并具有在封闭网络中短距离传输的最小缓冲区。推荐用于稳定广播的总延迟为3-4RTT。此外，SRT能够比其竞争对手RTMP更好地处理长距离（数千公里）和高比特率（10 Mbps或更高）的传送。
图7.实验室中的SRT广播延迟测量
在上面的示例中，实验室测量的SRT广播延迟为3帧，每秒25帧。也就是说，40 ms* 3 = 120 ms。由此可以得出结论，在SRT广播期间，也可以在UDP广播中实现0.1秒的超低延迟。SRT可扩展性与HLS或DASH / CMAF的级别不同，但是CDN和转发器（重播器）强烈支持SRT，并且还支持通过侦听器模式下的媒体服务器直接向最终客户端广播。
Haivision在2017年披露了SRT库的源代码并创建了SRT联盟，该联盟由350多个成员组成。
附上原文链接：
https://www.elecard.com/page/low_broadcast_latency_and_protocols_for_implementation_thereof
