4.1. 参数名称解析
这一节，我将逐个向大家介绍会影响SRT传输性能的参数名称，他们包括：Round Trip Time（RTT，往返延时）、RTT Multiplier（RTT倍数）、Packet Loss Rate（丢包率）、Bandwidth Overhead（带宽开销）以及Latency（延时），SRT加密等。
4.1.1. Round Trip Time (RTT)
RTT（往返延时）表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。我们可以通过RTT知道两台设备（在我们的应用中，即为SRT源设备和SRT目标设备）在网络中的距离。在配置SRT传输时，我们就能以这个值为参考，设置带宽开销以及传输延时。
当两台设备连接在局域网的同一台交换机上时，RTT值几乎为0（小于1 ms），而随着基础设施建设越来越完善，即使跨越大洋，也可能得到很低的RTT值。
要想得到两台设备间的RTT值，我们可以使用ping命令。例如，如果我想知道我的电脑和Google在美国的免费DNS服务器8.8.8.8之间的RTT值，就可以使用电脑ping这个IP地址，从而得到他们之间的RTT值，如下图，我们从中可以知道，此时该网络链路RTT值平均约为51 ms。
4.1.2. RTT Multiplier
RTT Multiplier是一个用于计算SRT延时的数值，它可以反应出网络拥塞程度和RTT之间的关系，随着网络拥塞的增加，SRT控制信息数据包的交换量以及丢包的重传量也会随之增加，这些额外传输的数据包的传输时间都会受限于RTT，所以为了抵消掉这些数据包的传输延时，就必须要增加SRT延时，而调整SRT延时的依据就是RTT Multiplier了，他们的关系如下：
SRT Latency = RTT Multiplier * RTT
我们也可以换一个RTT Multiplier的理解方式：它表示了在SRT传输中，对一个数据包的最大重传次数。当然，这个值不会直接出现在SRT的配置参数中，而是用于计算最理想的理论SRT延时。
4.1.3. Packet Loss Rate
Packet Loss Rate（丢包率）这个参数大家就再熟悉不过了，它通常表示丢掉的数据包占总发送数据包的百分比。在SRT传输中，我们可以把出现丢包的情况大致分为两种，在不同的情况下，分别会对我们设置Bandwidth Overhead有不同的影响：
✦ Constant loss（稳定的丢包）
即链路的丢包率不会出现太大波动，基本处于一个恒定的数值。在这种情况下，要想稳定传输，就要求SRT开销应不小于此时的理论最小值（如下公式）：
Minimum Bandwidth Overhead = 1.65 * Packet Loss Rate
✦ Burst loss（爆发式丢包）
即链路会出现大量连续的丢包，并且丢包量达到或超过SRT latency buffer（缓存区）内缓存的数据包量。在这种情况下，要想稳定传输，要求SRT开销应不小于此时的理论最小值（如下公式）：
Minimum Bandwidth Overhead = 100 ÷ RTT Multiplier
这种爆发式丢包一旦持续时间超过了设置的SRT延时，将会导致接收端收到的流中断，所以，SRT传输延时应该保证永远大于最差网络环境下的网络持续丢包时间。.
4.1.4. Bandwidth Overhead
Bandwidth Overhead（带宽开销）是一个根据网络链路质量设置的百分比值，用这个百分比值乘以编码器编码的视音频总码率，就可以得到Bandwidth Overhead允许的最大开销，这个值与视音频码率的总和就是当前SRT传输带宽的最大值了，也就是这个SRT通道可以使用的最大带宽。
它的作用首先是传输伴随SRT流的控制信息数据包，另外还包括所有媒体数据包的重传，所使用的网络链路条件越差，就需要越多的控制信息数据包的交互以及媒体数据包的重传，也就需要设置越大的Bandwidth Overhead值。
如果从“开销”的角度理解，它就是在传输所需的媒体内容（可以理解为载荷payload）外，额外要占用的“无效”带宽，但它与我们常见的协议开销、TCP首部开销、UDP首部开销有所区别，这里的带宽开销并不是固定的20~60字节TCP首部开销或8字节UDP首部开销，而是根据网络情况实时变化的，网络链路条件越差，正常传输所需的开销就越多。
在高骏SRT设备中，Bandwidth Overhead的设置范围是5%~100%，默认大小为25%。
为了让大家对Bandwidth Overhead这个概念理解得更清晰，下面我们举个例子来说明。
假如需要使用HDE-650S实时传输视频，设置视频编码码率为2000 kbps，音频码率为128 kbps（只使用一对立体声），所以视音频的总码率为2128 kbps，我们可以算上一些元数据和其他附加数据，向上取整为2200 kbps，如果我们设置Bandwidth Overhead为默认值25%，那么为传输这段视频所保留的总带宽则为：
2200 + (25% * 2200) = 2750 kbps (2.75 Mbps)
这个值表示的是SRT传输可以使用的最大带宽，如果在网络传输的过程中没有产生丢包，那么就只会使用很少量的开销来进行控制。通常只要能保证SRT总带宽不超过在两台SRT设备间的的可用带宽，数据流就能够保证顺利地传输。
4.1.5. Latency
Latency（延时）对大家也是一个很熟悉的概念了，具体来说，它在这里用来表示通过网络传输数据包的时间延迟。在高骏SRT设备中，Latency的设置范围是20 ms至8000 ms，而我们设置的这个延时大小，则代表了可用于管理SRT数据包的最大buffer（缓存区）的大小。
在SRT传输中，SRT源设备需要将它发出的数据包在buffer内排序，用于进行传输和重传，在SRT源设备的buffer内会保存那些还没有被SRT目标设备确认收到的数据包。
而SRT目标设备则需要将它收到的数据包（在收到时可能是乱序的）存储在buffer内，并以正确的顺序排列，确保之后的解码正常，在SRT目标设备的buffer内会保存那些已经收到并等待解码的数据包（包的顺序按16进制1到f）。
图4-4 SRT传输中的buffer
在传输过程中，我们应该确保SRT源设备缓存在buffer中的内容（换算成以毫秒为单位）始终低于设置的Latency值，同时保证SRT目标设备缓存在buffer中的内容不要减少到0，这样才能保证SRT目标设备正确的收到所有数据包。
SRT Latency是基于当前网络链路的性能来设置的（如我们前面说到的RTT与网络丢包率等），例如在一个较好的网络环境中，丢包率为0.1%-0.2%，那么根据经验可能将RTT Multiplier选为4就可以了，也就是：
SRT Latency = 4 * RTT
在使用时，我们在SRT源设备和SRT目标设备两端都可以设置Latency的大小，最终将取两个值中较大的一个为SRT传输延时。
图4-5 在HDD-461中SRT Statistics显示的Latency-Buffer-RTT图表
4.1.6. SRT加密
在使用SRT传输时，高骏SRT设备可以使用AES加密算法进行128位或256位的内容加密，并在SRT目标设备中解密，确保传输内容的安全。
要想打开加密功能，首先要在SRT源设备中选择“Encryption”项的加密类型（AES-128或AES-256），并在SRT源设备和SRT目标设备中的“Passphrase”栏内填写相同的加密口令。
4.1.7. 传输过程中的Latency、Buffer和BW Overhead
了让前面介绍的几个参数更好理解，下面我们通过一张图表来将它们形象的表现出来，下图描述了在一次SRT传输过程中，传输数据量随着时间的变化图，期间由于一次网络问题，传输数据量降为零，短暂的链路断开后，又恢复了数据传输，具体如下：
图4-7 SRT传输过程中的传输数据量变化图
（图片来自SRT Alliance的指导文档《SRT Deployment Guide, v1.1, Issue 01》）
＊注：
- 绿色直线：表示该链路可用的最大带宽；
- 红色虚线（偏上）：表示根据流量带宽和BW Overhead计算得到的SRT最大带宽；
- 红色虚线（偏下）：表示正常情况下的流量带宽，即视频、音频、元数据等；
- 蓝色曲线：表示传输数据量随时间变化的曲线；
- 灰色区域：表示接收端buffer缓存的数据总量。
我们首先来解释一下接收端buffer，它是SRT目标设备缓存的数据包，我们在前面说过，它可以换算成以毫秒为单位的时间值，具体是如何做的呢，中间有这样一个简单的数学公式：
时间 = 缓存数据量大小 ÷ 流量带宽
而在上图中，灰色区域的面积就表示buffer内缓存的数据量，由于在链路故障点之前始终保证了稳定的传输码率，将buffer缓存一直维持在“满”的状态，所以灰色区域对应的时间轴长度与SRT延时基本相同。
在链路出现故障后，传输码率降为零，随后又重新建立起连接，再次开始传输，也就是说SRT目标设备在一段时间内没有收到任何数据包。
当SRT传输出现这样的情况时，SRT目标设备将用buffer中缓存的数据来保证输出给解码部分的数据流，设置的SRT延时越长，buffer中就能缓存的数据就越多。
随后，一旦链路恢复，SRT源设备就会重新开始传输数据，其中将包括重传在链路故障期间丢失的数据包，为了这部分重传数据，SRT就会使用到在正常流量带宽之外的“开销”部分。一般情况下，带宽开销的大小应该保证在可能出现的最坏的网络状态下，SRT源设备能够在爆发期（burst time，图中区域B）内传输链路故障期间传输失败的所有数据（图中区域A），也就是区域B的面积应与区域A的面积相等。
在保证输出图像连贯的条件下，SRT连接能够承受的链路故障（完全没有数据传输）的最长时间为：
SRT Latency (ms) * Bandwidth Overhead (%) ÷ 100
4.2. 基本设置方法
在我们设置SRT传输参数时，所使用的网络链路状态通常是千变万化，即便是相同的网络链路，不同时间也可能会有不同的网络状态，但是，不论何时，我们都要总结出一套通用的技巧，来有理有据地提供一系列初始设置参数，然后再根据实际的效果做出相应的调整，下面就让我来给大家介绍一些SRT的基本设置方法。
设置过程可以分为以下七步：
4.2.1. 检测网络链路的Round Trip Time（RTT）值
✦ 使用ping命令检测所使用的网络链路的RTT值；
✦ 如果已经建立起SRT连接，可以在SRT设备的Statistics统计页面中查询RTT值；
✦ 当RTT ≤ 20 ms时，应认为RTT值为20 ms，因为SRT不对时间单位低于20 ms的数据做出响应。
4.2.2. 检测网络链路的Packet Loss Rate（丢包率）
✦ 网络链路的丢包率将直接影响SRT延时和BW Overhead的计算，我们通常可以使用iperf来检测网络丢包率。
✦ 如果已经建立起SRT连接，可以在SRT设备的Statistics统计页面中获取网络链路的丢包率， Resent Bytes和Sent Bytes两个统计数据的比值即为网络丢包率，为了保证准确性，应该至少保证数据的统计时间超过60秒，网络链路丢包率计算公式如下：
Packet Loss Rate = Resent Bytes ÷ Sent Bytes * 100
4.2.3. 根据测得的网络丢包率，从下表中查找相应的RTT Multiplier和BW Overhead值
表4-1 不同丢包率时RTT Multiplier和BW Overhead的取值
（表格来自SRT Alliance的指导文档《SRT Deployment Guide, v1.1, Issue 01》）
＊注：
1. 表格中的BW Overhead取值同时考虑了前文提到的Constant Loss和Burst Loss两种情况，取两种情况下计算得到的较大值（较大值全部为100 ÷ RTT Multiplier）；
2. 表格中计算的最小SRT Latency为RTT ≤ 20 ms时（即RTT取值为20 ms），在实际使用时应代入实际测得的RTT值；
3. 表格中所列的数值，基本代表了一般情况下最高效的SRT设置，如果网络环境变得更差，或者希望系统容错率更高，也可以取更大的RTT倍数和BW Overhead值。
从表格中我们可以看到，随着网络丢包率的增高，RTT Multiplier顺理成章地逐渐变大，BW Overhead却在逐渐变小，为什么它会给出这样的建议呢？下面给大家分享一些我个人的想法。
我们前面已经介绍过，RTT Multiplier表示了SRT连接中一个数据包的最大重传次数，也就是说，在网络丢包率不超过1%时，表格建议设置最大3次重传就可以基本保证数据包能够传输到接收端了，而经过3次重传数据包都没能到达接收端的概率就是 (1/100)^3×100%=0.0001%（一百万分之一）；以此类推，我们可以得到数据包最终丢失的概率公式为：
将上述函数画在二象限图表中，可得下图：
从上图中可知，如果按照表格中的RTT Multiplier值和BW Overhead值设置SRT传输参数，那么在传输过程中一个数据包最终没能到达接收端的概率将始终小于0.0002%（一百万分之二）。
我们不妨主观地判断，这个表格建议我们能够认为概率为0.0002%的事件是几乎不可能发生的事件（即数据包几乎不可能无法到达接收端），从而认定此时的SRT传输是安全的。
但是，为什么随着网络丢包率的增加，设置的BW Overhead值是在逐渐减小的呢？我们可以尝试按照表格中的规律，将网络丢包率、RTT Multiplier、BW Overhead的值继续推演下去，即以1%为单位逐渐增加网络丢包率，同时不断地增大RTT Multiplier值，来确保：
p^(RTT Multiplier)≤0.0002%,p为网络最高丢包率
并根据得到地网络丢包率和RTT Multiplier值，分别计算Constant Loss和Burst Loss两种情况下的BW Overhead的值，并将其绘制成图标如下（具体推演数据不在这里列出）：
为了保证表格中的参数设置能够同时兼容Constant Loss和Burst Loss两种网络丢包情况下的SRT传输，BW Overhead应该取上图中较大的数值，而在网络丢包率不超过10%时，始终是Burst Loss状态下的BW Overhead的值更大，并且不断减小（上图中橙色线），所以我们才会看到表格中的BW Overhead值不断减小；而当网络丢包率超过10%后，就变成了Constant Loss状态下的BW Overhead的值更大，所以就应该选择数值较大的蓝色线，这之后BW Overhead将逐渐增大。
以上这些内容完全是我根据《SRT Deployment Guide, v1.1, Issue 01》中的参数表格所做的猜想，无论正确与否，希望能够给大家一点启发。
4.2.4. 通过以下公式确定SRT Latency
SRT Latency = RTT Multiplier * RTT
✦ 当RTT ≤ 20 ms时，RTT取值统一为20 ms。
4.2.5. 测试可用链路带宽
✦ 使用iperf测试；
✦ 如果已经建立起SRT连接，可以通过SRT设备Statistics统计页面中的Max Bandwidth和Path Max Bandwidth两个参数获取链路带宽信息。
4.2.6. 确定传输码率
✦ SRT传输码率将会包括视频、音频、元数据等有效数据，再加上SRT协议开销，我们可以得到如下关系式：
Channel Capacity＞SRT Stream Bandwidth * (100 + Bandwidth Overhead) ÷ 100
✦ 如果不满足上述关系式，应减小视音频码率，直到满足；
✦ 通常情况下，建议保留出更多的空余带宽来抵抗不断变化的链路带宽，所以下面这个关系式会具有更强的安全性：
0.75 * Channel Capacity＞SRT Stream Bandwidth * (100 + Bandwidth Overhead) ÷ 100
4.2.7. 检查SRT传输参数设置是否正确
✦ 检查SRT传输参数最好的方法，就是在开始进行SRT传输后，查看SRT源设备的Statistics统计页面图表， Send Buffer数值应该保持始终不超过SRT Latency的值，如果两条线十分接近，应当适当增加SRT延时。
4.2.8. 关于iPerf
iPerf是一个网络性能测试工具，通过它我们能够得到网络链路的带宽、延迟、抖动以及丢包等信息，从而判断一个网络链路的性能状态。
在常用的Windows平台中，我们可以在网上下载到iPerf应用程序，并放在系统目录 %systemroot% 中，通过命令行窗口来运行，需要注意，iPerf3（如iPerf 3.1.3）与iPerf（如iPerf 2.0.9）之间不兼容；除此之外，也可以选择带有用户界面的应用程序，这样就不需要牢记复杂的操作命令了，如下图：
图4-10 iPerf软件
这里，我只向大家介绍测试传输带宽所用的命令（使用iPerf 2.0.9），如果大家感兴趣，可以去研究iPerf更多的使用方式。
在开始测试前，应该先确保打开防火墙相应的端口，同时停止其他数据流的传输，保证测试结果的准确性。
在SRT传输的接收端，输入如下命令：
iperf -s -u -i 1 -p “port#”
-s：表示iperf为server模式；
-u：表示使用UDP协议；
-i 1：表示反馈信息的时间间隔为1秒；
-p “port#”：表示通过某一个端口号进行测试。
在SRT传输的发送端，输入如下命令：
iperf -c “IP ADDRESS OF DESTINATION” -u -b “BW” -i 1 -p “port#”
-c “IP ADDRESS OF DESTINATION”：表示iperf为client模式，访问server端的公网IP并进行测试；
-u：表示使用UDP协议；
-b “BW”：表示测试的带宽值；
-i 1：表示反馈信息的时间间隔为1秒；
-p “port#”：表示通过某一个端口号进行测试。
然后我们就可以在窗口中看到测试结果了。例如，我在一台电脑上同时运行iperf server和iperf client，将得到下图中的结果：
图4-11接收端的iPerf命令和测试结果
图4-12 发送端的iPerf命令和测试结果
从上图中可知，测试得到网络带宽能够满足5.5 Mbps（由命令中写的带宽值而来），网络抖动为0.000 ms，丢包率为0%。在真正的互联网环境下，我们就能够以此来判断网络链路的性能了。
4.3. SRT统计信息和优化传输设置
在进行SRT传输时，两端的设备会交互大量的网络条件信息和数据包传输信息，而正是这些重要的信息内容让SRT在传输视音频信息时能够使用最佳的传输策略，SRT设备会将其中一些重要的信息参数以曲线图的方式表现出来，让他们变得简单直观，而对于操作人员来说，能够理解这些参数所代表的意义对优化SRT传输设置至关重要。
4.3.1. HDE-650S中的链路统计信息（Link Statistics）
在HDE-650S的Statistics统计信息中，包含了SRT状态、传输和丢失的数据包数，码率、启动时长、网络状态信息等等参数，如下图：
图4-13 HDE-650S的Link Statistics统计信息
其中，可选择查看SRT协议或简单UDP协议的输出统计信息，简单UDP协议的输出统计信息只包含状态和码率，这里就不介绍了。另外可以选择曲线图的取样时间范围，可选择最近5分钟、最近60分钟或最近24小时内的统计数据信息。
Link Statistics中呈现的参数项包括：
注意事项：
✦ 首先应注意Status保持Connected状态，即保持SRT连接正常；
✦ 当发现Reconnections值不断变大时，表明两台设备间的网络通讯异常；
✦ 当Received NAKs值保持稳定上升时，证明在传输链路中存在某些网络问题，导致始终有一定量的数据包无法正常到达接收端；
✦ 如果发现Skipped Packets值缓慢增加，通常可以增加一些SRT Latency来解决；但是如果发现Skipped Packets的值会快速变大，那么就应该降低一些视频码率，如果有足够的可用带宽，也可以适当的增加Bandwidth Overhead。
在编码器HDE-650S的Link Statistics中，还可以看到两个曲线图，分别表现带宽和延时随时间变化的曲线，如下图：
图4-14 HDE-650S中的统计数据曲线
在上方的Bandwidth Used图中，我们可以看到传输码率曲线，以及设备预测的最大链路带宽（仅供参考）。
在Delays图中，则会体现在SRT传输过程中，buffer是如何来改善传输效果的，途中我们可以看到buffer和RTT随时间变化的曲线，而延时则作为基准线保持不动。
注意事项：
✦ 在编码器中，buffer的数值（绿色曲线）通常不会超过SRT延时的值（黑色直线），如果编码器的发送buffer曲线越过了Latency线，那么就需要增加SRT Latency的值。
✦ 如果编码器的发送buffer曲线经常会到达或越过Latency线，那么基本可以证明当前的网络带宽不足以支撑所要求的视频码率，此时就应该降低视频码率；如果编码器的发送buffer曲线只是偶尔会超过Latency线，这时就应该增加SRT延时。
4.3.2. HDD-461中的链路统计信息（Link Statistics）
在HDD-461的Statist城市统计信息中，可以看到SRT状态、重传、丢包数、带宽信息、网络状态信息等等参数，如下图：
其中，可以选择曲线图的取样时间范围，可选择最近5分钟、最近60分钟或最近24小时内的统计数据信息。
Link Statistics中呈现的参数项包括：
注意事项：
✦ 首先应注意Status保持Connected状态，即保持SRT连接正常；
✦ 当发现Reconnections值不断变大时，表明两台设备间的网络通讯异常；
✦ 传输时出现少量的Lost Packets属于正常现象；
✦ 如果发现Skipped Packets值缓慢增加，通常可以增加一些SRT Latency来解决；但是如果发现Skipped Packets的值会快速变大，那么就应该降低一些视频码率，如果有足够的可用带宽，也可以适当的增加Bandwidth Overhead百分比。
在解码器HDD-461的Link Statistics中，也有两个曲线图，同样表现带宽和延时随时间变化的曲线，如下图：
图4-16 HDD -461中的统计数据曲线
在上方的Bandwidth Used图中，我们可以看到传输码率曲线，丢包率曲线以及接收数据流传输所使用的带宽。
注意事项：
✦ 如果在解码器输出画面中出现太多的跳帧或丢帧，那么应该增加SRT延时，降低视频码率，和/或增加Bandwidth Overhead百分比
在Delays图中，同样会体现Buffer曲线与Latency线的关系。
注意事项：
✦ 理想状态下，解码器的buffer值应该十分接近Latency值，如果解码器的接收buffer经常降到0，通常是因为链路带宽不足以支撑所要求的传输码率，此时应该调低传输码率；如果解码器的buffer只是偶尔下降到0，则可以通过增加SRT延时来解决。
原文链接：https://blog.csdn.net/weixin_42228920/article/details/90946259