下載
多媒體通訊同步方法,主要有時間戳記同步法、同步標記法、多工同步法三種。下面主要討論時間戳記同步法,特別是RTP時間戳記同步。內容包括RTP媒體間同步的實現,為什麼需要RTCP的NTP時間來實現媒體間同步?沒有RTCP,能實現RTP媒體間的同步嗎?DirectShow時間戳記和RTP時間戳記的區別,MPEG2-TS流的時間戳記等。本文只簡單討論時間戳記同步的原理,不涉及具體的實現方法,如音訊框架和視訊框架時間戳記的計算方法,怎樣根據時間戳記去做音視頻的呈現等。
根據RTP規範,不同的RTP媒體流是分開傳輸的,且使用各自獨立的時間戳記進行同步。假設在一次ApsaraVideo for VOD中,傳輸兩路RTP媒體流,一路視頻,一路音頻。根據視訊框架時間戳記,可以實現視頻流內同步,這很好理解,通過視訊框架時間戳記可以計算出相鄰視訊框架的時間間隔,也就是視訊框架之間的相對時間關係很容易通過時間戳記來確定,按照這個間隔去呈現視頻,就可以獲得較好的效果。同理,音頻流也可以實現自身的同步。
那麼音頻和視頻這兩路媒體間如何?同步呢?我們只使用音視頻的RTP時間戳記,看能否實現媒體間的同步。音視頻的RTP時間戳記的增長速率一般是不同的,但沒關係,知道了具體的單位後,兩者是可以通過單位換算聯絡起來的。如:
現在來看,這種方法好像可以實現同步,因為音視頻被映射到同一個時間軸上了,音頻和視訊框架間的相對關係很清楚。慢著,RTP規範要求時間戳記的初始值應該是一個隨機值,那麼假設音訊框架時間戳記的初始值是隨機值1234,視訊框架時間戳記的初始值是隨機值5678,看起來應該是下面這樣:
這麼做合適嗎?我們把音訊框架時間戳記1234和視訊框架時間戳記5678對應到絕對時間軸的0上,我們這麼做的理由是什嗎?你可能會說,因為那是第一個音訊框架和第一個視訊框架,所以可以對應到同一個點上,在第一幅圖中我們就是這麼做的,把音訊框架時間戳記0和視訊框架時間戳記0對應到絕對時間軸的0上。但是RTP規範並沒有規定第一個視訊框架的時間戳記和第一個音訊框架的時間戳記必須或者應該對應到絕對時間軸的同一個點上,從整個RTP規範中不能直接得出這樣的結論,也推導不出這樣的結論。
我們上面兩幅圖所做的轉換是不正確的,為什麼呢?因為在做轉換時,隱含了一個假設,我們想當然地認為這個假設是成立的,實際上它並不總是成立。這個假設就是第一個視訊框架和第一個音訊框架的時間戳記應該對應到同一個點上,即無論它們時間戳記是多少,都應該在同一時間播放。
僅僅使用RTP時間戳記是無法實現媒體間同步的,根本的原因是音頻時間軸和視頻時間軸是完全獨立的,通過音訊框架和視訊框架的時間戳記,無法確定一個視訊框架和一個音訊框架的相對時間關係,也就是無法把它們都準確定位在絕對時間軸上,只能準確定位一個。
要實現RTP媒體間同步,需要藉助於RTCP,在RTCP的SR包中,包含有<NTP時間,RTP時間戳記>對,音訊框架RTP時間戳記和視訊框架RTP時間戳記通過<NTP時間,RTP時間戳記>對,都可以準確定位到絕對時間軸NTP上,音訊框架和視訊框架的相對時間關係就可以確定下來了。
上面提到,我們的那個隱含的假設並不總是成立,那就是說它有成立的時候。那是不是說當它成立時,我們就可以不用RTCP來做媒體間同步了?答案是,基本上可以這麼認為。
例如,對於RTP即時資料流,在發送端媒體間就同步的很好,在接收端只需做少許處理,不需要RTCP,就可以實現媒體間同步。當然,這隻是少數例外。因為RTP規範並不包括這個假設,所以我們還是按照RTP規範來做吧。
下面說一下DirectShow和MPEG2-TS的時間戳記。DirectShow中的時間戳記和RTP中的時間戳記,除了單位不一樣,計算方法不一樣外,本質的區別就是DirectShow中的音訊框架和視訊框架時間戳記使用的是同一個時間軸,所以不需要藉助其他的東西,僅僅使用音訊框架時間戳記和視訊框架時間戳記就可以實現媒體間同步。MPEG2-TS流中也有時間戳記,它的時間戳記和RTP及DirectShow的時間戳記都不同,TS流中的音訊框架和視訊框架時間戳記使用的也是同一個時間軸,TS流中的音頻和視頻是複用的,這在一定程度上就起到了同步的作用,所以它並不是在每個幀上都打時間戳記,比如它的PTS時間戳記就是每隔0.1秒一個,缺失的時間戳記是通過其他時間戳記插值計算出來的。