jitter buffer QoS的解決方案

乙個分享webrtc的大神：

qos出現的背景：

而當網路發生擁塞的時候，所有的資料流都有可能被丟棄；為滿足使用者對不同應用不同服務質量的要求，就需要網路能根據使用者的要求分配和排程資源，對不同的資料流提供不同的服務質量：

1、對實時性強且重要的資料報

文優先處理；

2、對於實時性不強的普通資料報文，提供較低的處理優先順序，網路擁塞時甚至丟棄。

為了滿足上述需求，qos出現了，定義如下：

所以當網路過載或擁塞時，qos 能確保重要業務量不受延遲或丟棄，同時保證網路的高效執行。

支援qos功能的裝置，能夠提供傳輸品質服務；針對某種類別的資料流，可以為它賦予某個級別的傳輸優先順序，來標識它的相對重要性，並使用裝置所提供的各種優先順序**策略、擁塞避免等機制為這些資料流提供特殊的傳輸服務。配置了qos的網路環境，增加了網路效能的可預知性，並能夠有效地分配網路頻寬，更加合理地利用網路資源。

1、傳送端原理：

傳送端在傳送資料的時候，某個rtp包的seq為send_seq，傳送端把這個包通過udp socket傳送出去的同時，把這

個rtp包的資料拷貝到send_seq對應節點的buffer中去，以便這個rtp包接收方沒收到時，傳送方還能重發這個rtp包。

這裡要注意的一點是，傳送端和接收端的迴圈buffer節點數要能被65536整除，這樣rtp seq增加到最大值65535時對應

最後乙個節點，下乙個rtp包的seq為0正好對應上第乙個節點，避免rtp seq掉頭時出現漏洞。

2、接收端原理：

和傳送端類似，接收端也開闢了一段節點數能被65536整除的迴圈buffer，用於快取接收到的rtp包。接收端收到rtp

包時，需要去解析rtp包頭，取出接收到的rtp包的seq，對應下圖中的received_seq。

當收到第乙個包時，start_seq和end_seq都被設定為received_seq，並把收到的rtp包送到解碼單元。後面收到rtp包時，有做兩件事情：第

一、接收的模組將接收到的rtp包拷貝到received_seq指向的節點的buffer，並將這個節點的資料flag（用於標記該節點是否填充了資料）設定為true，同時要根據start_seq、end_seq和received_seq的關係來決定要不要將end_seq更新為received_seq的值，如果received_seq對應的包本來應該end_seq對應的包之前到達，則不更新end_seq的值，否則就更新。第

二、要每過一段時間都要去掃瞄start_seq到end_seq對應的每個節點，首先，若當前時間和start_seq對應的資料到達時間的差值超過一定閾值（比如500ms），則將start_seq和end_seq之間的每個節點的資料全部丟棄，將每個節點的資料flag設定為false，更新start_seq為end_seq。其次，若start_seq對應的節點的下乙個節點的資料falg為true，則將該節點的資料送到解碼單元，同時將start_seq更新為該節點的seq，並將該節點的資料flag設定為false；若flag為false，且當前時間和start_seq對應的資料到達時間的差值超過一定閾值（比如50ms），則將該節點的seq（lost_seq）傳送給傳送端，請求傳送端將seq對應的rtp資料再發一遍。

這樣，當有些包很久（大於500ms）都沒收到，就認為它來不了，直接將它們丟棄；有些包短時間（小於50ms）沒來，則向傳送端傳送重傳請求，請求傳送端再發一次該包，試圖能補上這些包。

3、結果說明

3.2、加入qos模組會帶來一定的延遲和卡頓，因為丟包重傳是需要時間的。

3.3、上述方案也就是webrtc裡面的nack的具體實現方式。

jitter buffer QoS的解決方案

jitter buffer QoS的解決方案

ADB server didn t ACK解決方法

NoSuchMethodError 解決方法

jitter buffer QoS的解決方案

jitter buffer QoS的解決方案

ADB server didn t ACK解決方法

NoSuchMethodError 解決方法

相關推薦