SRT开源的视频传输协议
原文出处：SRT: 开源的视频传输协议
SRT（Secure Reliable Transport）是新一代低延迟视频传输协议，是一种开源、免费和应用灵活的规范，它的性能与专用的协议一样优秀，同时能够在不同制造商生产的产品之间工作。本文主要参考Haivision的SRT白皮书，概述了SRT的一些关键特性，并将SRT与常见传输格式及新一代传输协议QUIC进行比较，最后简述SRT的发展现状。
关键特性
直接建立连接
SRT允许直接在信号源和目标之间建立连接，这与许多现有的视频传输系统形成了鲜明对比，这些系统需要一台集中式服务器从远程位置收集信号，并将其重定向到一个或多个目的地。基于中央服务器的体系结构有一个单点故障，在高通信量期间，这也可能成为瓶颈。通过集线器传输信号还增加了端到端信号传输时间，并可能使带宽成本加倍，因为需要实现两个链接:一个从源到中心集线器，另一个从中心到目的地。通过使用直接从源到目的地的连接，SRT可以减少延迟，消除中心瓶颈，并降低网络成本。
使用ARQ机制进行包投递
比较三种包投递机制，顶部是一个未经纠正的数据流，每当包丢失时，输出信号就会产生错误。中间按照前向纠错 (Forward Error Correction，FEC)机制，它向流中添加固定数量的额外数据，可用于重新创建丢失的包。底部按照自动重传请求（Automatic Repeat-reQuest，ARQ）机制，发送方根据接收方的请求重新发送丢失的包，从而避免了FEC的恒定带宽消耗。
ARQ的工作原理是在视频源和目标之间建立双向连接。每个出站数据包被赋予一个唯一的序列号，而接收者使用这些序列号来确定是否以正确的顺序正确地接收了所有传入的数据包。如果数据包在网络中丢失，接收方可以创建丢失信息包的序列号列表，并自动向发送方发送请求，以便重新传输。对于错误率高的网络(特定时间或发生故障时的网络)，这个过程可以重复多次。ARQ要求在发送位置进行缓存(为了在需要重传的情况下临时存储数据包)，在发送到视频解码器或其他接收器之前，在接收位置设置一个缓冲区，将数据包重新排列到正确的顺序。
SRT使用ARQ机制主要是因为它可以处理互联网上最常见的错误类型，即损失主要是由随机的丢包造成的。这些错误可以很容易地通过发送方对没有到达接收方的任何数据包进行简单的重传来修复。如果包含位错误的信息包到达接收方，它们将被视为丢失的信息包，发送方将被要求重新传输它们。另一个好处是，SRT为每个包提供高分辨率的时间戳，以便在接收端输出时精确地再现媒体流的时序。这有助于确保下游设备能够正确解码视频和音频信号。
而FEC只适用于能够支持FEC数据所需额外带宽的系统，以及能够承受网络错误率超过阈值时可能发生的信号中断的系统。
使用UDP包格式
SRT会话期间发送的每个包都使用UDP(User Datagram Protocol)包格式，它提供了低开销、低延迟的包投递。大多数为专业应用程序而设计的实时媒体传输网络都使用UDP，因为它提供了稳定的、可重复的包投递系统，具有一致的吞吐量。
不使用TCP(Transmission Control Protocol)的原因在于TCP要求流的所有字节完全按照它们的原始顺序交付。虽然这听起来像是一种发送视频的好方法，但经验表明并非如此。有了视频，一些丢失的字节可以被纠正，或者在最坏的情况下被忽略。使用TCP，不可能跳过坏字节;相反，只要它需要,协议将继续重试发送丢失的数据。这是许多冻结帧的来源，也是在拥挤的网络环境中出现“rebuffering”符号的原因，可能会对观众产生重大影响。TCP的第三个影响是微妙的，但对视频传输很重要。TCP在网络拥塞发生时自动降低包传输速率，虽然这种行为有利于减少网络中的总体拥塞，但它不适用于视频信号，因为视频信号的速度不能低于其标称比特率。
以握手和功能信息交换开始
SRT提供了三种不同的握手模式，让设备相互联系，并设置发送和接收数据包所需的必要数据，例如IP地址。第一种是调用模式，其中SRT端点试图连接到一个已知地址和UDP端口号的远程设备。第二种是侦听器模式，在这种模式下，SRT设备将持续监视传入的通信流，以将其监视到定义的地址和端口号，以等待来自调用方设备的连接。第三种模式称为“汇聚”，其中两个端点同时充当调用者和侦听器，以便通过特定类型的防火墙更容易地建立连接。
每次握手都需要在继续之前通过使用安全cookie对端点标识和密码进行双向确认。握手过程完成后，调用者和侦听器交换它们的功能和配置。网络的两端都需要知道两个端点之间的总体延迟，以便能够建立正确的缓冲区大小来处理包重传延迟。连接带宽也可以估计和通信，以允许视频被压缩至适应网络的容量。可以选择在发送方和接收方之间交换加密密钥，以使用AES 128/192/256位加密对IP包内的视频和音频内容进行加密，使传输更安全。
SRT与常见传输格式比较
SRT与目前市场上的大多数其他视频流传输格式(如RTMP、HLS和MPEG-DASH)相比有几个特点，包括:
非专有
SRT是一个开源解决方案，已经集成到多个平台和体系结构中，包括基于硬件的可移植解决方案和基于软件的云解决方案。因为所有的系统都依赖于相同的底层代码库，所以互操作性被简化了。
能处理长时间的网络延迟
由于其灵活的、自适应的缓冲区管理系统，SRT可以在几毫秒到几秒的延时之间的连接上很好地工作，因此可以处理任何可能在私有网络或全球Internet上发现的东西。
支持多种流类型
与其他一些只支持特定视频和音频格式的解决方案不同，SRT与负载无关。任何类型的视频或音频媒体，或者实际上任何可以使用UDP发送的其他数据元素，都与SRT兼容。
支持多个并发流
多个不同的媒体流例如多个摄像机角度或可选音频轨道，可以通过在一个点对点链接上共享相同UDP端口和地址的并行SRT流发送。这可以在保持每个信号的媒体格式和时序的同时实现，从而允许MP4视频信号与JPEG2000流共享链接。这简化了网络配置和防火墙遍历。
增强防火墙遍历
任何现代组织，无论是基于媒体还是其他，都不允许企业系统无限制地访问公共互联网。防火墙保护私有网络设备(如pc和服务器)免受不必要的外部连接和攻击。SRT使用的握手过程支持出站连接，而不需要在防火墙中打开危险的永久外部端口，从而维护公司安全策略。
信号时间准确
许多压缩视频信号格式对信号不同元素之间的时序变化所造成的中断非常敏感。使用SRT，每个数据包都有一个由发送方分配的高分辨率时间戳，接收方可以恢复该时间戳，以精确重建信号时序关系，而不考虑网络延迟变化。此外，在握手过程中，SRT端点建立了稳定的端到端延迟概要，消除了下游设备需要有自己的缓冲区来应对不断变化的信号延迟。
无需中央服务器
一些专有媒体传输系统需要在发送方和接收方之间使用集中式服务器，这会增加成本和延迟。SRT连接可以直接在设备之间进行，因此不需要中央服务器。此外，如果需要，可以使用集中式服务器和中继点部署SRT，以便应用程序(如基于云的内容收集系统和以集中式模型为首选的剪辑分发网络)。
成本低
SRT系统是使用免费的开放源代码库实现的，这有助于降低各方的成本。SRT部署不需要版税、长期合同或每月订阅费。
基于API
SRT技术包基于API，允许供应商与平台和端点建立紧密的、可重复的集成。
拥有开源社区
SRT已被业界领先的开源项目所采用，例如:
- VideoLAN的VLC，免费的开源跨平台多媒体播放器和框架;
- GStreamer是小型设备和移动设备的基础流引擎;
- Wireshark，领先的网络流分析仪;FFmpeg是世界上最流行的开源视频压缩工具包。
与QUIC比较
SRT和QUIC都旨在克服UDP的包丢失和测序问题，同时消除TCP(传输控制协议)常见的缓冲延迟。两种协议都使用TLS 1.3提供安全传输，TLS1.3是传输层安全协议的最新版本。
QUIC使用了许多技术来最小化阻塞，例如根据每个流所采取的路径估计持久带宽，根据带宽判断包生成的节奏，以及主动重传支持错误纠正或开始加密等事情的最重要的包。
QUIC还通过减少建立连接所需的往返次数，以及避免在建立了主连接之后在Web页面上与次要源建立连接，从而降低了延迟。与握手、加密设置和初始数据请求相关联的多个步骤合并在初始设置中，而像HTTP/2所采用的压缩和多路复用过程用于避免访问页面上的子源的单独设置。
SRT使用了许多这些技术的变体，包括快速会话设置、带宽估计和通过低延迟重传技术处理包丢失恢复，它在拥塞高时通过丢包来缓和这种情况。但是，SRT不是依赖HTTP和ABR来改变比特率以适应带宽可用性的变化，而是实时分析网络条件并过滤掉抖动、噪声和拥塞的影响。
由于SRT与HTTP Live streaming (HLS)、MPEG-DASH和其他ABR模式下的流媒体标准大相径庭，因此在中段和终段应用程序中，它面临着一场艰苦的战斗。
发展现状
在今年5月举行的plug-in大会上，15个联盟成员成功完成了50多项测试，验证了摄像头、编码器、解码器、网关、多观众和玩家之间的SRT流。
Haivision 和 Wowza共同创建了SRT联盟，自从SRT在2017年成为一种开源技术以来，已有130多家公司通过支持SRT联盟支持了该开源项目。他的供应商和终端用户共同努力，以提高业界对SRT的认识，并将其作为互联网上低延迟视频传输的通用标准。突出的SRT联盟成员包括Ateme、Blonder Tongue、Brightcove、Ericsson、Eurovision、Haivision、Harmonic、Limelight,、Matrox、Sencore和Wowza。
现在，有超过50种支持SRT的产品已经上市，包括IP摄像机、编码器、解码器、网关、OTT平台和CDNs。SRT协议在全球许多应用程序和市场上被数千个组织使用。最终用户包括康卡斯特(Comcast)、ESPN、福克斯新闻(Fox News)、微软(Microsoft)、NBC体育(NBC Sports)、美国橄榄球联盟(NFL)和腾讯(Tencent)。
参考资料
[1]https://www.haivision.com/resources/white-paper/
原文出处：知否知否 SRT技术到底是什么？
传统的IP编解码器大多使用UDP等不可靠传输协议直接进行传输，无法解决公网环境下的抖动与丢包问题，因此，这类编解码器方案无法直接应用于普通互联网传输的场景。
而高骏（北京）科技有限公司推出的编解码与媒体网关产品，使用SRT可靠传输技术，成功实现了普通互联网环境下、多地之间，安全可靠的高清视频传输与分发。
那么实现普通互联网下可靠传输的SRT技术到底是什么？
1. SRT联盟
想了解SRT技术，我们可以从SRT联盟说起，这是一个由Haivision和Wowza合作成立的，管理和支持SRT协议开源应用的组织，这个组织致力于促进视频流解决方案的互通性，以及推动视频产业先驱协作前进，实现低延时网络视频传输。
联盟成立后，高骏（北京）科技有限公司率先加入了该组织，并且成为首批进入“SRT Ready”状态的公司（研发出SRT产品，并通过SRT联盟官方联调）。
2. SRT传输技术
SRT（Secure Reliable Transport）是一种能够在复杂网络环境下实时、准确地传输数据流的网络传输技术，它在传输层使用UDP协议，虽然UDP协议是一种不可靠传输协议，但是凭借SRT强大的数据恢复能力，再加上UDP协议自身速度快、开销低的特点，最终实现了SRT安全、稳定、快速的传输效果。
SRT是一种面向连接的点对点协议，每一路SRT流仅需一个UDP连接，其中除了一路要传输的数据流外，还包含了双向的控制信息。
Encrypts video streams
Recovers from severe packet loss
Dynamically adapts to changing network conditions
协议的特点正如其名：通过加密保证传输内容的安全；在严重丢包的情况下可靠地恢复数据流；动态适应时刻变化地网络情况传输数据。
得力于其可靠的传输质量和极低的传输延时，SRT技术被广泛应用于视频流传输领域。
在音视频流从SRT源设备（如下图中编码器）传输到SRT目标设备（如下图中解码器）的过程中，SRT会实时地检测和适应两台设备间不断变化的网络状态，抵抗由于网络拥塞而导致的带宽抖动，凭借其强大的错误恢复机制，将网络丢包的可能性降到最低。同时SRT还可以进行AES加密，从而确保数据在传输过程中的信息安全。
注：文章中将分别以蓝、黄两种颜色强调SRT源设备和SRT目标设备，方便大家理解描述语句。
3. SRT的典型应用模式
由于SRT技术安全、可靠、快速的特点，它可以适应各种各样的使用需求。而且，有SRT协议的存在，即使你不掌握复杂的IP路由和交换知识，也可以快速地建立起视频传输通道，完成视频传输任务。
这里简单地列出几个最典型的应用模式：
（1）点对点单向传输和视频互动
SRT最简单的应用方式，就是在两点之间进行视频传输工作，比如进行单向视频传输，将视频从A地传输到B地；或者两地互传，实现两地间的双向视频互动。
点对点单向视频传输
点对点双向视频互动
注：
HDE-650S：高骏公司自主研发的SRT互联网传输编码器，支持4:2:2编码； HDD-461：高骏公司自主研发的SRT互联网传输解码器； 两台设备搭配使用最低支持40ms超低编解码延时。
这里简单介绍一下HDE-650S和HDD-461。作为专业的编解码设备，它们分别支持输入和输出多种基带信号格式，支持ASI、UDP和SRT等多种数据流格式的输出、输入，同时支持4:2:2演播室级编码，编解码延时最低可达40ms，是理想的编解码解决方案。
（2）点对多点传输
通过使用高骏SMH媒体网关，可以将一个编码器发出的视频流，分发给多个解码器，以SMH媒体网关为中心节点，先接收编码器发出的视频流，再将其复制、分发给多个解码器，从而实现点到多点的视频传输。
注：
SMH是高骏公司自主研发的SRT媒体网关。在这里，SMH媒体网关既是SRT目标设备，接收来自编码器HDE-650S的视频流；同时也是SRT源设备，将视频流发送给多个解码器HDD-461。
（3）视频流协议转换与分发
凭借媒体网关设备，可以实现SRT、TS over UDP、RTMP PULL/PUSH等多种视频流协议的输入与输出，并对各个视频流进行复制、转换、分发等工作，这大大增加了SRT系统的兼容性，使本地TS over UDP和RTMP流能够顺利融入SRT系统，提高视频转发的灵活性。
本次内容和大家简单分享了SRT技术的由来和特点，以及一些常见的应用模式，相信各位已经对SRT技术有了一定的了解。下一期技术分享“Section 2. SRT协议解析”，我们会详细阐述SRT的工作原理以及握手模式，敬请期待！
参考资料：
（1）SRT Alliance指导文档《SRT Deployment Guide, v1.1, Issue 01》 （2）白皮书《Haivision SRT Open Source White Paper》 （下载链接：www3.haivision.com/srt-alliance-guide，www3.haivision.com/srt-open-source-wp） 如有描述或翻译用词不当之处，还请大家帮忙指出，我们共同交流。
原文出处：SRT协议解析
1.SRT工作原理
要说SRT的工作原理，我们先从其纠错机制说起。
下面描述了在数据包传输过程中，不使用数据纠错，使用FEC（Forward Error Correction）纠错，和使用ARQ（Automatic Repeat request）纠错三种链路传输方式的模式和结果。
如果没有数据纠错，结果自不必说，一旦发生丢包，得到的就是不完整的数据流，如下图。
数据包传输时没有纠错机制 图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》
如果使用FEC纠错，则会在传输的数据流中加入一定比例的前向纠错数据，当发生丢包时，接收端就可以根据前向纠错数据，恢复丢掉的数据包，如下图。
但是使用FEC就必须面对这样的问题：无论是否产生丢包，前向纠错数据都需要占用一定的传输带宽；而且当丢包率超过前向纠错数据能够恢复的阈值时，FEC将无法恢复丢失的数据包。
数据包传输时使用FEC纠错 图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》
如果使用ARQ纠错，就需要在发送端和接收端之间建立双向连接。在接收端收到数据包后，会按照数据包的顺序进行排序（传输过程中数据包可能会发生乱序），如果发现其中有丢失的数据包，就会向发送端发出重传请求，由发送端将丢失的数据包重新发送到接收端，从而实现数据包的恢复，如下图。
数据包传输时使用ARQ纠错 图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》
而我们说的SRT技术，正是使用的ARQ纠错机制，这主要是因为在网络传输时，带宽抖动和丢包通常都是随机发生的，只有在网络出现问题的时候才需要纠错机制的介入，只需在发生丢包后让发送端重传丢失的数据包即可，这样既保证了传输的质量，同时又能减少无谓地消耗传输带宽；除此之外，SRT会为数据包提供更精准的时间戳，让接收端能够准确校准媒体流的包顺序，保证传输正常。
之前已经说过，SRT协议依靠双向传输的UDP流来保证公网环境下的视频传输质量。除了从SRT源设备到SRT目标设备持续发送视频数据外，在两台设备之间还会持续地交换SRT控制信息，以此来在两台设备之间实现以UDP为底层协议的连接，进行信息交互，确保视频数据能够准确地传输到接收端。
SRT连接中的双向UDP流
注：
SRT源设备发送的UDP流包含数据业务流和SRT控制信息； SRT目标设备接收源设备发来的UDP流，同时回复相应的SRT控制信息。
为了让SRT保持连接状态，必须确保控制信息数据包的发送间隔不超过10ms。每当SRT目标设备收到一个数据包后，都会回复一个“ACK”确认控制信息数据包，告诉SRT源设备已经收到这个数据包，如果在10ms内收到多个数据包，则只回复一个“ACK”，确认这期间收到的所有数据包；然而，数据包的到达时间间隔难免会超过10ms，这时就需要增加“keep alive”控制信息数据包，确保SRT连接不会断开。
在SRT连接中，从目标设备返回源设备的控制信息通道也会占用一定的带宽。在业务数据完全正常传输的情况下（即没有错误信息需要返回到发送端），控制信息占用带宽大约为40Kbps；传输时丢失的数据包越多，目标设备发出的控制信息就越多，信息量会与丢包率线性相关，每丢失1个数据包，大约会消耗400bps的可用带宽。
2.SRT握手模式
现在我们已经知道SRT的工作原理了，那么一个SRT连接又是如何建立的呢？要清楚这个问题，我们就不得不了解SRT握手模式：Caller & Listener和Rendezvous。
在讨论建立SRT连接时，我们不需要区分SRT源设备和SRT目标设备，发送端和接收端都可以发起建立SRT连接，我们只要知道哪端的设备满足设置相应模式的网络需求即可。
01 Caller模式
功能：
设置Caller模式的设备将作为SRT会话的发起者，它必须知道对应设置Listener模式的设备的公网IP地址及其监听的UDP端口。
使用场景：
① 让一台设备发起建立一个点对点传输的SRT连接； ② 设备所在的网络有防火墙，但没有防火墙操作权限； ③ 设备的IP地址是DHCP动态获取的； ④ 设备没有固定的公网IP地址。
02 Listener模式
功能：
设置Listener模式的设备会监听发起SRT会话的请求，它需要知道应该使用的UDP端口（如网络管理员分配给SRT传输使用的UDP端口），并一直在这个端口上监听发起SRT会话的请求。
使用场景：
① 让一台设备监听发起SRT会话的请求； ② 设备所在的网络有防火墙，并且可以控制防火墙，打开需要的UDP端口； ③ 设备直接暴露在公网环境下。
03 Rendezvous模式
功能：
两台设置Rendezvous模式的设备会共同协商，通过相同的UDP端口号建立一个SRT会话。
使用场景：
① 两台设备所在的网络都有防火墙，但是没有防火墙的操作权限，如果防火墙设置了适当的工作模式（将在Section 3. SRT实际应用场景中详细介绍），可通过此模式建立SRT会话。
一旦完成SRT连接的建立，SRT源设备和SRT目标设备便开始交换控制信息，如网络状况信息、丢失的数据包等等，无论设备设置的是Caller、Listener还是Rendezvous模式都无关紧要了，直接利用建立起来的SRT通道去传输数据就可以了。
3 SRT如何建立连接
那么这三种握手模式实际又是如何把SRT会话建立起来的呢，下面我们通过简单地图示来了解这个过程。
（1）由SRT源设备发起建立SRT连接
如下图，将编码器HDE-650S设置为Caller模式，解码器HDD-461设置为Listener模式，编码器（Caller）将向设置的UDP端口连续发送控制信息数据包，请求建立SRT连接（图中①），当解码器（Listener）收到这些数据包后，便开始回复它自己的控制信息数据包（图中②），一旦握手成功，编码器便开始在UDP流中增加视频流，开始视频传输（图中③）。
SRT源设备发起建立SRT连接的过程
（2）由SRT目标设备发起建立SRT连接
如下图，将编码器HDE-650S设置为Listener模式，解码器HDD-461设置为Caller模式，解码器（Caller）将向设置的UDP端口连续发送控制信息数据包，请求建立SRT连接（图中①），当编码器（Listener）收到这些数据包后，便开始回复它自己的控制信息数据包（图中②），一旦握手成功，编码器便开始在UDP流中增加视频流，开始视频传输（图中③）。
SRT目标设备发起建立SRT连接的过程
（3）使用Rendezvous模式建立SRT连接
如下图，SRT源设备和SRT目标设备同时设置为Rendezvous模式，两台设备一起向对方发送控制信息数据包，一旦握手成功，编码器便开始在UDP流中增加视频流，开始视频传输。
使用Rendezvous模式建立SRT连接的过程
4.SRT与防火墙
在实际使用场景中，特别是在通过互联网进行数据传输时，终端设备通常都会经过防火墙再连接到互联网，SRT流就必须穿过防火墙进行传输。这种情况下，我们就需要网络管理员来帮忙对防火墙进行适当的配置，尤其像网络地址转换（NAT）和数据包过滤的设置，防火墙的配置情况将会决定设备使用哪一种握手模式。
下图中，一台编码器尝试通过互联网将视频流发送给解码器，两台设备都在防火墙后。我们不妨假设编码器使用Caller模式，解码器使用Listener模式，为了使它们握手成功，并建立SRT会话，就必须满足下列条件：
① 解码器端的防火墙需要允许某个供SRT使用的UDP端口可以从互联网接入； ② 编码器必须知道解码器端防火墙的公网IP和开放的UDP端口； ③ 两端的防火墙都要允许双向UDP传输； ④ 两端的防火墙都要配置端口转发（NAT），允许编码器和解码器之间的数据流传输； ⑤ 两端的防火墙都要关闭数据包过滤功能，允许编码器和解码器之间的交互数据包通过。
经过防火墙进行视频传输
本次内容向大家介绍了SRT技术的工作机制，让大家在“什么是SRT”的基础上进一步了解了SRT的原理及基本策略，相信各位已经跃跃欲试了。下一期技术分享“Section 3. SRT实际应用场景”，我们会通过实例展示如何配置使用SRT来进行视频传输，敬请期待！
（由于篇幅有限，本文对传输纠错机制以及传输协议都没有深入介绍，后续有机会我们会专门和大家进行更细致深入的交流。）
参考资料：
（1）SRT Alliance指导文档《SRT Deployment Guide, v1.1, Issue 01》
（2）白皮书《Haivision SRT Open Source White Paper》
（下载链接：www3.haivision.com/srt-alliance-guide，www3.haivision.com/srt-open-source-wp）
如有描述或翻译用词不当之处，还请大家帮忙指出，我们共同交流。