前一段時間在給公司產品的弱網提示功能提供數據支撐的時候，是根據WebRTC拋來上的StatsReport中的packetsLost、packetsSent/packetsReceived作爲計算的數據來源進行的。採用的丟包率算法是：
（單位時間內packetsLost差）÷（單位時間內packetsSent/packetsReceived差）= 單位時間內的丟包率
期初，我們採取的單位時間是1秒。即每1秒就計算一次丟包率。但從實際的數據上來看，會發生這樣的現象：
上圖是通過WebRTC的StatsReport報上來的原始數據，每1秒打印一條，我過濾了其他，只保留了audio。從數據中我們很容易發現一個問題，就是每秒的packetsSent差都是50，但是packetsLost的值會發生275 -> 446 (差值171) 這種巨大的變化。
所以，如果我們按照單位時間1秒來計算丟包率，就會得到這樣的結果：
(446-275) ÷ (4590-4540) = 171 ÷ 50 = 3.42 = 342%
顯然如果我們按照單位時間1秒來計算丟包率是不合適的，否則就會出現上面展示的現象，上一秒的丟包率還是0，下一秒的丟包率就成了342%。
所以，我目前的處理方法是修改丟包率的計算公式，丟包率不再採用固定單位時間更新，而是根據丟包數發生變化的時候來計算。即當packetsLost發生變化時，記錄當前packetsSent/packetsReceived數值，直到下一次packetsLost發生變化時，記錄新的packetsSent/packetsReceived數值，丟包率的計算公式不變（還是本文一開始的），兩次packetsLost差值作爲分子，兩次packetsSent/packetsReceived差值作爲分母。得到最終的丟包率。這裏的主要變化是不再考慮時間，即丟包率數值的更新不以某個固定時間來計算，而完全按照packetsLost發生變化才計算。
經過上面的調整以後，還是借用圖中的數值。當packetsLost首次=275時，packetsSent=4240。之後過了7秒，packetsLost變爲446，packetsSent變爲4590，那麼新的丟包率就是：
(446-275) ÷ (4590-4240) = 171÷350=0.4886=48.86%
這樣處理後的丟包率數值看起來“更可信”一點。
歡迎讀者提供WebRTC的audio/video更好的丟包率計算方法~