基于VoIP的媒體采集/播放的設計考慮

2019-11-03 08:59:20

字體：大中小

來源：轉載

供稿：網友

代雯蕾黃桂金

華中科技大學電信系武漢430074

　　摘要在Voip（Voice Over IP，基于IP的話音）服務當中，媒體的采集/播放質量將直接影響到通話質量。本文詳細描述了基于VoIP的媒體采集/播放的設計實現，以及需要注意的一些問題。

　　關鍵詞 VoIP RTP（Realtime Transport PRotocol，實時傳輸協議）音頻視頻

　　1 背景

　　隨著寬帶互聯網的普及和技術的巨大進步，VoIP技術已經成為了能夠與傳統電話服務和PBX產品的相匹敵的技術。VoIP終端將音頻、視頻模擬信號進行抽樣、編碼處理成壓縮幀，然后轉換為IP包進行傳輸，從而達到了在IP網上進行多媒體通信的目的。本文將從VoIP對媒體采集/播放的要求出發，分析可能影響采集/播放的性能的幾個因素并提出解決方法。

　　2 VoIP的媒體采集/播放要求

　　VoIP通常采用G.723.1或G.728等音頻編碼方式，要求能夠提供采樣頻率為8000Hz，每樣本點為13比特以上的采集能力。因此，音頻采集需輸出指定時間間隔(20~200ms，缺省值為20 ms)、采樣頻率為8000Hz、每樣本點為16比特的音頻數據。對應的，音頻播放將得到一定時間間隔、采樣頻率為8000Hz、每樣本點為16比特的音頻數據。

　　視頻編碼通常采用H261和H263兩種方式，要求以1/30秒的時間間隔提供一個完整的一幀符合CIF（Common Intermediate Format，畫面大小為352 * 288）、QCIF（Quarter-CIF，176 * 144）或者SQCIF（sub-QCIF，128 * 96）格式的原始視頻數據。對應的，視頻播放將得到固定時間間隔、完整的一幀符合CIF、QCIF或者SQCIF格式的視頻數據。

　　3 VoIP的媒體封裝要求

　　原始媒體流經過編碼后，按一定規則被切割成段，繼而進行RTP封裝。RTP包帶有一個固定包頭：

　　其中，采集模塊關心的只是timestamp字段。 timestamp為時間戳，表示音頻/視頻數據的采樣時刻，其初值隨機。對于音頻數據，其分辨率為1/8000秒，對于視頻數據，要求其分辨率為1/90000秒。

　　4 可能影響系統性能的幾個因素及解決方法

　　評價系統的性能，必須從兩個方面來考慮，即處理時間和占用的內存空間。下面就可能影響系統性能的幾個因素進行討論，并提出解決方法。

　　4.1 采集/播放與其他模塊之間的數據交互

　　采集的媒體數據將發送至音頻/視頻編碼部分，為了避免反復申請/釋放內存，編碼模塊應盡可能地在采集模塊發送的數據塊內就地編碼，而不是另申請一塊數據存放編碼后的數據（在視頻編碼中，若某幀與上一幀差別太大，該幀編碼后的數據量可能無法裝入一個RTP包當中，必須分為多個RTP包發送，這種情況下，另外申請空間無法避免）。同時，由于編碼后的數據還會做RTP封裝，為了避免反復拷貝，采集模塊發送至編碼模塊的數據塊應為RTP包頭留有余地。

　　考慮到編碼算法（如H.263，G.728，G.723.1）需要從采集模塊得到時間戳，原始數據長度，視頻幀號等信息，所以需要定制一個結構來存放這些數據，稱之為編碼信息結構。因此，采集模塊發送到編碼模塊的數據塊內，首先存放的是一個聯合（Union），該聯合中包括RTP包頭結構和編碼信息結構。接下來存放的才是原始媒體數據。

　　根據編碼方式的不同，RTP包頭的長度也可能不同，如G.728僅有一個RTP固定包頭，而H.263和H.261需先添加一個RTP載荷頭，再添加固定包頭。出于對可擴展性的考慮，在數據塊的結構中需有一個字段來指示“有用的”數據相對與本數據塊的偏移量。

　　4.2 音頻采集/播放模塊的內部結構

　　采集模塊為音視頻會議提供數據源，因此音視頻數據采集的實時性非常重要。在實現方法上，采用系統開銷較小的方式。以Windows系統為例，可以采用Waveform Audio SDK來完成音頻采集，用VFW SDK來完成視頻采集，而不選用DirectShow。同樣地，音視頻的播放也可通過上述兩類SDK來完成。

　　由于人類對聲音比較敏感，所以為了保證音頻采集/播放的連續性與均勻性，音頻采集和播放都應申請一個環形緩沖區以存放待編碼/播放的音頻數據塊地址。之所以存放數據塊地址而不直接將音頻數據填入，是因為若直接填入數據，采集側每次將數據發送至編碼模塊時，需要將數據從緩沖區內拷出；同時播放側每次從同步模塊接收音頻數據時，亦需要將數據從消息中拷入緩沖區。這樣做對性能有一定的影響。為了減少拷貝，可在緩沖區內僅存放數據塊的地址，在音頻采集模塊向音頻編碼模塊，或者是同步模塊向音頻播放發送數據時，只需指出該數據塊的地址及音頻數據偏移量即可，而不需要重復拷貝。

　　在實時操作系統系統環境下，音頻采集/播放模塊可分為兩個獨立的任務或線程，即音頻采集和音頻播放。其中，音頻采集線程還擁有一個子線程，即數據發送線程，該線程的任務是實時地將采集完畢的音頻數據發送至音頻編碼模塊；音頻播放線程也擁有一個子線程，即數據播放線程，該線程的任務是實時地將音頻數據從播放緩沖區取出，送至音頻驅動以供播放。

　　音頻采集模塊在收到采集啟動消息后，將待采集數據塊（為了保證采集的連續性，這里需要是多個數據塊）的地址告知驅動，并通知驅動開始采集；當一塊數據塊采集完成后，數據發送線程將采集的數據取出發送給音頻編碼實體，并申請下一塊數據送給驅動。音頻播放模塊在收到播放啟動消息后，并不馬上播放，而是先將同步模塊發來的數據填入播放（環形）緩沖區。在填到一個門限值后，從緩沖區的第一塊數據開始，將多個數據塊的地址送往驅動，并通知驅動開始播放；每當一塊數據播放完成后，數據播放線程都取出下一塊數據送給驅動。

　　4.3 線程的同步與互斥

　　由于音頻的采集和播放都是由兩個線程協作完成的，因此線程間的同步與互斥是重點。在音頻采集線程和數據發送線程之間，音頻播放線程和數據播放線程之間需要進行同步，也就是說，當一個數據塊采集/播放完畢時，需要以某種方式告知數據發送/播放線程去取下一個數據塊。

　　對于VoIP的應用來說，通知的實時性最為重要。首先考慮回調函數方式，它的實時性最高，但在一些系統中（如Windows），在回調函數中調用音頻驅動的某些函數可能會引起死鎖；其次是事件通知方式，即在數據發送線程中，等待“采集完成”事件的發生，一旦采集完成，該事件即被置為“有事件”狀態，這種方式的實時性較好，只是獲取數據塊索引的方式略為麻煩（因為送往驅動待采集/播放的數據不止一塊）；采集完成后，驅動亦可向指定的線程發送消息，但由于消息機制的實時性不高，所以不作考慮。因此，一般采用事件進行通知的方式來完成同步和互斥。

　　5 時間戳的產生

　　根據協議規定，音頻時間戳的分辨率為1/8000秒，視頻時間戳的分辨率為1/90000秒，因此需要采用高精度的計數器（其分辨率不低于1/90000秒）。由于音視頻時間戳要求的分辨率不同，在沒有兩個計數器的情況下，可以用一個計數器來得到兩種時間戳。

　　首先獲取計數器頻率Freq。在啟動采集時，查詢計數器的初使值，保存在一個靜態變量當中。接下來通過md5算法產生一個32bit的隨機數賦予timeStamp作為第一個RTP包的時間戳。每當有數據塊采集完成，查詢當前計數器的值，計算與計數器初始值的差值CntGap，將這個差值與計數器周期相乘得到實際時間差timeGap，即：

　　timeGap = (double)( (double) CntGap / Freq)，將這個時間差除以RTP時間戳的周期1/8000（1/90000），再加上時間戳的初值，即得到本次采集的時間戳。

　　6 結束語

　　由于音/視頻數據的采集/播放性能直接關系到通話質量，所以高性能的VoIP終端離不開高性能的媒體采集/播放模塊。本文提出了影響音/視頻數據的采集/播放性能的一些因素，并討論了以Windows操作系統為例的設計方法。在其他平臺上開發VoIP終端時，采集/播放模塊與操作系統的接口由于實際平臺的不同將會有所差異，但本方案提出的模塊內部結構，與周圍模塊的接口等與平臺無關，因此仍有一定的參考價值。

　　
----《中國數據通信》