SRT协议推拉流

今天有个实习生问我 SRT 协议如何推拉流，那我们今天就来彻底搞懂它。

文章目录

- [SRT 协议地址简单介绍](#SRT 协议地址简单介绍)
- [SRT 推流](#SRT 推流)
- - 方式一：OBS
  - [方式二：FFMPEG 推流](#方式二：FFMPEG 推流)
- [SRT 拉流](#SRT 拉流)
- - 方式一：ffplay
  - [方式二：VCL 播放](#方式二：VCL 播放)
- SRT协议概述
- [SRT 和RTMP协议](#SRT 和RTMP协议)

SRT 协议地址简单介绍

每个公司可能定义的规则及端口不一样，所以本次示例不代表所有，可参考七牛srt 推流地址

bash 复制代码

srt://<RTMPPublishDomain>:1935?streamid=#!::h=<Hub>/<streamTitle>,m=publish,domain=<RTMPPublishDomain>

解析：

srt:// : 这明确指示客户端 (OBS) 使用SRT 协议去发起连接
<RTMPPublishDomain>:1935 告诉客户端，连接到哪个服务器的哪个端口
?streamid=#!::h=<Hub>/<streamTitle> ：重要参数，用于在握手时传递元数据，它通常用于模拟 RTMP 中的 "App名称(hub)"和"流名称"

#运行流程

当推流软件（OBS等）看到 srt:// 开头，就会准备使用SRT协议。它向服务器 miku-live-rtmp.teweichaowan.com 的 1935 端口 发起一个 SRT 握手连接 。服务器上的SRT服务正监听着这个端口，于是接受连接并进行通信。这个端口内部运行的其实是SRT服务，而不是RTMP服务。

SRT 推流

方式一：OBS

直接输入推流地址

方式二：FFMPEG 推流

shell 复制代码

ffmpeg -re -stream_loop -1 -i /Users/Downloads/bbb_30fps_gop_60_3mbps.mp4 -vcodec copy -acodec copy -f mpegts 'srt://publish-srt.sdk.com:1935?streamid=#!::h=test/ztest02,m=publish,[domain=](http://domain=hycdn-publish-srt.qnsdk.com/)publish-srt.sdk.com'

-f mpegts : 至关重要！ SRT 协议通常传输的是 MPEG-TS 容器格式的流。这个选项告诉FFmpeg 将音视频流打包成 MPEG-TS 格式后再通过 SRT 发送。
-re 是按视频播放帧率推流

SRT 拉流

方式一：ffplay

ffplay -i 'srt://play-referer.sdk.com:1935?streamid=#!::h=hutest/ztest,m=request,[domain=play-referer.sdk.com](http://domain=hycdn-play-referer.qnsdk.com/)'

方式二：VCL 播放

VLC 播放 SRT 需要单独设置streamid，不能在输入 URL 的地方携带 streamid

（1）Preferences------interface------show all------stream output------Access output ------ SRT

输入streamd后面的内容，例如 #!::h=hutest/ztest,m=request,[domain=play-referer.sdk.com](http://domain=hycdn-play-referer.qnsdk.com/)

（2）输入URL 播放

输入URL 播放即可播放

SRT协议概述

SRT 全称 **Secure Reliable Transport ，是一款开源、低延迟、可靠的点对点流媒体传输协议，**从目前测试情况下，好像很少有客户使用该协议。但是也要简单了解下。

SRT 基于 UDP 协议，但通过「自定义可靠传输机制」弥补了 UDP 无保障的缺陷。简单看下SRT 的核心技术原理

1. ARQ 重传机制（可靠传输核心）

原理：发送端标记每个数据包，接收端实时反馈 "已接收" 确认（ACK）；若超时未收到 ACK，发送端重传丢失的数据包。
优化：采用「选择性重传」（仅重传丢失的包，而非全部重传），避免 TCP 重传导致的延迟飙升。

FEC 前向纠错（抗丢包关键）

原理：发送端在数据包中插入 "冗余数据"（如每发送 8 个有效包，附带 2 个冗余包），接收端即使丢失部分数据包，也能通过冗余数据还原原始内容，无需等待重传。
配置：可通过参数调整冗余率（如 10%~50%），冗余越高抗丢包能力越强，但带宽占用越高。

智能拥塞控制（适配网络波动）

SRT 内置「基于延迟的拥塞控制算法」（Latency-Based Congestion Control），实时监测网络延迟和带宽波动，动态调整发送速率，避免网络拥塞导致的丢包。
支持自定义 "目标延迟"（如设置 100ms），协议会自动平衡延迟和可靠性。

原生加密（安全传输）

所有传输数据默认采用 AES-256-GCM 加密，密钥通过协商机制动态生成，无需额外配置 TLS/SSL，避免传输过程中数据被窃取或篡改。

SRT 和RTMP协议

SRT 和 RTMP 是流媒体传输领域最常用的两大协议，核心差异源于传输层基础（UDP vs TCP），最终体现在延迟、可靠性、适用场景等关键维度，

传输层基础：SRT 是基于UDP，RTMP是基于TCP
核心设计目标：SRT 低延迟 + 抗丢包 + 安全，解决公网传输痛点；RTMP 传统直播推流，适配 CDN 分发，兼容性优先
抗丢包能力：SRT比RTMP较强
部署：SRT：支持点对点传输（比如摄像头直接推流到云端服务器，无需中转），降低部署成本，但需解决 UDP 端口开放、NAT 穿透问题（公网传输需公网 IP 或打洞服务器）；RTMP：必须通过 RTMP 服务器 / CDN 中转（比如阿里云 / 腾讯云 CDN），部署简单，但需支付 CDN 费用，且中转会增加延迟。

关于SRT 协议简单了解下，知道怎么推拉流即可。