Micosoft實(shí)時(shí)通信API多媒體支持慨述

2019-11-17 04:51:04

字體：大中小

供稿：網(wǎng)友

　　摘要：微軟實(shí)時(shí)通信（RTC）API是一套提供有豐富功能的核心組件。這些性能我們可以在Windows Messenger和其它使用實(shí)時(shí)通信API的應(yīng)用程序中看到。本文將介紹由這些組件提供的多媒體支持。應(yīng)用程序開發(fā)人員可能想把實(shí)時(shí)通信特色整合到他們的應(yīng)用程序中去，還可以使用實(shí)時(shí)通信特性來構(gòu)建他們自己的社區(qū)。　　介紹

　　根據(jù)Microsoft Windows xp的介紹，豐富的通信特性已經(jīng)被組合并增強(qiáng)以便在基礎(chǔ)結(jié)構(gòu)中提供為實(shí)時(shí)通信(RTC)軟件提供支持。這些特性被Microsoft Windows Messenger用來顯示實(shí)時(shí)語音和視頻、即時(shí)消息及其他協(xié)同信息。此外，API也顯示出能夠在任何應(yīng)用程序中使用其豐富的通信基礎(chǔ)結(jié)構(gòu)。

　　本文將詳述應(yīng)用程序開發(fā)人員怎樣在軟件中加入實(shí)時(shí)通信的多媒體性能。當(dāng)使用實(shí)時(shí)通信客戶端應(yīng)用程序接口建立起應(yīng)用程序的時(shí)候，用戶經(jīng)歷了一次豐富的音頻與視頻體驗(yàn)，而開發(fā)者則免費(fèi)地得到了一套范圍很廣的改進(jìn)功能。使用這個(gè)應(yīng)用程序接口建起的應(yīng)用程序還可以使用實(shí)時(shí)通信提供的即時(shí)消息和出席（PResent）函數(shù)。有關(guān)這個(gè)應(yīng)用程序接口的介紹在Windows Platform SDK中可以找到。

　　音頻與視頻解碼器有效性

　　Windows實(shí)時(shí)通信客戶端支持下表所列的音頻解碼器，同時(shí)也列出了有關(guān)的采樣率與比特率。解碼器選擇是基于參與會(huì)話的客戶端以及他們之間的帶寬兩者來綜合考慮的。例如，假如一個(gè)參與者使用56K的連接速率撥號(hào)上網(wǎng)，將不能使用G.711，因?yàn)樗隽丝捎脦挕Ａ硪粋€(gè)例子是，假如一個(gè)參與者支持SIREN但是另一個(gè)不支持；這種情況下，我們更喜歡的解碼器SIREN就不能使用了。假如兩個(gè)參與者都支持SIREN并且?guī)捵銐颍敲碨IREN將是比其他解碼器更好的選擇。
解碼器采樣率比特率實(shí)時(shí)協(xié)議包持續(xù)時(shí)間G.7118 Kilohertz (kHz)64 kilobits per second (Kbps)20 milliseconds (msec)G.722.116 Khz24 Kbps20 msecG.7238 Khz6.4 Kbps 30 msec, 60 msec or 90 msecGSM 8 Khz 13 Kbps20 msecDVI4 8 Khz32 Kbps20 msecSIREN 16 Khz 16 Kbps 20 msec or 40 msec　　H.263解碼器支持視頻。用于這個(gè)解碼器的比特率可以從6KBps到125之間變化。H.261解碼器也支持兼容性。QCIF (176x144)在這個(gè)版本中被支持。不支持第三方解碼器的插件。聲學(xué)回聲消除（AEC）

　　AEC建模揚(yáng)聲器輸出的音頻，并把它從麥克風(fēng)捕捉的信號(hào)中剔除。AEC能夠保證在另一個(gè)客戶端不會(huì)聽到回聲。

　　為了使AEC可用，我們需要運(yùn)行Windows Messenger的音頻與視頻調(diào)節(jié)向?qū)А?在向?qū)У囊纛l調(diào)節(jié)部分，清除"I am using headphones"復(fù)選框的選擇。

Micosoft實(shí)時(shí)通信API多媒體支持慨述（圖二）

圖1、音頻與視頻調(diào)節(jié)向?qū)?duì)話框

　　在編程的時(shí)候，我們可以使用IRTCClient接口的PreferredAEC方法來啟動(dòng)或者禁止AEC。

　　假如想獲得關(guān)于實(shí)時(shí)通信客戶端應(yīng)用程序接口的具體資料，請(qǐng)參閱Platform SDK。

　　實(shí)時(shí)通信客戶端使用的AEC模塊是微軟DirectSound架構(gòu)的一部分。這個(gè)組件包括下面的特性和限制：

　　　· AEC只能在小的房間里工作，房間最大為25*15*9英尺。

　　　· AEC只能使用單聲道音頻流。假如輸出的是多聲道立體聲，那么只有一個(gè)聲道能夠接收回聲消除。

　　　· AEC不能消除來自其他聲源的聲音，比如背景中收音機(jī)播放的歌曲。

　　　　注重下面兩個(gè)限制只針對(duì)Windows XP實(shí)時(shí)通信客戶端。可以從Windows Update上下載一個(gè)程序包，去除這個(gè)限制。

　　　· AEC需要存在相同時(shí)鐘頻率的音頻截取和處理設(shè)備。這意味著AEC不能使用USB音頻設(shè)備。假如實(shí)時(shí)通信客戶端探測到用戶使用了USB音頻設(shè)備，那么調(diào)節(jié)向?qū)ё詣?dòng)禁止復(fù)選框，這樣可以防止用戶啟動(dòng)AEC。

　　　· AEC只能用于8 kHz或者16 kHz的樣本信號(hào)。這意思就是AEC不能在使用其他采樣率的聲卡上工作，例如采樣率為44 kHz的基于AC 97的聲卡。同樣，調(diào)節(jié)向?qū)z測到這樣的聲卡也會(huì)禁用AEC。

　　在編程時(shí)，我們可以使用IRTCClient接口的PreferredAEC方法控制AEC。

　　冗余音頻編碼

　　冗余音頻編碼是一個(gè)用于補(bǔ)償語音包損失的技術(shù)。實(shí)時(shí)通信客戶端實(shí)現(xiàn)了一個(gè)單語音包冗余算法。當(dāng)冗余語音算法可用時(shí)，每個(gè)語音包都帶有當(dāng)前音頻幀和一個(gè)前期的音頻幀。假如一個(gè)音頻包丟失了，接收程序還有一次機(jī)會(huì)從后面的包中取得音頻幀。這個(gè)操作過程可在IETF RFC 2198中查到。可以被復(fù)原的連續(xù)音頻包的最大數(shù)是3。基于實(shí)時(shí)控制協(xié)議(RTCP)中提供的信息，這種方法是適用的。

　　這個(gè)算法從零冗余開始，當(dāng)探測到音頻包丟失的時(shí)候，就引入冗余。原始音頻包和攜帶了原始數(shù)據(jù)副本的音頻包之間的間隔決定了有多少丟失的包能夠被恢復(fù)。這個(gè)間隔可以在1到3個(gè)包之間變化。比如說，假如間隔為2并且我丟失了第N個(gè)包，那么我可以在第N+2個(gè)包里取得同樣的信息。假如我丟失了第N和N+1個(gè)包，那么我仍然可以從第N+2和N+3個(gè)包中取得所有的信息。假如我丟失了第N,N+1,N+2個(gè)包，那么第N個(gè)包中的信息就不能被恢復(fù)了（它在第N+2個(gè)包內(nèi)）。下面的表格說明了各個(gè)間隔高低不同的包損失率。
間隔損失率（低）損失率（高）005141029 1531420
　　實(shí)時(shí)通信客戶端自動(dòng)執(zhí)行冗余音頻編碼。　動(dòng)態(tài)抖動(dòng)緩沖和調(diào)節(jié)

　　抖動(dòng)緩沖通過緩沖接收到音頻包，并調(diào)節(jié)它們的效果渲染來平衡這些音頻包中的延遲誤差。其結(jié)果是把更加平滑的聲音傳送給用戶。客戶端有一個(gè)500毫秒的抖動(dòng)緩沖。換句話說，緩沖可以平滑化接收語音包中500毫秒的延遲誤差而不會(huì)讓用戶聽到斷裂的聲音。

　　整體效果渲染緩沖是一個(gè)兩秒鐘的循環(huán)緩沖。假如我們?cè)诜浅６痰臅r(shí)間里獲得了一個(gè)數(shù)據(jù)量超過兩秒的包，那么新的包就會(huì)丟失。

　　在這個(gè)版本中，抖動(dòng)緩沖在一個(gè)新的音頻流忽然爆發(fā)的時(shí)候會(huì)重新調(diào)整。

　　自動(dòng)增益控制（AGC）

　　AGC是一個(gè)基于輸入信號(hào)水平自動(dòng)調(diào)節(jié)增益的機(jī)制。實(shí)時(shí)通信客戶端通過調(diào)節(jié)基于捕捉音頻水平的麥克風(fēng)增益來實(shí)現(xiàn)AGC。

　　當(dāng)音頻水平（不管是獲得還是渲染）增加值超過某個(gè)閾值，就會(huì)發(fā)生削波（clipping）。削波是指當(dāng)捕捉設(shè)備或者渲染設(shè)備的輸出不再依據(jù)輸入增益變化并且輸出值基本上保持在最高水平的時(shí)候，造成的音頻破碎。當(dāng)實(shí)時(shí)通信客戶端探測到音頻增益超過了某個(gè)閾值--連續(xù)探測到每個(gè)包的脈沖編碼調(diào)制峰值的平均值高于一個(gè)上限閾值--它就會(huì)自動(dòng)減小增益以便不發(fā)生削波。

　　另一方面，假如捕捉到的音頻太低（比如說連續(xù)探測到每個(gè)包的脈沖編碼調(diào)制峰值的平均值低于一個(gè)下限閾值）那么實(shí)時(shí)通信客戶端就提高增益。增益會(huì)被調(diào)節(jié)以便其音頻水平不會(huì)超過用戶在調(diào)節(jié)向?qū)е性O(shè)置的水平。

　　注重，在啟動(dòng)AEC的時(shí)候不會(huì)調(diào)節(jié)增益，因?yàn)檫@需要AEC重會(huì)聚，而這可能會(huì)花費(fèi)幾秒鐘的時(shí)間。

　　帶寬測定

　　實(shí)際可用的帶寬可能比使用Windows Sockets報(bào)告的本地連接速度要少。這可能有好幾個(gè)原因，包括線路連接速度慢，帶寬被其它應(yīng)用程序使用等等。

　　為了測算實(shí)際可用帶寬，實(shí)時(shí)通信客戶端發(fā)送"背靠背"RTCP包。另一個(gè)終端通過計(jì)算包之間的延遲可以估算出實(shí)際帶寬。這種測定方法開始是每個(gè)RTCP報(bào)告中都要進(jìn)行（大約每5秒一次），然后逐步縮減到每三個(gè)RTCP報(bào)告進(jìn)行一次。

　　目前，測定的結(jié)果指出連接是否是LAN，當(dāng)計(jì)算實(shí)際可用帶寬的時(shí)候被用做一個(gè)上限。以后，這個(gè)算法將擴(kuò)展到能夠給出更具體的結(jié)果。

　　質(zhì)量控制算法

　　實(shí)時(shí)通信媒體中質(zhì)量控制（QC）的目的是給不同網(wǎng)絡(luò)連接情況下的實(shí)時(shí)通信客戶端用戶提供一個(gè)非常好的音頻與視頻體驗(yàn)。質(zhì)量控制不斷的監(jiān)視網(wǎng)絡(luò)情況，計(jì)算用于輸出流的可用帶寬，動(dòng)態(tài)改變音頻與視頻輸出流的設(shè)定來提供流平滑和抖動(dòng)與延遲最小化。在音頻與視頻輸出流中，QC把音頻的優(yōu)先級(jí)設(shè)置的較高。

　　當(dāng)QC接收來自以下三個(gè)源之一的命令或者事件的時(shí)候，QC會(huì)調(diào)節(jié)輸出流：應(yīng)用程序、遠(yuǎn)程參與者和即時(shí)傳送協(xié)議（RTP）模塊。應(yīng)用程序通過添加或者刪除流，或者改變最大bit率的設(shè)定來觸發(fā)一個(gè)調(diào)節(jié)過程。當(dāng)遠(yuǎn)程參與者發(fā)送一個(gè)新的改變流或者bit率的SDP (會(huì)話描述協(xié)議，session Description Protocol)的時(shí)候，調(diào)節(jié)過程也會(huì)被觸發(fā)。RTP模塊周期性地發(fā)送媒體事件通知監(jiān)聽器猜測的帶寬和包損失率。一旦接收到這些事件，QC會(huì)調(diào)節(jié)輸出音頻與視頻流。

　　QC算法由三部分組成：計(jì)算輸出流的可用帶寬，動(dòng)態(tài)選擇并設(shè)置音頻解碼器并且計(jì)算用于視頻輸出流的帶寬和幀速率。在下面的三節(jié)里將討論這些問題。

　　可用帶寬

　　QC基于下面這些因素計(jì)算用于輸出流的可用帶寬：

　 · 本地帶寬

　　本地帶寬相當(dāng)于探測到的連接速度減去保留帶寬。保留帶寬最小值為20 Kbps，通常是探測到的連接速度的2/5。保留帶寬用于除了音頻/視頻流之外的SIP信號(hào)等。在調(diào)用開始的時(shí)候--在任何猜測帶寬被RTP模塊報(bào)告之前--假如測定值大于200Kbps的話，本地帶寬被限制為不得超過120Kbps。

　　· 遠(yuǎn)程帶寬

　　遠(yuǎn)程帶寬被SDP使用。

　　· 應(yīng)用程序帶寬

　　應(yīng)用程序帶寬由應(yīng)用程序設(shè)置，最大上限為1 Mbps，應(yīng)用程序通過設(shè)置IRTCClient接口的MaxBitrate值配置這個(gè)帶寬最大值。

　　· 猜測帶寬

　　猜測帶寬等于RTP模塊報(bào)告的帶寬減去保留帶寬。保留帶寬最小為10 Kbps，通常是報(bào)告值的3/10。

　　· 前次分配帶寬

　　前次分配帶寬根據(jù)上次調(diào)用計(jì)算的可用帶寬。

　　· 當(dāng)前帶寬

　　當(dāng)前帶寬是輸出流使用的實(shí)際帶寬。

　　· 當(dāng)前損失率

　　當(dāng)前損失率是從本地終端發(fā)送的包的損失百分比。

　　· 連續(xù)零損失報(bào)告數(shù)

　　當(dāng)一個(gè)零損失報(bào)告被接收時(shí)，這個(gè)數(shù)值加1。當(dāng)有一個(gè)非零損失報(bào)告被接收的時(shí)候，這個(gè)數(shù)值設(shè)為零。

　　音頻解碼器選擇

　　用于輸出音頻流的解碼器基于下面幾種因素選擇和配置。

　　· 可用帶寬。

　　· 用可用帶寬計(jì)算算法得出的帶寬極限值。

　　· 存在輸出視頻信息流。

　　· 選擇SDP的解碼器。

　　· 用于每個(gè)音頻解碼器的預(yù)設(shè)定最小帶寬。

　　· RTP模塊是否已經(jīng)報(bào)告帶寬猜測值。

　　· 轉(zhuǎn)換解碼器的帶寬閾值。

　　將會(huì)根據(jù)不同的情況選擇出最佳的解碼器和幀尺寸。在調(diào)用時(shí)，這些更改會(huì)動(dòng)態(tài)發(fā)生。

　　視頻信號(hào)帶寬和幀速率

　　用于輸出視頻信息流的設(shè)定基于下列因素計(jì)算：

　　· 可用帶寬。

　　· 最新選擇的音頻解碼器所使用的大致帶寬。

　　· 應(yīng)用程序設(shè)置的時(shí)空交換。

　　基于以上所述因素計(jì)算的視頻bit率和幀速率將不會(huì)中斷音頻傳輸。而且，所有的改變都是動(dòng)態(tài)發(fā)生的。應(yīng)用程序可以使用IRTCClient接口的MaxBitRate和TemporalSpatialTradeOff來影響算法，但是不能決定最后的設(shè)定。

　　結(jié)論

　　Windows XP的即時(shí)通信客戶端的媒體特性可以為所有類型的應(yīng)用程序提供一個(gè)使用實(shí)時(shí)通信特性的巨大的平臺(tái)。
這些特性在Windows Messenger中展現(xiàn)了出來，并且通過使用實(shí)時(shí)通信客戶端API也可在其他應(yīng)用程序中使用。

上一篇：優(yōu)秀的界面設(shè)計(jì)是如何誕生的

下一篇：單元測試作業(yè)指導(dǎo)系列講座之一