毕业设计:音视频通信软件的设计与实现(可保护TCP传输的单人通信与网络逻辑完全树服务模型的及时会议系统)

第1章           音视频通信软件的设计

1.1   音视频通信软件需求分析

1.1.1         音视频通信软件需求说明

从技术上而言,音视频通信技术,涉及到音视频设备操作、音视频流编解码、媒体流网络传输、流媒体接收处理等相关技术,门槛高,难度大。另外,由于媒体流信息量大,及时要求度高,还要保障媒体帧的流畅性,这就对依耐于高速网络、高性能的硬件设备以及相关媒体流网络包的建包和解包算法。

本课题主要以实现音视频通信会议功能为重点的音视频通信软件,主要包含基本的单人音视频功能、音视频会议功能。通过对构架类分布式的服务源服务模式,最终实现“基于网络逻辑完全树架构的服务模式”系统,从而将服务重责平均分配到各个参加网络音视频会议的各个用户子机,减轻总服务源(会议发起方)的服务“压力”,进行使整个通信系统达到“有福共享,有难同当”的最佳服务状态。该音视频通信软件的核心需求是搭建几种特殊的完全树网络逻辑架构,限于其研究目的,不实现P2P功能,但需提供可扩展的网络接口,所以其应用范围仅限于某一子网。

1.1.2         运行环境需求

该音视频通信软件要求在Windows XP或Windows Server 2003操作系统下运行,需要Divx5.02编解码器,以实现媒体帧的编码和解码操作。

1.1.3         功能需求

本次研发的音视频通信软件主要需实现如下功能:

(1)    三种网络登录模式设计(广播、多播、CS);

(2) 本地音视频设备设置;

(3) 支持单人聊天模式与音视频会议模式;

(4)简单的文字辅助单聊、群聊功能。

1.2   软件开发环境   

1.2.1         软件开发语言

本课题所涉及的音视频通信软件,使用了C++语言进行开发,C++语言主要具备下列特点和优势:

(1)C++由C发展而来,与C兼容,C程序基本可以不加修改应用于C++;

(2)C++具备C语言的全部优点,并增加了面向对象机制;

(3)C++编译器资源很广泛,几乎涵盖所有常见操作系统;

(4)C++执行效率很高,运行速度快。      

1.2.2         软件开发平台

1、操作系统

该课题所涉及到的音视频通信软件,在普通用户通用机型,Windows XP操作系统中完成全部开发和测试。Windows XP 为目前单机普通用户主流机型,能更好的满足广大计算机用户的需求。

2、集成开发环境

该课题中,集成开发环境选用了微软的Visual Studio 2005。Visual Studio 2005是一个基于Windows操作系统的可视化集成开发环境。Visual Studio 2005包括编辑器、调试器以及程序向导AppWizard、类向导Class Wizard等全套工具。所有组件通过Developer Studio集成为完整的开发环境。值得一提的是,Visual Studio 2005所提供的MFC能够较为方便地完成图形界面应用程序。

3、其他辅助平台

该课题中,媒体流帧解编码部份采用了Divx5.02编解码器实现。

DivX是一项由DivXNetworks公司发明的,类似于MP3的数字多媒体压缩技术。它由DivXNetworks公司发明,基于MPEG-4标准,DivX配置CPU要求是300MHz以上、内存要求是64M以上、8M以上显存的显卡.DivX视频编码技术是为了打破微软ASF的种种协定的束缚,由Microsoft mpeg4 v3修改而来,使用的MPEG-4压缩算法可以把MPEG-2格式的多媒体文件压缩至原来的10%,更可把VHS格式录像带格式的文件压至原来的1%。通过DSL或CableModen等宽带设备,它可以让你欣赏全屏的高质量数字电影。无论是声音还是画质都可以和DVD相媲美。同时它还允许在其他设备(如安有机顶盒的电视、PocketPC)上观看。

1.3   总体设计    

本课题所完成的音视频通信软件,主要完成三种用户登录模式:广播、多播、CS,用户可以根据当前网络支持状况,选择其中一种合适的登录模式;支持同一时间与多人进行一对一音视频聊天;另外,邀请在线好友进行音视频会议;同时,软件支持文字辅助聊天。

针对该软件的主要需求,摄像设备的独占性特点,主要可以采取两种设计方案实现:

(1) 捕获音视频设备媒体流,进行相应编码操作,将视频流以图片帧的方式,绘制图像到相应窗口,建立发送地址表,通过TCP/UDP网络套接字对表内的所有客户主机地址发送媒体流,同时接收Filter接收相应网络媒体流,进行相应解码操作后输出媒体流到相应音视频显示设备终端;

(2)捕获音视频设备媒体流、进行相应编码操作,建立发送分支Filter,对相应客户方建立相应音视频发送Filter分支与视频显示分支,同时接收Filter接收相应网络媒体流,进行相应解码操作后输出媒体流到相应音视频显示设备终端。其中,收发Filter分为单人聊天收发Filter与音视频会议收发Filter,分别支持TCP媒体流与UDP媒体流。

显然,第一种方式更简单易懂,更容易实现,然而所带来的系统开销也是非常庞大的。对应每一个音视频会话,就对应一个网络地址,在发送媒体流时,遍历这个地址表的同时将绘制媒体流图片帧到相应窗口,这消耗大量CPU运算时间,严重影响系统性能。同时,第一种实现方式也失去了DirectShow技术的优势。另外,在本课题的音视频会议软件,要求满足广大即时通信软件的特点:即时、高效、简捷。所以,本课题的音视频通信软件采用第二种方式实现,建立以Filter支链为基础的Filter Graph运行方式,可以有效节约系统资源,便于软件管理与维护。针对此种实现方法,程序总体运行流程如图 3 - 1所示。

图 3 - 1 音视频通信软件系统总流程

1.4   功能模块划分

根据功能实现需要,并兼顾代码的模块化、规范化,本课题所开发的音视频通信软件主要设计为由以下三大模块构成,如图 3 - 2所示。

 

图 3 - 2 音视频通信软件模块划分

1、用户管理子系统,主要实现以下功能:

(1)群用户管理:主要管理群用户上线、下线、群消息;

(2)网络登录模式:实现网络登录多态接口,并扩展为广播、多播、CS登录模式。

(3)消息包分析:分析并提交网络消息包与窗口消息包。

2、音视频通信管理子系统,主要实现以下功能:

(1)单人聊天模式:一对一进行音视频聊天功能;

(2)音视频会议模式:具有完全树网络逻辑服务模式的音视频会议功能。

3、协同辅助模块,主要实现以下功能:

该模块辅助音视频通信时,相应请求、应答消息管理,并提供用户界面,接受用户输入,判断输入合法性。

1.5   用户管理子系统详细设计

该子系统主要实现软件群用户的管理、用户网络登录以及用户消息包解析功能,为后期音视频通信提供用户组对象。该子系统包含了群用户管理、网络登录模式、消息包分析三大功能,该子系统总体流程如图 3 - 3所示。

图 3 - 3 用户管理子系统运行流程

1.5.1         群用户管理模块设计

该功能模块设计为主要负责管理群组用户,维护应用程序用户列表,发送与接收群组消息,分别处理用户上线、用户下线以及群用户消息。针对群用户管理模块的具体功能需求,重点数据类型和各个子功能分别设计如下:

1、网络通信包设计

网络通信包是音视频通信软件之间协同通信的网络消息报文,因此,网络通信包设计为封装各个用户通信的基本参数信息,封包组成成份有:封包头、设备标识、通信名称以及附加内容。其中封包头和设备标识为四个字节的枚举类型;通信名称为256个字节长度;附加内容为1124个字节长度。总共1388个字节长度,小于1500,能保障封包在传输过程中不被分片 ,以完整的形式到达对方。网络消息包具体设计,如表3 – 1 所示:

 

 

网络通信包

 

名称

长度(byte)

字段名

备注

封包头

4

mUserWay

封包类型,枚举变量,包含用户入网形式以及附加封包头标识信息;

设备标识

4

mVideo

设备状态标识,枚举变量,用于标识当前是否有音视频设备;

通信名称

256

musername

用户名称,字符串变量,长度256,用户基本通信名称;

附加内容

1124

mexData

附加数据,字符串变量,长度1124,附加消息封包字段或填充字段;

表 3 - 1 网络通信包(UserNetPack)定义表

2、群用户网络形为设计

群用户网络形为设计为三种方式:登录网络、退出网络、网络消息群发。原理与飞鸽协议相类似,即:某登录时发布我上线了的消息,其它用户收到该消息后向其返回它也在线的消息。目地在于方便系统管理用户群组,方便即时与群中用户进行音视频聊天或者音视频会议。登录系统时,由用户填写基本信息后登录网络并启动相应系统服务;退出系统时,由程序自动向群中用户发送退出消息报文并关闭相应系统服务;群发网络消息时,将通过网络接口向群组用户发送消息。其中通过设计网络通信包头值,以区分不同的用户形为,封包头为一个4个字节的枚举类型,其定义见表3 – 2所示:

 

网络通信包头

字段名

备注

UserWrong

未知用户登录标识头,初始值0;

UserAdd

用户登录网络标识头,表示某一用户上线或刷新好友列表;

UserLeave

用户离开网络标识头,表示某一用户下线;

UserAddBack

用户登录网络标识头,表示某一用户返回的在线标识;

UserGroupData

用户群组消息与附加消息头标识,表示某一用户的群发消息或附加消息封包(音视频请求);

表 3 - 2 网络通信包头(UserWay)定义表

其中,UserGroupData字段的具体定义将在后面消息包分析部份作详细说明。

1.5.2         登录模式模块设计

本课题所研发的音视频通信软件,可以让用户选择三种不同的网络登录模式:广播、多播、服务器登录(CS)。三种登录模式完成的功能基本相同,即发送群组消息报文与单播消息报文以及相同的网络接收模块。音视频通信软件设计了一个多态的网络接口抽象类,三种不同登录模式类从该类派生,实现抽象接口,从而在达到统一的同时,又可以完成不同的功能。多态接口类与三种登录类之间的关系,如图3 – 4 所示

图 3 - 4 网络登录类关系图

1、网络多态接口设计

多态与虚函数是面向对象编程思想的核心之一,多态性是允许将父对象设置成为和一个或多个它的子对象相等的技术,它使得能够利用同一类(基类)类型的指针来引用不同类的对象,以及根据所引用对象的不同,以不同的方式执行相同的操作。网络登录模式就设计为一个接口类,即抽象类。它的操作函数设计为一系列纯虚函数,由它派生出来的广播登录类、多播登录类、CS登录类实现这些接口函数,如图3 – 4 所示。网络多态接口类设计如表3 – 3 所示:

网络多态接口类

功能接口

实现函数

备注

设置用户管理者

SetUserManager

获得父管理者指针地址;

设置通信地址

SetIpandPort

设置群播IP地址和网络端口号;

创建网络套接字

StartSocket

创建网络套接字;

群发消息报文

SendA

向所有在线用户群发消息报文;

单播函数1

SendB

向特定地址的某一主机发送消息报文,同Send;

单播函数2

Send

向特定地址的某一主机发送消息报文;

开启消息包接收线程

StartRecvData

创建网络消息包接收线程;

停止消息包接收线程

StopRecvData

停止网络消息包接收线程;

关闭套接字

CloseSocket

关闭所有套接字;

返回群播套接字

GetSocket

返回当前群播套接字;

表 3 - 3 网络多态接口类(CbaseSocket)接口函数表

2、三种登录模式设计

由于不同用户网络状况的不同,于是从网络多态接口类派生的三种网络登录模式类:广播登录类、多播登录类、CS登录类,根据自身的登录类型,以不同的方式去实现表3 – 3 所示的网络接口,从而它们具有相同功能。由于广播登录类和多播登录类都是向相似的网络地址终端发送UDP数据报文,所有它们的接收功能模块,完全一致,即将接收到的网络消息包,可直接交于上层分析处理(ParseNetworkStream)。CS登录模式,即客户端服务器模式,设计为接收的所有网络包由中继服务器转发的UDP数据报文,因此不能解析出对方的网络地址信息,所以CS模式下网络通信包设计为将表3 – 1 的网络通信包再次封装,形成CS模式下独特的网络包格式,即CsUdpPack = IP + UserNetPack 的消息封包,其中IP为长为16字节的字符串数组,这样CS网络包就比UserNetPack多了16个字节,在接收消息报文时,只要根据报文的长度就可以分辨出这两个不同的网络封包。

1.5.3         消息包分析模块设计

本课题所研发的音视频通信软件,涉及到很多网络通信部份,将各个音视频通信软件组成了一个庞大的网络通信系统。因此,将设计统一的网络消息包分析模块。消息包分析模块注意逐一分析接收到的网络消息包,并将其组包成窗口消息包投递到用户窗口消息缓冲池中。其中,用户消息包枚举类型userway的键值UserGroupData必须包含其它用户信息,因为通过该键值,进一步将网络通信包UserNetPack的附加参数封装成集成音视频请求、应答、群消息于一体的GroupMessage消息子封包,GroupMessage封包设计如表3 – 4 所示:

 

 

附加群组通信封包

 

名称

长度(byte)

字段名

备注

封包头

4

mexHead

封包类型,枚举变量,包含通信双方的音视频请求、应答与群组信息标识;

基本通信的端口

16

mexPort

基本通信端口,字符串变量,长度16,常用于控制音视频通信;

UDP命令端口

16

mUDPManagerPort

音视频通信控制命令端口,字符串变量,长度16,配合mexPort使用;

TCP服务端口

16

mTCPServerPort

音视频通信TCP服务端口,字符串变量,长度16,配合mexPort使用,用于单人聊天模式;

附加内容

1024

mexData

其它封装包或者附加的通信信息;

表 3 - 4 附加群组通信封包(GroupMessage)定义表

其中,附加群组通信封包包头(Exhead)标识含有请求、应答以及群组消息标识。它用于音视频聊天模式和音视频会议模式下请求与应答消息封包,以及群组消息封包,它的各个标识定段有:未定义头(ExWrong)、单人聊天模式下请求头与应答头(ExSingleRequest&ExSingleAnswe)以及端口请求与应答头(EXSocketPort),拒绝头ExSingleClose;音视频会议模式下,会议请求与应答(ExGroupRequest&ExGroupAnswer),

用户群组消息头(ExGroupMessage)。

UserNetPackGroupMessage都是用地音视频通信软件网络通信的基本消息包,为了让应用程序窗口有效的识别这些消息封包,本课题所设计的音视频通信单独为窗口自定义了一种窗口消息封包,即ParsePack,详细设计见表3 – 5 ,它的基本信息参数用于应用程序的响应过程。考虑到音视频通信软件窗口在处理底层网络通信封包时,不能阻塞在某个对话窗口,在将对话窗口设置为非模态窗口的同时,设计消息桥搭建窗口消息缓冲池解决了该类问题。关于消息桥搭建消息缓冲池,如图3 – 5 所示:

 

 

用户分析封包

 

名称

长度(byte)

字段名

备注

显示名称

300

mShowName

用户显示名称,字符串变量,长度300,用来唯一标识音视频软件用户;

通信IP地址

16

mIp

网络通信地址,字符串变量,长度16,网络通信主机IP地址;

群组通信封包

1076

mMessage

群组通信封包,字符串变量,长度16,包含基本网络封包扩展后的信息;

封包指针变量

4

mNext

指针变量,长度4,用于指向网络封包缓冲区的下一个封包地址;

表 3 - 5 用户分析封包(ParsePack)定义表

应用主程序窗口消息包缓冲区

用户窗口消息包缓冲区

文本框: 1.PostMessage文本框: 2.SendMessage

图 3 - 5 消息桥搭建消息缓冲池设计图

 

1.6   音视频通信管理子系统详细设计

针对所研发的音视频通信软件可用于同时与多人进行音视频聊天以及召开音视频会议的功能,所以设计了两种不同的音视频发送和接收Filter,分别应用于两种不同的通信模式。单人聊天模式下,音视频媒体流传输采用TCP协议,基于该模式下的发送和接收Filter都是TCP传输Filter;音视频会议模式下,音视频媒体流采用UDP协议,基于该模式下的发送和接收Filter都是UDP传输Filter。两种不同模式下都要去访问只可独战的摄像头硬件设备,因此,音视频通信软件为本地音视频Graph图设计一个本地音视频基图管理类ClocalGraphAdmin,实现设备共享。该Graph图在系统登录成功后创建,系统未使用时释放使用权。本地音视频图如图3 – 6 ,图 3 – 7 所示:

 

 

本地音视频Graph基图:

图 3 - 6 视频Graph基图

图 3 - 7 音频Graph基图

视频Graph基图中含6个基本Filter,主要用于视频帧的显示与发送,其中VideoCapture实现视频帧的捕获,Video Infinite Pin Tee Filter 对视频频的分支,Video Divx Pro 5.02 Coder对视频帧进行编码,My AVIDec Filter 对视频帧显示的解码,Sender Infnite Pin Tee Filter为发送分支Filter,用于连接多个视频发送FilterRender Infnite Pin Tee Filter为视频显示分支Filter,用于连接多个视频显示Filter;音频Graph基图中含三个基本Filter,主要用于音频帧的发送,其中,Audio Capture实现音频帧的捕获,Audio MPEG Layer-3 Filter 对编码音频帧为MP3格式,Audio Infinite Pin Tee Filter将音频流进行分支,用于连接多个音频发送Filter

应用程序从窗口消息缓冲池中取出的消息有三种:单人聊天模式请求消息、音视频会议邀请消息、群用户组消息。对于前两种的音视频请求信息和所有音视频通信窗口,应用程序将创建对应非模态对话窗口,将分别建立窗口CPtrList链表,由应用程序负责维护。关于两种音视频通信模式的具体设计如下:

1.6.1         单人聊天模式模块设计

应用程序收到单人聊天模式请求消息后,将创建单人聊天模式请求窗口,并设置了超时时间为30秒,30秒后请求窗口将自动拒绝该音视频请求。在限定时间内,用户同意了该请求并返回确认消息,双方将创建单人聊天窗口,建立本地和远程音视频Graph图,并开始通信过程。如表 3 – 6所示为单人聊天模式请求窗口与主窗口通信的消息包:

 

 

 

单人聊天模式通信请求包

名称

长度(byte)

字段名

备注

通信角色

4

mAVRole

通信身份标识,分为请求方与应答方;

通信意向

4

mAVIdea

通信意向标识,同意或拒绝;

本机可用端口

16

mMyPort

本机可用端口,用于文字聊天;

对方显示名称

300

mHisShowName

对方显示名称,唯一身份标识;

对方网络地址

16

mHisIp

对方主机IP地址;

对方可用端口

4

mHisPort

对方可用端口,用于文字聊天;

对方命令端口

4

mHisUdpManagerPort

用于启动音视频通信音视频Graph图;

本机命令端口

4

mMyUdpManagerPort

用于启动音视频通信音视频Graph图;

本机服务端口

4

mTcpServerPort

本地音视频媒体流TCP服务商口;

附加数据

100

mExData

附加数据项;

表 3 - 6 单人聊天模式通信请求包(AVaskMessagePack)定义表

 

通信双方都同意音视频聊天后,就开始创建音视频通信发送和接收Graph图,开始音视频聊天过程,详细模块设计如下:

1、创建本地音视频发送链路

针对单人聊天模式下的音视频通信需要为每一个客户方建立一条媒体流发送链路,以向对方发送本地音视频帧。如图3 - 7 所示,将在本地音视频Graph基本之上连接该项发送链路。本地视频显示链路也需要在此时建立并连接到Render Infinite Tee Filter上。在创建与连接本地音视频链路时,需要由基图管理类ClocalGraphAdmin负责创建并链接。该发送链路中,发送Filter是TCP网络传输Render Filter,与接收Filter彼此成对。由于TCP协议的可靠传输,使媒体帧完整的到达,但可能在对方无法接收数据时,使发送端阻塞,从而停止了本地音视频Graph图的运行,因此发送Filter需要独立于音视频Graph图的发送线程来保障整个Graph图有效的运行。在发送音视频帧时,将上层Filter传来的帧拷贝到一个暂时缓冲区中待数据发送线程给予发送,期间,该缓冲区由互斥量保护其完整性。

1、创建远程音视频接收Graph图

双方音视频通信时,需要将对方的音视频流接收、解码并显示,这就需要创建音视频接收Graph图。该图需要由接收Filter、解码Filter、显示Filter组成,接收Filer是TCP网络传输Filer,与发送Filter彼此成对,该接收Filter是基于推模式CbaseFilter派生而来的Source Filter,需要由一个独立线程进行音视频流的接收;解码Filter有Divx、AVI以及MP3组成,显示设备为Video Render与Audio Render。

1.6.2         音视频会议模式模块设计

音视频会议模式是研究课题的重点题目,它是一对多的音视频聊天过程,和音视频聊天模式有相同的地方,但音视频会议所面临的是很多个在线用户。本课题设计了一种能降低了对会议发起方的资源的需求的服务模式,该服务模式是基于分布服务原理,智能动态的建立网络逻辑完全树的过程。服务模式设计为单支树、完全二叉树、完全三叉树以及四叉、五叉树,还包括1对多的服务模式。图3 – 8 为四种特殊服务模式网络逻辑模型及相关描述。下面是关于音视频会议模式下网络消息封包以及相关音视频Graph图的管理的详细设计:

图 3 - 8 四种特殊网络逻辑服务模型

 1、会议模式消息封包设计

音视频会议模式的网络封包需要不同对单人聊天模式下的消息封包,该模式下需要设计网络消息封包与窗口消息封包,如:会议邀请应答窗口消息、会议控制消息以及音视频Graph图网络封包和会议媒体帧UDP分片封包。详细设计如下:

会议邀请应答窗口消息是会议被邀请方向主应用程序窗口确认的窗口消息。在用户确认参加该音视频会议后,主应用程序窗口会收到该会议确认消息,同时打开会议通信窗口,开始音视频会议。关于会议邀请应答窗口消息具体设计,如表3 – 7 所示。

会议控制消息被设计用于控制整个会议系统有效的运行,它包含控制包头与附加控制信息,包头为枚举类型,并定义为:

MCPHead(MCPNONE,MCPLogin,MCPLogout,MCPOrder)

会议控制封包含两种子封包:会议用户子网络封包和会议控制子网络封包。会议用户子网络封包主要用于会议用户进入会议、退出会议的控制外,还包含了会议用户的基本会议服务信息;会议控制子网络封包主要用于会议服务发起方在建立网络逻辑完全树服务模式时发送给各个会议用户的控制命令。它们的具体设计如表3 – 8,表 3 – 9所示。

由于音视频会议模式下采用UDP传输音视频帧,所以会议媒体帧UDP分片封包被设计为表示媒体帧的分片信息,用于组装媒体帧,其具体定义见表3 – 10。

 

会议邀请窗口应答消息

名称

长度(byte)

字段名

备注

通信意向

4

mHead

通信意向,枚举类型,同意(MRPGree),拒绝(MRPUNGRee)

发起方显示名称

300

mHisName

对方显示名称,唯一身份标识标识;

发起方地址

16

mHisIp

对方主机IP地址;

发起方登录端口

16

mHisUdpPort

用于参加会议的服务端口;

会议主题

256

mMeetingName

描述会议主题;

会议备注

768

mMeetingEx

描述会议相关信息;

表 3 - 7 会议邀请应答窗口消息(MeetingRequestPack)包

 

会议用户子封包

名称

长度(byte)

字段名

备注

登录会议名称

300

mUserShowName

登录会议时用的显示名称;

设备标识

4

mHasVideo

视频设备标识,枚举类型,无设备(VideoNone),有设备(VideoHas);

发起方地址

4

mServerVideoPort

本机视频的UDP服务端口;

发起方登录端口

4

mServerAudioPort

本机音频的UDP服务端口;

表 3 - 8 会议用户子网络封包(MeetingUserPack)

 

 

会议控制子网络封包

名称

长度(byte)

字段名

备注

服务模式

4

mTreeMode

会议服务模式,枚举类型,TREEMODE定义字,含有TREEONE,TREETWO,TREETHREE,TREEFOUR,

TREEFIVE,TREEMAX字段,分别对应1:1、1:2、1:3、1:4、1:5、1:N的服务状态。

智能标识

2

mbSmart

会议发起方服务类型,bool类型,智能(true),手动(false);

附加内容

512

mOrderExData

附回内容或填充字段;

表 3 - 9 会议用户子网络封包(MeetingOrderPack)

 

 

会议媒体帧分片封包

名称

长度(byte)

字段名

备注

媒体类型

4

mMedia

媒体类型,枚举类型,TREEMODE定义字,含量有MediaAudio、MediaVido、MediaPayload字段,分别对应音频媒体帧头、视频媒体帧头以及媒体帧负荷;

分片ID

4

mUdpPackNumber

该分片序列号;

分片总数

4

mUdpNumber

该类型分片总数;

分片长度

4

mUdpLength

该分片帧长度

分片数据

1024

mUdpData

实际帧负荷;

表 3 - 10 会议媒体帧UDP分片封包(MeetingUdpPack)

2、网络逻辑完全树架构原理

本论文音视频会议模式下的网络逻辑完全树服务是类似于分布服务原理。会议发起方被定义为总服务源,每个与会的客户方被定义为子服务源。总服务源在传递音视频媒体流的同时还负责控制整个会议网络;子服务源在接收某个服务源(总服务源或子服务源)媒体流的同时也可以作为会议服务源的一部份,即向其它连接到子服务源的客户方发送媒体流。在此过程中,各个服务源按照规定的法则进行协作,由该法则实现网络逻辑完全树的服务模式,创建该服务模式的过程就是模拟完全树的过程。在网络逻辑完全树的服务模式下,加入会议的主机都有自己的一个顺序号,总服务源会议号为0,其它子服务源依次递增。在收到总服务源的命令控制包时,子服务源在向总服务源索要媒体帧类型建立音视频Graph接收图后,按照完全树规则计算它的服务源位置,并解析出该位置主机地址后向它发送连接消息包。例如,某一主机获得的顺序号为n,服务器返回的完全树服务模形为TREETWO,则它的服务源位置序号为:(n-1)/ TREETWO。除TREEMAX外,其它模式命令m的服务源位置序号计算算法为:(n-1)/m,而TREEMAX的服务源为总服务源,服务源位置为了0。图3 – 9 为网络逻辑完全树架构演示图:

图 3 - 9 网络逻辑完全树架构演示图

3、创建音视频会议的会话

具体实现音视频通信的会话过程由音视频Graph图实现。音视频Graph图分为发起方的音视频本地Graph图和接收方的音视频远程Graph图。音视频Graph图的创建与单人音视频会多聊天模式下相同,但会议模式下发送Filer与接收Filter是UDP传输Filter,音视频帧将通过会议发送Filter分片后由UDP发送至接收Filter,接收Filter接收到分片帧包后将对其进行组装。为了减少对系统性能的依耐,设计了最为简单组装算法,即组装假设UDP分片包有序到达,将UDP分片依次放入Sample帧中,直到该包接收完毕或者下一个音视频帧的分片包到来(网络传输过程中可能出现的丢帧所致)。

音视频会议设计为两种服务状态:智能状态与手动状态。手动状态为会议发起方手动设置的服务状态;智能状态是由系统根据当前系统性能自动设置的服务状态。智能状态实现系统与网络性能的实时监控,实现原理为ICMP协议,如ping www.swust.edu.cn 时收到的ICMP回复报文如下:

其中bytes为返回字符长度字段、time为返回时间字段、TTL为路由跳数字段。智能状态下用到的是time字段,即从发送到收到ICMP的时间差,该时间差不但反应了当前网络状态还反应了当前系统运行状态,是一种快捷高效的性能判定指标。系统每一分钟向特定主机发送ICMP请求报文,统计四次返回的平均时间,从而分析当前网络与系统性能值,根据该值决定当前服务模式,对于该值的判定方案如下:

平均返回时间(ms)                 服务模型                  描述

0-5                   TREEMAX         1:N

  6-10                  TREEFIVE        1:5

  11-20                 TREEFOUR        1:4

  21-40                 TREETHREE       1:3

  41-70                 TREETWO         1:2

   >70                  TREEONE         1:1

 

图 3 – 10 和 3 – 11 为音视频会议模式下发起方与接收方模块层次图:

图 3 - 10 音视频会议发起方层次图

图 3 - 11音视频会议接收方层次图

1.7   辅助模块详细设计

辅助模块主要包含该音视频通信系统的用户界面,重要的三个用户界面设计如下:

1、音视频通信系统主界面

音视频通信软件为了方便各用户使用将用户登录作为系统设计的一部份。主界面类似QQ软件用户界面,包含用户、系统、帮助三大功能区。用户功能区实现用户登录、注销、刷新、退出功能;系统功能能实现群发消息、发起会议、音视频设置功能;帮助功能区为本软件相关说明。主界面采用MFC界面设计器完成,设计效果如图 3 - 4所示:  

图 3 - 4 音视频通信系统主界面设计

2、单人音视频聊天窗口

单人音视频通信模式下,用户可以进行一对一的音视频聊天外,还可以进行简单的文字通信功能以及全屏等特效,它的设计效果图如3 – 13 所示:

 

图 3 – 13 单人音视频聊天窗口

3、音视频会议窗口

音视频会议时包含了一系列会议设置窗口与通信窗口,它们的设计效果如图 3 - 5所示:

图 3 - 5 音视频会议窗口组

 

阅读更多
个人分类: 程序开发
想对作者说点什么? 我来说一句

java实现网络音频 视频通信

2017年08月31日 13MB 下载

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭