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也可在其他应用程序中使用。

上一篇：优秀的界面设计是如何诞生的

下一篇：单元测试作业指导系列讲座之一