音视频开发系列（16）技术解码 | SRT和RIST协议综述

 概要 

近些年来，互联网行业出现了几波和音视频相关的热潮：VR、短视频、直播等。除了VR因技术成熟度问题，还在蓄势待发，短视频和直播持续热度不减，以各种方式进入新的行业应用领域。视频直播方向，RTMP仍是最流行的上行传输协议，但RTMP的局限性也越来越凸显：

• RTMP的容器格式FLV，存在不支持新的codec、不支持多音轨、时间戳精度过低等等缺陷；

• RTMP基于TCP做传输，TCP的公平、可靠传输设计并不适用于实时音视频传输。

业界出现了一些新的上行传输方式：SRT、RIST、基于WebRTC的推流、基于fmp4的推流（DASH-IF Live Media Ingest Protocol）等。腾讯云支持SRT协议直播推流，客户反馈相比传统的RTMP，SRT对推流卡顿问题有明显改善[1]。本文重点介绍SRT的功能特性、适用的场景以及后续改进提升的方向，并简要介绍下RIST协议。

 SRT协议 

SRT协议的起源和发展

SRT协议继承自UDT协议，包括协议设计和代码库。UDT是基于UDP的文件传输协议，最初是针对高带宽、高延迟场景（如远距离光纤传输）设计，用于弥补TCP的不足。关于UDT协议的详细介绍见Experiences in Design and Implementation of a High Performance Transport Protocol, Yunhong Gu, Xinwei Hong, and Robert L. Grossman 2004][2]。Haivision将UDT用于流媒体传输，加入了针对流媒体传输场景的优化特性，如端到端固定延迟等，改造成了SRT协议。SRT协议标准目前还处于草稿阶段[3]。Haivision在2017年开源了libsrt项目[4]，并成立SRT联盟，迄今为止已有500多成员。腾讯云是SRT联盟成员之一[5]。

SRT的功能特性

• 两种传输模式：file文件传输模式和live直播流模式；
  这里我们主要关注live模式。live模式既支持loss模式也支持lossless无损模式。

• SRT作为传输协议，可以使用任意流媒体封装格式；
  但要注意，loss模式要求容器格式必须有错误恢复resync机制，可选范围基本只剩下TS格式或者H.264、annexb之类的裸流。

• 双向传输；
  这一能力使得SRT在一些场景可以替换TCP，比如用SRT做RTMP的传输层。但要注意，SRT设计上是假设双向传输的流彼此无依赖关系，而RTMP存在双向的信令交互，RTMP over SRT模式会出现一些非常隐蔽的缺陷，见后文详述。

• 支持ARQ和FEC两种丢包恢复机制；

• 支持connection bonding，目前处于实验阶段。

固定延迟

SRT最突出的特性是端到端固定延迟（Fixed end-to-end latency）。一般的传输协议，从一端send()到另一端receive()所占用的时间是波动的，SRT抹平了网络的抖动，可以保证从srt_sendmsg()到srt_recvmsg()的时间基本恒定。srt_sendmsg()给数据打一个时间戳，在接收端检查时间戳，决定什么时候可以把数据交给上层应用。核心思想并不复杂：buffer抗抖动，根据时间戳保持固定延迟。具体实现还考虑了time drift问题。

端到端延迟约等于配置的SRTO_RECVLATENCY + 1/2 RTT0，RTT0是握手阶段计算得到的RTT。配置的latency要足够补偿RTT的波动，同时考虑丢包重传次数。

固定端到端延迟由TSBPD（Timestamp-based packet delivery）开关控制，是否允许丢包由TLPKTDROP（Too late packet drop）控制。前者受后者影响，只有允许丢包，才能保证固定延迟，否则网络情况较差时，到达的数据包会超过配置的延迟。在同时开启TSBPD和TLPKTDR