施維老師的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