一种H.323视频会议系统音视频同步方法

之后依然存在的丢包，必然是及其少量的。本方法中的音频采样、组帧和打包是分开处理的，即音视频RTP包号分别连续，所以一般情况，依据各自的包序号即可判断是否有丢包。而对于一个会话中收到的第一个媒体包即丢失的情况，一旦出错，可能导致音视频播放时间整体错位。本文通过发送端所加的RTP 包头中的时戳来避免这种情况，时间戳的计算公式如下：

Timestamp（0） = （unsigned long） r and（）；

Timestamp（t）=Timestamp（0）+△T*fr eq /1000;

△T = T（t） – T（0），时间差，单位： ms;freq: 采样频率；

H.323 视频会议中，与会各方的编解码协议、采样率、帧率等参数在打开通道后的能力协商阶段即已确定，要改变这些参数，必然要重新能力协商，而任何时候应用层都知道协商的结果。所以只要规定一个会话中发送的头一个音频包和头一个视频包的时戳相同，即可由时戳来建立音视频包的对应关系。实际上，视频数据头一帧的图像分成多个包传输，这几个包具有相同的时戳，同时丢失的可能性很小。而且视频组帧解码过程中，还要分I 帧、P 帧和B 帧区别处理，比如每个GOP 中只要I 帧丢失，其后的P 帧和B 帧都必须丢弃，直到收到下一个I 帧，这已经超出了本文的研究范围，此处不再详述。

4 理论分析和结果验证

理论上讲，采用本方法后，在网络状态良好时能做到音视频传输中的完全同步。网络状态恶化时，随着丢包率的增加，同步效果会稍微变差，其中随机丢包比周期丢包对同步效果的影响更明显，这是因为随机丢包会引起更多的网络抖动。而在帧率码率和编解码协议不变的情况下。带宽越小，网络越容易拥塞，所以带宽降低时同步效果也会变差。

将本方案应用在开源的H.323 协议栈OPENH323 上[7],实现了一个简单的基于PC 机的H.323 桌面终端。两台终端建立会话，通过IP cloud 在两台终端间模拟各种复杂恶劣的网络环境，然后使用Wireshark 抓包，可以看到音视频包的发送接收时间以及有关包头信息，进而计算出传输中引起的音视频偏差时间。考虑到算法的复杂度，本方案选择了相对较易实现的H.261 和GSM6.10 作为音视频编解码协议。图3 是呼叫建立后在发送端10.21.11.121 上截的图。发送端敲击麦克风，接收端看到敲击动作的同时听到敲击声，同步效果良好。

图3 验证平台--终端互通实现效果图。

终端10.21.11.121 在正常网络环境下，以512k的带宽呼叫终端10.21.11.152,呼叫建立5 分钟之后用Wireshark 抓到的音视频数据包如图4 和图5 所示：

图4 发送端音视频数据抓包。

图5 接收端音视频数据抓包。

随机选取了20 个这样的音视频组合，测得传输引起的音视频时间差值，求的平均值为0.000051s,即51μs.可以认为，在正常情况下，传输阶段不会引起失步。

多次改变呼叫带宽和网络丢包率，反复试验，得到的不同环境下由传输引起的音视频时间差如表1 所示。

表1 不同环境下由传输引起的音视频时差（单位：μs）。

由表1 中的数据可以看出，随着丢包率的增大，音视频失步有所增加。并且相同丢包率下，随机丢包对同步效果的影响更明显，这和理论分析的结果完全吻合。但是即便在播放阶段还有2%丢包这样恶劣的环境下，传输引起的音视频时间差仍然低于1000us.

即： 该方法将[-80ms,+80ms] 的同步范围的159/160 留给音视频处理和组帧解码阶段。

理论上讲，低带宽高丢包环境下，使用该方法后视频质量会有所下降。这是因为，本文的算法增加了视频帧被丢弃的概率。如图4 所示，每个CIF 格式的视频帧需要4 个H.261 的RTP 包来传输，其中任意一个包丢失都会使该帧成为无用帧被丢弃。采用了本文的同步策略后，如果该视频帧对应的音频包丢失，该帧也会被丢弃。这一点可以根据系统的实际需求做出取舍，比如用前一个包的重复播放来代替丢掉的音频包，而这样会增加音频播放的滞顿感。这些问题正在进一步研究中。

5 结语

本方法最大的亮点在于很好的实现了音视频同步的同时，最大程度的遵守了RTP 协议和H.323 标准。

此外，该方法实现简便、可以和现有的唇音同步方案同时使用、并且不会额外增加系统的负担，具有很大的实用价值。