CN1147806C - 基于ip网的多媒体实时授课系统 - Google Patents

Abstract

本发明公开了一种基于IP网的多媒体实时授课系统，其由授课端、听课端、课堂服务中心以及多点控制单元(Multipoint Control Unit，MCU)四个部分组成；它通过教学现场的多媒体录制和网络传输，实现教学现场的直播，并通过师生多媒体多模式交互、教师自然板书授课、教学内容检索、应用程序共享、课件同步浏览、电子白板、课件实时录制、课堂管理等功能，解决传统课堂教学在时间和空间上的制约问题，大大扩展了教学规模，实现名师授课及教育资源的共享。

Description

基于IP网的多媒体实时授课系统

一、所属领域

本发明属于计算机设计与应用技术领域，涉及计算机软件、信息传递技术、多媒体技术以及网络教育/远程教育。特别涉及一种基于IP网的多媒体实时授课系统

二、背景技术

随着信息传递技术的发展，网络教育/远程教育已普遍被人们所接受，在这方面的研究也取得了显著的成就。申请人经过查新，检索到三篇与本发明相关的属于视频会议(VideoConference)领域的专利，它们分别是：

1. Method for video telephony over a hybrid network；

2. System，method and article of manufacture with integrated video conferencing billing in acommunication system architecture；

3. System，method and article of manufacture for communications utilizing calling，plans in ahybrid network.

在上述专利1中，发明人提出了一套在分组交换网下开展多媒体视频会议的方法，该套方法主要有以下特点：

1)支持群组交互模式下多媒体数据的发送、接收；

2)多媒体数据采用RTP(Real-time Transport Protocol)协议进行传输；

3)采用RSVP(Resource reSerVation Protocol)协议对交互过程中的视音频质量进行控制；

4)数据传输支持单播(unicast)、组播(multicast)、广播(broadcast)三种模式；

5)交互过程可以保存为本地媒体文件；

6)采用目录管理机制对会议成员进行管理。

7)采用软硬件相结合的实现策略。

在专利2中，发明人提出了一套在视频会议系统中创建呼叫的过程，该过程主要描述了呼叫双方的认证、授权、能力协商，此外还定义了呼叫消息所携带数据的内容与格式。目前，视频会议系统一般都采用类似的呼叫机制。

在专利3中，发明人提出了一套在分组交换网下开展多媒体视频会议的方法，并实现了该系统。此套方法与系统主要有以下特点：

1)支持多个分组间基于RTP协议的组播数据发送、接收；

2)采用目录管理机制对会议成员进行管理；

3)通过创建虚拟现实环境，实现分组间的用户相互感知，并能通过虚拟对象进行交互；

4)采用目录管理机制对会议成员进行管理；

5)交互过程可以保存为本地媒体文件；

6)采用软硬件相结合的实现策略。

根据上述查新，现有系统在通信方面存在以下四方面的问题：

1.不能支持组播数据的跨网段传输，网络带宽资源利用率较低，进而导致系统所能支持的端结点数目以及分布范围都存在很大局限性。

2.大多数同步实时授课系统直接采用了视频会议系统中的多点群组交互机制，这种交互机制不适合于实时授课。采用这种交互机制，不仅增加了上层管理的复杂程度，同时也造成不必要的系统资源开销，特别是网络带宽资源的开销。

3.缺乏自适应的服务质量(Quality of Service，以下简称QoS)控制机制，主要表现在：一、QoS控制机制无法适应网络状态的动态性。二、QoS控制机制对分布环境异构性的适应能力较差。

4.缺乏课件自动生成机制，只能将教学现场保存为媒体文件，无法生成教案与教学现场同步的课件。

三、发明内容

根据上述现有技术存在的缺陷或不足，本发明的目的在于，提供一种基于IP网的多媒体实时授课系统(RealClass)。

实现上述发明目的的技术解决方案是，一种基于IP网的多媒体实时授课系统，包括，授课端、多个听课端、课堂服务中心以及多点控制单元四个部分组成；

其中授课端是教师通过网络为听课端提供授课现场的实时视频、音频及电子教案的平台，通过电子白板、应用程序共享以及文本Chat等工具与听课端进行交互，对整个教学过程进行控制；

授课端包括一事务管理模块，用以实现与课堂服务中心进行状态、控制信息的交互；并能根据交互结果对底层的视频、音频数据采集、传输、发送、回放进行管理；

其底层的视频、音频数据处理是由Avmeeting控件实现；Avmeeting控件从本地的媒体设备中读取视频、音频数据，并通过服务质量数据发送控件发送到授课端网段的多点控制单元；同时调用服务质量数据接收模块从授课端网段的多点控制单元读取听课端的视频、音频数据，并将此数据与授课端的媒体数据在本地进行回放；

听课端是学生通过网络接收授课端的视频、音频及电子教案信息的平台，听课端获得交互权限后，与授课端进行视频、音频或其它方式交互，听课端与听课端之间也可通过分组方式进行交互；

听课端也包括一事务管理模块，用以实现与课堂服务中心进行状态、控制信息的交互，并能根据交互结果对底层的视频、音频数据采集、传输、发送、回放进行管理；

其底层的视频、音频数据处理同样是由Avmeeting控件实现；Avmeeting控件从本地的媒体设备中读取视频、音频数据，并通过服务质量数据发送控件发送到授课端网段的多点控制单元；同时调用服务质量数据接收模块从授课端网段的多点控制单元读取授课端的视频、音频数据，并将此数据与本地的媒体数据在本地进行回放；

课堂服务中心是管理员用于对授课系统进行监控的控制台；其通过与授课端、听课端、多点控制单元的状态和控制消息交互，实时获取多媒体实时授课系统的状态，并对多媒体实时授课系统各个端结点的工作进行控制；

多点控制单元用于完成系统中视频、音频数据的路由、转发以及处理；支持各结点的视频、音频数据的跨网段传输并进行有效控制；其特征在于：

所述的多点控制单元采用了分布式多点控制单元机制，分布在每个网段中；多点控制单元在各网段内部，向同网段的各个结点以组播方式发送数据；在各网段之间，授课端多点控制单元向其它各个网段多点控制单元以单播方式发送数据；此外，授课端与听课端的数据则单播发送到授课端的多点控制单元；

多点控制单元分为多点控制器MC和多点处理器MP两部分；多点控制器MC包含多点交互控制模块和服务质量参数确定模块，多点处理器MP分为服务质量控制机制模块和视频、音频数据处理模块；

多点交互控制模块通过对多点处理器MP的操作，用于实现对授课端和听课端的视频、音频交互控制，此外，它还根据与课堂服务中心交互的命令与状态信息，生成当前多点控制单元与即授课端、听课端的多点控制单元连接的状态信息；

服务质量参数确定模块根据此状态生成当前多点控制单元分的各个输出媒体流的服务质量参数，此参数将传递给多点处理器MP中的服务质量控制机制，作为其为每个输出媒体流分配网络带宽的依据；

服务质量控制机制是一种基于分层结构的动态自适应服务质量分布控制模型，该模型一方面采用基于端结点的分布控制，并在端结点引入动态自适应的流控机制，根据网络状态自动调整控制策略；另一方面，与服务质量控制相关的网络技术、视频编码技术以及前向纠错码(Forward Error Correction，以下简称FEC)容错技术基于分层结构进行有机集成；

服务质量控制模型分为服务质量控制层、实时传输协议(Real-time Transport Protocol，以下简称RTP)层以及FEC层；服务质量控制层用于实现多媒体数据传输的准入控制、流量控制和区分服务；RTP层用于实现多媒体数据包的实时、有序传输；  FEC层用于为上层提供传输通路；

视频、音频数据处理模块由多点控制器MC中的多点交互控制模块驱动，用于获取服务质量控制机制整形后的数据，对其进行数据融合和转发处理，并将处理后的数据传送到服务质量控制机制进行发送；

多点处理器MP的服务质量控制机制根据多点控制器MC传递来的服务质量参数以及当前的网络状态进行服务质量控制，包括对视频、音频数据处理模块处理后的多媒体数据进行带宽分配和发送，以及对由其它端结点发送来的多媒体数据进行整形。

本发明的其它一些特点是，服务质量控制层还对音频数据流采用固定带宽分配策略；对于视频数据流，则采用动态自适应的带宽分配策略；在此基础上，根据H.261、H.263、MPEGI、MPEG II视频编码的特性，视频编码帧可以分为设计了一个选择发送视频帧的算法，该算法保证了在数据包不丢失的情况下，发送到对方的编码数据都可被正确解码；

RTP层在实现多媒体数据包的实时、有序传输时，还通过实时传输控制协议(Real-timeTransport Control Protocol，以下简称RTCP)包的交互动态获取当前数据传输的时延、抖动、丢包率网络状态参数，以这些参数作为服务质量控制层进行带宽分配的依据，和前向纠错码层实施动态前向纠错码机制的主要依据；

FEC层还引入了反馈机制，根据当前的丢包率，动态控制FEC数据包的发送。

所述的视频、音频数据可以采用两种课件同步录制机制：一种是实时采集教案内容、教学现场的视频、音频数据，并压缩生成流媒体文件，供课后点播；二是将教学内容转换成超文本，并和实时录制视频、音频同步集成；

第一种技术路线：在授课端，多媒体实时授课系统通过定时截取屏幕或窗口获得当前教案内容的内存BMP映像，同时将当前视频捕获设备采集到的视频帧数据转化成内存BMP格式，然后将两部分BMP数据在位图基础上进行融合，并将融合后的数据发送到流媒体压缩引擎上；多媒体实时授课系统同时还将音频设备采集到的音频数据也发送到该引擎；压缩引擎将接收到的融合数据作为视频数据进行实时编码，同时将接收到的音频数据也进行实时编码，并将编码后数据一起发送到流媒体服务器；此外，流媒体压缩引擎还可将编码数据以RM文件形式在本地进行保存；

第二种技术路线：  采用HTML-Recorder工具和多媒体实时授课系统配合运行，它是一个后台程序；它一方面实时地采集教师的视频、音频数据并生成ASF流媒体文件，另一方面它将教师对教案的操作实时记录在时间戳日志中，包括教案换页、显示每个条目的时间戳等；当运行结束时，HTML-Recorder自动将时间戳写入ASF文件；并将PowerPoint格式的教案转化为一系列HTML网页及相关媒体文件；最后，将携带时间戳的ASF文件与HTML格式的教师教案按照固定的框架进行封装，从而生成教学课件。

本发明通过教学现场的多媒体录制和网络传输，实现教学现场的直播，并通过师生多媒体多模式交互、教师自然板书授课、教学内容检索、应用程序共享、课件同步浏览、电子白板、课件实时录制、课堂管理等功能，解决传统课堂教学在时间和空间上的制约问题，大大扩展了教学规模，能够实现名师授课及教育资源的共享。

四、附图说明

图1、本发明的多媒体实时授课系统RealClass的网络分布示意图；

图2、本发明的实时授课系统RealClass的授课端工作机制示意图；

图3、本发明的实时授课系统RealClass的听课端工作机制示意图；

图4、本发明的实时授课系统RealClass的课堂服务中心工作机制示意图；

图5、本发明的实时授课系统RealClass的MCU实现框架示意图；

图6、RealClass系统中端口使用规定；

图7、MCU实现的分布式MCU的工作机制示意图；

图8、视频数据融合的工作机制示意图；

图9、融合后的视频效果示意图；

图10、本发明的音频数据融合的工作机制示意图；

图11、基于分层结构的动态自适应QoS控制模型示意图；

图12、本发明的RealScreen系统的工作机制示意图；

图13、本发明的HTML-Recorder工具的工作机制示意图；

图14、HTML-Recorder工具生成的课件形式示意图；

图15、授课端用户界面；

图16、听课端用户界面；

图17、课堂服务中心的用户界面。

五、具体实施方式

为了更清楚的理解本发明，以下结合附图和实施例对本发明作进一步的详细描述。

本发明的多媒体实时授课系统主要包括以下几方面内容：

1.多媒体实时授课系统RealClass的组成

多媒体实时授课系统(RealClass)是一个面向实时网络教学的分布式多媒体应用系统。从物理分布上可分为授课端、听课端、课堂服务中心以及多点控制单元(Multipoint ControlUnit，以下简称MCU)四个部分。其中，授课端是教师的控制台，通过网络为听课端提供授课现场的实时视音频及电子教案，并通过电子白板、应用程序共享以及文本Chat等工具与听课端进行交互，此外授课教师还可对整个教学过程进行控制。听课端是学生的听课平台，通过网络接收授课端的视频、音频及电子教案信息，当听课端获得交互权限后，还可与授课端进行视频、音频或其它方式的交互，听课端与听课端之间在授课教师许可的情况下也可通过分组方式进行交互。课堂服务中心是管理员的控制台，用于对授课系统进行监控，并充当视频会议系统中的GateKeeper。MCU主要完成系统中视频、音频数据的路由、转发以及处理(如多路视频、音频融合)，从工作机制上可分为集中式MCU和分布式MCU。在本系统中，为了扩大规模，实现多媒体数据的自适应传输，采用了分布式MCU机制，即在系统所分布的每个网段中都存在一个MCU结点。

2.组播数据跨网段传输机制

研究目的：解决媒体数据的跨网段(子网)高效传输问题，以及视频、音频融合问题。

研究背景：在交互式多媒体同步实时授课中，当结点数多于两个时，需要引入称为多点控制单元(Multipoint Control Unit，MCU)的实体(Entity)。它的功能主要包括两点：①支持各结点的视频、音频数据的跨网段传输并进行有效控制；②对交互过程中的视频、音频数据进行融合处理。

目前，MCU大多采用集中式，由专门的MCU硬件实现，成本高，扩展性差。

本发明的解决策略：

在RealClass系统的设计中，本发明提出并实现了一种基于软件的分布式MCU机制，即在每个独立的网段，设置一个MCU，从而形成一个级联的树型MCU。采用单播和组播相结合的数据发送策略，即各MCU之间采用单播数据发送，各个网段内部采用组播数据发送，这样不仅可以大大节省网络带宽，而且还实现了组播数据的跨网段传输和视频、音频数据的融合，有效地提高了系统的可扩展性。

3.视音频融合机制

研究目的：研究解决授课端和听课端视频、音频融合的问题，将两路或多路视频、音频数据合并成一路数据，使得融合后的视频具有“画中画”的效果，对于音频，则具有“混音”效果。

问题背景：在实时教学系统中，视频、音频融合是十分需要的。因为听课端需要感受到一个“真实”的教学环境，因此需要把授课端及正在和授课端进行交互的“焦点”听课端的视频、音频数据进行融合，这样不仅可以大大减少数据量和网络带宽的占用，而且还可以为异地听课端提供一个更加形象、逼真的教学视听环境。

目前，有关视频、音频融合的基本原理大致雷同，本系统的特点是：采用软件实现，支持两路或四路视频融合，和MCU有机集成，无需附加软硬件。

4.动态自适应QoS控制机制

研究目的：在没有传输质量保障的IP网上，研究解决如何保障实时教学过程的多媒体数据传输质量的问题，即如何解决传输过程中延迟、抖动、丢包等问题。

问题背景：现有TCP/IP协议采用的是尽力而为(best-effort)的服务机制，该机制虽能较好地满足诸如WWW、Email、FTP等Internet的非实时应用，但它不适合于诸如网络实时教学等的实时多媒体应用。因此，要实现基于IP网的交互式同步实时授课，必须在现有TCP/IP传输机制的基础上增加服务质量(QoS，Quality of Service)控制机制。

目前，国际上的一些标准化组织，如IETF等已提出了基于IP网实现QoS控制机制的相关协议和模型，如RTP/RTCP协议、IntServ/RSVP模型、DiffServ模型及MPLS模型等。这些协议和模型为QoS控制机制的深层研究提供了较好的基础，但在实际应用中都存在一定的局限性。主要表现为：

(1)无法适应网络状态的动态性，现有QoS控制机制无法根据可用带宽、丢包率等网络状态参数的动态变化而动态调整控制策略，即不具备自适应能力。

(2)对分布环境异构性的适应能力较差。分布环境的异构性主要表现在分布的各个结点其软硬件体系结构和数据发送方式可能存在差异。前者表现为结点可能具有不同的接入速率、主机性能，甚至不同的操作系统；后者则表现为结点可能采用组播或单播发送方式。现有QoS控制机制基本上不具备适应上述分布异构环境，可扩展性较差。

(3)目前QoS控制机制仅局限于从网络角度提出解决策略。这种单一策略的控制机制在网络负载较重时，提供的服务质量明显下降。

本发明提出了一种基于分层结构的动态自适应QoS分布控制模型。其主要设计思想为：一方面，借鉴DiffServ模型中基于端结点的分布控制思想，并在端结点引入动态自适应的流控机制，使得本模型不仅具有可扩展性，而且还能根据网络状态自动调整控制策略。另一方面，采用多角度解决策略，将与QoS控制相关的网络技术、视频编码技术以及FEC(ForwardError Correction)容错技术等进行有机集成，从而使得本模型在带宽受限的情况下也能为媒体流传输提供合适的服务质量。

5.多媒体教学现场同步录制技术

研究目的：同步实时录制教学现场及教案内容，生成流媒体课件，供学生课后点播学习。

问题背景：能够在实时教学过程中，一边进行实时授课，一边自动进行同步课件录制与生成，是一件十分有意义的工作。不仅能够快速简捷地生成课件资源，减少课件制作的重复工作，而且为学生课后自主点播学习提供了机会。

目前，这方面工作存在的问题是：数据量太大，生成的课件无法进行后期修改和维护，模式单一。

本发明的解决方法：根据教学实际，本发明提出了两种解决思路：一种是实时采集教案内容、教学现场的视频、音频数据，并压缩生成流媒体(如rm或MPEG-IV等格式)文件，供课后点播；二是将教学内容转换成超文本(HTML文档)，并和实时录制视频、音频同步集成，形成“HTML+流媒体”格式的课件。这两种解决方案各有特点，可以视实际情况选择使用，主要区别在于是否对授课端计算机屏幕上的教案部分实现流式视频编码。

以下是发明人依上述技术方案完成的实施例。

6.1实时教学系统的组成

基于IP网的多媒体实时授课系统RealClass包括，授课端、听课端、课堂服务中心以及多点控制单元(Multipoint Control Unit，MCU)四个部分组成。

6.2子系统设计

以下对RealClass系统中的各个子系统(包括授课端子系统、听课端子系统、课堂服务中心子系统及MCU子系统)的工作机制进行说明，对于各个子系统的详细设计说明参看相应的详细设计方案。

6.2.1授课端工作机制

授课端的工作机制图2所示，其中授课端事务管理模块主要实现与课堂服务中心进行状态、控制信息的交互，并能根据交互结果对底层的视频、音频数据采集、传输、发送、回放进行。底层的视频、音频数据处理是由Avmeeting控件实现的。Avmeeting控件从本地的媒体设备中读取视频、音频数据，并通过QoS数据发送控件发送到本网段(授课端网段)的MCU；同时调用QoS数据接收模块从本网段MCU读取焦点听课端的视频、音频数据，并将此数据与授课端的媒体数据在本地进行回放。

6.2.2听课端工作机制

听课端的工作机制图3所示，其中听课端事务管理模块主要实现与课堂服务中心进行状态、控制信息的交互，并能根据交互结果对底层的视频、音频数据采集、传输、发送、回放进行。底层的视频、音频数据处理同样是由Avmeeting控件实现的。Avmeeting控件从本地的媒体设备中读取视频、音频数据，并通过QoS数据发送控件发送到授课端网段的MCU；同时调用QoS数据接收模块从本网段MCU读取授课端的视频、音频数据(对于非焦点听课端，读取的是授课端和焦点听课端融合后的数据)，并将此数据与本地的媒体数据在本地进行回放。

6.2.3课堂服务中心工作机制

课堂服务中心工作机制如图4所示。其通过与授课端、听课端、MCU的状态和控制消息交互，实时获取RealClass系统的状态，并对RealClass系统各个端结点的工作进行控制。

6.2.4 MCU工作机制

MCU可分为多点控制器MC和多点处理器MP两部分，其实现框架如图5所示。

MC包含多点交互控制和QoS参数确定两个模块。多点交互控制模块的主要功能是通过对MP的操作实现对远程教学过程中的授课端和听课端的视频、音频交互控制，此外，它还根据与课堂服务中心交互的命令与状态信息生成当前MCU与其它端结点(授课端、听课端、其它MCU)连接的状态信息。QoS参数确定模块根据此状态生成当前MCU的各个输出媒体流的QoS参数，此参数将传递给MP中的QoS控制机制，作为其为每个输出媒体流分配网络带宽的依据。

MP可分为QoS控制机制和视频、音频数据处理两个模块。其中视频、音频数据处理模块是MP的核心模块，由MC中的多点交互控制模块驱动。视频、音频数据处理模块获取QoS控制机制整形后的数据，对其进行数据融合和转发等处理，并将处理后的数据传送到QoS控制机制进行发送。MP的QoS控制机制根据MC传递来的QoS参数以及当前的网络状态进行QoS控制，主要包括对视频、音频数据处理模块处理后的多媒体数据进行带宽分配和发送，以及对由其它端结点发送来的多媒体数据进行整形。

6.2.5各个模块间的接口

由MCU实现框架图，MCU的内部接口包括以下几个部分：

■ MC中的QoS参数确定模块与多点交互控制模块之间的接口

MC中的QoS参数确定模块与多点交互控制模块之间的接口是多点交互控制模块根据由课堂服务中心发送来的全局MCU状态、本网段端结点状态生成的全局MCU状态列表和本网段端结点状态列表。

■ MC中的QoS参数确定模块与MP中的QoS控制机制之间的接口

MC中的QoS参数确定模块与MP中的QoS控制机制之间的接口是QoS参数确定模块根据全局MCU状态列表和本网段端结点状态列表生成的各个输出媒体流的QoS参数，即媒体流的带宽许可范围。

■ MC中的多点交互控制模块与MP中的视音频数据处理模块之间的接口

MC中的多点交互控制模块与MP中的视音频数据处理模块之间的接口是由MC生成的或转发课堂服务中心的视音频数据融合命令、视音频数据转发命令。

■ MP中的QoS控制机制与视音频数据处理模块之间的接口

MP中的QoS控制机制与视音频数据处理模块之间的接口包括经QoS控制机制整形后传输到视音频数据处理模块的数据，以及经视音频数据处理模块的处理后传输到QoS控制机制的数据。

由MCU与RealClass系统中的其他端结点的交互关系，MCU的外部接口包括以下几个部分：

■ MC中的多点交互控制模块与课堂服务中心之间的接口

MC中的多点交互控制模块与课堂服务中心之间的接口主要是两者之间交互的命令和状态，包括：

(1)由MCU向课堂服务中心发送的命令和状态，主要有MCU登录命令、MCU退出命令、端结点视音频控制命令。

(2)由课堂服务中心向MCU发送的命令和状态，主要有全局MCU状态、本网段端结点状态、视音频数据融合命令、视音频数据转发命令。

■ MP中的QoS控制机制与授课端和听课端的接口

MP中的QoS控制机制与授课端、听课端、其它MCU的接口主要指他们之间视音频数据收发端口的规定，对端口合理的规定，可以大大简化交互的控制逻辑。

在RealClass系统中，规定授课端向2001端口发送视频数据，向2000端口发送音频数据，从4001端口接收视频数据，从4000端口接收音频数据；听课端向3001端口发送视频数据，向3000端口发送音频数据，从4001端口接收视频数据，从4000端口接收音频数据；  MCU从2000～2001端口获取读取授课端视音频数据，从3000～3001端口获取读取听课端视音频数据，处理后向4000～4001端口发送视音频数据。如图6示。

■ MP中的QoS控制机制与其他MCU中的QoS控制机制之间的接口

MP中的QoS控制机制与其他MCU中的QoS控制机制之间的接口即MP之间的接口。在RealClass系统中，规定MP之间进行视音频数据交互时，视频数据使用5001端口，音频频数据使用5000端口。如图6示。

6.3主要关键技术

6.3.1组播数据跨网段传输机制

由于IP网一般不支持组播数据的跨网段发送，在本系统中，本发明基于分布式MCU实现了组播数据的跨网段，其原理如图7所示。主要思想是采用级联的MCU对组播数据进行转发。具体工作机制如下：

I.授课端将本地视频、音频数据单播发送到授课端MCU，并接收经授课端MCU组播发送的数据，此数据是授课端视频、音频与焦点听课端视频、音频融合后的数据。

II.授课端MCU将接收到的授课端视频、音频数据与焦点听课端视频、音频数据融合后，单播发送到各个非授课端MCU上，并组播到本地的授课端与各个听课端。

III.非授课端MCU将来自授课端MCU的视频、音频数据组播到本地各个听课端。

IV.焦点听课端将本地视频、音频数据单播发送到授课端MCU。

上述机制使得同步实时授课系统的负载不再受限于听课端的结点数目，而仅受限于听课端所分布的网段数目，从而有效地提高了系统的可扩展性。

在交互过程中，本发明提出了一种适合实时教学的多媒体群组交互模式——镜头焦点交互模式，其含义为：在同一时刻，允许一个称为“焦点”的听课端结点与教师进行交互，并将两者的多媒体数据经MCU融合后发送到其余各个结点，从而实现实时同步教学过程的传输。在这一过程中，学生可以随时向教师提出交互请求，教师可根据需要随时切换焦点。采用这种镜头焦点交互模式，不仅简化了实时授课系统的上层管理，而且还避免了不必要的带宽资源开销。

6.3.2视频、音频数据融合技术

本发明的解决方法：

■ 视频融合

当MCU中的MP接收到两路视频数据后，对其进行解码，解码后的数据为CIF格式或BMP格式，若解码后为BMP格式，则首先将其转化为CIF格式。对于两路CIF格式的数据，首先将其中一路视频帧转化成一路QCIF格式，然后再和另一路视频帧进行融合，根据视频的原编码算法，再对融合后的视频帧进行编码。视频融合的工作机制如图8所示。融合后的视频效果如图9所示。

■ 音频融合

当MP接收到两路音频数据后，对其进行解码，解码后的数据为线性的音频数据，然后将两路线性的音频数据进行代数迭加，进而根据音频的原编码算法，再对迭加后的音频数据进行编码。音频融合的工作机制如图10所示。

6.3.3动态自适应QoS控制机制

本QoS控制模型的实现要点为：

■ 基于端结点的分布控制机制

本模型引入了具有自适应能力的流控机制，它能根据当前网络状态为视频数据流动态分配网络带宽，同时对每个视频数据包能否进入网络进行准入判断。网络状态主要包括可用带宽、传输延迟以及丢包率。该机制所依据的网络状态是端结点间的整体状态，这充分掩盖了内部结点的异构性，使得该模型能较好地适用于异构的分布环境。

■ 基于分层结构的多角度解决策略

和以往不同的是：本发明对QoS问题的解决采用的是多角度、多层次的解决策略。把QoS控制模型分为QoS控制层、RTP层以及FEC层三个层次，如图11所示，并将网络传输、视频编码以及FEC容错这三个QoS的具体控制措施有机分布到这三个层次之中。

QoS控制层：主要实现多媒体数据传输的准入控制、流量控制和区分服务。主要措施为：对音频数据流采用固定带宽分配策略；对于视频数据流，则采用动态自适应的带宽分配策略，在此基础上，根据每个视频数据包的编码特征确定其是否可以进入网络，即是否发送到RTP层。

RTP层：主要实现多媒体数据包的实时、有序传输，并通过RTCP包的交互动态获取当前数据传输的时延、抖动、丢包率等网络状态参数，这些参数不仅是QoS控制层进行带宽分配的依据，也是FEC层实施动态FEC机制的主要依据。

FEC层：主要功能是为上层提供一条透明的可靠传输通路，避免因网络传输丢包导致的重传。本层还引入了反馈机制，即根据当前的丢包率，动态控制FEC数据包的发送。

上述三个层次之间有明确的接口，每一层通过其接口向上层提供透明的服务。在发送端，媒体数据由应用程序经QoS控制层、RTP层以及FEC层逐层分解并添加包头信息后发送到网络系统；在接收端，媒体数据由网络系统经FEC层、RTP层以及QoS控制层逐层还原后返回到应用程序。

■ QoS控制层

QoS控制层的主要功能是对输出媒体流进行流量限制。根据多媒体应用对视音频数据QoS需求特点，本模型中，采用音频数据优先的策略，基于带宽预留思想为音频数据流分配固定带宽；对于视频数据，则采用动态自适应的带宽分配机制，并在此基础上，引入基于视频编码特征的信包调度模块，使得当网络负载较重时，只发送对QoS影响较大的媒体数据。以下对视频数据的带宽分配机制与信包调度机制进行说明，并给出调度算法。

视频数据的带宽分配采用了“线性增长成倍衰减”的策略，此策略为：若当前的数据包丢失率小于某个阈值，则线性增加分配带宽值；若当前的数据包丢失率大于某个阈值，则将当前带宽值乘上衰减比例因子，作为新的分配带宽值。基于上述策略的带宽分配机制既能充分利用带宽资源，又能有效地降低丢包率。

视频数据的信包调度由令牌管理模块和数据包发送判定模块协同完成。令牌管理模块的工作机制是基于“漏桶算法”^[2]，其主要作用是对媒体数据发送速率进行限制，使得发送速率符合带宽分配模块所确定的速率。该子模块以带宽分配模块所确定的速率生成令牌，如令牌池中令牌已满，则令牌停止生成；当数据包发送判定子模块确定要发送一个数据包时，首先通知该子模块减去数据包大小的令牌数。数据包发送判定子模块根据当前令牌池中的令牌数以及当前视频数据包的编码特征判定是否将数据包发送到网络。根据H.261、H.263、MPEGI、MPEG II等视频编码的特性，视频编码帧可以分为I帧(帧内编码)、P帧(帧间编码)以及B帧(双向预测)^[4，5]。考虑到I帧、P帧、B帧解码过程中的相互依赖关系，传输视频数据必须遵循以下原则：

(1)在传输过程中，I帧优先级最高，P帧优先级次之，B帧优先级最低；

(2)传输P帧的前提是必须传输与之关联的I帧或P帧；

(3)传输B帧的前提是必须传输与之前后相邻的I帧或P帧。

基于上述三个规则，提出如下调度算法对视频数据包的发送进行判定，此算法的主要思想是在带宽受限的情况下，尽可能多地发送优先级高的数据包。调度算法描述如下：

case  数据包帧类型  of

I帧：if B帧队列非空  and

当前令牌数＞(当前数据包大小+B帧队列大小)then

发送B帧数据包和当前数据包并将令牌数减去此次发送数据包大小之和

else

if当前令牌数＞  当前数据包大小then

发送当前数据包并将令牌数减去当前数据包大小；

清空B帧队列；

P帧：if  B帧队列非空  and

当前令牌数＞  (当前数据包大小+B帧队列大小+平均关键帧大小)then发送B帧数据包和当前数据包并将令牌数减去此次发送数据包大小之和；

else

if 此帧关联的I帧已发送  and

当前令牌数＞  (当前数据包大小+平均关键帧大小) then

发送当前数据包并将令牌数减去当前数据包大小；

清空B帧队列；

B帧：if 此帧的前一个I帧或P帧已发送  then

将此帧放入队列；

end.

其中，平均关键帧大小可通过对多个关键帧的大小统计获得，B帧队列大小指当前队列中所有B帧大小之和。

若在信包调度过程中不考虑数据包的编码特性，则在接收端接收到数据后，很可能因为其相关的I帧数据或P帧数据没有发送而无法解码，成为无用数据，这使得信道的实际利用率大大降低。本算法保证了在数据包不丢失的情况下，发送到对方的编码数据都可被正确解码，且解码后的数据具有最优的表现质量。

■ 3.2 FEC层

FEC层的主要功能是基于FEC容错技术为上层提供一条的“较可靠”的传输通道，FEC层虽无法提供完全可靠的数据传输，但能有效地降低丢包率。其工作机理是：在发送端把k个原始数据包编码生成n(n＞k)个数据包，使得n中的任何k个数据包都能够恢复出原始数据包，这样在接收端只要接收到任意m(m＞k-1)个数据包，就可以恢复原始的k个数据包，即允许传输过程最多丢失n-k个数据包^[3，6]。相对于目前网络传输中常用的ARQ(AutomaticRepeat Request)控制机制，FEC机制主要有以下优点：

(1)FEC机制是由数据发送端实现的，不需要与数据接收端进行交互，实现机制较ARQ简单；

(2)适用于组播或广播模式的数据发送，在这种一对多的发送模式下，性能不会随着接收方的数目增加而下降，即具有较好的可扩展性^[3]。

FEC机制的主要缺点就是在网络丢包率比较低的情况下，仍然生成固定数目的冗余数据包，这些数据包不仅占用了一定网络带宽，而且也增大了传输延迟^[3]。

本模型的FEC层将FEC机制和反馈机制结合起来，实现了动态自适应的FEC机制。该机制不仅能有效地降低数据传输过程中的丢包率，而且在丢包率较低的情况下能有效减少冗余数据占用的带宽。其主要机理为：

(1)根据媒体流丢包率的许可范围，确定n、k值；

(2)采用公式①确定实际发送的数据包数m(k≤m≤n)，此数值应保证在当前丢包率情况下，接收方仍能以较高的概率恢复编码前的k个数据包；

(1)编码器顺序将k个数据包编码成n个数据包；

(2)随机选择m个数据包发送。

在动态FEC机制中，m的确定是其中的关键。设当前采用<n，k>编码，当前丢包率为r，允许丢包率为R(R＜r)，m应满足下述公式：

$\underset{i=0}{\overset{m-k}{\mathrm{\&Sigma;}}}{C}_m^j{(1-r)}^{m-i}{r}^i>{(1-R)}^k---\left(1\right)$

其中，上式的左边表示当前丢包率为r时，接收端接收到m中的k个以上(包括k个)数据包的概率，即能还原出k个数据包的概率；上式的右边表示在允许丢包率为R时，接收端正确接收到k个连续数据包的概率，显然，只有满足上述不等式关系时，才有必要进行FEC编码。采用枚举法，逐个选取m值(k≤m≤n)代入上式测试，最后选取能使上式成立的最小m值。当r＜R或r＞＞R时，可能不存在使上述公式成立的m值，则当前没有必要进行FEC编码，FEC层直接将RTP数据包发送到网络系统。因而，上述公式不仅用于计算FEC编码传输中应实际发送的数据包数，而且也可用于判断是否对RTP数据包进行FEC编码。

6.3.4多媒体教学现场同步录制技术

■ 流媒体课件实时录制工具——RealScreen

RealScreen工具采用的是技术路线一，它不仅可以实现实时教学的流媒体课件录制，而且还可以实现教学现场的直播，RealScreen由授课端、服务器端以及听课端三个部分组成。其中授课端主要实现了教学现场与教案内容的录制与编码；服务器端主要实现流媒体课件的发布与点播服务，听课端实现课件的回放。RealScreen的工作原理如图12所示。

在授课端，RealScreen通过定时截取屏幕或窗口获得当前教案内容的内存BMP映像，同时将当前视频捕获设备采集到的视频帧数据转化成内存BMP格式，然后将两部分BMP数据在位图基础上进行融合，并将融合后的数据发送到流媒体压缩引擎上；RealScreen同时还将音频设备采集到的音频数据也发送到该引擎。压缩引擎将接收到的融合数据作为视频数据进行实时编码，同时将接收到的音频数据也进行实时编码，并将编码后数据一起发送到流媒体服务器。此外，流媒体压缩引擎还可将编码数据以RM文件形式在本地进行保存。在服务器端，流媒体服务器将接收到的数据以RM文件形式进行保存，同时根据听课端的请求，采用RTSP/RTP协议将流媒体数据传输到听课端。在听课端，用户采用RealPlayer将接收到的编码数据进行解码、回放。

RealScreen将授课教案和视频、音频进行有机融合，这使得RealScreen不仅可以支持任何形式的教案，自动、同步、实时地生成流媒体课件，而且还可以实现教学现场直播和按需点播的同步进行。(如图12所示)这种方式的缺点是数据量较大，对课件的后期改进比较困难。

■ 基于“HTML+流媒体”的实时课件录制工具——HTML-Recorder

HTML-Recorder工具采用技术路线二，能够较好地解决了RealScreen工具存在的数据量大、带宽占用多、后期修改困难等问题，其工作原理如图13示。

HTML-Recorder工具可以和RealCiass系统配合运行，是一个后台程序。它一方面实时地采集教师的视频、音频数据并生成ASF流媒体文件，另一方面它将教师对教案的操作实时记录在时间戳日志中，包括教案换页、显示每个条目的时间戳等。当运行结束时，HTML-Recorder自动将时间戳写入ASF文件；并将PowerPoint格式的教案转化为一系列HTML网页及相关媒体文件；最后，将携带时间戳的ASF文件与HTML格式的教师教案按照固定的框架(Frame)进行封装，从而生成教学课件。界面形式如图14示。

与RealScreen工具相比，HTML-Recorder工具生成的课件在传输时只占用相对较小的带宽，并具有更好视频、音频质量，而且生成的课件可以进行后期修改，但缺点是目前课件的格式只支持Powerpoint格式。

RealScreen工具和HTML-Recorder工具的有机结合，可以提供完善的课件录制功能。

6.3.5界面设计

界面是系统功能和特点的集中反映，为了真正实现交互式同步实时授课的效果，需要将授课端现场、课件内容及其它必要的辅助功能以多窗口的形式展现在教师或学生的面前。

■ 授课端用户界面

授课端用户界面如图15示。包括授课端视频显示区、听课端视频显示区、课件内容浏览区、功能按钮区、听课端状态显示区等5部分。其中听课端视频显示区可以由教师任意切换到任一听课端。

■ 听课端用户界面

听课端用户界面如图16示。包括听课端视频显示区、授课端视频显示区、课件浏览区、功能按钮区、授课端状态显示区等5部分，其中，课件浏览区和授课端显示区这两部分与授课端保持一致。

■ 课堂服务中心的用户界面

课堂服务中心的用户界面如图17示。包括听课端视频显示区、授课端视频显示区、授课端状态显示区、听课端状态显示区、功能按钮区以及MCU状态信息显示区等6部分。其中，听课端视频显示区可以任意切换到任何一个听课点上。

本发明与现有技术相比，所产生的效果是：

1.听课端个数：可同时支持20个以上教室的同步实时授课，并可同时支持4个以上不同子网之间的视音频交互。

2.课件格式：支持HTML/XML文档、Word文档、Powerpoint、MPEG4、RM、RAM、VRML等格式的课件，并能方便地扩充新的格式。

3.课件质量：以640×480窗口或800×600全屏方式清晰显示课件内容。

4.视频交互：遵循H.261标准实现视频数据实时采集和回放、融合，视频质量由QoS控制机制保证。

5.语音交互：遵循G.711标准实现音频数据实时采集和回放、融合。

6.视音频同步：唇音同步误差≤0.5秒。

7.系统延时：系统的影像、声音及课件内容在Internet/校园网上传输时延小于2秒。

8.应用程序共享：遵循T.120协议，支持各种Windows应用程序共享。

9.电子白板：遵循T.120协议。

Claims (3)

1.一种基于IP网的多媒体实时授课系统，包括，授课端、多个听课端、课堂服务中心以及多点控制单元四个部分组成；

其中授课端是教师通过网络为听课端提供授课现场的实时视频、音频及电子教案的平台，通过电子白板、应用程序共享以及文本Chat工具与听课端进行交互，对整个教学过程进行控制；

授课端包括一事务管理模块，用以实现与课堂服务中心进行状态、控制信息的交互；并能根据交互结果对底层的视频、音频数据采集、传输、发送、回放进行管理；

其底层的视频、音频数据处理是由Avmeeting控件实现；Avmeeting控件从本地的媒体设备中读取视频、音频数据，并通过服务质量数据发送控件发送到授课端网段的多点控制单元；同时调用服务质量数据接收模块从授课端网段的多点控制单元读取听课端的视频、音频数据，并将此数据与授课端的媒体数据在本地进行回放；

听课端是学生通过网络接收授课端的视频、音频及电子教案信息的平台，听课端获得交互权限后，与授课端进行视频、音频或其它方式交互，听课端与听课端之间也可通过分组方式进行交互；

听课端也包括一事务管理模块，用以实现与课堂服务中心进行状态、控制信息的交互，并能根据交互结果对底层的视频、音频数据采集、传输、发送、回放进行管理；

其底层的视频、音频数据处理同样是由Avmeeting控件实现；Avmeeting控件从本地的媒体设备中读取视频、音频数据，并通过服务质量数据发送控件发送到授课端网段的多点控制单元；同时调用服务质量数据接收模块从授课端网段的多点控制单元读取授课端的视频、音频数据，并将此数据与本地的媒体数据在本地进行回放；

课堂服务中心是管理员用于对授课系统进行监控的控制台；其通过与授课端、听课端、多点控制单元的状态和控制消息交互，实时获取多媒体实时授课系统的状态，并对多媒体实时授课系统各个端结点的工作进行控制；

多点控制单元用于完成系统中视频、音频数据的路由、转发以及处理，支持各结点的视频、音频数据的跨网段传输并进行控制；

其特征在于：

所述的多点控制单元采用了分布式多点控制机制，分布在每个网段中；多点控制单元在各网段内部，向同网段的各个结点以组播方式发送数据；在各网段之间，授课端多点控制单元向其它各个网段多点控制单元以单播方式发送数据；此外，授课端与听课端的数据则单播发送到授课端的多点控制单元；

多点控制单元分为多点控制器MC和多点处理器MP两部分；多点控制器MC包含多点交互控制模块和服务质量参数确定模块，多点处理器MP分为服务质量控制机制模块和视频、音频数据处理模块；

多点交互控制模块通过对多点处理器MP的操作，用于实现对授课端和听课端的视频、音频交互控制，此外，它还根据与课堂服务中心交互的命令与状态信息，生成当前多点控制单元与授课端、听课端的多点控制单元连接的状态信息；

服务质量参数确定模块根据此状态生成当前多点控制单元分的各个输出媒体流的服务质量参数，此参数将传递给多点处理器MP中的服务质量控制机制，作为其为每个输出媒体流分配网络带宽的依据；

上述服务质量控制机制是一种基于分层结构的动态自适应服务质量分布控制模型，该模型一方面采用基于端结点的分布控制，并在端结点引入动态自适应的流控机制，根据网络状态自动调整控制策略；另一方面，与服务质量控制相关的网络技术、视频编码技术以及前向纠错码容错技术基于分层结构进行有机集成；

服务质量控制模型分为服务质量控制层、实时传输协议层以及前向纠错码层；服务质量控制层用于实现多媒体数据传输的准入控制、流量控制和区分服务；实时传输协议层用于实现多媒体数据包的实时、有序传输；前向纠错码层用于为上层提供传输通路；

视频、音频数据处理模块由多点控制器MC中的多点交互控制模块驱动，用于获取服务质量控制机制整形后的数据，对其进行数据融合和转发处理，并将处理后的数据传送到服务质量控制机制进行发送；

多点处理器MP的服务质量控制机制是根据多点控制器MC传递来的服务质量参数以及当前的网络状态进行服务质量控制，包括对视频、音频数据处理模块处理后的多媒体数据进行带宽分配和发送，以及对由其它端结点发送来的多媒体数据进行整形。

2.根据权利要求1所述的基于IP网的多媒体实时授课系统，其特征在于：

上述服务质量控制层还对音频数据流采用固定带宽分配策略；对于视频数据流，则采用动态自适应的带宽分配策略；在此基础上，根据H.261、H.263、MPEG I、MPEGII视频编码的特性，视频编码帧设计了一个选择发送视频帧的算法，该算法保证了在数据包不丢失的情况下，发送到对方的编码数据都可被正确解码；

实时传输协议层在实现多媒体数据包的实时、有序传输时，还通过实时传输控制协议包的交互动态获取当前数据传输的时延、抖动、丢包率网络状态参数，以这些参数作为服务质量控制层进行带宽分配的依据，和前向纠错码层实施动态前向纠错码机制的主要依据；

FEC层还引入了反馈机制，根据当前的丢包率，动态控制FEC数据包的发送。

3.根据权利要求1所述的基于IP网的多媒体实时授课系统，其特征在于：所述的视频、音频数据可以采用两种课件同步录制机制：一种是实时采集教案内容、教学现场的视频、音频数据，并压缩生成流媒体文件，供课后点播；二是将教学内容转换成超文本，并和实时录制视频、音频同步集成；

第一种技术路线：在授课端，多媒体实时授课系统通过定时截取屏幕或窗口获得当前教案内容的内存BMP映像，同时将当前视频捕获设备采集到的视频帧数据转化成内存BMP格式，然后将两部分BMP数据在位图基础上进行融合，并将融合后的数据发送到流媒体压缩引擎上；多媒体实时授课系统同时还将音频设备采集到的音频数据也发送到该引擎；压缩引擎将接收到的融合数据作为视频数据进行实时编码，同时将接收到的音频数据也进行实时编码，并将编码后数据一起发送到流媒体服务器；此外，流媒体压缩引擎还可将编码数据以RM文件形式在本地进行保存；

第二种技术路线：采用HTML-Recorder工具和多媒体实时授课系统配合运行，它是一个后台程序；它一方面实时地采集教师的视频、音频数据并生成ASF流媒体文件，另一方面它将教师对教案的操作实时记录在时间戳日志中，包括教案换页、显示每个条目的时间戳等；当运行结束时，HTML-Recorder自动将时间戳写入ASF文件；并将PowerPoint格式的教案转化为一系列HTML网页及相关媒体文件；最后，将携带时间戳的ASF文件与HTML格式的教师教案按照固定的框架进行封装，从而生成教学课件。

Images