新一代直播传输协议SRT

Photo by Vlad Alexandru Popa from Pexels

SRT协议是基于UDT的传输协议，保留了UDT的核心思想和机制，抗丢包能力强，适用于复杂的网络。在LiveVideoStack线上分享中，新浪音视频架构师 施维对SRT协议的原理、优缺点特性以及在流媒体中的应用进行了详细解析。

文 / 施维

整理 / LiveVideoStack

视频回放 

https://www2.tutormeetplus.com/v2/render/playback?mode=playback&token=a1564111ef934005b4b1acf2105128e3

1. 为什么选择SRT？

 

毋庸置疑，现今存量最大的直播协议是RTMP，但随着新技术的不断发展与使用场景的不断拓展，继续使用RTMP会令人感到有些力不从心。RTMP协议的缺陷主要有以下四个方面：

 

RTMP协议缺陷

首先，RTMP协议太老，且最后一次更新是在2012年；同时HEVC/H.265/AV1等视频格式都没有官方定义，以至于需要国内CDN厂商自行定义。

 

RTMP连接过程较长，由于RTMP基于TCP（TCP存在三次握手），除此之外，其本身又存在c0/s0到c2/s2的三次握手，再加上connection，createstream，play/publish，总地来说RTMP完成一次建连需要进行9次会话，用于PC端勉强能够接受，对于移动端网络质量的要求则很高。

 

RTMP的拥塞控制完全依赖传输层，即完全依赖于TCP传输层的拥塞控制算法来进行拥塞管理，几乎没有什么优化；RTMP本身基于TCP传输，无法提供带宽自适应的算法。

 

在此背景下，众多厂商开始着手提供一些新的直播协议供行业参考。如QUIC、SRT等。本次我们将重点讲述SRT的特点与应用。

 

SRT协议的特点

 

Haivision联手Wowza在UDT的基础上针对音视频实时性提出了SRT协议。SRT是基于UDT的协议（UDT协议是基于UDP的传输协议，在IETF已经提交了4个版本），具有非常良好的丢包重传机制，丢包重传的控制消息非常丰富，同时支持ACK、ACKACK、NACK。

 

我们都知道音视频对于时间这一点非常在意，而SRT基于时间的报文发送，使其具有良好的防止流量突发的能力。SRT对上层提供了丰富的拥塞控制统计信息，包括RTT、丢包率、inflight、send/receive bitrate等。利用这些丰富的信息，我们可以实现带宽预测，并根据带宽的变化在编码层去做自适应动态编码与拥塞控制。

2. SRT协议原理分析

 

2.1 SRT基本思想

 

上图可以涵盖SRT的基本思想：对比编码后的视音频码流（左侧绿色折线“Source”）与经过公网传输后的码流（红色折线“NetworkTransmission”），可以看到编码后的源视音频码流具有固定的帧间隔与一定特性的可变比特率，但经过公网传输后的码流，其帧间隔变得不固定且码率特性也被完全改变，解码这样的信号是一项十分艰巨的挑战，甚至根本无法解码。

 

而如果使用加入纠错的SRT协议进行公共互联网传输，尽管编码后的视音频码流经过公网传输帧间隔变得不固定，但由于SRT协议封装中包含精准的时间戳，解码接收端可以通过该时间戳重现固定的帧间隔。更重要的是，通过规定延时量，同时划定了send buffer（发送端缓冲区）与receive buffer（接收端缓冲区），来自接收端的反馈信号（可以理解为后向纠错）通过一系列的设置、纠错、流量控制，使编码后的视音频码流拥有与原码流几乎一样的码率特性。

 

Encoder编码器处理完成的数据会被输入send buffer，send buffer会对数据进行时间校验，也就是按照一定的时间顺序编码并通过internet发送至receivebuffer，receive buffer按照报文上的时间戳一点点处理，确保生成的数据与源码流基本一致。

 

整个SRT协议的思想基于编码，具有抗丢包、抗拥塞、抗抖动等特性。

2.2 SRT报文基础

交互过程