srt知识梳理

• 
• rtmp 自己有三次握手，tcp有三次握手
• 一个建立连接完成，要9 次会话的来回，才能完成建连接
• 移动互联网，用手机比较难
• rtmp 完全依赖于 tcp
• 不能提供带宽自适应算法
• quic vs srt 都可以

• 有ack
• 有ack的ack
• 有nack
• • 基于时间报文发送和接收
• rtt
• inflight 就是报文发出去，但是还没收到ack
• • 在 应用层，就是编码层做带宽自适应的算法

编码器厂商发明的

• encoer 加大 send buffer 以及 internet 和 decoder 部分都叫做通道
• 其编码出来的是什么样的曲线，保证其在接收过程也是什么曲线，这样使得internet部分变得透明
• 怎么实现？
• 堆sender ，按照编码器编码出来的时间顺序 做发送
• receiver buffer ，解码出来平滑

一般的传输：

• 建立连接，快速连接
• 基于连接，怎么做丢包重传
• 丢包重传基础做拥塞控制

• srt 交互过程只有2次，大幅度提升建连过程
• 1 建连 2. 传输 3. 结束

报文

• 数据报文和控制报文

• UDP + UDT + data

• sequence 31bit ，2的31次方，有生之间不会翻转

• FF 报文位置

• KK 加密

• O 有序

• Dest Socket ID 这个是srt自己定义的socket id ，不是系统的

• 结构很简单
  

控制报文

• ACK ACKACK 是丢包重传报文

常规的SRT发送图

• 编码器 把报文放send buffer
• send buffer 按照编码器输出的时间顺序，严格发送出去
• 接收端
• • 延迟window，严格按照时间戳返回给 app

---

---

• -

丢包重传

• ack 机制，常用
• 收到5个报文，发一个ack 回去
• 发送者收到ack，移除这五个报文

• 第一个图：
• 接收者发送给发送者 ack
• 发送者收到ack，通过计算，发送ackack 给接收者
• 通过rtt 获取 网络质量情况
• rtt 越高，证明延迟越大
• rtt是个实时变化的值
• -

ack 控制报文

• • 每10 毫秒发送一个rtt，频率高
• • 发送端拿到rtt后就知道网络质量
• • rtt的变化情况
• • 可用buffer，传文件需要
• • 现在接收包的收包数目，与直播有关

• bps ，收包的比特率

• 

• 以上三个数据直观反映 网络状况

• rec buffer 接收端 缓存情况

• recv bitrate 当前时刻接收的码率情况

• -

• -quic 只有ack 方式

• • webrtc的rtp rtcp 只用 nack

• -srt 支持 ack nack ，目的是 强势抢占带宽

• • ack 代表包收到了，也可能ack包会丢失
    – nack 周期发送，可能会造成发送者多发报文

• 

• srt 在丢包时，重传比其他协议更多，抢占带宽

按照时间发送

• 编码器按照时间发送 == 按照编码器的编码速度发送

srt 可配置

-

• srt 发送策略
• 
• • 编码器的输入带宽
• • 编码器的最大带宽
• =- 编码器过载率**
• smpinpbw 实际测试出的编码bitrate

-

-如果配置，按照配置来，

• 如果没配置，按照实际的编码的比特率来。
• 如果不配置，如互联网，一般是不配置。所以常规是中间算法：
• 
• 实际的 * 1.25 bps
  -如果实际是1k，那么就是1250 bps

拥塞控制

拥塞避免

---

• 比如带宽变化，接收端 1000k 变 900，少了10%，带宽变窄了，导致丢包
• • 如果现在发送量是1.1M, 带宽变的更差，
• -1.1M -900 ， 少了200k，导致网络崩溃

---

— 仅仅使用丢包重传，无法解决网络拥塞
– 怎么办？

• 限号。治堵。

• SRT 的用拥塞控制代码简单：

• 接收方的缓存大小，接收方是否够收

• 1秒内发送来的数据 / （rtt + 10 ） ，因为检测周期是10

• 1个rtt 已经发出的东西，一个rtt时间段内，已经发出去的数据是多少。

• 直播中不会出现接收方缓冲不够用的情况

• 传文件才会存在

• 

• 只要大，就发

• 

• 大佬说，拥塞控制太简单，有bw，rtt 完全可以用bbr。

 

• 2个包，握手和capbility
  -
• ack ackack 很好
• 提供的信息很丰富
• 
• 带宽占用大 ，随着丢包率高，占用更大
• 按照编码器编码出来的实际的bitrate 来发送。
  -

srs4

• 自适应srt 编码方案，针对拥塞控制的提升
• 

-

-

• 编码器到 边缘节点这段。
• 提高源流质量，
• 对 编码器和解码器 最后一公里推流很适合。
• SRT 不是自适应的。
• SRT 要求先知道 RTT --》 延迟 ， 出口带宽 BW

互联网 不容忍预先测量

• 推流节点到边缘节点
• 配置参数，rtt 有限带宽 ，然后根据算法计算 latency ，sendbuffer和 出口带宽。
• 并非所有问题都在传输层解决
  -

-

• 简单推流配置
  -
• vhost 虚拟主机

-

-

-

-

• 拥塞控制 拥塞避免算法，
• 丢包率20% 带宽变为12M了！！

-

• 预测 带宽
• 调整编码比特率
• 从而拥塞避免
• 动态自适应
• GCC
  -

-

• DELAY是导数，看变化率
• 
• 卡门滤波，预估下一次网络带宽
• -
• • 把这个变为bbr的预测算法，而不需要在接收端实现
• -
• -
• • 1 s 内找到一个rtt 最小值
• • 1s 内找一个 最大的发送的bitrate
• inflight 发出了报文但是没有收到ack的报文的字节数目，报文还在漂在网络中
• • 1个 rtt内 最大的发送字节数
• -
• 

-传输层，bbr 会不发：

• 
• 1.2 和 0.8 是buffer ，0.8到1.2之间是保持不变 。
• 用bbr 应该是不发：
  -
• 这里为啥是减少btrate？
• bbr是放缓存，不发
• 不发 用塞避免了
• 但是编码器 buffer 满了，不发就是丢包。
• 长时间丢包照样会花瓶。
• 编码率大于了网络带宽的有效值
  –
• 通用编码器
• 

-降低bitrate，会降低画面质量，但不会改变分辨率

-

• 只降低编码器推流带宽 最后一公里的带宽
• 美国节点，推流到杭州
  -
• 1M 带宽

-

• 没有上面的问题。大佬说。

-FEC 是丢包回复，不是拥塞控制的

QUIC

-

-

-

• QUIC 不包括udp ip 头，有50个字节，加上udp ip 有七八十个，一个包才1366个字节。很亏？
• -QUIC 非常适合长距离传输
• 视频会议适合webrtc
• srt适合直播
• SRT的参数有可以调节的，有不变的

-

• 视频卡顿与 接收方的缓存有关
• • QUIC 是面向连接的，没有ack会断开。
    -
• webrtc 视频回宜
• 动态编码 自适应编码
• 低延迟
• 端上音视频同步
• • 端上带宽预估
• • OBS已经支持SRT
• SRT 传TS,比较整齐，非常有利于做基于时间的发送。

-推流用SRT,播放用RTMP