CN108881802A - 一种sip视频会议的演示源输入方法 - Google Patents

Abstract

本发明公开一种SIP视频会议的演示源输入方法，该方法可通过WiFi Display技术将移动设备Source端的镜像引入本地设备Sink端的会议室***，由此通过会议媒体传输实现与远端设备的演示共享，该演示源输入方法具体包括：步骤a：开启WiFi Display服务，Source端和Sink端建立P2P连接，通过RTSP协商后，Sink端将接收到的镜像的音视频流作为会议室***的演示流；步骤b：开启演示功能，通过AVS进程将演示流写入会议室***的媒体通道；步骤c：进一步判断Sink端当前是否处于会议室通话状态，如果在通话状态下则开启远端演示模式，即演示流通过媒体通道发送至远端设备，如果在非通话状态下则开启本地演示模式，即演示流渲染到本地LCD显示。本发明方法通过整合WiFi Display应用，在不增加硬件的前提下丰富了会议室***演示资源，提升用户体验。

Description

一种SIP视频会议的演示源输入方法

技术领域

本发明属于通讯技术领域，尤其涉及多媒体无线传输技术。

背景技术

随着IP技术越来越成熟，IP传输内容也越来越丰富。演示功能作为SIP电话的一项特色功能受到很多用户的亲睐，演示源变得越来越丰富，功能也越来越完善，演示源可以是本地画面也可以是另外一台设备的画面，通过HDMI in将另外一台设备作为演示源是当前SIP电话演示功能很普遍的做法，但是这种接入方式存在如下缺点：特定的硬件接口支持，如HDMI、USB或者VGA接口；设备连接距离受制于连接线的长度等，使用起来很不方便。

通过WiFi Display技术作为演示源传输的载体很好的克服了这些缺点，只要双方设备具有WiFi模块，支持P2P功能，通过软件支持即可实现演示功能，连接和断开通过软件接口即可控制，方便快捷、图像传输质量也很高。如果将WiFi Display技术结合现有的IP视频会议技术，即将WiFi Display的视频源作为视频会议中的演示源发送到远端与会设备，进一步实现会议资源的传输和共享。

发明内容

本发明目的在于提供一种主要包括将WiFi Display作为演示源接入SIP视频会议***的实现方案。

为了实现上述发明目的，本发明公开了一种SIP视频会议的演示源输入方法，该方法可通过WiFi Display技术将移动设备Source端的演示源引入本地设备Sink端的会议室***，由此通过会议媒体传输实现与远端设备的演示共享，该演示源输入方法具体包括：步骤a：开启WiFi Display服务，Source端和Sink端建立P2P连接，通过RTSP协商后，Sink端将接收到的镜像的音视频流作为会议室***的演示流；步骤b：开启演示功能，通过AVS进程将演示流写入会议室***的媒体通道；步骤c：进一步判断Sink端当前是否处于会议室通话状态，如果在通话状态下则开启远端演示模式，即演示流通过媒体通道发送至远端设备，如果在非通话状态下则开启本地演示模式，即演示流渲染到本地LCD显示。

优选的，在远端演示模式下，当布局控制只显示演示模式，则演示流无需解码后重新编码，直接通过媒体通道发送到远端设备进行解码显示。

优选的，在远端演示模式下，当布局控制需要同时显示本地视频和演示模式，则演示流需要先解码，然后与本地视频码流进行混叠、混叠后的码流编码打包后通过媒体通道发送到远端设备。

优选的，在会议室***中，本地端摄像头画面、远端视频画面、演示流画面是建立不同的Socket传输通道来传输的。

优选的，在步骤a中，通过Dbus消息将WiFi Display的流传输网络接口、WiFiDisplay的传输状态信息发送给所述Sink端。

优选的，Sink端内部的信令处理模块、音视频处理模块和UI显示控制模块该三个模块间的通信方式是通过Dbus来完成。

优选的，P2P成功建立连接后，Sink端的信令处理模块需要将Source端的IP地址、P2P网口以Dbus的方式通知音视频处理模块，为后续接收音视频流做准备。

优选的，在SETUP阶段，信令处理模块将解析到的媒体流端口及媒体参数通过Dbus消息发送给所述音视频处理模块；音视频处理模块根据传输过来的端口号及媒体参数提取音视频流作为会议室***的演示流。

优选的，当Source端做了暂停、播放等操作时，信令处理模块需要通知音视频处理模块和UI显示控制模块做相应的状态处理。

优选的，UI显示控制模块负责本地布局切换和远端显示的开关控制。

本发明一种SIP视频会议的演示源输入方法，通过WiFi Display应用可以将移动终端的镜像画面引入会议室***作为演示源与远端各与会设备显示共享。该方法突破数据格式限制，进一步丰富拓展了会议室***的演示源，增加新的会议场景应用，提升用户体验。

附图说明

图1 为本发明具体实施例中本地演示拓扑图；

图2为本发明具体实施例中远端演示拓扑图；

图3 为本发明具体实施例中WiFi Display视频流在通话过程中演示流程图；

图4为本发明具体实施例中 WiFi Display音频流在通话过程中演示流程图；

图5为本发明具体实施例中实现WiFi Display作为演示源的IP话机功能模块图；

图6 为本发明具体实施例中WiFi Display演示功能进程关系图；

图7为本发明具体实施例中 WiFi Display信令及音视频流处理流程图；

图8为本发明具体实施例中WiFi Display演示流设计的软件堆栈结构。

具体实施例

本发明基本原理：将手机的镜像通过WiFi Display技术作为演示源显示到本地IP话机设备，并且在通话过程中，将上述接收到的视频源通过会议室***的媒体通道发送到远端设备作为远端演示源。

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是此时所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了方便描述，附图中仅示出于本发明相关的部分而非全部结构。

图1给出了WiFi Display作为本地演示源的拓扑结构图，是非通话状态下的应用。手机Source端通过WiFi直连与Sink端建立P2P连接。连接成功后，Source端就可以通过WiFiDisplay协议将手机的镜像画面发送到Sink端。会议室中这种功能很实用，可以很方便的进行PPT演讲、内容演示等。Source端兼容的设备类型很多，包括支持WiFi Display协议的Android Phone、Android PAD、Window PC等。

图2为本发明具体实施例中远端演示拓扑图，给出了将Source端镜像作为演示流发送到远端的拓扑关系。图2和图1的区别在于：此时Source端的镜像可以发送到远端设备，这种场景主要是在视频会议中向远端演示本地设备的画面，视频会议***是以SIP协议为基础建立起来的，通过SIP信令完成本地和远端的消息传输及音视频流的传输。视频通话过程中，Source端通过WiFi Display协议将镜像传输给Sink端，Sink端获取到Source端的镜像流之后与本地摄像头的采集流做混频处理，然后重新编码打包后发送到远端。视频会议中通过WiFi Display来向远端演示本地设备的画面而不需要特定的硬件接口支持是很方便的，避免了复杂的接口连接过程。

图3 为本发明具体实施例中WiFi Display视频流在通话过程中演示流程图；图4为本发明具体实施例中 WiFi Display音频流在通话过程中演示流程图。下面以视频流作为实例进行具体说明，音频流可参照理解。

在视频通话过程中，通过WiFi Display协议将Source端的镜像画面发送到远端的流程主要包括以下几个步骤：

步骤1，Sink端开启WiFi Display服务，该过程建立在WiFi P2P基础上，并在WiFi信标、探测信号中加入了WiFi Display特有格式的探测信号。

步骤2，在步骤1的基础上，手机Source端在无线投屏功能中便可以搜索到Sink设备。选择该Sink设备连接，如果P2P协商成功，则两台设备之间便建立了P2P连接。这个时候两台设备之间形成了一个独立的局域网络。

步骤3，在步骤2的基础上，两台设备建立起多个Socket连接，Socket是建立在P2P连接的基础上（注：P2P建立连接后，两台设备会形成一个局域网，DHCP会给每台设备分配一个IP），建立多个Socket的目的是为了传输不同类型的数据，信令传输需要建立基于TCP的Socket，用的协议是RTSP，Source端为服务端，Sink端为客户端。音视频传输需要建立基于UDP的Socket，用的协议是RTP，Sink端为服务端，Source端为客户端，每个连接对应一个通道。P2P建立连接成功后，Sink端接收到连接成功的广播后，解析P2P连接信息获取到Source端的IP，通过Socket连接到Source端，连接建立后进行信令的交互，包括各自的能力、支持的编解码格式、音视频端口等信息，协商成功后，Sink端和Source端开始建立音视频的Socket，传输音视频数据，Source端作为服务端将镜像的音视频数据编码、打包并发送出去，Sink端作为客户端接收音视频数据，拆包、解码及渲染数据。形成交互通道。主要包括两个通道：信令通道和数据通道，其中信令通道主要用于传输RTSP协议，用于能力协商和码流控制，主要协商内容包括决定需要使用的最佳参数，包括音视频解码率，分辨率，信道负载等等。数据通道主要用于传输音视频流，通常以RTP协议作为载体。

步骤4，在步骤3的基础上，Source端和Sink端的连接完全建立起来。此时，通过信令通道可以控制码流的传输，包括暂停、播放、设置参数、获取参数、拆线，对应于RTSP协议的几种控制方法PAUSE、PLAY、 SET_PARAMETER、 GET_PARAMETER 、TEARDOWN。码流通过数据通道传输到Sink端设备。此外，根据信令通道传输过来的音视频参数可以对音视频流进行正确的解码。

步骤5，在步骤4的基础上，获取到音视频流之后音视频的传输是在P2P网口的特定端口上进行的，Sink端的进程默认在19000端口上建立Socket监听即可接收到音视频数据。会议室***中音视频的处理是通过AVS进程来解码、渲染的，最终都是通过将视频帧写入到显卡的缓冲区后在LCD上显示拿到了音视频流后，AVS进程就可以将该流与本地视频流做混频和混音处理或者通过会议室的媒体通道发送到远端。

在本发明具体实施例中，会议室***包括本地演示和远端演示。其中，非通话状态下打开演示开关为本地演示，本地演示的画面直接渲染到本地的LCD；通话状态下打开演示开关为远端演示，远端演示下码流会通过会议室***的媒体通道发送给远端。

此外，会议室***可以根据视频通话过程中的界面布局对码流进行相应的处理，如果布局控制不在本地显示演示画面，那么发送到远端的视频流就不需要解码后再重新编码，而是直接通过媒体通道转发到远端设备由其他与会方进行解码显示，即码流转发。如果布局控制需要同时显示本地和演示流，那么在接收到演示流后，需要先解码然后与本地码流进行混叠，最后将混叠后的码流进行编码打包再发送到远端，即码流的混音混频处理。

本发明方案中，WiFi Display作为演示源与会议室***原有的演示功能是兼容的，只是多提供了一种类型的演示源，会议室***中演示源有专门的媒体通道传输，是通过BFCP协议实现的，当WiFi Display成功建立后，AVS进程只需要将演示流写入媒体通道即可。

步骤6，在步骤5的基础上，将拆包、解码处理的音视频流输出到本地的声卡及显卡，此时，AVS进程会根据layout布局对多路视频流做合成处理，Layout布局主要有等分、子母和画中画等。同时，重新编码打包处理后的音视频流通过视频会议***的媒体通道发送到远端设备。

上述这些不同布局是根据会议控制界面的Layout来控制的，Layout可以控制本地、远端及演示流的布局方式，如果Layout中不显示演示画面，那么本地就不需要解码演示流，在会议室***中，本地端摄像头画面、远端视频画面、演示流画面是建立不同的Socket传输通道来传输的，这些不同的流在LCD上的布局方式是通过通话界面的Layout功能来控制的。

步骤7，在步骤6的基础上，远端设备在媒体流通道上收到音视频流之后，根据相关参数进行解码显示。这样就完成的Source端镜像的远端传输及显示。本地演示模式、远端单独演示、远端组合演示的布局方式都是通过通话界面的Layout功能控制的，实际是由音视频处理应用模块将不同通道的码流合成到同一个画面的过程，

图5为本发明具体实施例中实现WiFi Display作为演示源的IP话机功能模块图，从图中可知，在Sink端本发明的实现该功能主要包括三个功能模块：信令处理模块、音视频处理模块、UI显示控制模块。信令处理模块主要承担RTSP信令处理和Dbus消息处理两项职责。音视频处理模块主要承担音视频编解码、音视频混叠两项职责。UI显示控制模块主要承担本地布局切换控制、远端演示的开关控制。接下来具体说明各个模块的功能和职责。

信令处理模块主要处理Source端与Sink端之间的P2P配对连接、能力协商及信令交互，具体内容包括设备的连接认证、媒体流参数协商、媒体流控制等。 Dbus消息处理包括根据处理的RTSP信令发送相应的指令及参数给音视频处理模块及UI显示控制模块；从音频处理模块及UI显示控制模块接收到的Dbus消息选择相应的RTSP信令发送回给Source端进行音视频参数的更改及媒体流的控制。

该信令处理模块中区别于现有的WiFi Display技术的特征是Dbus消息机制的引入，Dbus属于进程间通信机制，该模块中通过Dbus消息方式中将WiFi Display的流传输网络接口、WiFi Display的传输状态信息发送给音视频处理模块及UI显示控制模块。例如：P2P成功建立连接后，信令处理模块需要将Source端的IP地址及P2P网口以Dbus的方式通知音视频处理模块，为后续接收音视频流做准备；Source端做了暂停、播放等操作时，信令处理模块需要通知音视频处理模块和UI显示控制模块做相应的状态处理。

音视频处理模块方面，Sink端接收音视频流之后根据演示功能需求对流进行编解码和混叠处理。如果布局控制只显示演示，那么发送到远端设备的视频流就不需要解码后再重新编码，而是直接通过媒体通道转发到远端设备进行解码显示，即码流转发；如果布局控制需要同时显示本地和演示流，那么在接收到演示流后，需要先解码然后与本地码流进行混叠，最后将混叠后的码流进行编码打包再发送到远端设备，即码流的混音混频处理。

UI显示控制模块主要负责本地显示的布局切换以及控制远端演示流的显示，具体包括本地布局切换和远端显示的开关控制。其中，本地布局切换主要是通话界面的Layout功能，控制本地画面、远端画面及演示画面的布局组织方式。远端显示的开关控制就是控制演示流的打开及关闭。

上述信令处理模块、音视频处理模块、UI显示控制模块三个模块间的通信方式是通过Dbus来完成的。Dbus属于进程间通讯的一种，还可以是其他的方式，例如Binder、信号等，在本发明中选择这种方式，属于比较高效的进程间通讯方式。

图6 为本发明具体实施例中WiFi Display演示功能进程关系图。

图7为本发明具体实施例中 WiFi Display信令及音视频流处理流程图。从该图中可以看出Source端与Sink端建立连接后，RTSP信令流与RTP媒体流分别在Sink端的不同端口上传输，默认的RTSP端口为7236，默认的RTP端口为19000。

当P2P连接成功后，信令处理模块与Source端建立RTSP连接，RTSP信令主要包括OPTION、 SETUP、GET_PARAMET、 SET_PARAMET、 PLAY、 PAUSE、TEARDOWN这几个信令。

首先，在SETUP阶段，信令处理模块将解析到的媒体流端口及媒体参数通过Dbus消息发送给音视频处理模块。

然后，音视频处理模块根据传输过来的端口号及媒体参数提取音视频流作为会议室***的演示流。

其次，音视频处理模块根据当前会议室***的状态通知显示控制模块有演示流的接入，询问用户是否开启演示画面，在整个通话状态下，用户可以随意的控制演示流的开启和关闭。

最后，用户可以通过Layout功能控制本地视频流、远端视频流及远端演示流三路流的布局方式，音视频处理模块通过视频解码、视频合成等处理将三路视频合成到同一个画面，进而渲染到LCD屏幕上，同时将三路流的音频合成做混音处理输出到本地音频设备，打开演示功能的同时远端用户也可以收到演示流，通过通话界面的Layout功能调整三路视频流在LCD屏幕上的布局方式。

图8为本发明具体实施例中WiFi Display演示流设计的软件堆栈结构。

软件堆栈结构是Android***通用的架构从上到下分为应用层、 框架层、本地层，应用层与框架层之间调用通过Binder机制完成通信， 框架层与本地层之间调用通过JNI来完成。信令控制服务为整个功能模块的控制中心，主要功能同图5中的信令处理模块，对上为应用层提供控制接口，控制WiFi Display服务的打开及关闭，对下为本地层库提供接口调用，同时提供了和WiFi P2P服务和音视频处理服务的通信的接口。P2P连接主要是调用***WiFi P2P Service来完成，媒体流的处理主要通过音视频处理服务来完成的。

这个属于本发明方法实现的WiFi Display演示功能的软件堆栈结构设计图，基于Android***软件的堆栈结构，这种从上到下层级软件设计中WiFi Display协议只是提供了标准，具体实现因不同的平台差异化可能会很大。

注意，上述仅为本发明的较佳实施例以及所运用技术原理。本领域技术人员会理解，本发明不限于所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。 因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (10)

1.一种SIP视频会议的演示源输入方法，其特征在于，可通过WiFi Display技术将移动设备Source端的镜像引入本地设备Sink端的会议室***，由此通过会议媒体传输实现与远端设备的演示共享，所述演示源输入方法包括：

步骤a：开启WiFi Display服务，所述Source端和所述Sink端建立P2P连接，通过RTSP协商后，所述Sink端将接收到所述镜像的音视频流作为所述会议室***的演示流；

步骤b：开启演示功能，通过AVS进程将所述演示流写入所述会议室***的媒体通道；

步骤c：进一步判断所述Sink端当前是否处于会议室通话状态，如果在通话状态下则开启远端演示模式，即所述演示流通过所述媒体通道发送至所述远端设备，如果在非通话状态下则开启本地演示模式，即所述演示流渲染到本地LCD显示。

2.根据权利要求1所述的演示源输入方法，其特征在于，在所述远端演示模式下，当布局控制只显示演示模式，则所述演示流无需解码后重新编码，直接通过所述媒体通道发送到所述远端设备进行解码显示。

3.根据权利要求1所述的演示源输入方法，其特征在于，在所述远端演示模式下，当布局控制需要同时显示本地视频和演示模式，则所述演示流需要先解码，然后与本地视频码流进行混叠、混叠后的码流编码打包后通过所述媒体通道发送到所述远端设备。

4.根据权利要求2或3所述的演示源输入方法，其特征在于，在所述会议室***中，本地端摄像头画面、远端视频画面、演示流画面是建立不同的Socket传输通道来传输的。

5.根据权利要求4所述的演示源输入方法，其特征在于，在所述步骤a中，通过Dbus消息将WiFi Display的流传输网络接口、WiFi Display的传输状态信息发送给所述Sink端。

6.根据权利要求5所述的演示源输入方法，其特征在于，所述Sink端内部的信令处理模块、音视频处理模块和UI显示控制模块该三个模块间的通信方式是通过Dbus来完成。

7.根据权利要求6所述的演示源输入方法，其特征在于，P2P成功建立连接后，所述Sink端的信令处理模块需要将所述Source端的IP地址、P2P网口以Dbus的方式通知所述音视频处理模块，为后续接收音视频流做准备。

8.根据权利要求7所述的演示源输入方法，其特征在于，在SETUP阶段，所述信令处理模块将解析到的媒体流端口及媒体参数通过Dbus消息发送给所述音视频处理模块；所述音视频处理模块根据传输过来的端口号及媒体参数提取音视频流作为所述会议室***的演示流。

9.根据权利要求8所述的演示源输入方法，其特征在于，当所述Source端做了暂停、播放等操作时，所述信令处理模块需要通知所述音视频处理模块和所述UI显示控制模块做相应的状态处理。

10.根据权利要求9所述的演示源输入方法，其特征在于，所述UI显示控制模块负责本地布局切换和远端显示的开关控制。