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

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