Windows 即時通訊 (RTC) 客戶端的媒體支援詳解

摘要

Microsoft Windows 的即時通訊 (RTC) 客戶端由一系列核心組件構成，提供豐富的通訊特性。這些特性透過 Windows Messenger 及其他使用此應用程式開發介面 (API) 的應用程式呈現給使用者。本文將概述與媒體相關的特性以及這些組件提供的增強功能。應用程式開發者或許想將 RTC 特性整合到自己的程式中以改善使用者體驗，開發者還能利用 RTC 的特性建構自己的社群。

引言

Microsoft Windows XP 整合並增強了豐富的通訊特性，為 RTC 體驗奠定了基礎。Windows Messenger 利用這些特性為使用者之間的通訊提供即時語音、視訊、即時訊息及其他協作功能。此外，所提供的 API 使得這些豐富的通訊特性可供任何應用程式使用。

本文詳細討論了添加到 RTC 的媒體改進特性，這些改進讓最終使用者和開發者都能獲得更愉快的體驗。當應用程式建構在 RTC 客戶端 API 之上，最終使用者能獲得豐富的音視訊體驗，而開發者可以讓程式獲得一系列免費的改進。使用這些 API 建構的應用程式還能存取 RTC 提供的即時訊息和在線狀態功能。有關這些 API 的資訊，可在 Windows Platform SDK 中獲得。

主要特性與改進

• 音訊/視訊編解碼器的可用性
• 回音消除 (AEC)
• 冗餘音訊編碼
• 動態抖動緩衝與調整
• 自動增益控制 (AGC)
• 頻寬估算
• 品質控制演算法

音訊/視訊編解碼器的可用性

Windows RTC 客戶端支援下表列出的音訊編解碼器，同時列出了相關的取樣率和位元率。選擇哪種編解碼器取決於通訊雙方的能力和頻寬。例如，如果其中一方使用 56 Kbps 的撥號連線，那麼 G.711 將被停用，因為它超出了可用的頻寬限制。又如，假設一方支援 SIREN，而另一方不支援，那麼首選的編解碼器 SIREN 將被停用。如果雙方均支援 SIREN 且頻寬足夠，那麼在所有編解碼器中 SIREN 即為首選。

H.263 是視訊支援的編解碼器，其位元率在 6 Kbps 到 125 Kbps 之間。為了相容性，H.261 也是被支援的編解碼器。該版本僅支援 QCIF (176×144) 解析度。不支援第三方編解碼器外掛。

回音消除 (AEC)

AEC 的工作原理是透過對講話者的輸出建模，並將其從麥克風捕捉的訊號中移除。AEC 有助於確保對方聽不到回聲。

要啟用 AEC，在 Windows Messenger 中執行「音訊和視訊調校」精靈 (Tools / Audio Tuning Wizard)。在音訊調校部分，取消勾選「I am using headphones」核取方塊。

圖一：音視訊調校精靈對話框

使用 IRTCClient 介面的 PreferredAEC 方法可透過程式設計實現對 AEC 的啟用和停用。RTC 客戶端使用的 AEC 模組是 Microsoft DirectSound 底層架構的一部分，包含以下特性與限制：

• AEC 僅在不超過 25×15×9 英尺的小房間有效；
• AEC 僅對單聲道有效，當輸出為多聲道立體聲時，僅有一個聲道能具有回音消除效果；
• AEC 無法消除來自其他聲音源的聲音，如背景中收音機播放的歌曲；
• 以下兩項限制僅適用於 Windows XP RTM 版 RTC 客戶端，可從 Windows Update 下載更新套件移除這兩項限制：
• AEC 要求音訊擷取與播放裝置使用同一個時脈，意味著 AEC 對 USB 音訊裝置無效。若偵測到此情況，音訊調校精靈中的核取方塊會被停用；
• AEC 僅對取樣率 8 kHz 和 16 kHz 的訊號有用，對其他取樣率的聲卡 (如基於 AC'97、約 44 kHz) 無效，調校精靈同樣會停用 AEC。

可在程式中透過 IRTCClient 介面的 PreferredAEC 方法控制 AEC。

冗餘音訊編碼

冗餘音訊編碼是一種補償封包遺失的技術。RTC 客戶端實作了一種 one-packet 冗餘演算法：啟用時，每個封包包含當前音訊框架與前一個音訊框架。若某封包遺失，接收端仍可在緊隨其後的封包中取得該框架。此過程依據 IETF RFC 2198 文件。可恢復的封包上限為 3 個。演算法根據即時通訊控制協定 (RTCP) 提供的資訊自適應調整。

演算法初始冗餘為 0，隨著封包遺失引入冗餘。原始資料封包與攜帶備份的封包間距決定可恢復多少遺失封包，距離範圍 1~3。下表說明不同丟包率下的距離取值：

RTC 客戶端實作了自動冗餘音訊編碼。

動態抖動緩衝與調整

抖動緩衝用於透過緩衝音訊封包並調整其呈現，平滑接收音訊中的延遲變化，使語音更平滑地傳給使用者。客戶端可擁有高達 500 毫秒的抖動緩衝，即可吸收 500 ms 內的延遲變化而不引起語音抖動。

播放緩衝為 2 秒的循環緩衝。若在極短時間內收到超過 2 秒的語音資料封包，新封包將被丟棄。此版本中，抖動緩衝在新的音訊資料高峰時重新調整。為確保高品質語音，傳送端應對所有編解碼使用靜音抑制，RTC 客戶端預設啟用靜音抑制。

自動增益控制 (AGC)

AGC 是根據輸入訊號電平動態調整增益的機制。RTC 客戶端根據擷取到的音量調整麥克風增益以實現 AGC。當音量 (無論擷取或播放) 超過某門檻，訊號會被限幅，導致聲音中斷。RTC 客戶端偵測到音訊增益達到門檻 (每個封包連續平均峰值脈衝編碼調製值超過最大門檻) 時，會自動降低增益避免限幅。反之，若擷取音量過低 (低於最低門檻)，則提高增益，但不超過使用者在調校精靈設定的值。注意：啟用 AEC 時增益不會增大，否則會導致 AEC 重新聚合，需數秒時間。

頻寬估算

實際可用頻寬可能少於 Windows Socket 回報的本地連線速度，原因包括通道低速連線、其他應用程式佔用頻寬等。為估算實際可用頻寬，RTC 客戶端發送連續的 RTCP 封包，對方根據封包間延遲估算頻寬。最初每個 RTCP 報告都用於估算，逐漸減為每三個封包之一。目前估算結果可指示連線是否為 LAN，並作為計算實際可用頻寬上限的依據；未來將擴展以提供更具體結果。

品質管理演算法 (QC)

RTC 媒體品質管理的目標是在不同網路環境中，透過 RTC 客戶端為使用者提供更好的音視訊服務。QC 持續監控網路環境，計算輸出流可用頻寬，動態改變音視訊輸出流設定，提供更平滑的流輸出、最小抖動與延遲。在音視訊流之間，QC 給予音訊更高優先級。

QC 於收到來自應用程式、遠端或即時傳輸協定 (RTP) 模組的命令/事件時調整輸出流：應用程式透過增減流或改變最大位元率觸發；遠端透過傳送新的 SDP (工作階段描述協定) 觸發；RTP 模組週期性發送 RTC 媒體事件回報對端估計頻寬與丟包率。QC 演算法包含三大部分：計算輸出流可用頻寬、動態選擇與設定音訊編解碼器、計算視訊輸出流頻寬與畫格率。

可用頻寬計算因素

• 本地頻寬：偵測連線速度減去保留頻寬 (20 Kbps 與偵測速度 2/5 之較小值)，保留頻寬用於非音視訊流量 (如 SIP 訊號)。通話初期若偵測頻寬 > 200 Kbps，本地頻寬限制在 ≤ 120 Kbps。
• 遠端頻寬：從 SDP blob 取得。
• 應用程式頻寬：由應用程式設定，上限 1 Mbps，透過 IRTCClient::MaxBitrate 設定。
• 估計頻寬：RTP 模組回報頻寬減去保留頻寬 (10 Kbps 與回報值 1/3 之較小值)。
• 先前分配頻寬：上一次計算的可用頻寬。
• 當前頻寬：流實際使用的總頻寬。
• 當前丟包率：本端發出封包的遺失百分比。
• 連續零丟包報告數：收到零丟包報告加 1，非零歸零。

音訊編解碼器選擇

輸出音訊編解碼器的選擇基於：可用頻寬、頻寬限制演算法、輸出視訊流是否存在、SDP 中編解碼器優先順序、各編解碼器預定義最小頻寬、RTP 是否已回報頻寬估計、編解碼器切換的頻寬門檻。根據條件動態選擇最佳編解碼器與框架大小。若有多種酬載類型，端點應準備好支援酬載類型與框架大小的變化。

視訊頻寬與畫格率

輸出視訊流畫格率由可用頻寬、最近選擇的視訊編解碼器總頻寬、應用程式設定的臨時頻寬計算，確保視訊不干擾音訊正常通訊。所有變化均為動態。應用程式可透過 IRTCClient::MaxBitRate 和 TemporalSpatialTradeOff 影響演算法，但無法決定最終設定。

結語

Windows XP 內建的即時通訊客戶端媒體特性，使 RTC 客戶端成為在各類應用程式中使用 RTC 特性的龐大平台。這些特性在 Windows Messenger 中得以體現，透過 RTC 客戶端 API 可廣泛應用於其他應用程式。