一般而言,延迟是指设备捕获特定视频帧(相机,播放器,编码器等)的时间与在最终用户的显示器上播放该帧的时间之间的时间差。
低延迟不会降低信号传输的质量,这意味着在编码和多路复用时需要最小的缓冲,同时在任何设备的屏幕上保持平滑清晰的图像。另一个前提条件是保证传递:所有丢失的数据包都应该被恢复,并且在开放网络上的传输不会造成任何问题。
越来越多的服务正在迁移到云中,以节省租金,电费和硬件成本。这增加了对具有高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时非常有用。WebRTCWeb 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多个成员组成。附上原文链接: