Micosoft實時通信API多媒體支持慨述

2019-11-17 04:51:04

字體：大中小

來源：轉載

供稿：網友

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

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

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

　　音頻與視頻解碼器有效性

　　Windows實時通信客戶端支持下表所列的音頻解碼器，同時也列出了有關的采樣率與比特率。解碼器選擇是基于參與會話的客戶端以及他們之間的帶寬兩者來綜合考慮的。例如，假如一個參與者使用56K的連接速率撥號上網，將不能使用G.711，因為它超出了可用帶寬。另一個例子是，假如一個參與者支持SIREN但是另一個不支持；這種情況下，我們更喜歡的解碼器SIREN就不能使用了。假如兩個參與者都支持SIREN并且帶寬足夠，那么SIREN將是比其他解碼器更好的選擇。
解碼器采樣率比特率實時協議包持續時間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解碼器支持視頻。用于這個解碼器的比特率可以從6KBps到125之間變化。H.261解碼器也支持兼容性。QCIF (176x144)在這個版本中被支持。不支持第三方解碼器的插件。聲學回聲消除（AEC）

　　AEC建模揚聲器輸出的音頻，并把它從麥克風捕捉的信號中剔除。AEC能夠保證在另一個客戶端不會聽到回聲。

　　為了使AEC可用，我們需要運行Windows Messenger的音頻與視頻調節向導。在向導的音頻調節部分，清除"I am using headphones"復選框的選擇。

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

圖1、音頻與視頻調節向導對話框

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

　　假如想獲得關于實時通信客戶端應用程序接口的具體資料，請參閱Platform SDK。

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

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

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

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

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

　　　· AEC需要存在相同時鐘頻率的音頻截取和處理設備。這意味著AEC不能使用USB音頻設備。假如實時通信客戶端探測到用戶使用了USB音頻設備，那么調節向導自動禁止復選框，這樣可以防止用戶啟動AEC。

　　　· AEC只能用于8 kHz或者16 kHz的樣本信號。這意思就是AEC不能在使用其他采樣率的聲卡上工作，例如采樣率為44 kHz的基于AC 97的聲卡。同樣，調節向導檢測到這樣的聲卡也會禁用AEC。

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

　　冗余音頻編碼

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

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

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

　　整體效果渲染緩沖是一個兩秒鐘的循環緩沖。假如我們在非常短的時間里獲得了一個數據量超過兩秒的包，那么新的包就會丟失。

　　在這個版本中，抖動緩沖在一個新的音頻流忽然爆發的時候會重新調整。

　　自動增益控制（AGC）

　　AGC是一個基于輸入信號水平自動調節增益的機制。實時通信客戶端通過調節基于捕捉音頻水平的麥克風增益來實現AGC。

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

　　另一方面，假如捕捉到的音頻太低（比如說連續探測到每個包的脈沖編碼調制峰值的平均值低于一個下限閾值）那么實時通信客戶端就提高增益。增益會被調節以便其音頻水平不會超過用戶在調節向導中設置的水平。

　　注重，在啟動AEC的時候不會調節增益，因為這需要AEC重會聚，而這可能會花費幾秒鐘的時間。

　　帶寬測定

　　實際可用的帶寬可能比使用Windows Sockets報告的本地連接速度要少。這可能有好幾個原因，包括線路連接速度慢，帶寬被其它應用程序使用等等。

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

　　目前，測定的結果指出連接是否是LAN，當計算實際可用帶寬的時候被用做一個上限。以后，這個算法將擴展到能夠給出更具體的結果。

　　質量控制算法

　　實時通信媒體中質量控制（QC）的目的是給不同網絡連接情況下的實時通信客戶端用戶提供一個非常好的音頻與視頻體驗。質量控制不斷的監視網絡情況，計算用于輸出流的可用帶寬，動態改變音頻與視頻輸出流的設定來提供流平滑和抖動與延遲最小化。在音頻與視頻輸出流中，QC把音頻的優先級設置的較高。

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

　　QC算法由三部分組成：計算輸出流的可用帶寬，動態選擇并設置音頻解碼器并且計算用于視頻輸出流的帶寬和幀速率。在下面的三節里將討論這些問題。

　　可用帶寬

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

　 · 本地帶寬

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

　　· 遠程帶寬

　　遠程帶寬被SDP使用。

　　· 應用程序帶寬

　　應用程序帶寬由應用程序設置，最大上限為1 Mbps，應用程序通過設置IRTCClient接口的MaxBitrate值配置這個帶寬最大值。

　　· 猜測帶寬

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

　　· 前次分配帶寬

　　前次分配帶寬根據上次調用計算的可用帶寬。

　　· 當前帶寬

　　當前帶寬是輸出流使用的實際帶寬。

　　· 當前損失率

　　當前損失率是從本地終端發送的包的損失百分比。

　　· 連續零損失報告數

　　當一個零損失報告被接收時，這個數值加1。當有一個非零損失報告被接收的時候，這個數值設為零。

　　音頻解碼器選擇

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

　　· 可用帶寬。

　　· 用可用帶寬計算算法得出的帶寬極限值。

　　· 存在輸出視頻信息流。

　　· 選擇SDP的解碼器。

　　· 用于每個音頻解碼器的預設定最小帶寬。

　　· RTP模塊是否已經報告帶寬猜測值。

　　· 轉換解碼器的帶寬閾值。

　　將會根據不同的情況選擇出最佳的解碼器和幀尺寸。在調用時，這些更改會動態發生。

　　視頻信號帶寬和幀速率

　　用于輸出視頻信息流的設定基于下列因素計算：

　　· 可用帶寬。

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

　　· 應用程序設置的時空交換。

　　基于以上所述因素計算的視頻bit率和幀速率將不會中斷音頻傳輸。而且，所有的改變都是動態發生的。應用程序可以使用IRTCClient接口的MaxBitRate和TemporalSpatialTradeOff來影響算法，但是不能決定最后的設定。

　　結論

　　Windows XP的即時通信客戶端的媒體特性可以為所有類型的應用程序提供一個使用實時通信特性的巨大的平臺。
這些特性在Windows Messenger中展現了出來，并且通過使用實時通信客戶端API也可在其他應用程序中使用。

上一篇：優秀的界面設計是如何誕生的

下一篇：單元測試作業指導系列講座之一