一、背景描述：

近日，項目現場傳來消息，終端音頻解碼聲音不正常，有爆破音。

我們的項目的視音頻使用RTP協議封裝，視頻使用H.264格式，音頻使用G.711格式，使用UDP發送接收。

音頻流傳輸是這樣的：

終端A -> 流媒體服務器 -> 終端B

在現場的同事，在流媒體服務器上面進行了抓包，流媒體服務器收到的音頻流、發出去的音頻流，解出來的聲音都沒有問題。

二、如何從RTP包中提取音頻數據

1、拿到.pcap文件后，使用wireshark打開

2、解碼為RTP：此時還是現實UDP包，點擊任意一個UDP包，鼠標右鍵，Decode As，窗口右側列表總選擇RTP

3、查看流信息：菜單 Telephony->rtp->stream analysis

4、保存.AU文件：在彈出窗口中，可以看到這個流的統計信息，包括丟包、亂序等，點擊左下角按鈕save payload as，選擇.au

5、收聽.AU文件：可以使用VLC直接打開，也可以使用audacity打開并且查看波形

三、分析PCM數據

既然服務器發出去的流沒有問題，那么只能從終端上面找原因了。

終端設備是嵌入式設備，使用嵌入式linux系統，音頻采集、播放使用ALSA接口，編解碼使用軟件模塊。

由于設備不在身邊，不能操作串口，所以我先選擇了修改代碼，在ALSA播放線程，保存音頻解碼后的PCM數據。

保存方法就是直接將收到的數據寫入一個文件中。

1、保存文件代碼

FILE *fp = NULL;if (!fp)fp = fopen("./audio_dec.pcm", "wb");fwrite(str_buf, strlen(str_buf), 1, fp); fflush(fp);

2、使用audacity打開

打開audacity

文件->導入->原始數據->選擇文件

窗口選擇 16bitpcm、小端、8K

四、分析G.711數據

發現PCM數據與線程播放效果一致，有問題。

那么再往上追查，在G.711解碼線程中保存rtp解包后的G.711數據

使用audacity打開的方法與打開PCM差不多，唯一的區別是原來選擇16bitPCM那里，選擇U-law

通過分析，這個G711數據也有問題，那么問題基本可以定位在設備收流和rtp解包這兩塊兒了。

五、設備上面抓包

需要在嵌入式設備上面抓包，需要下載并交叉編譯tcpdump

可以將tcpdump命令在程序中傳遞給shell執行

1、傳遞shell命令

char temp[128]; FILE* cmdFile;memset(temp, 0, sizeof(temp)); sprintf(temp, "linux shell cmd &"); cmdFile = popen(temp, "r"); pclose(cmdFile);

2、開始抓包

./tcpdump -i eth0 -w port_10006_recv.pcap -n -s0 udp port 10006 -C 10 &

3、停止抓包

killall tcpdump

將抓到的pcap文件使用wireshark打開，解包、流分析（參照‘二、從RTP中提取音頻數據’）

查看 Sequence errors（亂序） 和 Lost RTP packets（丟包） 這兩項。

發現，設備中收到的流，亂序率達到了40%，沒有丟包。

而在終端rtp解包代碼中，是不處理亂序的，直接解包后進行G.711解碼，所以亂序的音頻解碼后，聲音就不正常了。

后續文章描述如何處理亂序問題。

總結

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

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