下载文档原格式
1．引言在IP网上开发多媒体使用有巨大的商业前景，WWW的成功更使业界对此充满信心。
H．323建议是由ITU-T制订的基于分组交换网络（PBN）的多媒体会议系统（以下简称H.323会议系统）。
H.323会议系统不假定其工作的网络基础能提供服务质量（QoS）保证。
实际上，随着IP网的迅速发展，其主要使用于IP网中。
2．H.323会议系统的结构H.323会议系统中传输的信息流中包含音频、视频、数据和控制信息。
所有的信息流采用H.225.0建议来进行打包和传送。
为了实现在会议系统中传输上述信息流，H.323建议定义的多媒体会议系统主要由终端、网守（GateKeeper，亦称网闸）、网关（Gateway）、多点控制器（MC）、多点处理器（MP）和多点控制单元（MCU）等组成。
2.1 H.323终端H.323终端是能够在分组交换网络中提供实时、双向通信的节点设备。
H.323终端功能框图如图1所示。
其中系统控制单元、H.225.0层、分组网络接口、音频编解码单元是H.323终端必须具备的，视频编解码单元和数据使用是可选的。
下面简介终端基本组件的主要作用。
·音频编解码器：采用特定的音频编码算法产生数字化音频信号并进行相应的解码。
在运用中，编解码器使用的音频算法是在能力交换期间通过使用H.245协商得到的。
音频流应根据H.255.0标准进行格式化。
H.323终端可以同时发送或接收多个音频信道信息。
例如，它可以允许两种语音传送；对于多点会议，H.323终端需实施音频混合的功能。
·视频编解码器：采用特定的视频编码算法产生数字化视频信号并进行相应的解码。
视频编码不进行BCH纠错，且允许以不对称的视频比特率、帧速率、图像分辨率运行。
类似于音频编解码器，视频编解码器使用的编解码算法是在能力交换期间通过使用H.245协商得到的，视频流也应根据H.255.0建议规定的格式进行打包传送。
·数据信道：H.323终端通过H.245的控制消息建立一个或多个数据信道。
音视频同步的原理及实现方案-技术方案音视频同步是我们观看视频的一个基本体验，尤其对于视频画面中能看到声源动作（如：嘴型）的场景，音视频同步问题非常影响体验。
在短视频与直播APP中，采集端作为音视频的生产者，如果采集端产生的音视频源本身就无法保证同步，那么后面不管经过什么处理，都很难再让用户看到音视频同步的画面了，因此，在采集端保证音视频同步上尤其重要。
那么如何保证app在各种正常/非正常状况下尽量保证输出同步的音视频？本文就是讲述我们是如何解决上述问题的。
音视频同步的原理音视频采集的数据分别来自于麦克风与摄像头，而摄像头与麦克风其实是两个独立的硬件，而音视频同步的原理是相信摄像头与麦克风采集数据是实时的，并在采集到数据时给他们一个时间戳来标明数据所属的时间，而编码封装模块只要不改动音视频时间的相对关系就能保证音频与视频在时间上的对应。
如此封装好数据之后，播放端就能够根据音视频的时间戳来播放对应的音视频，从实现音视频同步的效果。
时间戳参考标准取格林威治时间做为对比标准，即音视频时间戳都为采集时间点相对于格林威治标准时间的时间差；取系统开机时间做为对比标准，即音视频时间戳都是采集时间点相对于手机开机时间的时间差。
目前iOS上AVCaptureSession这套API 就是参考这个时间标准给的时间戳。
其它时间戳标准基于“开源项目1”的音视频同步探讨原生某开源框架如图：简介音/视频被采集到之后会先经过音/视频处理模块，音/视频在被处理之后才进入计算时间戳的模块。
在帧到达时记一个计时起点，然后根据采集的帧间隔对接下来每一帧的时间戳进行计算：frameTimeStamp = lastFrameTimeStamp + frameDuration。
优点能输出frame duration稳定的音视频时间戳。
风险无论是音频还是视频，在手机过热、性能不足等极端情况下有可能出现采集不稳定的情况，比如说预计1s采集30帧，实际只采集到28帧，而音视频的时间戳是通过累加来计算的，这样就有会出现音视频不同步的情况。
H协议视频会议通信协议解析在当今信息化社会，视频会议作为一种高效的沟通方式被广泛应用，而H协议视频会议通信协议作为其中的核心技术之一，起着至关重要的作用。
本文将对H协议视频会议通信协议进行深入解析，旨在帮助读者更好地理解该协议的工作原理和应用场景。
一、H协议视频会议通信协议的定义与概述H协议，全称为H.323协议，是由国际电信联盟（ITU）制定的一套多媒体通信协议，用于在IP网络上实现音频、视频和数据的传输。
H协议的设计初衷是为了满足语音、视频和数据通信的需求，并保证通信的质量和可靠性。
H协议的通信过程主要分为建立连接、传输数据和终止连接三个阶段。
在建立连接阶段，通信双方需要进行协议交互，验证身份和能力，并达成约定的通信参数。
传输数据阶段是实际的通信过程，音视频数据通过字节流的方式进行传输。
在终止连接阶段，双方协商结束通话，并释放相关资源。
二、H协议视频会议通信协议的工作原理H协议视频会议通信协议的工作原理主要包括信令传输和媒体传输两个方面。
1. 信令传输：在H协议中，信令负责传输控制信息，用于协商连接建立、传输参数以及管理通信过程中的状态。
H协议中定义了一些必选和可选的信令消息，如呼叫设置、会话控制和带宽管理等。
这些信令消息通过H协议的信令通道进行传输，通常使用传输控制协议（TCP）进行可靠传输。
2. 媒体传输：H协议中的媒体传输主要负责音频、视频和数据的传输。
音频和视频的传输通常采用实时传输协议（RTP），数据的传输则使用实时传输控制协议（RTCP）进行控制。
RTP和RTCP可以在UDP 协议上运行，通过分组化的方式传输音视频数据。
三、H协议视频会议通信协议的应用场景H协议视频会议通信协议广泛应用于企业、政府机构、教育机构以及医疗领域等各个行业。
以下是几个典型的应用场景：1. 企业会议：在企业内部，通过H协议视频会议通信协议可以方便地进行远程会议，跨地域的员工可以实时沟通和协作，提高工作效率。
视频会议标准H.323简介视频会议属于同步的显式协作，是CSCW中一个发展得非常成熟的领域，已经有很多国际标准，目前最流行的视频会议标准是H.323。
A.1 概述H.323是International Telecommunications Union（ITU）推荐的协议族[21]，在1996年由ITU 的Study Group 15通过，是H.32X系列通信标准的一部分。
下表是该标准系列的简介：表 1 H.32X标准系列H.323是不提供服务质量保证的局域网上的多媒体通信标准。
这种网络目前处于统治地位，包括以太网、快速以太网和令牌环网上分组交换式的TCP/IP和IPX。
H.323标准既全面又灵活，其配置可以从只有语音的耳机到全功能的视频会议工作站。
它将占据主流市场，因为：☐它是已有网络设施的标准，可以处理局域网变化的延迟，用户不必更换网络。
☐IP局域网越来越强大，以太网带宽正在从10Mbps向100Mbps升级，千兆以太网也以出现。
☐提供设备到设备、应用到应用、供应商到供应商的互操作，符合H.323标准的产品可以互操作。
☐提供局域网和其它网络之间的互操作。
☐可以管理网络负载。
网络管理员可以限制视频会议使用的带宽，多点广播（multicast）可以降低带宽需求。
☐得到很多公司的支持，如Intel、Microsoft、Netscape等。
H.323的主要特点有：☐视频和音频数据流的编解码标准。
☐互操作性。
用户不必担心接收端的兼容性，除了确保接收端可以解码，还允许接收端和发送端协商能力。
标准还规定了通用呼叫设置和控制协议。
☐独立于网络。
H.323运行在通用网络基础上，随着网络技术、带宽管理技术的发展，H.323将利用增强的功能。
☐独立于平台和应用。
H.323不依赖任何硬件或操作系统。
☐多点支持。
支持三个或更多端点的会议而无需专用的多点控制器。
☐带宽管理。
视频和音频通信需要大量带宽，可能造成网络阻塞。
网络管理员可以限制H.323连接的数量或供H.323应用使用的带宽，保证紧要的通信不会被干扰。
视频会议原理随着信息技术的不断发展，视频会议作为一种新型的沟通方式开始流行起来，它打破了时间和空间的限制，使得人们在不同的地域和时区之间也能够进行高效的交流和协作。
而这一切的实现，离不开视频会议的原理。
本文将以此为主题，详细解析视频会议的原理。
一、视频会议的基础架构视频会议的基础架构主要包括三个方面：1、视频会议终端：视频会议终端可以分为硬件终端和软件终端两种，其中硬件终端一般是通过高清摄像头、麦克风、显示器等设备来进行图像和声音的传输，而软件终端则是通过电脑、手机等移动设备来实现。
2、视频会议网关：视频会议网关是视频会议系统的关键部分，它可以将来自不同终端的视频和音频信号进行编解码、传输和转换，从而将这些信号有效地传输出去。
视频会议网关的性能和质量直接影响着视频会议的效果。
3、视频会议服务器：视频会议服务器作为视频会议系统的核心部分，它可以对来自多个终端的视频和音频信号进行混音合成，并且能够对这些信号进行实时调节和控制，从而保证整个视频会议的质量和稳定性。
二、视频会议的传输协议视频会议的传输协议是视频会议系统的重要组成部分，它决定着视频和音频的传输方式和效率。
视频会议系统使用的传输协议主要包括：1、H.323协议：H.323协议是最早的视频会议传输协议之一，它主要是基于IP网络进行传输，可以传输音频、视频和数据。
优点是稳定性好，但缺点是传输效率比较低，并且不支持跨越不同网络的传输。
2、SIP协议：SIP协议是比H.323更加灵活的协议，可以实现多种格式的音视频传输，优点是传输效率高，支持跨越不同网络的传输，但缺点是稳定性比较差。
3、RTMP协议：RTMP协议是一种流媒体传输协议，可以实现音视频流的传输，并且可以跨越不同的网络，优点是传输质量高，但缺点是稳定性不太好，适用于小规模的视频会议。
三、视频会议的数据传输方式视频会议的数据传输方式可以分为两种：点对点模式和多点模式。
1、点对点模式：点对点模式是指两个终端之间建立直接的连接，可以进行双向的视频和音频传输。
浅析视频会议系统的标准及工作原理作者：薛文辉周国红邱利来源：《商场现代化》2009年第03期[摘要] 本文介绍了基于H.323视频会议的标准、优点,以及视频会议系统组成和基本工作原理。
[关键词] 视频会议标准 H.323 工作原理视频会议系统是通过互联网通信技术来实现的网络虚拟会议，通过图形、声音等多种方式交流信息，使在地理上分散的用户可以共聚一处。
支持人们远距离进行实时信息交流与共享、开展协同工作的应用视讯系统。
视频会议极大的方便了协作成员之间真实、直观的交流，对于远程教学和会议也有着举足轻重的作用。
一、基于H.323视频会议的标准国际电信联盟ITU对于视音频通讯及其兼容性的技术进行了规范，在这些基本的协议中，同时对语音、视频的编码格式，用户控制模式等要件进行了相关的规定。
ITU-T制定的适用于视频会议的标准有：H.320协议（用于ISDN上的群视频会议）、H.323协议（用于局域网上的桌面视频会议）、H.324（用于电话网上的视频会议）和H.310（用于ATM和B-ISDN网络上的视频会议）。
其中H.323协议成为目前应用最广最通用的协议标准。
基于网络的视频会议系统遵循H.323标准，采用实时传输协议(RTP)和实时传输控制协议(RTCP)实现音频和视频流的实时传输和控制，解决音频和视频流的同步；视频编解码采用H.261/H.263算法；支持在一个网络环境中同时召开多个独立会议；在多点控制单元(MCU)上实现多点会议的管理和控制。
H.323具有以下主要优点：1.H.323协议被设计成运行在通用的网络体系结构之上，具有网络独立性。
2.其协议提供了网络带宽管理功能，能够对网络中并发的H.323连接数和H.323应用可获得的带宽总量进行限制。
3.提供了连接基于电路交换或ISDN的视频会议的手段，并且支持多点会议和多播(multicast)功能。
4.H.323实现了不同厂商的多媒体产品和应用的互操作等。
一种H.323视频会议系统音视频同步方法
白骋宇;张海峰
【期刊名称】《计算机系统应用》
【年(卷),期】2010(019)006
【摘要】针对H.323视频会议系统设计了一种基于RTP的音视频同步方法,该方法在严格遵守RTP协议的前提下,将音视频数据联系起来通过同一个媒体通道传输,从而达到唇音同步的目的.实验表明:该方法在对图像质量影响很小的情况下,很好地实现了音视频的同步播放,并且具有实现简便.不增加系统负担等优点,具有广泛的实用性.
【总页数】4页(P183-186)
【作者】白骋宇;张海峰
【作者单位】杭州电子科技大学电子信息学院,浙江,杭州,310018;杭州电子科技大学电子信息学院,浙江,杭州,310018
【正文语种】中文
【相关文献】
1.一种多媒体信息交互系统音视频同步方法 [J], 郑睿;张江林;徐志江
2.一种穿越NAT/FW的有效方案——基于H.323集中式视频会议系统 [J], 汪飞;彭智洋;曹宁
3.一种优化的手机直播系统中音视频同步方法 [J], 潘晨光
4.一种改进的基于时间戳的空间音视频同步方法 [J], 薛彬;徐京;王猛
5.一种适用于嵌入式媒体播放器的音视频同步方法 [J], 程文青;陈云鹤;徐晶
因版权原因，仅展示原文概要，查看原文内容请购买。
H323视频会议系统中音视频混和器的研究与实现随着网络多媒体技术的快速发展，传统的电话会议系统已不能适应现代社会对多媒体通信的要求，在这种情况下，基于Internet的视频会议系统便应运而生。
文章主要介绍如何利用有限的网络带宽实现多点视频会议，即将多路视频在服务器端混合为一路，然后发送到各端点，该方案巧妙地利用了多点控制单元（MCU）的功能，有效地节省了网络带宽，非常适合目前Internet的现状，所实现的原型系统及测试结果表明了文章设计方案的可行性和有效性。
标签：H323；MCU；混合器；视频会议系统1 引言会议是人类社会政治经济生活中不可缺少的一部分。
随着ITU制定出第一个H.320标准和H.323标准，视频会议获得了长足的发展。
视频会议作为一种先进的多媒体通信手段，已逐步被众多政府部门和跨地区企事业单位所接受和采用[1]。
然而相对于Internet有限的带宽，图像通信所需要的带宽太大，视频会议无法承载原始视频的多路通信。
因此，多点控制单元（MCU）对于音视频的多路通信起着重要的作用[2]。
文章主要针对视频会议中的主要部分MCU，研究分析H.323视频会议中如何利用有限的带宽实现音视频的混合于传输。
2 H323协议简介H.323协议是ITU第15研究组SG-15于1996年通过的在不保证服务质量（QoS）的分组交换网络（PBN：Packet based networks）上传递信息的多媒体通信协议。
从整体上来说，H.323是一个框架性协议，它涉及到终端设备、视频、音频和数据传输、通信控制、网络接口方面的内容，还包括了组成多点会议的多点控制单元（MCU）、多点控制器（MC）、多点处理器（MP）、网关以及关守等。
H.323为基于网络的通信系统定义了四个主要的组件：终端（Terminal）、网关（Gateway）、网守（Gatekeeper）、多点控制单元（MCU）。
所有终端都必须支持语音通信，视频和数据通信可选.H.323规定了不同的音频、视频或数据终端协同工作所需的操作模式[3]。
H.323视频会议系统音视频同步原理针对H.323 视频会议系统设计了一种基于RTP 的音视频同步方法，该方法在严格遵守RTP 协议的前提下，将音视频数据联系起来通过同一个媒体通道传输，从而达到唇音同步的目的。
实验表明：该方法在对图像质量影响很小的情况下，很好地实现了音视频的同步播放，并且具有实现简便，不增加系统负担等优点，具有广泛的实用性。
H.323 视频会议系统中，发送端同时采集到的音视频数据能在接收端同时播放，则认为唇音同步。
终端采集到的音视频数据肯定是同步的，要保证同时播放，就要保证音视频在采集和播放处理过程中消耗的时间相同。
IP 网络的特点决定了通过不同通道的音视频数据传输所消耗的时间不可能完全相同，唇音同步是视频会议系统中的一大难题。
如果同时采样的音视频数据播放时间偏差在[-80ms,+80ms]以内，用户基本上感觉不到不同步，一旦超出[-160ms,+160ms],用户就可以明显感觉到，中间部分是临界范围。
1 引言1.1 文章安排本文第2 节分析了现有的音视频同步方案的缺点。
第3 节详细描述了本文所设计方案的实现过程。
第4 节给出实验数据以及分析结果。
第5 节给出结论。
1.2 基本介绍H.323 视频会议系统中，音视频不同步现象产生的原因除了网络环境外，还有一个是音视频的分开传输。
虽然H.323 建议音视频通过不同道道传输，但是实际传输数据的RTP[2,3]协议和其底层的UDP 协议都没有规定一对连接只能传输音频或者视频中的一种，通过同一个通道传输音视频完全可能，而且这样可以最大程度的减少网络原因引起的音视频不同步，本文给出了这一设想的实现方案，并做了验证。
2 现有解决方案目前最常用的唇音同步方法从思路上可以分为以下两类：思路一，发送端给每个要发送的RTP 包打上时戳，记录它们的采样时间。
接收端通过增加延时等方式，保证同时采样的数据同时播放。
这类方法的实现需要一个中立的第三方参考时钟，需要有RTCP 协议的SR[2,3]的参与，如果这两个条件不具备，同步就失去了依据。
思路二，唇音不同步本质上是由H.323 视频会议系统中音视频的分开传输和处理导致的，如果采用某种方法将音视频信息关联起来，就可以有效的避免不同步现象。
一种实现方案是，将音频按一定的对应关系嵌入到视频中传输，接收端从视频中提取音频数据并重建，从而达到唇音同步的目的[4].该方案实现较复杂，而且采用非标准的RTP 实现方式，会给不同厂商H.323 产品间的互通带来困难。
3 一种新的音视频同步方法本方法基本思路是：在音视频数据的采样、编码、打包、发送、网络传输、接收、网络异常处理、拆包、解码、播放这十个处理过程中，采集、编码、打包、拆包和解码的时间基本上固定，不会因为网络环境差异造成时延的差异，而发送、网络传输、接收、网络异常处理四个过程则具有较大的随机性，其处理时间会随着网络性能的不同有较大的差异，进而造成播放时音视频的不同步。
因此唇音同步处理的重点就在于保证发送、网络传输、接收、网络异常处理这四个过程中音视频的同步，即图1 中发送同步到组帧同步之间的部分。
图1 唇音同步实现全过程其他处理过程引起的时间差，只要在系统稳定后给音频加上固定的延时即可，因为一般情况下，音频处理所花的时间比视频处理少，具体的差值可多次实验统计得到。
RTP 协议规定每个RTP 包中所承载的有效载荷类型（PT）是唯一的，但是如果将音视频通过同一个通道传输，并且保证同一时刻采集到的音视频帧顺次交错发送，则既能保证音视频在传输中的同步，又遵守了RTP 协议。
音频数据量较小，一个RTP 包即能承载一帧，一个视频帧则需要多个RTP 包承载，帧结束标志采用RTP 包头中的Mark 字段，该字段为1,则说明当前包是一帧的结束包。
依据上述思想，方案具体实现过程设计如下：（1）发送端分别独立的对音视频信息进行采样，组帧和打包，然后放到各自的缓冲队列中等待发送（2）数据发送模块从发送缓冲中取数据，1）从音频缓冲队列中取一个包（一帧）；2）从视频缓冲队列中取数据，每取一个包，都判断RTP 包头的Mark 字段是否为1,如果为1,说明当前视频帧已经取完，转1），如果Mark 字段为0,说明当前视频帧还未取完，转2）；（3）音视频数据通过同一个通道发送到网络；（4）接收端收到数据，根据包头中的PT 字段区分音视频，放到各自的接收缓冲队列中进行请求丢包重传、乱序重排等网络异常处理[5,6],然后进入组帧缓冲等待解码器取走数据，进入组帧缓冲的数据没有乱序包和重包，偶有丢包；（5）音视频各自拆包组帧，实现过程如图2 所示：图2 组帧同步实现原理图。
（6）音视频从各自的解码缓冲队列中按顺序取数据送解码，通过组帧过程中给音视频数据加上的本地时戳来校准后同步播放。
丢包判断实现细节说明：在终端的可靠性和代码的健壮性得到保证的前提下，发送端是不可能有包序号不连续的，对于接收端，本方案中的丢包，是指经过丢包重传等网络异常处理策略之后依然存在的丢包，必然是及其少量的。
本方法中的音频采样、组帧和打包是分开处理的，即音视频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 标准。
此外，该方法实现简便、可以和现有的唇音同步方案同时使用、并且不会额外增加系统的负担，具有很大的实用价值__。
