目前總結出webrtc用於提公升qos的方法有：
nack、fec、svc、jitterbuffer、idr request、pacer、sender side bwe、vfr（動態幀率調整策略）。
這幾種方法在webrtc架構分布如下：
具體實現原理如下：
與nack對應的是ack，ack是到達通知技術。以tcp為例，他可靠因為接收方在收到資料後會給傳送方返回乙個「已收到資料」的訊息（ack），告訴傳送方「我已經收到了」，確保訊息的可靠。nack也是一種通知技術，只是觸發通知的條件剛好的ack相反，在未收到訊息時，通知傳送方「我未收到訊息」，即通知未達。
nack是在接收端檢測到資料丟包後，傳送nack報文到傳送端；傳送端根據nack報文中的序列號，在傳送緩衝區找到對應的資料報，重新傳送到接收端。nack需要傳送端傳送緩衝區的支援，rfc5104定義nack資料報的格式。若在jb緩衝時間內接收端收到傳送端重傳的報文，就可以解決丟包問題。對應上圖傳送端的rtcp rtpfb
具體請參考
fec是傳送端在傳送報文的時候，將之前的舊包也打包到新包裡面，若接收端有丟包，就用新包裡面冗餘的舊包恢復資料。
webrtc實現該冗餘功能，有三種方式：
1、red就是rfc2198冗餘。將前面的報文直接打入到新包裡面，在接收端解析主包和冗餘包。
3、flexfec較ulpfec，增加縱向oxr運算。增加網路抗丟包能力。
具體請參考
具體請參考：
jitterbuffer實現原理是，在收到網路上的rtp報文後，不直接進行解碼，需要快取一定個數的rtp報文，按照時間戳或者seq的順序進行重排，消除報文的亂序和抖動問題。jitterbuffer分動態jitterbuffer和靜態jitterbuffer兩種模式。靜態jitterbuffer快取報文個數固定。動態jitterbuffer是根據網路環路延時的情況，動態調整快取報文個數。
具體請參考
這個演算法的思路是根據接收端的丟包率或延時情況維護乙個狀態機。以根據丟包率為例，在判斷為overuse時，就根據一定的係數減少當前傳送端的位元速率值，當判斷為underuse時又根據增加係數來增加傳送端的位元速率值；然後將這個值通過rtcp包傳送給傳送端，傳送端根據該值來動態的調整位元速率。
具體請參考介紹
具體請參考
webrtc QOS方法十（pacer實現）
若僅僅傳送音訊資料，不需要pacer模組 pace queue是乙個基於優先順序排序的多維鍊錶，它並不是乙個先進先出的fifo,而是乙個按優先順序排序的list。報文優先順序規則是 根據報文型別確定資料優先順序處理函式如下 按照優先順序pop資料處理函式如下 pacingcontroller nex...
webrtc QOS方法七（攝像頭採集幀率調整）
檢查cpu占有率 編碼解碼時間，都沒有異常。按理來說效能是可以達到30fps的實時通訊能力的。1 首先確認到底是不是攝像頭採集出來的幀率就低，還是系統排程慢，導致採集幀率低。ffmpeg的命令列如下 ffmpeg list devices true f dshow i dummy 顯示要採集攝像頭裝...
2018彙總讀書篇
非學無以廣才，非志無以成學。知識淵博的人總能由內而外不經意間自然而然地顯露出自己的才華，而往往肚子裡只有一點墨水的人卻著急著顯擺。厚積薄發的震撼力量才能直擊別人內心深處。知識的海洋浩瀚無邊，而我僅駕著我的小船前行。很喜歡伏爾泰的一句話 書讀的越多而不加思索，你就會覺得你知道得很多 但當你讀書而思考越...