CN102625079B

CN102625079B - 一种三方视频会议的视频实现方法

Info

Publication number: CN102625079B
Application number: CN201210075934.2A
Authority: CN
Inventors: 艾志敏
Original assignee: Xiamen Yealink Network Technology Co Ltd
Current assignee: Xiamen Yealink Network Technology Co Ltd
Priority date: 2012-03-21
Filing date: 2012-03-21
Publication date: 2015-01-14
Anticipated expiration: 2032-03-21
Also published as: CN102625079A

Abstract

本发明一种视频三方会议的视频实现方法，主持方利用屏幕的显示资源，将在主持方屏幕上组合完成的三方视频截取后进行编码发送给会议参与方，在会议参与方的各自屏幕上分别显示该主持方发来的截屏数据，这样免去了混合视频数据的资源占用，从而可以控制住视频资源损耗，在低成本的硬件运行环境下，会议三方可同时互相可听可见。

Description

一种三方视频会议的视频实现方法

技术领域

本发明涉及一种三方视频会议的视频实现方法。

背景技术

目前市面上支持三方会议功能的设备较多，但大多数为音频会议设备，而视频会议设备往往价格较高，这主要是由于大部分实现三方视频会议功能算法对硬件要求较高，从而使得整体成本提升。

传统三方会议设备基本都是采用主持方接收其余两方数据混合RTP数据后传递给另外两方进行实现，其中音频与视频的实现方法各有所不同，下面针对这两种实现类型进行分析：

1、传统音频会议的实现方法：

如图1所示，A与C方实际并不直接传递数据，而是通过主持方B作为中转站，将第三方的数据与B方自身的数据进行混合后传递给第二方，因此，主持方B的处理尤为重要，但由于音频数据的处理相对较为简单，因此，原则上只需多创建两条线程对数据进行混合即可满足要求。对于主持方B的三方音频会议通话步骤为：

（1）主持方B创建针对A、C两方的RTP接收端口的Socket，并进行监听等待；

（2）将主持方B自身所发出的声音进行采样；

（3）主持方B接收A方所传输过来的RTP音频数据，解码后在扬声器中放出，并将解码后的声音数据与B方自身声音混合后，打包为RTP数据包发送给协商网络参数时C方的RTP接收端口；

（4）（与步骤（3）并行)主持方B接收C方所传输过来的RTP音频数据，解码后在扬声器中放出，并将解码后的音频数据与主持方B自身的混合后，打包为RTP数据包发送给协商网络参数时A方的RTP接收端口；

（5）这样，A方听到的声音就为B/C两方混合的声音，B方听到的声音则为A/C双方混合的声音，C方听到的声音为A/B双方混合的声音，从而形成三方音频会议。

2、传统视频会议的实现方法：

在视频会议情况下，若不考虑硬件成本，采用如上音频会议的方案也是可以实现的，并且可以达到参与方看到另一参与方与主持方的效果，但由于使用该方案对硬件要求较高，而目前大部分的视频话机都达不到该要求，因此，市面上的话机基本都退而求其之，只要三方都能够听到其余两方的声音，而参与方只要能看到主持方的视频，主持方也只要能同时查看其中任一方的视频即可。

三方视频会议中占用资源最多也最为复杂的是混合数据，因此，如图2所示，主持方B去除了混合视频数据的过程，而对于A/C两方数据的处理是有区别的，主要是由于对于视频通话来说，接收数据所占用的CPU相对于解码数据来说是较少的，因此，节省资源最为有效的是减少解码，故而去除了非当前激活的C方数据的解码，只保留关键帧以方便后续重新查看时的解码正常。因此，此时的CPU资源占用为：三方音频会议+单路纯视频通话+单路RTP数据接收所占用的CPU总和，基本只是比起单路音视频通话多占用音频混合的资源损耗。

对于主持方B的三方视频会议通话步骤如下（音频部分处理参见上面音频会议的实现方法）：

（1）主持方B创建针对A、C两方RTP接收端口的Socket，并进行监听等待；

（2）将主持方B自身的视频图像进行采样，并打包为RTP数据包，分别发送给协商网络参数时A、C两方的RTP接收端口；

（3）假定主持方B设置A方视频为当前显示的主视频，则主持方B接收A方所传输过来的RTP数据，解码后在显示屏的FrameBuffer上显示出来让用户可查看到；

（4）（与步骤（3）并行)B方接收C方所传输过来的RTP数据，但不进行解码，只是存储关键帧I帧数据，用于后续进行切换主视频为C方后进行解码补偿，避免刚显示时出现马赛克现象；

（5）若主持方B此时设置主视频为C方，则主持方B利用通信控制协议(SIP或自定义协议)请求C方重发I帧，从而更新最新视频图像，并将A、C两方数据处理方式对换。

上面的方案虽解决了资源不足的问题，但仍存在以下问题：

A、一方参与方无法查看到另一参与方的视频信息，失去三方会议最重要的原则：三方互相可听可见；

B、主持方只能同时查看到某一参与方视频，若需要查看另一参与方的视频就要进行切换，用户操作较为麻烦。

发明内容

本发明的目的在于提供一种可以控制住视频资源损耗，在低成本的硬件运行环境下，会议三方可同时互相可听可见的三方视频会议的视频实现方法。

本发明一种视频三方会议的视频实现方法，具体包括如下步骤：

步骤1、主持方B创建针对两个会议参与方A、C的RTP接收端口的Socket，并进行监听等待；

步骤2、主持方B将自身的视频图像进行采样，并在主持方B的屏幕上的对应B方的显示区域显示B方的视频；

步骤3、主持方B接收会议参与方A所传输过来的RTP数据，经解码后在主持方B的屏幕上对应会议参与方A的显示区域显示A方的视频；

步骤4、（与步骤3并行) 主持方B接收会议参与方C所传输过来的RTP数据，经解码后在主持方B的屏幕上对应会议参与方C的显示区域显示C方的视频；

步骤5、主持方B截取自身屏幕上由A、B、C三方的显示区域组成的联合显示区域，将其打包为RTP数据包，并将其分别发送给协商网络参数时两个会议参与方A、C的RTP接收端口；

步骤6、该两会议参与方A、C将来自主持方B的截屏RTP数据解码后在各自的屏幕上显示。

本发明进一步将收发包与编解码的处理步骤分离：

主持方B在上述步骤1中创建完Socket后，创建独立线程T1用于接收来自A或C方的RTP数据包，并将其分别存放在两个不同的公用队列中，并且在接收前将公用队列的数据加上访问锁，接收完成后将访问锁释放，该访问锁用于与下面的解码线程进行访问同步；

另一条独立解码线程T2通过定时获取上述两公用队列中的数据，将两公用队列中的所有数据取出后，将涉及整帧图像的多个数据包同时进行解码，这样在每次取数据前通过判断此时公用队列中积压的数据包的数量，如超过阈值，则解码线程T2在该情况出现后将中间的非关键帧去除直接解码I帧，取出解码前也需要将公用队列的数据加上访问锁，解码完成后将访问锁释放；

解码过程中解码线程T2在每次取数据前通过判断此时公用队列中积压的数据包的数量，若超过阈值，则该解码线程T2直接通过RTCP信令向数据发送方发送RTP数据包速率控制指令，请求减缓RTP数据包的发送速率；

编码过程也以上述步骤处理。

本发明利用屏幕的显示资源，将在主持方屏幕上组合完成的三方视频截取后进行编码发送给会议参与方，在会议参与方的各自屏幕上分别显示该主持方发来的截屏数据，这样免去了混合视频数据的资源占用。

附图说明

图1为传统音频会议实现方式的原理示意图；

图2为传统视频会议实现方式的原理示意图；

图3为本发明的流程示意图；

图4为本发明进一步改进的原理示意图；

图5为本发明视频会议实现方式的原理示意图；

以下结合附图和具体实施例对本发明做进一步详述。

具体实施方式

如图3、5所示，本发明一种视频三方会议的视频实现方法，具体包括如下步骤：

步骤5、主持方B截取自身屏幕上由A、B、C三方的显示区域组成的联合显示区域（如图3所示可以是矩形），并将其打包为RTP数据包，分别发送给协商网络参数时两个会议参与方A、C的RTP接收端口；

本发明一种视频三方会议的实现方法，主持方利用屏幕显示资源，将组合完成的三方视频截取进行编码后发送给会议参与方，这样免去混合视频数据的资源占用，如图3所示，从该CPU资源占用计算上可以看出，本发明虽然满足了三方可以互相查看对方视频的要求，但此时的资源占用还是要比其他话机多出一路视频通话解码，而对于视频通话来说，视频的解码对资源要求也是较高的，尤其是在H264-Codec下，而H264目前基本已成为视频通话的首选Codec，因此，需要进一步改进，将资源占用率再次下降。

如图3所示，主持方B此时的CPU资源占用：三方音频会议+两路纯视频通话解码+截屏+单路视频编码+基本的网络收发包总和。从本发明的CPU资源占用上来看，由于截屏本身的资源占用较低，同时在实现时使用数据缓存方式已基本达到最优方案，因此重点还是在于解码资源的利用上，而解决该问题最直接的方法当然是改进解码算法，但由于目前所采用的解码算法已为较为成熟的算法，同时若修改算法，则可能带来较多兼容性问题，因此，从另一方面考虑，将突破点放在降低解码时的资源占用上，而由于此时长期进行的操作只有编码与网络传输，而编码的修改与解码类似，故而从网络传输的资源占用上考虑。

首先，不可能降低网络传输速率，其次，也不可能去除网络包的发送，但可从避免网络传输峰值的占用考虑。由于之前网络发送与接收是与编解码绑定的，即在同一线程处理，因此，造成解码的速度会受到收发包的影响。

如图4所示，本发明进一步将收发包与编解码的处理步骤分离：

主持方B在所述步骤1中创建完Socket后，创建独立线程T1用于接收来自A或C方的RTP数据包，并将其分别存放在两个不同的公用队列中，并且在接收前将公用队列的数据加上访问锁，接收完成后将访问锁释放，该访问锁用于与下面的解码线程进行访问同步；

另一条独立解码线程T2通过定时获取上述两公用队列中的数据，将两公用队列中的所有数据取出后，多个数据包(即整帧图像，一般为6个数据包左右)同时进行解码，这样在每次取数据前通过判断此时公用队列中积压的数据量，如超过20个数据包，则解码线程在该情况出现后将中间的非关键帧(即非I帧)去除直接解码I帧，避免由于数据包过多而造成本地频繁解包，从而CPU占用过高的现象，取出解码前也需要将公用队列的数据加上访问锁，解码完成后将访问锁释放。

解码过程中解码线程T2在每次取数据前通过判断此时公用队列中积压的数据量，如超过30个数据包，则该线程直接通过RTCP信令向数据发送方发送RTP数据包速率控制指令，请求减缓RTP数据包的发送速率，避免缓冲区不足。

编码过程也类似处理。

这样，可以通过多个数据共同解码的方式避免原来通过同一线程将接收与解码串行，造成数据积压，从而频繁取包等待，占用CPU资源较高的问题，也可以通过解码线程根据当前积压数据的量来请求数据发送方RTP数据包发送的速率，从而可以控制整体传输带宽。

以上所述，仅是本发明较佳实施例而已，并非对本发明的技术范围作任何限制，故凡是依据本发明的技术实质对以上实施例所作的任何细微修改、等同变化与修饰，均仍属于本发明技术方案的范围内。

Claims

1. 一种视频三方会议的视频实现方法，其特征在于包括如下步骤：

步骤1、主持方B创建针对两个会议参与方A、C的RTP接收端口的Socket套接字，并进行监听等待；

步骤4、主持方B接收会议参与方C所传输过来的RTP数据，经解码后在主持方B的屏幕上对应会议参与方C的显示区域显示C方的视频，本步骤与步骤3并行；

2.根据权利要求1所述的一种视频三方会议的视频实现方法，其特征在于进一步将收发包与编解码的处理步骤分离：

主持方B在上述步骤1中创建完Socket套接字后，创建独立线程T1用于接收来自A或C方的RTP数据包，并将接收到的RTP数据包分别存放在两个不同的公用队列中，并且在接收前将公用队列的数据加上访问锁，接收完成后将访问锁释放，该访问锁用于与独立线程T2对公用队列的数据访问进行同步；

另一条独立线程T2通过定时获取上述两公用队列中的数据，将两公用队列中的所有数据取出后，将涉及整帧图像的多个数据包同时进行解码，这样在每次取数据前通过判断此时公用队列中积压的数据包的数量，如超过阈值，则独立线程T2将中间的非关键帧去除直接解码I帧，取出数据解码前也需要将公用队列的数据加上访问锁，解码完成后将访问锁释放；

解码过程中独立线程T2在每次取数据前通过判断此时公用队列中积压的数据包的数量，若超过阈值，则该独立线程T2直接通过RTCP信令向数据发送方发送RTP数据包发送速率控制指令，请求减缓RTP数据包的发送速率。