引言
文来自Haivision的白皮书，比较了RTMP和SRT两种流媒体协议的优缺点，并通过实验测试了两种协议在延迟和最大带宽两方面的表现。
介绍
对于希望在IP上以低端到端延时进行视频传输的人来说，可供选择的传输协议非常有限。尤其当使用公网作为传输媒介时，因为公网传输需要克服丢包、抖动等诸多障碍。基于此，文中比较和评估了两种常用协议RTMP和SRT的优缺点。
RTMP是一种成熟的流媒体协议，由于其基于TCP的包重传机制和可调缓冲区的能力，所以以可靠性著称。SRT是由Haivision开发的一种开源协议，它使用UDP数据流之上的智能分组重传机制，并使用AES256加密。文中研究了两种传输协议在公网上的传输能力，包括缓冲区的大小，延迟和带宽限制等。
传输时延对比
文中比较的时延指端到端延时，即一帧视频从摄像机采集到在显示器上显示所需要的时间。端到端延时主要受传输链和视频处理步骤的影响，包括编解码，传输媒介（互联网，卫星，光纤等），视频源和显示设备等。虽然每个步骤的延时较小，但累积起来会引入显著的延时。本部分的重点是研究RTMP和SRT对端到端延时的影响，为了使结果具有可比性，所以在测试阶段使用配置完全相同的设备，唯一的变量便是RTMP和SRT协议。但在某些情况下，为了获得稳定的RTMP流，需要对配置作出一定的更改。
测试装置
测试装置要求设计简单，易于复制，且不需要使用特殊的测试设备，最终的测试装置如图1所示。测试系统主要由信号源，显示屏幕，编码器，解码器，Wowza服务器和Haivision媒体网关服务器等组件构成。
信号源使用Blackmagic Hyperdeck Shuttle录像机作为视频源，直接作为第一个屏幕，另一个屏幕连接到编码器的输出端，两个屏幕均会显示时间码，时间码可以用来区分视频中的每一帧。使用一个摄像机捕获两个屏幕的图片（如图2所示），便可以根据时间码来得到编码过程中的延时。
图2 视频源与编码输出（时间差为编码时延）
编码器为一个Haivision KB或一个Makito X编码器。基带视频信号经过编码后，可以并行生成RTMP和SRT视频流，对两路视频流采取相同的音频和视频处理过程。编码配置参数如下所示。编码后的视频流码率达到了3Mbps，并且两路输出比特率有所差异，这是由不同的协议开销造成的。
表1 编码配置参数
解码器使用了VLC播放器，这是工业和家庭使用最广泛的视频播放器之一。本测试装置使用了标准的VLC安装设置，默认缓存为250ms。
RTMP流的传输目的地为Wowza流引擎，并托管在AWS上。而SRT流的目的地为Haivision媒体网关服务器，也托管在AWS实例上，并且二者位于同一个数据中心。虽然Wowza也支持SRT协议，但是它的SRT使用的是非常旧的版本，不能发挥SRT的全部潜力。
网络连接的上行链路由Fritzbox 7590 DSL调制解调器建立，下行链路为100Mps，上行链路为42Mbps。连接性能时刻处于监视状态，以确保该连接没有被其他应用程序饱和。
RTMP和SRT的一个主要区别是RTMP流包头中不包含时间戳，只包含实际流的时间戳，并且单个数据包不包含时间戳。因此RTMP接收端需要在规定的时间间隔内将每个接收到的数据包发送到解码器，为了消除各个包之间在传输时间上的差异，需要使用较大的缓冲区。而SRT流每一个数据包都包含时间戳，这使得接收端可以重建信号特性并且显著降低缓冲区的需求，也就是说，SRT发送端的比特流和接收端的比特流是高度相似的。RTMP和SRT流传输前后信号特性如图3所示。
（a）RTMP视频流信号特性
（b）SRT视频流信号特性
图3 RTMP和SRT流信号特性
RTMP和SRT的另一个显著区别是包重传机制。RTMP基于TCP，依赖于接收端返回的ACK，但是接收端在接收到一个包以后并不会立刻返回ACK，而是要在一系列的包接收完以后才会发回。如果发送端接收到ACK发现有丢包存在，则将当前的包序列重传。而SRT可以识别每个丢失的包，在发生丢包时只会重传丢失的包，从而能够降低延时。
此外，发送端和接收端的缓冲区大小也会影响延时。更大的缓冲区可以提供更高的吞吐量，但会引入更大的延时，并且每秒字节吞吐量必须小于缓冲区大小/RTT。客户端播放器越远，吞吐量就越小，除非距离很远，否则播放器的默认设置是足够的。但缓冲区也不能设置得太低，不然会严重限制吞吐量。在测试中，尝试使用65000字节的默认设置，但对于目的地在澳大利亚的流，RTT为360ms，为了实现稳定的流，所以缓冲区增加到260000字节。
延迟测试结果
与预期结果一样，视频流目的地越远，对端到端延迟的影响越大。这里的延时是指绝对的端到端延时，包含编解码，传输和显示设备延时。延时的测试结果如图4所示。
图4 往返端到端延时测试结果
德国-悉尼-德国：为了RTMP视频流和音频流的稳定，接收端缓冲区需要提高到260000字节，是默认设置的4倍。由于测试基于双向流，所以VLC播放器的接收缓冲区需要从默认值250ms增加到2000ms。低于这些值时，流的质量会受到影响甚至无法播放。
德国-California-德国：与悉尼相比，尽管去California的RTT约为悉尼的一半，但是RTT不是影响延迟的唯一因素。回到德国的链路有较大的波动导致单个包传输时间有差异。视频流从德国到California的传输使用默认缓冲区大小65000字节，返回路径需要增加缓冲区路径到650ms。
德国-Virginia-德国：令人惊讶的是，测试结果显示发送到Virginia的RTT比California的稍高（小于3帧或50ms），尽管在地图上Virginia距离德国更近。这说明最短的地理路径不一定是最快的，数据在数据中心和路由器之间以光速进行传输。根据数据链路的容量利用率，视频信号可能并不总是沿着最短的路径传输，而是以更快的路径而非更直接的路径。尽管RTT略高于California，但链路更稳定，抖动更少，并且允许RTMP缓冲区更小。使用默认值65000字节和250ms的VLC。
Thuringia-Frankfurt-Thuringia：对于从德国Thuringia到Frankfurt的AWS数据中心的媒体流，RTT只有17ms。端到端往返延时与Virginia和California相比并没有降低很多。但是，相比美国位置，SRT协议能够降低超过1秒的延迟。
在这些测试中，SRT相对于RTMP快了约2.5倍到3.2倍。如图5所示（使用Haivision KB编码器）。
图5 软件编解码器端到端延时测试结果
到目前为止，使用软件编解码最快的结果也有1.5s的延时，这在某些对延时要求较高的场景中是远远无法接受的。因此可以考虑使用硬件编码器和解码器来进一步降低延时。
测试装置中，硬件编解码器选型为Haivision Makito X，实际测试的延时结果如图6所示。实验结果表明，使用硬件编解码器可以显著降低延时。
图6 软件编解码器与硬件编解码器延时测试结果对比
CSDN站内私信我，领取最新最全C++音视频学习提升资料，内容包括（C/C++，Linux 服务器开发，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）
最大传输带宽对比
上面的测试结果证明了SRT在降低延时方面具有显著的作用，下面的测试则主要研究SRT在视频质量方面的性能。测试方法为逐步提高媒体流的带宽，并观察在当前带宽下视频流能否成功传输。考虑到延时才是测试的重点，所以在增加媒体流带宽时，保持缓冲区大小不变。带宽测试装置如图7所示。
图7 带宽测试装置
为了测试高带宽媒体流，测试地点选择了具有良好的互联网连接状况的地方——位于华盛顿Redmond的微软制作工作室，距离下一个互联网主要连接点只有两跳的距离，并且所有的连接设备都支持1Gbps的传输速率。具体测试方法为，使用2Mbps视频流来确定缓冲区大小，一旦2Mbps流稳定下来，则固定缓冲区大小不变，依次使用1，2，6，10，20Mbps的流进行传输测试。媒体流由Haivision KB5.4编码器提供，发送到California和Virginia的AWS数据中心的Haivision媒体网关，为了测试视频的质量，视频流通过SRT被发回Redmond，并在Haivision Play 2000机顶盒上播放。测试结果如图8所示。
图8 带宽测试结果
带宽测试结果表明，SRT在任何地方都可以传输高达20Mbps码率的媒体流，而RTMP只在发送端和接收端位于同一大洲时才表现良好，当距离过远时，如图8中红色线所示，只能传输2Mbps码率的流。
结论
在端到端延迟和最大传输码率方面，SRT的性能高于RTMP。尽管这些测试是在实验室中完成，并且使用工具包来添加丢包和抖动，但在测试过程中有意使用公网进行传输，所以结果仍然具有较高的可信度。展望未来，SRT会成为流媒体公网传输的又一个选择。