前面文中描述了打包格式為RTP，負載為G.711的音頻流的分析方法。

并且得知了設備收到的RTP流有嚴重的亂序情況。

那么，發送端發出的流是正常的，接收端收到的流卻亂序嚴重，這是什么原因呢？

一、查看路由

linux命令行輸入 tracert -d 目的IP

二、發送端要增加VBV控制發送速度

有的發送端并不控制發送速度，UDP本身并不是可靠連接，發送速度不均勻、過快，會導致接收端丟包或者亂序。

這個也很好驗證，可以讓發送端給一臺PC發，如果PC收到的RTP包也有丟包或者亂序的情況，則說明發送端有問題。

解決的辦法就是在發送端加入VBV處理，控制發送速度，盡量保持勻速發送。

在加入音頻的VBV控制之后，每20ms左右發送一個G.711包（負載為160字節，20ms一幀的音頻數據），音頻包亂序率從40%降低到2%左右了。

三、接收端要增加重排序功能

雖然亂序率降低到2%左右了，但畢竟還是有亂序的，所以還是要增加重排序功能。

這個功能對視頻也尤其重要。

在代碼實現上要設計好，在沒有亂序的情況下，不要帶來額外的延遲。

大概的算法可以是：

做兩個隊列，最好是雙向循環隊列，可以使用鏈表。

一個是接收隊列，用于重排序

一個數發送隊列，用于下一級模塊獲取重排序后的數據

1、先存入接收隊列，從隊尾開始對比，插在比他序號小的成員后面

2、從接收隊列中，從對頭開始，一個一個的出上一個出去序號+1的包，出去的包存入輸出隊列

3、如果接收隊列中，還沒有想找的序號，就先不出，等著

4、如果接收隊列長度超過上限，則將想找的序號+1，再重復‘3’

5、只要輸出隊列中有包，就讀出來，從輸出隊列出來的包應該是連續的

四、測試

將現場抓取的pcap文件使用bittwist修改目的IP后，發到本地設備進行測試

bittwiste -I in.pcap -O out.pcap -T ip -d 原來的目的IP,新的目的IP

先運行bittwist -d查看可用的適配器接口
bittwist -i <適配器接口號> -l 0 <文件名.pcap>

總結

以上是生活随笔為你收集整理的RTP音频流分析以及乱序问题的解决方法（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。