## 一、前言

目前互联网上的视频直播有两种，一种是基于RTMP协议的直播，这种直播方式上行推流使用RTMP协议，下行播放使用RTMP，HTTP+FLV或者HLS，直播延时一般大于3秒，广泛应用秀场、游戏、赛事和事件直播，满足了对交互要求不高的场景；另一种是WebRTC协议的直播，这种直播方式使用UDP的协议进行流媒体的分发，直播延时小于1秒，同时连接数一般小于10个，主要应用在视频通话、秀场连麦等应用场景。除了上述两种场景外，还有一种视频直播的场景，就是同时要求低延时和大并发的场景，比如赛事直播、股票信息同步、大班教育等。SRT可以很好地满足上述场景的要求。

开到这个srt协议，估计很多人和我一样都有疑问，srt一般叫字幕，之前还有rtp、rtsp、rtmp，这几年突然多了个srt的，以为他们是亲兄弟或者表兄弟。通过查阅相关资料，个人理解的是，srt协议就是udp协议的增强版，之前用udp就可以推拉流，而这个srt也是基于udp，同时增强了机制防止丢包，意味着可以做到低延迟和高并发。其实本人测试下来，在不开启音视频同步的情况下，rtsp是实时性最好的，开启同步机制下，srt实时性最好。

用ffmpeg实现srt的推拉流也非常简单，从ffmpeg5开始支持srt格式，但是测试下来发现性能比较差，从ffmpeg6开始性能比较好，但是ffmpeg6的srt如果打开的是不存在的srt地址，会崩溃，目前为止测试的ffmpeg6.1还有这个问题，而ffmpeg7没有这个问题，可能也在不断的迭代和修复bug。用srt拉流和之前的流程完全一样，从底层就支持，完全不用变。而srt推流，需要合并到udp推流大类中，格式是mpegts。

## 二、效果图