CN112543297B - 一种视频会议直播方法、装置和*** - Google Patents

Abstract

本申请公开了一种视频会议直播方法、装置和***，方法包括：通过网页即时通信WebRTC连接，接收主播客户端创建视频会议后发送的第一路流媒体数据以及至少一个连麦客户端发送的第二路流媒体数据；对接收到的多路流媒体数据进行混合，得到与主播客户端对应的第一合并流媒体数据以及与各连麦客户端对应的第二合并流媒体数据；将第一合并流媒体数据输出至主播客户端，将第二合并流媒体数据分别输出至各连麦客户端；以及将多路流媒体数据发送至内容分发网络CDN，以使CDN将多路流媒体数据发送至观看客户端。本申请实施例客户端只需要上传自己的流媒体信息，减轻了客户端的带宽和性能压力，提高了直播的时效性。

Description

一种视频会议直播方法、装置和***

技术领域

本申请涉及互联网技术领域，具体涉及一种视频会议直播方法、装置和***。

背景技术

一般的视频会议解决方案包括软件实现和硬件实现，硬件实现时，一台会议专用设备动辄上万，不适用于小型企业，而软件实现时，由于本身技术方案的局限性，也无法支持全公司级别的会议宣讲活动。直播解决了协同办公场景下企业多人大规模互动视频会议成本高，参与人数有限等技术问题。

网络直播是利用互联网及流媒体技术进行直播，主播客户端通过采集摄像头的数据，并将数据进行视频编码，将编码的视频推流送到内容分发网络CDN服务器，其他观众则从CDN服务器拉取数据流进行观看。用户如需进行桌面共享、电子白板等协同办公业务，可开启相应功能，主播客户端切换视频采集为桌面采集，并渲染电子白板后，将采集到的数据进行推流，从而实现对协同办公的支持。

然而，目前，协同办公与直播的结合方案在多人互动时，主播端的带宽、视频编解码压力很大，影响了上行带宽有限并且网络环境不稳定的移动网络下的直播效果。

发明内容

鉴于上述问题，提出了本申请以便提供一种克服上述问题或者至少部分地解决上述问题的一种视频会议直播方法、装置和***。

根据本申请的一个方面，提供了一种视频会议直播方法，包括：

通过网页即时通信WebRTC连接，接收主播客户端创建视频会议后发送的第一路流媒体数据以及至少一个连麦客户端发送的第二路流媒体数据；

对接收到的多路流媒体数据进行混合，得到与所述主播客户端对应的第一合并流媒体数据以及与各连麦客户端对应的第二合并流媒体数据；

将所述第一合并流媒体数据输出至所述主播客户端，将与各连麦客户端对应的所述第二合并流媒体数据分别输出至各连麦客户端；以及将所述多路流媒体数据发送至内容分发网络CDN，以使所述CDN将所述多路流媒体数据发送至观看客户端。

根据本申请的另一个方面，提供了一种视频会议直播装置，包括：

数据接收模块，用于通过网页即时通信WebRTC连接，接收主播客户端创建视频会议后发送的第一路流媒体数据以及至少一个连麦客户端发送的第二路流媒体数据；

混合模块，用于对接收到的多路流媒体数据进行混合，得到与所述主播客户端对应的第一合并流媒体数据以及与各连麦客户端对应的第二合并流媒体数据；

直播模块，用于将所述第一合并流媒体数据输出至所述主播客户端，将与各连麦客户端对应的所述第二合并流媒体数据分别输出至各连麦客户端；以及将所述多路流媒体数据发送至内容分发网络CDN，以使所述CDN将所述多路流媒体数据发送至观看客户端。

根据本申请的再一个方面，提供了一种视频会议直播***，该视频会议直播***包括：主播客户端，连麦客户端，直播服务器，以及与所述直播服务器连接的即时通话服务器，所述即时通话服务器中包括如本申请的一个方面所述的视频会议直播装置。

根据本申请的又一个方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被处理器执行时，实现如本申请一个方面所述的方法。

应用本申请实施例的视频会议直播方法、装置和***，服务端通过网页即时通信WebRTC连接，接收主播客户端发送的第一路流媒体数据以及至少一个连麦客户端发送的第二路流媒体数据，通过媒体旁路处理的方式将视频会议中主播和连麦成员的流媒体数据进行加工处理(包括：音频混音、视频拼接)后推送给CDN，客户端只需要上传一路自己的流媒体信息，无需消耗过多带宽，减轻了客户端的压力，并且，主播和连麦成员直播互动与服务端数据上报CDN可以同时进行，提高了多人互动协同办公直播场景的时效性。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本申请一个实施例的视频会议直播方法的流程示意图；

图2示出了本申请一个实施例的视频会议直播方法的时序图；

图3示出了本申请一个实施例的视频会议直播方法支持电子白板功能的时序图；

图4示出了本申请一个实施例的视频会议直播装置的框图；

图5示出了本申请一个实施例的视频会议直播***的框图；

图6示出了本申请一个实施例的计算机可读存储介质的结构示意图。

具体实施方式

下面将参照附图更详细地描述本申请的示例性实施例。虽然附图中显示了本申请的示例性实施例，然而应当理解，可以以各种形式实现本申请而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本申请，并且能够将本申请的范围完整的传达给本领域的技术人员。

音视频通话技术，是指两个或两个以上不同地方的个人或群体，通过传输线路及多媒体设备，将声音、影像及文件资料互传，以实现同时进行会议的技术。视频会议与电话类似，除了能看到与你通话的人并进行语言交流外，还能看到他们画面，使处于不同地区位置的人就像在同一空间内沟通。WebRTC(Web Real-Time Communication，网页即时通信)作为音视频通话技术的解决方案之一，被广泛应用于互联网音视频开发项目中。WebRTC解决了Web页面无法捕获音视频的问题支持P2P(即浏览器间)的视频交互。

直播属于近两年互联网热门行业，随着与各行各业的不断融合，直播行业迎来空前的繁荣发展。直播主要由直播客户端(或直播网页端)以及管理后台构成。众多用户将其用于在线研讨会、营销会议等网络活动场景，扩大市场活动，有效提高管理和运营效率，提升企业销售业绩，增强企业竞争力。其有别于电视直播/视频直播等传统直播手段，属于网络直播领域。网络直播更注重互动性。主持人可以针对有现场直播需求的用户，利用互联网(或专网)和先进的多媒体通信技术，通过在网上构建一个集音频、视频、桌面共享、文档共享、互动环节为一体的多功能网络直播平台，企业或个人可以直接在线进行语音、视频、数据的全面交流与互动。而企业化协同办公对直播也有着很大的需求。

协同办公是将现代化办公和计算机网络功能结合起来的一种新型的办公方式。音视频会议、直播互动，是协同办公***下很好的能力载体。而本申请方案即是满足该类应用场景下的需求。基于WebRTC的协同办公直播方案，采用WebRTC框架、实现音视频通话、会议、直播互动、直播连麦的基础服务功能，并在其上面提供包括桌面白板、远程共享、桌面控制等一系列的协同办公通用解决方案。用户可以在移动、Web、PC等多端中进行互通互联的实时音视频业务，适用于远程音视频、多方视频、视频会议、同屏辅助、直播互动等场景，提供高可用、高品质、超低延时的实时网络服务。

随着客户的需求增加，对于协同办公下的直播，如何实现更加贴近面对面会议体验成为了新的挑战。互动直播应运而生。互动直播，也叫连麦直播，是主播直播期间，可以与其中某一个观众或者几个观众进行互动，并且其他观众能够观看到这个互动过程。直播连麦功能的推出让直播的传播方式变成平等的互动社交模式，主播和观众的身份也由此转换为发起者和参与者。而在此场景下如何原有协同办公中的白板互动、桌面共享能力，使得直播互动的应用场景更加多元化，更加适合于协同办公业务需求。

在现有协同办公和直播功能叠加的方案中，用户通过直播客户端采集并编码音视频数据后，直接使用RTMP(Real Time Messaging Protocol，实时消息协议)协议推流到CDN(Content Delivery Network，内容分发网络)，其他用户以观众模式使用对应的拉流地址从CDN中拉取音视频流。用户如需进行桌面共享、电子白板等协同办公可开启相应功能，直播客户端切换视频采集，将媒体采集设备由用户画面采集切换为桌面采集，并渲染电子白板后，将采集到的数据进行推流。

针对白板互动、连麦互动等互动模式，有一种方案是主播端接收观众端发送的音频、视频、互动数据，主播端将自己的声音和观众的声音做混音，模拟观众的互动操作进行渲染展示，并将自己的画面与观众的画面做视频合成，最后将混合后的声音和画面推流到CDN服务器。这种方案有如下缺点：

首先，协同办公与直播没有完全融合为一套解决方案，相互之间独立使用，对于后续业务发展不利。从流程上说，互动是通过直播平台将互动二人或多人的操作传给主播，并由主播端进行桌面媒体采集后上报推流，并没有实现真正多人互动协同办公的直播场景。

其次，主播端的带宽压力很大。主播必须通过直播平台发送一路音视频数据给连麦观众、同时还需要推送一路流到CDN服务器。所以相比单人直播，连麦后主播端的上行流量将变为原来的两倍，而同时也要接收连麦观众的下行流推送。对于多人连麦，每增加一位连麦观众，就要多收一份下行推送。这个二倍的流量在Windows操作***、Mac操作***等具有高带宽、高稳定性的网络环境下影响不大，但对于上行带宽有限、网络环境不稳定的移动网络，将会大大影响直播的效果。

而且，主播端的视频编解码压力将会增大。主播必须编码一路视频给直播连麦观众，同时需要合成并编码一路数据推送给CDN，两次编码对于移动主播端的性能压力非常大。而且由于网络的不稳定，可能导致音频、视频、互动操作等具有时间差异，客户端需要大量缓存临时数据并进行比对，保证时间的对应。

最后，由于推送CDN数据是在多人音视频互动之后，对直播造成了观众可感知的延迟体验，无法满足协同办公这类要求时效性较高的业务场景。

对此，本申请提供一种视频会议直播方案，将协同办公与直播进行结合，实现一套用户体验更好、可扩展性更强的协同办公直播平台。本申请的技术构思在于：主持人客户端(或称主播客户端)不再直接将采集到的流媒体推流到CDN，而是基于即时通话服务器，由即时通话服务器转发给直播服务器，再由直播服务器处理后推流到CDN。

即时通话服务器用于实现多人的音视频会议，而且会议模式下所有的数据包都是通过即时通话服务器中转，具体的，即时通话服务器在转发给连麦客户端的同时，转发一份音视频数据到直播服务器，直播服务器对收到的语音进行混音，同时对收到的视频画面做混合处理，处理完毕以后再推流到CDN。通过这种方案，将现有的由主播端执行的混音、混屏及推流的操作，转移到即时通话服务器和直播服务器承担，降低了客户端资源耗损，满足了协同办公的低延时、高时效等业务需求。

图1示出了本申请一个实施例的视频会议直播方法的流程示意图，参见图1，本实施例的视频会议直播方法包括：

步骤S101，通过网页即时通信WebRTC连接，接收主播客户端创建视频会议后发送的第一路流媒体数据以及至少一个连麦客户端发送的第二路流媒体数据。

步骤S102，对接收到的多路流媒体数据进行混合，得到与所述主播客户端对应的第一合并流媒体数据以及与各连麦客户端对应的第二合并流媒体数据。

步骤S103，将所述第一合并流媒体数据输出至所述主播客户端，将与各连麦客户端对应的所述第二合并流媒体数据分别输出至各连麦客户端；以及将所述多路流媒体数据发送至内容分发网络CDN，以使所述CDN将所述多路流媒体数据发送至观看客户端。

由图1所示可知，本实施例的视频会议直播方法，通过网页即时通信WebRTC连接接收主播客户端的第一路流媒体数据以及至少一个连麦客户端的第二路流媒体数据；对多路流媒体数据进行混合，得到与所述主播客户端对应的第一合并流媒体数据以及与各连麦客户端对应的第二合并流媒体数据，将第一合并流媒体数据、第二合并流媒体数据分别输出至主播客户端或各连麦客户端，并将多路流媒体数据发送至内容分发网络CDN，以进行分发实现直播。由此，借助音视频会议业务架构，由服务端通过媒体旁路处理的方式将视频会议中主要成员(即主播和连麦观众)的流媒体数据进行加工处理(包括：音频混音、视频拼接)后推送给CDN，如此，客户端只需要上传一路自己的流媒体信息，无需消耗过多带宽。

图2示出了本申请一个实施例的视频会议直播方法的时序图，图2中的主持人表示主持人客户端，具体实现形式可以为安装于电脑、手机等设备上的浏览器。参与观众表示连麦客户端，直播平台可以为安装于电脑、手机等设备上的浏览器。观众表示观看客户端，观看客户端是普通观众所使用的手机、电脑等设备上的浏览器，观看客户端和连麦客户端的数量为多个。

本实施例的视频会议直播基于WebRTC技术实现，在WebRTC技术中用户无需注册和登录，只要多人访问同一个URL(含有WebRTC为每个直播房间分配的特定ID)，就可以进行视频会议。参与视频会议需要客户端所在终端提供摄像头功能。通过WebRTC，客户端从用户摄像头获取图像并传给服务器来实现视频会议。

参见图2，在一个实施例中，视频会议直播方法包括：

参见图2，步骤S201，创建会议；

视频会议的主持人，通过客户端创建一个具有直播功能的视频会议。

步骤S202，通过WebRTC推送第一路流媒体数据；

主持人客户端，或称主播客户端在创建视频会议后通过WebRTC流媒体通道发送第一路流媒体数据到即时通话服务器，即时通话服务器接收第一路流媒体数据。

这里，即时通话服务器接收第一路流媒体数据包括接收主播客户端以用户数据报协议UDP协议格式发送的第一路流媒体数据。也就是说，本申请实施例中，主持人客户端向即时通话服务器传输流媒体数据是基于UDP(User Datagram Protocol，用户数据报协议)协议实现的，之所以采用UDP协议是因为，本申请实施例的应用场景为视频会议，视频会议等协同办公业务对实时性要求比较高。UDP私有协议与基于TCP(Transmission ControlProtocol传输控制协议)的协议族RTMP(Real Time Messaging Protocol，实时消息传输协议)相比具有优势，UDP协议面向无连接，避免了TCP协议做网络质量控制所需要的开销，能够做到比较低的延迟。

步骤S203，通过WebRTC推送第二路流媒体数据；

连麦客户端通过WebRTC推送第二路流媒体数据到即时通话服务器。

用户通过申请上台连麦或主持人邀请连麦方式加入视频会议进行直播连麦，达到相当于面对面交流的效果。连麦的本质是视频通话，而视频通话最重要的指标是延时，只有低延时，主播和连麦观众才可以较好的互动、交流。根据ITU-TG.114标准，单向通话延时大于150ms就可使得通话连续性受到影响，最大可容忍时延为400ms。

因此，本实施例中至少一个连麦客户端在与即时通话服务器建立网页即时通信WebRTC连接后发送第二路流媒体数据。通过网页即时通信WebRTC连接接收主播客户端创建视频会议后发送的第一路流媒体数据以及至少一个连麦客户端发送的第二路流媒体数据包括：通过网页即时通信WebRTC连接接收至少一个连麦客户端以所述UDP协议格式发送的第二路流媒体数据。

也就是说，连麦客户端与即时通话服务器之间也是基于UDP协议通信的，从而主持人和连麦观众通过即时通话服务器实现连麦互动，实时性好，普通观众看到的合成画面里主播和连麦观众的互动也是同步实时的，满足了低延时的要求。

步骤S204，混音、混屏；

由于本实施例应用于视频会议的直播，所以，即时通话服务器在收到主播客户端和各连麦客户端的流媒体数据之后，对接收到的多路流媒体数据进行混合，得到与所述主播客户端对应的第一合并流媒体数据以及与各连麦客户端对应的第二合并流媒体数据。

比如，当前参与连麦的成员有主持人A，连麦观众B和连麦观众C，即时通话服务器用于实现即时通话的效果。因此，当即时通话服务器收到连麦观众B的音视频数据之后，将主播端的声音和连麦观众B的声音进行混音，并将主播端的画面与连麦观众B的画面做视频合成，而后生成一路流媒体数据，将这一路流媒体数据发送至主播端。以及，将连麦观众B的声音与连麦观众C的声音进行混音，并将连麦观众C的画面与连麦观众B的画面做视频合成，生成另一路流媒体数据发送至连麦观众C。以此，对参与连麦的成员之间的音视频数据的混合并返回至各参与连麦的成员，实现即时音视频通话效果。具体的混音和混屏技术手段可采用现有技术实现。

步骤S205，混音、混屏；

参见图2，本实施例的即时通话服务器在将第一合并流媒体数据输出至主播客户端或将第二合并流媒体数据分别输出至各连麦客户端时，还将多路流媒体数据发送至内容分发网络CDN，以使CDN将所述多路流媒体数据发送至观看客户端。具体的，先将多路流媒体数据发送至直播服务器，由直播服务器进行混音、混屏后再发送到CDN。

需要说明的是，本步骤中的混音、混屏与上一步骤中的混音、混屏的不同之处在于数据处理对象不同。接上例，当前参与连麦的成员有主持人A，连麦观众B和连麦观众C，即时通话服务器将收到的多路流媒体数据发送至直播服务器，直播服务器对这3路流媒体数据进行转码和混合(包括混音、混屏)并向每个客户端输出合并流媒体数据。比如，即时通话服务器将收到的来自主播客户端的第一路流媒体数据、来自连麦观众B的第二路流媒体数据、来自连麦观众C的第二路流媒体数据，一共三路流媒体数据发送至直播服务器，直播服务器收到这三路流媒体数据中的声音进行混音，对视频画面进行合成，得到混合结果。

步骤S206，实时推流；

直播服务器将得到的混合结果实时推流到CDN。即，将所述多路流媒体数据发送至内容分发网络CDN包括：将所述多路流媒体数据发送至直播服务器，以使所述直播服务器对所述多路流媒体数据进行混合处理后将混合结果封装成实时消息传输协议RTMP流数据并推送到所述CDN。

本实施例中直播服务器通过RTMP协议向CDN传输RTMP流数据，这是由于服务端之间网络一般比较稳定，所以通过基于TCP协议的RTMP协议推送RTMP流数据以提升音视频质量。

步骤S207，实时推流。

CDN收到混合结果后进行分发，即，实时推流，供观众通过浏览器观看视频会议的直播内容以及主持人与上台观众的互动内容。

由上可知，本实施例的视频会议直播，主持人和连麦观众使用实时音视频技术来进行连麦互动，实时性高，普通观众看到的合成画面里主播和连麦观众的互动也是同步实时的，降低了延时，提高了用户满意度。采用即时通话可以更好的与协同办公场景结合，真正实现多人互动协同办公的直播场景，拥有更灵活的业务扩展能力。另外，所有客户端的上行推流不再依赖RTMP协议，而是使用基于WebRTC的即时通话服务器，所以传输层的服务质量QoS(Quality of Service)控制更加智能高效，客户端带宽和性能压力不复存在，应用于移动端的连麦互动直播时，本方案优势更加明显。

如前述，本申请实施例将协同办公业务与直播进行结合，基于即时通话服务器和直播服务器，提供屏幕共享、电子白板、远程协助等协同办公相关业务功能。以电子白板为例进行说明，电子白板是一种大型触控设备，其可被应用于教学用途以提供可进行互动操作的环境。如今电子白板已经逐渐取代旧式的黑板或白板等设备，并且大量运用于课堂以及会议室等场合。电子白板一般具有触控书写功能，用户可以利用触控笔等工具来在电子白板上进行书写、绘图。

图3示出了本申请一个实施例的视频会议直播方法支持电子白板功能的时序图，

参见图3，本实施例的方法包括下列步骤：

步骤S301，通过WebRTC推送第一路流媒体数据；

主持人客户端(即主播客户端)通过WebRTC流媒体通道发送第一路流媒体数据到即时通话服务器，即时通话服务器接收第一路流媒体数据。

本步骤中的流媒体数据推送过程与前述步骤S202中相同，因此，这里不再重复说明。

步骤S302，通过WebRTC推送第二路流媒体数据；

本步骤中的参与观众向即时通话服务器推送流媒体数据过程与前述步骤S203中相同，因此，这里不再重复说明。

步骤S303，混音、混屏；

即时通话服务器对流媒体数据的混音、混屏过程与前述步骤S204中相同，因此，这里不再重复说明。

步骤S304，混音、混屏；

直播服务器对流媒体数据的混音、混屏过程与前述步骤S205中相同，因此，这里不再重复说明。

步骤S305，实时推流；

直播服务器向CDN推流的过程与前述步骤S206中相同，因此，这里不再重复说明。

步骤S306，实时推流；

CDN进行分发，数据推流的过程与前述步骤S207中相同，因此，这里不再重复说明。

步骤S307，电子白板操作；

在视频会议过程中，主持人在主持人客户端桌面的电子白板上进行书写或绘画。此时，主持人客户端上的影像采集设备采集主持人的书写或绘画轨迹，得到指示主播客户端桌面的电子白板画面的视频数据，将该视频数据以及主持人书写/绘画时的音频数据一并发送到即时通话服务器，即时通话服务器将这一电子白板上的操作的视频数据发送给白板服务，从而白板服务根据书写/绘画轨迹生成操作结果，将操作结果分别发送发给主播客户端、连麦客户端，实现电子白板互动。

也就是说，第一路流媒体数据包括音频数据以及指示主播客户端桌面的电子白板画面的视频数据；第二路流媒体数据包括：音频数据以及指示连麦客户端桌面的电子白板画面的视频数据；本实施例的视频会议直播方法还包括，将指示主播客户端桌面的电子白板画面的视频数据以及指示连麦客户端桌面的电子白板画面的视频数据发送至电子白板服务器，以使电子白板服务器，生成电子白板操作结果数据后返回给主播客户端或连麦客户端显示。

也就是说，主持人客户端在开启电子白板功能后，将采集源由主持人画面切换为桌面画面，主持人客户端采集到桌面的电子白板上的操作之后，通过WebRTC流媒体通道，将电子白板操作的音视频数据推送到即时通话服务器。本实施例中，即时通话服务器可以针对每个视频会议创建对应的会议号或称会议室编号，房间编号，后续在支持电子白板功能时，利用会议号标识一个电子白板服务，以对即时通话服务器服务的多个视频会议进行区分。

步骤S308，电子白板操作；

同样的，连麦客户端采集指示连麦客户端桌面的电子白板画面的视频数据，将采集的视频数据通过WebRTC传送至即时通话服务器，即时通话服务器将指示连麦客户端桌面的电子白板画面的视频数据发送至电子白板服务器，以使电子白板服务器，生成电子白板操作结果数据后返回给主播客户端或连麦客户端显示。

电子白板服务器，主要用于根据主持人或连麦观众在电子白板上的书写、绘画轨迹，更新电子白板画面，生成电子白板操作结果，比如，主持人在电子白板上书写了一行字，电子白板服务器确定出这一行字在桌面上对应的起始点坐标和终点坐标，并根据点坐标绘制、渲染电子白板画面生成操作结果后返回主持人客户端和各连麦客户端进行显示，实现电子白板的即时交互。

另外，由于音频和视频采集、传输、处理不同，可能存在音画不同步的问题，对此，本申请实施例在对接收到的多路流媒体数据进行混合之前，针对各路所述流媒体数据创建对应的缓冲区，将各路所述流媒体数据存储到对应的缓冲区中；当预设时间周期到来时，从各所述缓冲区中取出所述流媒体数据以进行混合。

比如，采用WebRTC的Jitterbuffer即抖动缓冲器实现音画同步。具体的，预先创建不同的缓冲区，将收到的音频数据、视频画面存储到对应的缓冲区中，每隔一段均匀的时间间隔，收集音频数据进行混音，收集视频画面进行混屏，实现音画同步。

同样的，对于卡顿(卡顿是指两帧视频间隔超过预设时长)问题，本实施例通过抖动缓冲器进行缓冲，实现卡顿、抖动等自适应。

与前述方法实施例同属于一个技术构思，本申请实施例还提供了视频会议直播装置，图4示出了本申请一个实施例的视频会议直播装置的框图，参见图4，本实施例的视频会议直播装置400，应用于即时通话服务器，包括：

数据接收模块401，用于通过网页即时通信WebRTC连接，接收主播客户端创建视频会议后发送的第一路流媒体数据以及至少一个连麦客户端发送的第二路流媒体数据；

混合模块402，用于对接收到的多路流媒体数据进行混合，得到与所述主播客户端对应的第一合并流媒体数据以及与各连麦客户端对应的第二合并流媒体数据；

直播模块403，用于将所述第一合并流媒体数据输出至所述主播客户端，将与各连麦客户端对应的所述第二合并流媒体数据分别输出至各连麦客户端；以及将所述多路流媒体数据发送至内容分发网络CDN，以使所述CDN将所述多路流媒体数据发送至观看客户端。

在本申请的一个实施例中，数据接收模块401具体用于通过网页即时通信WebRTC连接接收所述主播客户端以用户数据报协议UDP协议格式发送的第一路流媒体数据以及至少一个连麦客户端以所述UDP协议格式发送的第二路流媒体数据。

在本申请的一个实施例中，所述直播模块403具体用于将所述多路流媒体数据发送至直播服务器，以使所述直播服务器对所述多路流媒体数据进行混合处理后将混合结果封装成实时消息传输协议RTMP流数据并推送到所述CDN。

在本申请的一个实施例中，所述第一路流媒体数据包括音频数据以及指示所述主播客户端桌面的电子白板画面的视频数据；所述第二路流媒体数据包括：音频数据以及指示所述连麦客户端桌面的电子白板画面的视频数据；

直播模块还用于，将所述指示所述主播客户端桌面的电子白板画面的视频数据以及指示所述连麦客户端桌面的电子白板画面的视频数据发送至电子白板服务器，以使所述电子白板服务器根据接收的数据生成电子白板操作结果后将电子白板操作结果返回给所述主播客户端或所述连麦客户端进行显示。

在本申请的一个实施例中，混合模块402在对接收到的多路流媒体数据进行混合之前，针对各路所述流媒体数据创建对应的缓冲区，将各路所述流媒体数据存储到对应的缓冲区中；当预设时间周期到来时，从各所述缓冲区中取出所述流媒体数据以进行混合。

需要说明的是，上述装置实施例的具体实施方式可以参照前述对应方法实施例的具体实施方式进行，在此不再赘述。

图5示出了本申请一个实施例的视频会议直播***的框图，参见图5，本实施例的视频会议直播***500包括：主播客户端501，连麦客户端502，直播服务器503，以及与所述直播服务器503连接的即时通话服务器504，

所述即时通话服务器502中包括前述实施例中的视频会议直播装置400。

需要说明的是，上述***实施例中直播服务器的各功能的说明、即时通话服务器的各功能的说明可以参照前述对应方法实施例的说明，在此不再赘述。

综上所述，本申请的技术方案与现有由客户端推送流媒体数据到CDN服务器相比，最大的区别是借助音视频会议业务架构，由服务端通过媒体旁路处理的方式将会议中主要成员流媒体数据进行加工处理(包括：音频混音、视频拼接)后再通过RTMP协议推送给CDN网络，客户端只需要上传一路自己的流媒体控制，无需消耗过多带宽。而且音视频会议采用UDP协议进行传输，更适合实时通话业务。服务端之间网络稳定通过TCP推送提升音视频质量。最后通过WebRTC开发框架的抖动缓冲器，解决丢包、抖动等网络问题。对于协同办公，现有方案并没有将直播与协同业务紧密结合，而本方案使用音视频会议业务架构，更好的与协同业务融合，为后续业务扩展提供了更好的延展性。

需要说明的是：

在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本申请也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请的内容，并且上面对特定语言所做的描述是为了披露本申请的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本申请并帮助理解各个发明方面中的一个或多个，在上面对本申请的示例性实施例的描述中，本申请的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本申请的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本申请实施例的视频直播方法中的一些或者全部部件的一些或者全部功能。本申请还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本申请的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

根据本申请一个实施例的电子设备包括处理器和被安排成存储计算机可执行指令(计算机可读程序代码)的存储器。存储器可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。存储器具有存储用于执行上述方法中的任何方法步骤的计算机可读程序代码的存储空间。例如，用于存储计算机可读程序代码的存储空间可以包括分别用于实现上面的方法中的各种步骤的各个计算机可读程序代码。计算机可读程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。这些计算机程序产品包括诸如硬盘，紧致盘(CD)、存储卡或者软盘之类的程序代码载体。这样的计算机程序产品通常为例如图6所述的计算机可读存储介质。图6示出了根据本申请一个实施例的一种计算机可读存储介质的结构示意图。该计算机可读存储介质存储有用于执行根据本申请的方法步骤的计算机可读程序代码，可以被电子设备的处理器读取。具体来说，该计算机可读存储介质存储的计算机可读程序代码可以执行上述任一实施例中示出的方法。计算机可读程序代码可以以适当形式进行压缩。

应该注意的是上述实施例对本申请进行说明而不是对本申请进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本申请可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (6)

1.一种视频会议直播方法，其特征在于，包括：

通过网页即时通信WebRTC连接，接收主播客户端创建视频会议后发送的第一路流媒体数据以及至少一个连麦客户端发送的第二路流媒体数据，所述第一路流媒体数据包括音频数据以及指示所述主播客户端桌面的电子白板画面的视频数据；

所述第二路流媒体数据包括：音频数据以及指示所述连麦客户端桌面的电子白板画面的视频数据；

针对各路所述流媒体数据创建对应的缓冲区，将各路所述流媒体数据存储到对应的缓冲区中；当预设时间周期到来时，从各所述缓冲区中取出所述流媒体数据以进行混合；

对接收到的多路流媒体数据进行混合，得到与所述主播客户端对应的第一合并流媒体数据以及与各连麦客户端对应的第二合并流媒体数据；

将所述第一合并流媒体数据输出至所述主播客户端，将与各所述连麦客户端对应的所述第二合并流媒体数据分别输出至各连麦客户端；以及将所述多路流媒体数据发送至直播服务器，以使所述直播服务器对所述多路流媒体数据进行混合处理后将混合结果封装成实时消息传输协议RTMP流数据并推送到CDN，以使以使所述直播服务器对所述多路流媒体数据进行混合处理后将混合结果封装成实时消息传输协议RTMP流数据并推送到CDN所述CDN将所述多路流媒体数据发送至观看客户端；

所述方法还包括，将所述指示所述主播客户端桌面的电子白板画面的视频数据以及指示所述连麦客户端桌面的电子白板画面的视频数据发送至电子白板服务器，以使所述电子白板服务器根据接收的数据生成电子白板操作结果后将电子白板操作结果返回给所述主播客户端或所述连麦客户端进行显示；

主播客户端不再直接将采集到的流媒体推流到CDN，而是基于即时通话服务器，转发给直播服务器，再由直播服务器处理后推流到CDN，会议模式下所有的数据包都是通过即时通话服务器中转，即时通话服务器在转发给连麦客户端的同时，转发一份音视频数据到直播服务器，直播服务器对收到的语音进行混音，同时对收到的视频画面做混合处理，处理完毕以后再推流到CDN，将现有的由主播端执行的混音、混屏及推流的操作，转移到即时通话服务器和直播服务器承担，以降低端资源耗损。

2.如权利要求1所述的方法，其特征在于，所述通过网页即时通信WebRTC连接，接收主播客户端创建视频会议后发送的第一路流媒体数据以及至少一个连麦客户端发送的第二路流媒体数据包括：

通过网页即时通信WebRTC连接接收所述主播客户端以用户数据报协议UDP协议格式发送的第一路流媒体数据以及至少一个连麦客户端以所述UDP协议格式发送的第二路流媒体数据。

3.一种视频会议直播装置，其特征在于，包括：

数据接收模块，用于通过网页即时通信WebRTC连接，接收主播客户端创建视频会议后发送的第一路流媒体数据以及至少一个连麦客户端发送的第二路流媒体数据，所述第一路流媒体数据包括音频数据以及指示所述主播客户端桌面的电子白板画面的视频数据；

所述第二路流媒体数据包括：音频数据以及指示所述连麦客户端桌面的电子白板画面的视频数据；

针对各路所述流媒体数据创建对应的缓冲区，将各路所述流媒体数据存储到对应的缓冲区中；当预设时间周期到来时，从各所述缓冲区中取出所述流媒体数据以进行混合；

混合模块，用于对接收到的多路流媒体数据进行混合，得到与所述主播客户端对应的第一合并流媒体数据以及与各连麦客户端对应的第二合并流媒体数据；

直播模块，用于将所述第一合并流媒体数据输出至所述主播客户端，将与各连麦客户端对应的所述第二合并流媒体数据分别输出至各连麦客户端；以及将所述多路流媒体数据发送至直播服务器，以使所述直播服务器对所述多路流媒体数据进行混合处理后将混合结果封装成实时消息传输协议RTMP流数据并推送到CDN，以使所述CDN将所述多路流媒体数据发送至观看客户端；将所述指示所述主播客户端桌面的电子白板画面的视频数据以及指示所述连麦客户端桌面的电子白板画面的视频数据发送至电子白板服务器，以使所述电子白板服务器根据接收的数据生成电子白板操作结果后将电子白板操作结果返回给所述主播客户端或所述连麦客户端进行显示。

4.如权利要求3所述的装置，其特征在于，

所述数据接收模块，具体用于通过网页即时通信WebRTC连接接收所述主播客户端以用户数据报协议UDP协议格式发送的第一路流媒体数据以及至少一个连麦客户端以所述UDP协议格式发送的第二路流媒体数据。

5.一种视频会议直播***，其特征在于，该视频会议直播***包括：主播客户端，连麦客户端，直播服务器，以及与所述直播服务器连接的即时通话服务器，

所述即时通话服务器中包括如权利要求3-4中任一项所述的视频会议直播装置。

6.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被处理器执行时，实现如权利要求1-2中任一项所述的方法。