施维老师srt讲座笔记
边听边记的
如果有侵权，联系[email protected] zhangbin 删掉
- 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 ，不是系统的
-
结构很简单
扫描二维码关注公众号，回复： 10019085 查看本文章
控制报文
- 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 周期发送，可能会造成发送者多发报文
- ack 代表包收到了，也可能ack包会丢失
-
-
-
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会断开。
-
- QUIC 是面向连接的，没有ack会断开。
- webrtc 视频回宜
- 动态编码 自适应编码
- 低延迟
- 端上音视频同步
-
- 端上带宽预估
-
-
-
- OBS已经支持SRT
- SRT 传TS,比较整齐，非常有利于做基于时间的发送。
-
-推流用SRT,播放用RTMP
