2 VoIP的媒體采集/播放要求
　　VoIP通常采用G.723.1或G.728等音頻編碼方式，要求能夠提供采樣頻率為8000Hz，每樣本點為13比特以上的采集能力。因此，音頻采集需輸出指定時間間隔(20~200ms，缺省值為20 ms)、采樣頻率為8000Hz、每樣本點為16比特的音頻數(shù)據(jù)。對應的，音頻播放將得到一定時間間隔、采樣頻率為8000Hz、每樣本點為16比特的音頻數(shù)據(jù)。
　　視頻編碼通常采用H261和H263兩種方式，要求以1/30秒的時間間隔提供一個完整的一幀符合CIF（Common Intermediate Format，畫面大小為352 * 288）、QCIF（Quarter-CIF，176 * 144）或者SQCIF（sub-QCIF，128 * 96）格式的原始視頻數(shù)據(jù)。對應的，視頻播放將得到固定時間間隔、完整的一幀符合CIF、QCIF或者SQCIF格式的視頻數(shù)據(jù)。
　　3 VoIP的媒體封裝要求
　　原始媒體流經(jīng)過編碼后，按一定規(guī)則被切割成段，繼而進行RTP封裝。RTP包帶有一個固定包頭：
　　其中，采集模塊關心的只是timestamp字段。 timestamp為時間戳，表示音頻/視頻數(shù)據(jù)的采樣時刻，其初值隨機。對于音頻數(shù)據(jù)，其分辨率為1/8000秒，對于視頻數(shù)據(jù)，要求其分辨率為1/90000秒。
　　4 可能影響系統(tǒng)性能的幾個因素及解決方法
　　評價系統(tǒng)的性能，必須從兩個方面來考慮，即處理時間和占用的內存空間。下面就可能影響系統(tǒng)性能的幾個因素進行討論，并提出解決方法。
　　4.1 采集/播放與其他模塊之間的數(shù)據(jù)交互
　　采集的媒體數(shù)據(jù)將發(fā)送至音頻/視頻編碼部分，為了避免反復申請/釋放內存，編碼模塊應盡可能地在采集模塊發(fā)送的數(shù)據(jù)塊內就地編碼，而不是另申請一塊數(shù)據(jù)存放編碼后的數(shù)據(jù)（在視頻編碼中，若某幀與上一幀差別太大，該幀編碼后的數(shù)據(jù)量可能無法裝入一個RTP包當中，必須分為多個RTP包發(fā)送，這種情況下，另外申請空間無法避免）。同時，由于編碼后的數(shù)據(jù)還會做RTP封裝，為了避免反復拷貝，采集模塊發(fā)送至編碼模塊的數(shù)據(jù)塊應為RTP包頭留有余地。
　　考慮到編碼算法（如H.263，G.728，G.723.1）需要從采集模塊得到時間戳，原始數(shù)據(jù)長度，視頻幀號等信息，所以需要定制一個結構來存放這些數(shù)據(jù)，稱之為編碼信息結構。因此，采集模塊發(fā)送到編碼模塊的數(shù)據(jù)塊內，首先存放的是一個聯(lián)合（Union），該聯(lián)合中包括RTP包頭結構和編碼信息結構。接下來存放的才是原始媒體數(shù)據(jù)。
　　根據(jù)編碼方式的不同，RTP包頭的長度也可能不同，如G.728僅有一個RTP固定包頭，而H.263和H.261需先添加一個RTP載荷頭，再添加固定包頭。出于對可擴展性的考慮，在數(shù)據(jù)塊的結構中需有一個字段來指示“有用的”數(shù)據(jù)相對與本數(shù)據(jù)塊的偏移量。
　　4.2 音頻采集/播放模塊的內部結構
　　采集模塊為音視頻會議提供數(shù)據(jù)源，因此音視頻數(shù)據(jù)采集的實時性非常重要。在實現(xiàn)方法上，采用系統(tǒng)開銷較小的方式。以Windows系統(tǒng)為例，可以采用Waveform Audio SDK來完成音頻采集，用VFW SDK來完成視頻采集，而不選用DirectShow。同樣地，音視頻的播放也可通過上述兩類SDK來完成。
　　由于人類對聲音比較敏感，所以為了保證音頻采集/播放的連續(xù)性與均勻性，音頻采集和播放都應申請一個環(huán)形緩沖區(qū)以存放待編碼/播放的音頻數(shù)據(jù)塊地址。之所以存放數(shù)據(jù)塊地址而不直接將音頻數(shù)據(jù)填入，是因為若直接填入數(shù)據(jù)，采集側每次將數(shù)據(jù)發(fā)送至編碼模塊時，需要將數(shù)據(jù)從緩沖區(qū)內拷出；同時播放側每次從同步模塊接收音頻數(shù)據(jù)時，亦需要將數(shù)據(jù)從消息中拷入緩沖區(qū)。這樣做對性能有一定的影響。為了減少拷貝，可在緩沖區(qū)內僅存放數(shù)據(jù)塊的地址，在音頻采集模塊向音頻編碼模塊，或者是同步模塊向音頻播放發(fā)送數(shù)據(jù)時，只需指出該數(shù)據(jù)塊的地址及音頻數(shù)據(jù)偏移量即可，而不需要重復拷貝。
　　在實時操作系統(tǒng)系統(tǒng)環(huán)境下，音頻采集/播放模塊可分為兩個獨立的任務或線程，即音頻采集和音頻播放。其中，音頻采集線程還擁有一個子線程，即數(shù)據(jù)發(fā)送線程，該線程的任務是實時地將采集完畢的音頻數(shù)據(jù)發(fā)送至音頻編碼模塊；音頻播放線程也擁有一個子線程，即數(shù)據(jù)播放線程，該線程的任務是實時地將音頻數(shù)據(jù)從播放緩沖區(qū)取出，送至音頻驅動以供播放。
　　音頻采集模塊在收到采集啟動消息后，將待采集數(shù)據(jù)塊（為了保證采集的連續(xù)性，這里需要是多個數(shù)據(jù)塊）的地址告知驅動，并通知驅動開始采集；當一塊數(shù)據(jù)塊采集完成后，數(shù)據(jù)發(fā)送線程將采集的數(shù)據(jù)取出發(fā)送給音頻編碼實體，并申請下一塊數(shù)據(jù)送給驅動。音頻播放模塊在收到播放啟動消息后，并不馬上播放，而是先將同步模塊發(fā)來的數(shù)據(jù)填入播放（環(huán)形）緩沖區(qū)。在填到一個門限值后，從緩沖區(qū)的第一塊數(shù)據(jù)開始，將多個數(shù)據(jù)塊的地址送往驅動，并通知驅動開始播放；每當一塊數(shù)據(jù)播放完成后，數(shù)據(jù)播放線程都取出下一塊數(shù)據(jù)送給驅動。
　　4.3 線程的同步與互斥
　　由于音頻的采集和播放都是由兩個線程協(xié)作完成的，因此線程間的同步與互斥是重點。在音頻采集線程和數(shù)據(jù)發(fā)送線程之間，音頻播放線程和數(shù)據(jù)播放線程之間需要進行同步，也就是說，當一個數(shù)據(jù)塊采集/播放完畢時，需要以某種方式告知數(shù)據(jù)發(fā)送/播放線程去取下一個數(shù)據(jù)塊。
　　對于VoIP的應用來說，通知的實時性最為重要。首先考慮回調函數(shù)方式，它的實時性最高，但在一些系統(tǒng)中（如Windows），在回調函數(shù)中調用音頻驅動的某些函數(shù)可能會引起死鎖；其次是事件通知方式，即在數(shù)據(jù)發(fā)送線程中，等待“采集完成”事件的發(fā)生，一旦采集完成，該事件即被置為“有事件”狀態(tài)，這種方式的實時性較好，只是獲取數(shù)據(jù)塊索引的方式略為麻煩（因為送往驅動待采集播放的數(shù)據(jù)不止一塊）；采集完成后，驅動亦可向指定的線程發(fā)送消息，但由于消息機制的實時性不高，所以不作考慮。因此，一般采用事件進行通知的方式來完成同步和互斥。
　　5 時間戳的產生
　　根據(jù)協(xié)議規(guī)定，音頻時間戳的分辨率為1/8000秒，視頻時間戳的分辨率為1/90000秒，因此需要采用高精度的計數(shù)器（其分辨率不低于1/90000秒）。由于音視頻時間戳要求的分辨率不同，在沒有兩個計數(shù)器的情況下，可以用一個計數(shù)器來得到兩種時間戳。
　　首先獲取計數(shù)器頻率Freq。在啟動采集時，查詢計數(shù)器的初使值，保存在一個靜態(tài)變量當中。接下來通過MD5算法產生一個32bit的隨機數(shù)賦予timeStamp作為第一個RTP包的時間戳。每當有數(shù)據(jù)塊采集完成，查詢當前計數(shù)器的值，計算與計數(shù)器初始值的差值CntGap，將這個差值與計數(shù)器周期相乘得到實際時間差timeGap，即：
　　timeGap = (double)( (double) CntGap / Freq)，將這個時間差除以RTP時間戳的周期1/8000（1/90000），再加上時間戳的初值，即得到本次采集的時間戳。
　　6 結束語
　　由于音/視頻數(shù)據(jù)的采集/播放性能直接關系到通話質量，所以高性能的VoIP終端離不開高性能的媒體采集/播放模塊。本文提出了影響音/視頻數(shù)據(jù)的采集/播放性能的一些因素，并討論了以Windows操作系統(tǒng)為例的設計方法。在其他平臺上開發(fā)VoIP終端時，采集/播放模塊與操作系統(tǒng)的接口由于實際平臺的不同將會有所差異，但本方案提出的模塊內部結構，與周圍模塊的接口等與平臺無關，因此仍有一定的參考價值。

中國數(shù)據(jù)通信