SRT互联网传输设备技术分享

SRT互联网传输设备技术分享
前 言
序 言
Chapter 1. 什么是SRT？
1.1. SRT 联盟
1.2. SRT传输技术
1.3. SRT的典型应用模式
1.3.1. 点对点单向传输和视频互动
1.3.2. 点对多点传输
1.3.3. 视频流协议转换与分发
Chapter 2. SRT协议解析
2.1. SRT工作原理
2.2. SRT握手模式
2.2.1. Caller模式
2.2.2. Listener模式
2.2.3. Rendezvous模式
2.3. SRT如何建立连接
2.3.1. 由SRT源设备发起建立SRT连接
2.3.2. 由SRT目标设备发起建立SRT连接
2.3.3. 使用Rendezvous模式建立SRT连接
2.4. SRT与防火墙
Chapter 3. 实际应用场景
3.1. 在公网环境下开启视频传输：Caller & Listener模式
3.2. 在公网环境下开启视频传输：Rendezvous模式
3.3. 探讨：Rendezvous模式与防火墙
Chapter 4. 配置SRT传输参数
4.1. 参数名称解析
4.1.1. Round Trip Time (RTT)
4.1.2. RTT Multiplier
4.1.3. Packet Loss Rate
4.1.4. Bandwidth Overhead
4.1.5. Latency
4.1.6. SRT加密
4.1.7. 传输过程中的Latency、Buffer和BW Overhead
4.2. 基本设置方法
4.2.1. 检测网络链路的Round Trip Time（RTT）值
4.2.2. 检测网络链路的Packet Loss Rate（丢包率）
4.2.3. 根据测得的网络丢包率，从下表中查找相应的RTT Multiplier和BW Overhead值
4.2.4. 通过以下公式确定SRT Latency
4.2.5. 测试可用链路带宽
4.2.6. 确定传输码率
4.2.7. 检查SRT传输参数设置是否正确
4.2.8. 关于iPerf
4.3. SRT统计信息和优化传输设置
4.3.1. HDE-650S中的链路统计信息（Link Statistics）
4.3.2. HDD-461中的链路统计信息（Link Statistics）
结束语
前 言
写这篇文章的初衷，是想把自己在使用SRT设备过程中的经验和想法分享给公司同事和一些用户。因为SRT对一些人来讲，还比较陌生，如果能够通过一篇文章，把简单的基础知识分享给大家，既能增加对SRT的理解，也可以了解SRT的简单原理，这样在工作中，无论是在搭建传输系统时，还是在使用设备的过程中，都能够游刃有余的解决问题；同时，如果要将这些知识清晰的梳理出来，对我自己也是一次系统学习SRT知识的机会，于公于私，这都是一件值得去做的事。

当然，SRT Alliance提供了相应的指导文档《SRT Deployment Guide, v1.1, Issue 01》，我也是从这份文档开始学习起来的，但是截至到写这篇文章为止，我还没有看到相应的中文版本，这对于一部分国内的用户来说使用起来就会不太方便。

于是，当这两件事同时出现的时候，我写这篇文档的思路也就逐渐清晰了：依托于SRT Alliance这篇指导文档的内容以及逻辑结构，同时加入我自己的思考和想法，再通过高骏SRT设备作为操作界面呈现出来，最终形成一篇中文版本的技术分享文档。

在这篇文章中，我大量借鉴了《SRT Deployment Guide, v1.1, Issue 01》的内容，很多语句都是我将原文翻译过来的，所以难免会有翻译不准、措辞不当的地方；同时，在文中会涉及传输协议、传输纠错机制、防火墙等一些专业知识，其中大多是我通过自学的途径来掌握的，没办法做到准确无误。所以如果有各方面的专业人士发现了我在翻译、描述中的错误，非常希望您能帮我指出问题，我将感激不尽，您可以通过我的个人邮箱联系到我：[email protected]。

原本为了让这篇文章更好的散播出去，我是将它分成四部分在高骏公司的微信公众号上连载发布的，但是弊端就是在推送时间之后，不方便大家再去查找相关的内容，所以这次主要是将原来的连载文章合并起来，并进行必要的修正，形成完整版的文档，分享给大家。

如果您对SRT Alliance的原文文档感兴趣，可以从以下链接中下载阅读，本文参考、涉及的文档包括：
《SRT Deployment Guide, v1.1, Issue 01》下载链接：www3.haivision.com/srt-alliance-guide
《Haivision SRT Open Source White Paper》下载链接：www3.haivision.com/srt-open-source-wp

最后，感谢以往教会我各种知识和技能的师傅、领导、同事、同学和朋友，你们给予我的每一点知识对我来说都非常重要！也感谢SRT Alliance给我们提供如此强大的技术以及相关的指导文档，使我们有机会在工作和生活中学习、应用到SRT技术，也希望你们不断壮大，给所有的使用者带来更多的便利。

序 言
传统的IP编解码器大多直接使用UDP等不可靠传输协议直接进行传输，无法解决公网环境下的抖动与丢包问题，因此，这类编解码器方案无法直接应用于普通互联网传输的场景。

而高骏（北京）科技有限公司推出的使用SRT可靠传输技术的编解码器和媒体网关产品，可成功实现在普通互联网环境下、多地之间，安全可靠的高清视频传输、分发功能。

那么，如此方便好用的功能究竟是如何实现的呢？

为了让大家对SRT传输设备有更深入的了解，将这些看似深奥、复杂的技术和产品变得平易近人，我特意写了这篇文档，与大家分享和讨论SRT技术以及高骏互联网传输设备。文章将分为四部分：什么是SRT，SRT协议解析，实际使用场景和配置SRT传输参数，文章思路由浅入深，由理论到应用，尽可能地将SRT协议清晰地介绍给每一个阅读这篇文章的朋友，希望大家能够从中有所收获。

Chapter 1. 什么是SRT？
1.1. SRT 联盟
想了解SRT技术，我们可以从SRT联盟说起，这是一个由Haivision和Wowza合作成立的，致力于管理和支持SRT协议开源应用的组织，这个组织致力于促进视频流解决方案的互通性，以及推动视频产业先驱协作前进，实现低延时网络视频传输。

1.2. SRT传输技术
SRT（Secure Reliable Transport）是一种能够在复杂网络环境下实时、准确地传输数据流的网络传输技术，它在传输层使用UDP协议，虽然UDP协议是一种不可靠传输协议，但是凭借SRT强大的数据恢复能力，再加上UDP协议自身速度快、开销低的特点，最终实现了SRT安全、稳定、快速的传输效果。

图1-2 SRT Open Source官方logo
（图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》）

SRT是一种面向连接的点对点协议，每一路SRT流仅需一个UDP连接，其中除了一路要传输的数据流外，还包含了双向的控制信息。

协议的特点有如其名字：通过加密保证传输内容的安全；在严重丢包的情况下可靠地恢复数据流；动态适应时刻变化地网络情况传输数据。

得力于其可靠的传输质量和极低的传输延时，SRT技术被广泛应用于视频流传输领域。

在音视频流从SRT源设备（如下图中编码器）传输到SRT目标设备（如下图中解码器）的过程中，SRT会实时地检测和适应两台设备间不断变化的网络状态，抵抗由于网络拥塞而导致的带宽抖动，凭借其强大的错误恢复机制，将网络丢包的可能性降到最低。同时SRT还可以进行AES加密，从而确保数据在传输过程中的信息安全。

图1-3 SRT技术的典型传输方式
＊注： 文章中将分别以蓝、黄两种颜色强调SRT源设备和SRT目标设备，方便大家理解描述语句。

1.3. SRT的典型应用模式
由于SRT技术安全、可靠、快速的特点，它可以适应各种各样的使用需求。而且，有SRT协议的存在，即使你不掌握复杂的IP路由和交换知识，也可以快速地建立起视频传输通道，完成视频传输任务。

这里，我简单列出几个最典型的应用模式：

1.3.1. 点对点单向传输和视频互动
SRT最简单的应用方式，就是在两点之间进行视频传输工作，比如进行单向视频传输，将视频从A地传输到B地；或者两地互传，实现两地间的双向视频互动。

图1-4 点对点单向视频传输

图1-5 点对点双向视频互动
＊注：
1. HDE-650S：SRT互联网传输编码器，支持4:2:2编码；
2. HDD-461：SRT互联网传输解码器；
3. 两台设备搭配使用最低支持40ms超低编解码延时。

这里对HDE-650S和HDD-461先做一个简要的介绍，它们是专业的视频编解码设备，分别可以输入和输出多种基带信号格式，支持ASI、UDP和SRT等多种码流格式的输出、输入，支持4:2:2编码，编解码延时最低可达40ms，是理想的编解码解决方案。

图1-6 HDE-650S和HDD-461的输入与输出

1.3.2. 点对多点传输
通过使用高骏SMH媒体网关，可以将一个编码器发出地视频流，分发给多个解码器，以SMH媒体网关为中心节点，先接收编码器发出地视频流，再将其复制、分发给多个解码器，从而实现点到多点的视频传输。

图1-7 点对多点视频传输
＊注：
SMH：SRT媒体网关。在这里，SMH媒体网关既是SRT目标设备，接收来自编码器HDE-650S的视频流；同时也是SRT源设备，将视频流发送给多个解码器HDD-461。

1.3.3. 视频流协议转换与分发
凭借媒体网关设备，可以实现SRT、TS over UDP、RTMP PULL/PUSH等多种视频流协议的输入与输出，并对各路视频流进行复制、转换、分发等工作，这大大增加SRT系统的兼容性，使本地TS over UDP和RTMP流能够顺利融入SRT系统，提高视频转发的灵活性。

图1-8 通过SMH媒体网关完成视频流协议的转换与分发

Chapter 2. SRT协议解析
为了让各位对SRT有更深入的了解，下面让我们一起来看看SRT是如何工作的。

2.1. SRT工作原理
要说SRT的工作原理，我们先从其纠错机制说起。

下图描述了在数据包传输过程中，不使用数据纠错，使用FEC（Forward Error Correction）纠错，和使用ARQ（Automatic Repeat request）纠错三种链路传输纠错方式的模式和结果。

如果没有数据纠错，结果自不必说，一旦发生丢包，得到的就是不完整的数据流，如下图。

图2-1 数据包传输时没有纠错机制
（图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》）

如果使用FEC纠错，则会在传输的数据流中加入一定比例的前向纠错数据，当发生丢包时，接收端就可以根据前向纠错数据，恢复丢掉的数据包，如下图。

但是使用FEC就必须面对这样的问题：无论是否产生丢包，前向纠错数据都需要占用一定的传输带宽；而且当丢包率超过前向纠错数据能够恢复的阈值时，FEC将无法恢复丢失的数据包。

图2-2 数据包传输时使用FEC纠错
（图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》）

如果使用ARQ纠错，就需要在发送端和接收端之间建立双向连接。在接收端收到数据包后，会按照数据包的顺序进行排序（传输过程中数据包可能会发生乱序），如果发现其中有丢失的数据包，就会向发送端发出重传请求，由发送端将丢失的数据包重新发送到接收端，从而实现数据包的恢复，如下图。

图2-3 数据包传输时使用ARQ纠错
（图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》）

而我们说的SRT技术，正是使用的ARQ纠错机制，这主要是因为在网络传输时，带宽抖动和丢包通常都是随机发生的，只有在网络出现问题的时候才需要纠错机制的介入，只需要在发生丢包之后让发送端重传丢失的数据包就可以了，这样既保证了传输的质量，同时又能减少无谓地消耗传输带宽；除此之外，SRT会为数据包提供更精准的时间戳，让接收端能够准确校准媒体流的包顺序，保证传输正常。

之前已经说过，SRT协议依靠双向传输的UDP流来保证公网环境下的视频传输质量。除了从SRT源设备到SRT目标设备持续发送视频数据外，在两台设备之间还会持续地交换SRT控制信息，以此来在两台设备之间实现以UDP为底层协议的连接，进行信息交互，确保视频数据能够准确地传输到接收端。

图2-4 SRT连接中的双向UDP流
＊注：
1. SRT源设备发送的UDP流包含数据业务流和SRT控制信息；
2. SRT目标设备接收源设备发来的UDP流，同时回复相应的SRT控制信息。

为了让SRT保持连接状态，必须确保控制信息数据包的发送间隔不超过10ms。每当SRT目标设备收到一个数据包后，都会回复一个“ACK”确认控制信息数据包，告诉SRT源设备已经收到这个数据包了，如果在10ms内收到多个数据包，则只回复一个“ACK”，确认这期间收到的所有数据包；然而，数据包的到达时间间隔难免会超过10ms，这时就需要增加“keep alive”控制信息数据包，确保SRT连接不会断开。

在SRT连接中，从目标设备返回源设备的控制信息通道也会占用一定的带宽。在业务数据完全正常传输的情况下（即没有错误信息需要返回到发送端），控制信息占用带宽大约为40Kbps；传输时丢失的数据包越多，目标设备发出的控制信息就越多，信息量会与丢包率线性相关，每丢失1个数据包，大约会消耗400bps的可用带宽。

2.2. SRT握手模式
现在我们已经知道SRT的工作原理了，那么一个SRT连接又是如何建立的呢？要清楚这个问题，我们就不得不了解SRT握手模式：Caller & Listener和Rendezvous。

在讨论建立SRT连接时，我们不需要区分SRT源设备和SRT目标设备，发送端和接收端都可以发起建立SRT连接，我们只要知道哪端的设备满足设置相应模式的网络需求即可。

2.2.1. Caller模式
✦ 功能：
设置Caller模式的设备将作为SRT会话的发起者，它必须知道对应设置Listener模式的设备的公网IP地址及其监听的UDP端口。

✦ 使用场景：
①让一台设备发起建立一个点对点传输的SRT连接；
②设备所在的网络有防火墙，但没有防火墙操作权限；
③设备的IP地址是DHCP动态获取的；
④设备没有固定的公网IP地址。

2.2.2. Listener模式
✦ 功能：
设置Listener模式的设备会监听发起SRT会话的请求，它需要知道应该使用的UDP端口（如网络管理员分配给SRT传输使用的UDP端口），并一直在这个端口上监听发起SRT会话的请求。

✦ 使用场景：
①让一台设备监听发起SRT会话的请求；
②设备所在的网络有防火墙，并且可以控制防火墙，打开需要的UDP端口；
③设备直接暴露在公网环境下。

2.2.3. Rendezvous模式
✦ 功能：
两台设置Rendezvous模式的设备会共同协商，通过相同的UDP端口号建立一个SRT会话。

✦ 使用场景：
①两台设备所在的网络都有防火墙，但是没有防火墙的操作权限，如果防火墙设置了适当的工作模式（将在Chapter 3.实际应用场景中详细介绍），可通过此模式建立SRT会话。

一旦完成SRT连接的建立，SRT源设备和SRT目标设备便开始交换控制信息，如网络状况信息、丢失的数据包等等，无论设备设置的是Caller、Listener还是Rendezvous模式都无关紧要了，直接利用建立起来的SRT通道去传输数据就可以了。

2.3. SRT如何建立连接
那么这三种握手模式实际又是如何把SRT会话建立起来的呢，下面我们通过简单的图示来了解这个过程。

2.3.1. 由SRT源设备发起建立SRT连接
如下图，将编码器HDE-650S设置为Caller模式，解码器HDD-461设置为Listener模式，编码器（Caller）将向设置的UDP端口连续发送控制信息数据包，请求建立SRT连接（图中①），当解码器（Listener）收到这些数据包后，便开始回复它自己的控制信息数据包（图中②），一旦握手成功，编码器便开始在UDP流中增加视频流，开始视频传输（图中③）。

图2-5 SRT源设备发起建立SRT连接的过程

2.3.2. 由SRT目标设备发起建立SRT连接
如下图，将编码器HDE-650S设置为Listener模式，解码器HDD-461设置为Caller模式，解码器（Caller）将向设置的UDP端口连续发送控制信息数据包，请求建立SRT连接（图中①），当编码器（Listener）收到这些数据包后，便开始回复它自己的控制信息数据包（图中②），一旦握手成功，编码器便开始在UDP流中增加视频流，开始视频传输（图中③）。

图2-6 SRT目标设备发起建立SRT连接的过程

2.3.3. 使用Rendezvous模式建立SRT连接
如下图，SRT源设备和SRT目标设备同时设置为Rendezvous模式，两台设备一起向对方发送控制信息数据包，一旦握手成功，编码器便开始在UDP流中增加视频流，开始视频传输。

图2-7 使用Rendezvous模式建立SRT连接的过程

2.4. SRT与防火墙
在实际使用场景中，特别是在通过互联网进行数据传输时，终端设备通常都会经过防火墙再连接到互联网，SRT流就必须穿过防火墙进行传输。这种情况下，我们就需要网络管理员来帮忙对防火墙进行适当的配置，尤其像网络地址转换（NAT）和数据包过滤的设置，防火墙的配置情况将会决定设备使用哪一种握手模式。

下图中，一台编码器尝试通过互联网将视频流发送给解码器，两台设备都在防火墙后。我们不妨假设编码器使用Caller模式，解码器使用Listener模式，为了使它们握手成功，并建立SRT会话，就必须满足下列条件：
① 解码器端的防火墙需要允许某个供SRT使用的UDP端口可以从互联网接入；
② 编码器必须知道解码器端防火墙的公网IP和开放的UDP端口；
③ 两端的防火墙都要允许双向UDP传输；
④ 两端的防火墙都要配置端口转发，允许编码器和解码器之间的数据流传输；
⑤ 两端的防火墙都要关闭数据包过滤功能，允许编码器和解码器之间的交互数据包通过。

图2-9 经过防火墙进行视频传输

Chapter 3. 实际应用场景
在了解SRT协议的基本原理后，我们可以尝试使用高骏公司的互联网编解码器模拟来进行视频传输，感受一下协议中提到的参数是如何在实际应用中体现的。

3.1. 在公网环境下开启视频传输：Caller & Listener模式
让我们再来简单复习一下Caller和Listener模式建立SRT连接的工作机制。其实直接从字面含义就能够对他们的关系有所认识了，SRT握手模式设置为Caller模式的一端，需要负责“呼叫”预先选定的UDP端口（即向Listener端公网IP的这个UDP端口发送数据包），从而发起一个SRT握手以建立连接；而SRT握手模式设置为Listener的一端，则需要负责“监听”预先选定的UDP端口，时刻准备回应Caller端发来的建立SRT握手请求的数据包。

那么在实际应用时我们应该如何来将Caller + Listener模式的理论付诸实践呢？我们先来假设有这样一个应用场景：

某公司有固定的视频传输任务，需要将视频从广州办事处实时传输到北京总部，由于资源问题，只有北京总部可以提供公网IP以及可用的UDP端口，而办事处只能提供互联网连接。

图3-1 使用互联网将视频从广州实时传输到北京

根据现有的资源条件，我们可以这样设置SRT来建立视频传输连接：

由于北京总部可以提供公网IP（203.0.113.74）以及可用的UDP端口，这里假设防火墙打开的UDP端口号为12345，那么，我们就需要将北京的SRT设备（HDD-461）设置为Listener模式，并监听12345号UDP端口，准备建立SRT连接；相应的，广州的SRT 设备（HDE-650S）需要设置为Caller模式，只需要能够接入互联网即可，它将向北京总部的公网IP 203.0.113.74的UDP端口12345发送控制信息数据包，尝试通过此端口来建立SRT连接。

按照以上描述，我们就可以得到这样一个SRT源设备（HDE-650S）和SRT目标设备（HDD-461）的网络关系图：

图3-2 HDE-650S和HDD-461的网络关系图

那么我们应该如何在编解码器中设置这些SRT参数呢？

首先来看编码器HDE-650S，参考下图HDE-650S的SRT输出设置（编码器的其他参数设置不在此处表现）：
①打开SRT输出，将“Output Enable”设置为“Enable”；
②编码器使用Caller模式，将“Connection Mode”设置为“Caller”；
③“Address”一项填入北京总部提供的公网IP地址“203.0.113.74”；
④“Destination Port”一项填入北京总部提供的UDP端口号“12345”；
⑤“Latency” （传输延时）、“Encryption”（加密）、“Bandwidth Overhead”（带宽开销）、“Time To Live”（TTL）、“Type of Service”（ToS）可使用默认值。

图3-3 HDE-650S的SRT输出设置

然后我们再来看解码器HDD-461，参考下图HDD-461的输入设置（解码器的其他参数设置不在此处表现）：
①“Input Name”可以填写一个方便识别的任务名称，此处设置为“SRT_Listener”；
②“Input Source”选择“SRT”，设置为SRT模式；
③解码器使用Listener模式，“SRT Mode”设置为“Listener”；
④“Listener Port”一项填入选择的UDP端口号“12345”；
⑤“Latency” （传输延时）、“Encryption”（加密）、“Bandwidth Overhead”（带宽开销）、“Time To Live”（TTL）、“Type of Service”（ToS）可使用默认值。

图3-4 HDD-461的输入设置

正常情况下，完成上述配置后，编码器和解码器即可顺利完成SRT握手，并开始传输视频流，如下图，图中显示SRT状态为“Connected”，证明SRT连接正常，在解码器HDD-461中可以看到，正在对接收到的视频流进行解码。

图3-5 连接成功后的编解码器状态

3.2. 在公网环境下开启视频传输：Rendezvous模式
我们在上次的文章中说过，Rendezvous模式可以在两端防火墙都没有做端口转发规则时建立SRT连接，从而实现两点之间的视频传输。这时，需要在两端分别设置对方的出口公网IP以及相同的端口号，这样，两台设备将同时向对方的出口公网IP发送控制信息数据包，用来建立SRT连接。

我们继续使用前面的例子来模拟，但是更换一个使用场景：

某公司临时决定从广州办事处将视频信号实时传输到北京总部，来不及申请在防火墙中做端口转发规则，所以两端的设备都没办法通过对方公网IP的某个特定端口来直接找到对方。

这时，就可以使用Rendezvous模式来建立SRT连接，我们需要将北京的SRT设备（HDD-461）设置为Rendezvous模式，并写入广州办事处SRT设备的出口公网IP地址和一个没有被使用的UDP端口号，同时，再将广州的SRT 设备（HDE-650S）也设置为Rendezvous模式，并写入北京总部SRT设备的出口公网IP地址和相同的UDP端口号，这样就可以建立起SRT连接了，我们同样画出一个SRT源设备（HDE-650S）和SRT目标设备（HDD-461）的网络关系图：

图3-6 HDE-650S和HDD-461的网络关系图

按照图中的相互关系，我们继续使用编解码器来设置相应的参数。

首先来看编码器HDE-650S，参考下图HDE-650S的SRT输出设置（编码器的其他参数设置不在此处表现）：
①打开SRT输出，将“Output Enable”设置为“Enable”；
②编码器使用Rendezvous模式，将“Connection Mode”设置为“Rendezvous”；
③“Address”一项填入北京总部解码器HDD-461的出口公网IP地址“203.0.113.74”；
④“Destination Port”一项填入一个没有被使用的UDP端口号“12345”；
⑤“Latency” （传输延时）、“Encryption”（加密）、“Bandwidth Overhead”（带宽开销）、“Time To Live”（TTL）、“Type of Service”（ToS）可使用默认值。

图3-7 HDE-650S的SRT输出设置

然后我们再来看解码器HDD-461，参考下图HDD-461的输入设置（解码器的其他参数设置不在此处表现）：
①“Input Name”可以填写一个方便识别的任务名称，此处设置为“SRT_Rendezvous”；
②“Input Source”选择“SRT”，设置为SRT模式；
③解码器使用Rendezvous模式，“SRT Mode”设置为“Rendezvous”；
④“Address”一项填入广州办事处编码器HDE-650S的出口公网IP地址“198.51.100.182；
⑤“Listener Port”一项填入选择的UDP端口号“12345”；
⑥“Latency” （传输延时）、“Encryption”（加密）、“Bandwidth Overhead”（带宽开销）、“Time To Live”（TTL）、“Type of Service”（ToS）可使用默认值。

图3-8 HDD-461的输入设置

如果一切正常，完成这些配置后，这家公司北京的领导应该就能看到广州办的实时视频了。

3.3. 探讨：Rendezvous模式与防火墙
我们在前面的模拟场景中很轻松就完成了Rendezvous模式下的SRT连接，看似水到渠成，然而实际情况并不是这么简单，在这背后还隐藏着一些网络的相关知识，下面我们就来简单讨论一下SRT使用Rendezvous模式穿过防火墙建立连接的情况，毕竟知其然，也要知其所以然。

当然，网络安全与防火墙是一门很深奥的专业网络知识，我的能力有限，就不跟大家讨论深层次的内容了，这里只针对和SRT相关的知识做简单的分享。

图3-9 负责网络安全的防火墙
（图片来自网络）

首先，我们需要知道，在使用Rendezvous模式时，设备发出的控制信息数据包的源端口与目的端口都是一样的。在之前的例子中，编码器发出的控制信息数据包的源端口为12345，目标端口也是12345，同样的，解码器发出的控制信息数据包的源端口和目标端口也都是12345。换句话说，这“四个”端口号相同是Rendezvous模式穿越防火墙建立SRT连接的必要条件。

因此，在编解码器之间的防火墙就必须确保不转换数据包包头中的端口号。

图3-10 Rendezvous模式下两端使用相同的端口号穿过防火墙建立SRT连接

现在市场上能够见到的防火墙，基本都是能够进行状态检测的状态防火墙（stateful firewall，现在由于这个功能过于普遍，也就不再有人特意提出这个概念了），它能够进行状态数据包检查或状态查看，实现连接追踪（connection tracking）的功能，而Rendezvous模式正是倚靠这个功能来创建一个贯穿两个防火墙的网络通道，并在其中进行数据传输。

防火墙在工作时，会根据正在传输的流量，创建一个连接追踪表（connection tracking table），并保持动态更新。

例如在上图中，在防火墙A中的连接追踪表会记录下源设备HDE-650S的内网IP和端口号、NAT转换后的公网IP和端口号、以及访问的目标设备HDD-461防火墙的公网IP和端口，如下表：

这时，当对端发来数据包时，防火墙A的连接追踪表还会记录下另一条反向入站信息，如下表：

当反向的数据包到达防火墙A时，发送数据与接收数据相同的端口号会对防火墙A产生“欺骗”效果，让它认为收到的入站数据是对出站数据的回复消息，从而允许数据包通过防火墙，一直到这个传输会话断开，SRT连接也就这样建立起来了。

在大多数非专业场景中，我们用的网络设备都是使用PAT（NAT重载）进行公网IP到局域网IP的地址转换（如家用路由器等），这时，网络设备在转换地址时都会改变源端口号，所以Rendezvous模式大多无法使用，不如直接用路由器做静态端口映射规则来的方便，这样就可以在这端使用Listener的模式，监听映射的端口，另一端使用Caller模式建立连接；相比之下，Rendezvous模式反而是很少被用到。

Chapter 4. 配置SRT传输参数
当我们真正使用互联网去传输视频的时候，千变万化的网络环境是我们不得不面对的，要想在各种复杂的网络环境下都能顺利地传输视频，就必须要学会如何去优化SRT传输设置，还记得我们在上一章中使用默认配置的那些参数吗？他们就是让SRT工作在最佳状态的关键。

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值平均约为50 ms。

图4-1 通过ping命令得到RTT的大小

除此之外，如果两台SRT设备已经建立连接，还可以在设备的“Statistics”统计信息中查看两台设备间的RTT值，如下图。

图4-2 在HDE-650S中SRT Statistics显示的RTT

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首部开销，而是根据网络情况实时变化的，网络链路条件越差，正常传输所需的开销就越多。

图4-3 HDE-650S中的SRT Bandwidth Overhead设置

在高骏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-6 SRT中的AES加密

4.1.7. 传输过程中的Latency、Buffer和BW Overhead
了让前面介绍的几个参数更好理解，下面我们通过一张图表来将它们形象的表现出来，下图描述了在一次SRT传输过程中，传输数据量随着时间的变化图，期间由于一次网络问题，传输数据量降为零，短暂的链路断开后，又恢复了数据传输，具体如下：

图4-7 SRT传输过程中的传输数据量变化图
（图片来自SRT Alliance的指导文档《SRT Deployment Guide, v1.1, Issue 01》）
＊注：
1. 绿色直线：表示该链路可用的最大带宽；
2. 红色虚线（偏上）：表示根据流量带宽和BW Overhead计算得到的SRT最大带宽；
3. 红色虚线（偏下）：表示正常情况下的流量带宽，即视频、音频、元数据等；
4. 蓝色曲线：表示传输数据量随时间变化的曲线；
5. 灰色区域：表示接收端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-8 在HDE-650S中的SRT Statistics统计信息

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-9 在HDE-650S中的SRT Statistics统计信息

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状态、重传、丢包数、带宽信息、网络状态信息等等参数，如下图：
图4-15 HDD-461的Link Statistics统计信息

其中，可以选择曲线图的取样时间范围，可选择最近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延时来解决

结束语
当大家看完前面的内容，可能会有各种各样的想法，或是为语言的漏洞而感到不满，或是因我的不专业而觉得滑稽，但是无论如何，我都希望每个人在读过这些文字之后，多多少少能够有所收获，从而让我觉得自己反复推敲的措辞并不是徒劳，也让我能感受到写作、分享是快乐的，毕竟这是我第一次自发的、有思想的写东西出来。当然，如果你能帮我发现这篇文章中有的错误，或是有任何的意见和建议，还是希望你能通过我的邮箱告知我：[email protected]。

最后说回SRT这件事，我看到自SRT Alliance成立以来，已经有越来越多的公司和组织加入了这个联盟，如大家所熟识的微软、爱立信、IMT、罗德与施瓦茨等等，也有VLC这种开源媒体播放软件开始支持SRT，也许以后SRT真就成了手机和电脑上无处不在的东西了呢，到时候我写的这几段文字可能也就显得更加浅薄了，但是无论如何还是希望好的技术能够越来越强大，这样技术才能不断进步，人们的生活才能逐步改善。

2019年6月7日记：
就在我想要将这篇文档上传到CSDN的几天前，我看到SRT在官网上更新了一些新消息：一，是OBS将开始支持SRT ；二，SRT P2P，即SRT点到点传输；三，安全性提升；四，将支持FEC；五，将支持路由冗余。另外，Alliance官网上的Deployment Guide也对之前的版本做了更新，尤其在FQA部分增加了很多新的内容。我看到的SRT已经在开始逐步进化了，大家让它变得越来越强大、安全、稳定，也让它越来越具有普适性，我真心希望它能茁壮地成长起来。
————————————————
版权声明：本文为CSDN博主「梁泽仁」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_42228920/article/details/90946259