由于音視頻流是以兩條獨立的數據流在網絡上傳輸的,如果網絡質量相當差,那么在接收端收到的音視頻數據流就有可能不是同步的了,為了克服這種不同步的現象,需要添加同步機制。的同步機制是使用開源庫jrtplib3.7.1來實現的,嚴格遵守rtp協議標準。
解決的方案如下:
當有數據需要發送時,往數據中加入時間戳,在接收端,讀取時間戳,進行比較,如果相同或相差很近,就提交播放,如果其中一個時間戳更大,就等待。如果網絡質量很差,那么存在兩種不同步的情況:
1. 對于單條數據流來說,如果網絡質量很差,可能出現數據流的接收不流暢,如果沒有做流暢處理,那么就可能出現抖動現象,這需要使用rtp中的時間戳解決。
2. 對于多條數據流來說,如果網絡質量很差,可能出現本應該同時播放的數據幀沒有在同一時間到達,需要做同步處理。
解決第1個問題的方法是向每個發送的數據包加上時間戳,在rtp庫中,時間戳表示在打包數據段中*個采樣所對應的時間,時間戳的啟始值是隨機的,后續的時間戳是在前一個時間戳上的增量,在SendPacket中的時間戳參數表示的是時間戳增量,所以數據流的同步需要計算出時間戳增量。
對于音頻數據,由于音頻數據的采樣率是8000Hz,所以每采樣一次需要時間是1/8000s,由于是每20ms封包一次,所以時間戳的增量是(20*10**-3)*8000=160。
對于視頻數據,由于視頻數據的采樣率是90000Hz,所以每采樣一次需要時間是1/90000s,如果幀率是25幀/s,所以時間戳增量是90000/25=3600。
在發送端,每發送一個數據包,都打上該數據包對應的時間戳值,只需要向SendPacket的zui后個參數傳遞時間戳增量,rtp庫會自動算出時間戳,并加到發送的rtp數據包首部里邊。
在接收端,當收到一個數據包時,獲取該rtp數據包的時間戳值,計算出與前一個數據包的時間戳值的差值,乘以該媒體流的時間戳單位,就得出了當前數據包與前一個數據包之間的間隔的打包時間T。所以只要保證在與前一個數據包被提交過后T時間后再提交當前接收到的數據包,那么在rtp層就解決了上邊提出的*個問題。
解決第2個問題的方法是使用rtcp發送者報告數據包中的時間信息,發送者報告被發送的間隔時間是不固定的,它的大小與參與到會話中的同步源數量成正比。每個發送者報告中都有個ntp時間和rtp時間,該ntp時間表示在發送時間戳為該rtp時間的rtp包時的系統時間,就是在發送這個rtp包時的系統時間,所以這兩個時間值有對應關系,由于對于一個同步源,時間戳單位是固定的,所以可以由后續的某個數據包的rtp時間戳計算出這個數據包所對應的時間,這個時間就是在發送這個數據包時,發送端的系統時間。
使用這種方法就可以計算出每個收到的rtp數據包在發送端的系統時間,這個系統時間在發送端是單調遞增的,所以可以通過這個值來同步多條數據流。