公网传输技术之SRT协议解析(上)

LiveVideoStack 2022年3月11日

作者:张博力

编辑:Alex

▼扫描图中二维码了解音视频技术大会更多信息▼

图片

摘  要: SRT协议(即安全可靠传输协议)是一个新兴的网络传输协议,适用于实时音视频传输。本文将从SRT协议的原理分析入手,尝试定义出一个衡量SRT链路可靠性高低的指标:链路安全冗余量(Secure-Margin),并详细介绍如何依照这个指标来部署一个可靠的SRT传输链路,并分析在不同的直播场景中的参数调整策略。

引  言

音视频的信号传输技术作为广电领域的重点技术之一,保障了传输的安全和质量。传统的信号传输手段也许可以用三句话来概括:天上一颗星,地下一根缆,中间面对面的微波。

“天上一颗星” 指的是卫星传输,优点是灵活安全可靠并且对于直播现场的条件没有特殊要求,但其设备投资和费用非常昂贵。“地下一根缆” 指的是光纤传输,优点是安全可靠并且延时极低,但它很依赖光缆链路的基础建设,灵活性较差。“中间面对面的微波” 最初指的是通视条件下的定向微波,后来又发展出长距离的U波段“大微波”和短距离的2G波段“小微波”。随着5G和互联网技术的飞速发展,通过公共互联网安全可靠的传输音视频信号已经成为一种可能,实际上我们的传输手段又多了一种:无需面对面的公网传输。

然而公共互联网中普遍存在着不同程度的丢包、抖动、延时和带宽波动,这就需要一种可靠的传输协议来保证传输链路的可靠性。SRT(Secure Reliable Transport)协议,即安全可靠传输协议,是一种新兴的音视频传输协议,在音视频的点对点实时传输方面有着非常好的应用效果。

广电的技术人员习惯通过链路的冗余量来估算链路的可靠程度,卫星链路中的类似指标是载噪比冗余量(C/N Margin),光纤链路可以通过光功率衰减和接收端灵敏度来估算光功率冗余量。类比这些概念,本文将从SRT协议的理论基础谈起,尝试定义一个衡量SRT链路可靠性的指标——安全冗余量(Secure-Margin)。接着根据这个指标,讨论SRT协议中相关参数的设置步骤和策略。

1、SRT协议原理分析

SRT协议能够在不可预测的互联网环境下提供安全、可靠的数据传输,目前广泛应用在流媒体传输领域。理论上SRT可以传输任意类型的数据,但由于其特别针对实时音视频传输做了优化,目前的主要应用场景是跨越公共互联网点对点传输实时音视频数据

SRT协议最初是一个私有协议,在2017年4月由SRT联盟将其开源,由于该协议良好的性能以及开源、应用灵活等特性,越来越多的厂商和设备开始支持SRT协议。在实际工作中,搭配使用不同厂商的SRT设备也能够实现高可靠、低延时的音视频传输,这对于用户来说非常方便和灵活。

1.1 SRT协议和UDP协议

追述SRT的开发历程我们会发现,它是由**UDT(UDP-based Data Transfer)**协议改进而来,SRT协议保留了UDT协议大多数的核心概念和机制,同时引进了一些改进和增强功能,其中主要包括针对实时音视频的流量控制、增强的拥塞控制、控制数据的修改、加密机制的改进。UDT协议由Grossman提出,该协议在UDP协议的基础上添加了可靠性控制和拥塞控制机制来保证可靠性,可以有效地利用高速广域网络的高带宽,实现文件的高效、可靠传输。由于UDT协议主要适用于高吞吐的文件传输,SRT主要适用于流媒体传输,所以从应用层面来说,SRT协议和UDT协议之间的差别其实是不可跨越的。

抛开SRT协议的历史,我们可以把它理解成一个基于UDP协议的流媒体传输协议。众所周知,UDP协议是一种基于数据报的不可靠传输协议,它以提高数据的传输速率作为主要设计原则,只能提供不可靠的数据传输服务,尽最大努力交付。

图1展示了裸露的UDP协议在有损网络上的传输效果,测试中利用软件Netem模拟了具有丢包、抖动、延迟的有损网络,在源端将音视频信号进行信源编码,编码后输出的TS流具有可变比特率(VBR)和固定的帧间隔,但是在跨越网络后输出的码流特性已经完全改变,固定的帧间隔也因为网络的抖动发生了改变,实际上解码器很难从这样的码流中恢复出正常的音视频信号。

图片

图1  UDP协议在有损网络下的传输性能

由图2可以看到,SRT协议很好地克服了有损网络环境中的丢包和抖动,在输出端很好地还原了输入的码流,它通过有效的差错控制、精确的时间戳、反馈信号、根据延时量定义缓冲区等一系列机制,实现了在有损网络下的流媒体传输,其中差错控制使用了自动重传请求机制(ARQ)。

图片

图2  SRT协议在有损网络下的传输性能

1.2 自动重传请求:ARQ

数字通信中的差错控制方法大致可分为两类:前向纠错(FEC,Forward Error Correction)和自动重传请求(ARQ,Automatic Repeat reQuest)。从七十年代开始,ARQ思想就被广泛应用在各类通信技术和传输协议中,发展至今经历了多次进化,SRT协议发明者声称其对ARQ技术的改进可以称得上ARQ技术的第三次飞跃。

图3表示了ARQ技术的基本思想,接收端成功收到数据包后通过反馈信道向发送端传送一个指示接收成功的信号(ACK),若超时未收到, 则通过反馈信道向发送端传送一个要求重传的信号(NAK),发送端收到此NAK信号后就重新传送相应的未被接收的数据包。因此这种机制除了要求发送端需要一个重传缓冲区之外,接收端也需要一个能依次存放数据包的缓冲区。

图片

图3  自动重传请求技术(ARQ)基本思想

图4表示了ARQ和FEC之间的区别,一般情况下,我****们要根据实用场景的特点和需求来选择ARQ或FEC。以卫星通信为例,通信链路的单次往返时延即RTT约为540ms,并且噪声都为高斯白噪声,这种情况下使用ARQ效率就很低,也会造成非常大的延时,FEC就成为了最合适的选择。互联网环境中的丢包和抖动有很多都是突发的,这种环境就比较适合ARQ技术来工作,因此SRT最初选择了ARQ作为纠错方式。随着SRT应用领域的发展和扩大,最新版的SRT也加入了对FEC的支持,从而更好地适应各类场景下的应用。

图片

图4 FEC和ARQ链路对比图

2、定义链路的安全冗余量 (Secure-Margin)

在广电领域的直播工作中,工作人员都会习惯通过链路的冗余量来估算链路的可靠程度,卫星链路中的类似指标是载噪比冗余量(C/N Margin),光纤链路可以通过光功率衰减和接收端灵敏度来估算光功率冗余量。类比这些概念,本文从应用层面出发,尝试定义出SRT链路的安全冗余量(Secure-Margin),并给出定性和定量的分析。

在讨论安全冗余量之前,我们首先来了解**单次往返时延(RTT,Round-Trip Time)**的概念:它表示了数据在发送端和接收端之间进行一次往返所需要花费的时间,也可以理解为两点之间一来一回所需要的时间。RTT的值与两点之间物理距离有关,同时也受到网络接入方式和路由选择的影响。

也许可以用一句话表示如何配置一个可靠的SRT传输链路:我们要保证发送缓冲区的使用量(使用单位毫秒来衡量)低于延时量,并且保证接收缓冲区的使用量永远不会接近零。这句话的原理将在下文详述,它实际上指出了SRT链路中的两个临界崩溃点,而SRT链路安全冗余量表示了链路离临界崩溃点还有多少余量。

2.1 发送端缓冲区冗余量

参考图3,ARQ的工作机制决定了发送端需要一个重传缓冲区,接收端也需要一个能依次存放数据包的缓冲区。另一方面,SRT协议通过设定延时量(Latency)统一规定了发送缓冲区和接收缓冲区的最大可使用量。

发送缓冲区的作用是来保存有可能需要重传的数据包,即那些还没有收到肯定应答(ACK)的数据包,如果发送端收到了关于某个数据包的肯定应答,该数据包将被从发送端缓冲区踢出。如果一直没接收到回复的ACK信号,该数据也不能永远保存在发送端缓冲区中,SRT协议规定了保存的最长时间为延时量。

参考图5,并结合SRT的工作原理,我们把延时量的长度想象成一个同时在发送端和接收端从左向右滑动的窗口,图中的1号至6号数据包都已收到肯定应答(ACK),已从发送端缓冲区踢出,7号数据包还保存在缓冲区等待接收方的回复。这是一种较好的传输状态,发送端缓冲区的使用比例很小,大部分数据都已经被及时接收并且收到肯定应答。

参考图6,接收方没有收到3号数据包,并向发送端回复了否定应答(NAK),由于种种原因这一过程被延误,导致3号数据包已经处在窗口最左侧,随着窗口的滑动下一步它将被从发送端缓冲区踢出。这种情况下如果3号数据包的重新传输再出现丢失或者延误,该数据包就会丢包,解码端的图像可能也会出现问题。同时我们也注意到图中发送端缓冲区已经被填满,这也表示了一种处于丢包临界点的传输状态。

图片

图5 发送端和接收端缓冲区(较好状态)

图片

图6 发送端和接收端缓冲区(较差状态)

根据分析可以得出结论:发送端缓冲区被占用的比例越少,链路越安全,若发送端缓冲区被占满,链路则很有可能发生丢包

根据SRT的工作机制可知:数据保存在发送端缓冲区的最长时间为延时量(Latency),相反保存在发送端缓冲区的最短时间为链路的单次往返时延(RTT)。如果把发送端缓冲区被填满定为临界崩溃点,则发送端缓冲区冗余量SendBuffer-Margin的定义为:一段时间内缓冲区的最大空余量除以发送端缓冲区的最大值,则公式如下:

图片

需要注意的是,我们通过状态图观察发送端缓冲区最大占用量的使用可以忽略那些偶尔出现的短时间峰值。

图7是某次直播当天的发送端缓冲区监测图,图中延时量为125ms,RTT为10ms,这段时间内的发送端缓冲区冗余量约为40%。由于通过测试选择了合适的参数,即使图中后半段网络出现了波动,我们仍然保证了较为充足的发送端缓冲区冗余量。

图片

图7 发送端缓冲区监测图

2.2 接收缓冲区冗余量

接收缓冲区的作用是将收到的数据包排序(SRT协议在SRT包头记录了精确的时间戳),排序一方面是解码的需要,另一方面是为了找出未及时到达的数据包,向发送端返回否定应答(NAK),并等待重传。

参考图5,接收端的1号数据包已经被送至解码器,2号数据包随着延时量窗口的滑动也即将送至解码器,同时2号至6号数据包都已保存在接收缓存区中,接收缓冲区几乎被数据包填满,这是一种较好的链路状态。

参考图6,这是一种较差的链路状态,接收端未收到3号数据包,并且3号数据包在接收端窗口最左侧,意味着3号数据包很可能被跳过,解码出的图像会出现问题。在这种情况下接收缓冲区数据包较少,原因有可能是丢包或者网络带宽和视频码率不匹配。

由此可以得出结论:接收缓冲区的理想状态应该是其使用量应该略低于延时量,若接收缓冲区占用量变为零,解码图像很可能会出现问题

根据SRT的工作机制可知:数据存放在接收端缓冲区的最长时间应略低于延时量的数值(Latency)。如果把接收端缓冲区使用量变为零看作临界崩溃点,则接收端缓冲区冗余量ReceiveBuffer-Margin的定义为:一段时间之内接收端缓冲区的最小占用量除以接收端缓冲区的最大值,公式如下:

图片

图8是某次直播当天的接收端缓冲区监测图,图中延时量为125ms,RTT为10ms,在图中这一段时间内的接收缓冲区冗余量约为40%。

图片

图8 接收端缓冲区监测图

2.3 链路的安全冗余量

根据SRT的工作机制,发送端和接收端的缓冲区状态是相互影响的,并且状态较差一端的缓冲区冗余量实际上决定了链路的安全冗余量,那么定义链路的安全冗余量(Secure-Margin)等于发送端缓冲区冗余量(SendBuffer-Margin)和接收端缓冲区冗余量(ReceiveBuffer-Margin)两者的最小值

根据SRT的机制和延时量的含义,实际上延时量和RTT一起定义了数据包能够被重传的次数,这个次数等于延时量除以RTT,我们可以依此进一步定义重传次数冗余量的概念:

图片

至此我们分别用百分比重传次数两种形式定义了链路的安全冗余量(Secure-Margin),该指标表示了SRT链路差错控制能力的冗余量,同时也是从应用的层面出发,给SRT协议的链路测试以及参数调整设立了一个目标。理解安全冗余量的含义能够帮助工作人员更好地读懂缓冲区状态图,并且以此为参考更有针对性地调整参数,我们也强烈推荐结合该指标和缓冲区状态图来一起评估链路的安全状态。

参照图7和图8,可以观察到RTT一直比较平稳,有时候我们的直播任务往往没有这么好的网络条件,如果遇到RTT突增的情况,链路安全冗余量在下降,而重传次数冗余量在成倍的下降,这时以百分比计算的安全冗余量就不能真实反映链路安全的变化情况,需要同时计算链路的重传次数冗余量。

3、配置SRT流的策略

3.1 测量网络链路的基础参数

在配置SRT流之前我们必须测量自身链路的可用带宽、丢包率、单次往返时延RTT,并注意观察这些指标是否在变动以及变动的范围。

  • 可用带宽:可以使用Iperf软件测量SRT流的链路可用带宽。

  • 丢包率:丢包率是衡量网络堵塞程度的一种方法,使用丢失数据包与发送数据包的百分比表示。信道的丢包率会驱动SRT延迟和带宽开销计算,并可从Iperf统计信息中提取。

  • RTT:要确定两台设备之间的RTT,可以使用ping命令,如果RTT<=20ms,则使用20ms作为RTT值。这是因为SRT无法对时间尺度小于20ms的事件进行响应。

3.2 设定延时量

延时量(Latency)可以说是SRT协议中最重要的参数,它是一个固定值,可设置范围是80ms-8000ms。延时量越大,SRT链路的差错控制能力就越高,但链路总延时会增加。通过前期测试选择合适的延时量,能够帮助我们在链路的可靠性和低延时之间取得平衡。表1给出了不同丢包率和RTT下延时量的建议值。

最大丢包率(%) RTT乘数 带宽开销(%) 最小延时量(当RTT<=20ms)
<=1 3 33 60ms
<=3 4 25 80ms
<=7 5 20 100ms
<=10 6 17 120ms

表1 SRT参数设置表

参考表1,延时量的计算公式如下,其中如果RTT小于20ms,按20ms来计算:

延时量Latency=RTT*RTT乘数

上式中RTT乘数的实际含义是SRT链路能够完成的重传次数,也代表了链路的差错控制能力,这也是为什么丢包率越高,所需要的RTT乘数越高,所需要的延时量也越高,而之前定义的链路重传次数冗余量可以理解成目前还未使用的重传次数。

最初我们完全按照这张表来配置SRT链路,但经过多次直播工作之后我们发现按照推荐值配置的链路安全冗余量并不一定充足,一个好的习惯是提前进行链路测试,并结合安全冗余量和缓冲区状态图来选择合适的延时量。

关于延时量还有其他几个需要注意的点:

  • 在链路其他参数固定的情况下,提高延时量,安全冗余量(Secure-Margin)会随之增大。

  • 延时量(Latency)可以在编码器和解码器上分别设置,若数值不一样,以较高的数值为准,这也就意味着我们仅在某一端把延时量参数降低是无法生效的。

  • 延时量参数并不能代表传输链路的端到端延时,计算链路总延时还需要考虑编码器延时、解码器延时以及RTT。

  • 体育比赛这类直播的传输链路需要很低的延时,因为观众肯定不希望从邻居的欢呼声或者朋友圈得知进球,我们需要非常谨慎地权衡延时量和安全冗余量,从而找到一个折衷的参数。以上图的直播为例,在保证充足安全冗余量的情况下,端到端延时只有0.8秒左右,远小于卫星链路的延时。

3.3 设定带宽开销比例

带宽开销(Bandwidth Overhead)是一个百分比参数,其计算基数为音视频码流比特率,默认值为25%,最高不建议超过50%。这部分由用户分配的额外带宽是用来重传丢失的数据包、传输反向控制数据以及处理拥塞,也就是说带宽开销比例与链路的差错控制能力也是息息相关的,实际上SRT协议中每丢失一个数据包就需要在接收端消耗大约400bps的可用带宽。

图9是一种SRT链路发生崩溃的极端情况,可以用该图来理解带宽开销的功用。在链路崩溃发生后,首先缓冲区数据会暂时填补解码器对数据的持续需求,紧接着链路恢复后,额外划定的带宽开销会弥补之前对缓冲区数据的消耗,在处理完这次突发事件后,整个SRT链路会恢复正常。

图片

图9 带宽开销示意图

关于带宽开销有几点需要注意:

  • 参考表1,可以找到在不同丢包率下的带宽开销比例的最小值,根据链路状态可稍作上浮。

  • 带宽开销的计算基数是视频+音频+元数据+其他辅助数据的总比特率,在估算时要加以注意。

  • 在确定了编码的流带宽之后,可以通过_流带宽*(1+带宽开销)_来计算所需要的链路可用带宽,实际应用中建议在此基础上再增加一些链路可用带宽来对抗波动,建议值为**流带宽*(1+带宽开销)*1.33**。以HEVC方式编码4K信号为例,如果编码后的TS流为40Mbits,带宽开销为25%,建议的链路可用带宽应该在67Mbits以上。

  • 参考图9,区域A和区域B必须相等,实际上SRT链路能够容忍的网络中断时间为_延时量*带宽开销_。综艺晚会或者政府会议这样的直播工作,其对延时并不敏感,可以考虑充分利用延时量和带宽开销这两个参数来极大增强链路的可靠性。假设我们在这种情况下设置延时为8000ms,带宽开销为50%,那么网络即使中断4秒钟也不会影响SRT链路的正常工作,SRT链路这一特性甚至是卫星和光纤链路都不具备的。

结 束 语

近年来,SRT协议在广电领域的发展呈现多点开花的趋势,在现场直播、远程制作、上行推流、国际间远距离传输多方面都有着广泛的应用。在实际部署SRT链路的过程中,前期大量的测试工作是必不可少的,在测试时可以通过观察安全冗余量和缓冲区状态图来判断链路的安全性。

《公网传输技术之SRT协议解析》的下篇将从SRT数据包的角度来分析SRT协议的运行机制和原理,并演示如何通过Wireshark来进行抓包和故障诊断,敬请期待。

参考文献:

1. Haivision.SRT Protocol Technical Overview[M/OL].(2018-10) [2022-02].www3.haivision.com/srt-protocol-technical-overview.

2. Yunhong Gu,Robert L.Grossman.UDT:UDP-based data transfer for high-sspeed wide area networks[J].Computer Networks,2006,51(7):1777-1799.

3. Haivision.SRT Open Source White Paper[M/OL].(2019-1) [2022-02].www3.haivision.com/srt-open-source-wp.

4. SRT Alliance. SRT Deployment Guide,v1.1,Issue 01[M/OL].(2018-10) [2022-02].www3.haivision.com/srt-alliance-guide.

作者简介:

张博力,安徽广播电视台工程师。


图片

还可输入800
全部评论
作者介绍

LiveVideoStack

音视频技术社区

文章

粉丝

视频

阅读排行
  • 2周
  • 4周
  • 16周
热门视频

用互联网发展视角看元宇宙创新

龙明康/AI工程院常务副院长

单目3D人体姿态估计的挑战和探索

宋波/人工智能高级工程师