RTSP（H.264+AAC）音視訊推流心得--linux C

調試RTSP遇到的問題

    RTSP的開源代碼很多，移植方法也很多，是以在這裡不做過多的描述。我主要來為大家講述下移植過程中遇到的一些容易忽視的問題。

一、系統32位和64位相容的問題

    目前大部分的嵌入式系統都是32位的，不過不乏有些64位的。是以在移植過程中我們要特别小心。下面是64位和32位系統資料類型所占位元組的大小。

32位：

int               4個位元組

long int       4個位元組

long long    8個位元組

指針            4個位元組

64位：

int               4個位元組

long int       8個位元組

long long    8個位元組

指針            8個位元組

在移植過程中，我們會有網絡位元組序的轉換步驟。因為比如包、ssrc和時間戳，都需要位元組轉換，這裡要特别注意。在調試中，我們可以列印出轉換前後的值，分析對錯。當然，也可以通過wareshark抓包分析，檢視相關資訊是否正确。

二、打時間戳問題

1、H.264時間戳：

timestamp=90000/幀率.*（幀号 - 基準幀号）                //基準幀号，我們一般是找到關鍵幀的前一幀做為基準幀

2、AAC時間戳：

AAC比較特殊，因為它的編碼需要1024的采樣點才能正常編碼（PCM-->AAC），是以我們一般以1024做為時間戳機關。

timestamp=1024*(幀号-基準幀号)                    //我們同樣以找到視訊關鍵幀為基準，記錄音頻此前的幀号做為音頻基準

一幀音頻資料也就是PCM音頻源資料的1024采樣點編碼後的一包資料。

三、音視訊無法正常播放的調試

1、一般先調試視訊，視訊調試OK後，再加入音頻調試

    首先确定音視訊源是否OK；其次确定RTP打包是否OK（此時要注意系統位數）；網絡抓包檢視連結是否建立成功，SDP資訊是否合理。

2、如果播放單視訊，視訊出現播放速率不對，過慢、卡頓或者過快，很有可能是時間戳有問題

    具體檢視時間戳數值是否整齊，還有就是抓包看包序是否連續，是否有丢包。

3、如果加入音頻後導緻音視訊出現異常。則可能是以下兩種原因導緻

原因一：

音視訊時間戳打的有問題。

原因二：

    在發送視訊幀的時候，中間插入了音頻幀，導緻解碼端無法正常解碼。（我其實不太贊成此推論，我懷疑是RTSP伺服器版本的問題。因為理論上音視訊的傳輸是通過不同的端口進行的。但是實際調試中，卻是出現了該問題，抓包發現視訊幀隻要被插隊，音視訊播放就會出現異常）

  因為視訊幀很大，一般需要分多個包發送。比如一個I幀，它有300個包，而在發送到200個包的時候，突然被一個音頻幀插隊，後續在繼續發剩下的100幀，這樣接收端就沒法解析播放。

解決方案：一采用單線程處理音視訊發送；二采用多線程分别發送音視訊時，應該加入鎖，防止視訊幀被插隊。     

這時個人的一些心得體會，歡迎大家一起讨論，一起分析，一起提高。