CN115037979A - 投屏方法及相关设备 - Google Patents

Abstract

本公开提供一种投屏方法，包括：第一终端的视频会议客户端发送投屏请求到视频会议服务端；接收到所述视频会议服务端反馈的会议信息之后，所述视频会议客户端根据所述会议信息加入与本次视频会议对应的实时通信(RTC)房间，向所述第一终端的RTC客户端发送发布屏幕的指令，向所述第一终端的屏幕采集模块发送开始屏幕采集指令，以使所述屏幕采集模块开始进行屏幕采集；以及在收到来自所述屏幕采集模块的首帧图像之后，向所述RTC客户端发布接收到的首帧图像，以使所述RTC客户端实现所述首帧图像的编码以及向第二终端的传输。基于上述投屏方法，本公开还提供了一种投屏装置、电子设备、存储介质以及程序产品。

Description

投屏方法及相关设备

技术领域

本公开涉及互联网技术领域，尤其涉及一种投屏方法、投屏装置、电子设备、存储介质及程序产品。

背景技术

投屏是指将投屏端中的信息投射到展示端上进行展示的技术。通过投屏可以将一个终端设备，例如手机、平板、笔记本、电脑等的画面“实时地”显示到另一个终端设备的屏幕上，例如，平板、笔记本、电脑、电视、一体机、投影仪等等。其中，输出的内容包括各类媒体信息和实时操作画面。目前，投屏已经成为目前生活、学习以及工作中分享信息的重要手段。在影响使用者体验的多种指标中，建立投屏过程的时延就是其中的重要一项。

发明内容

有鉴于此，本公开的实施例提供一种投屏方法，可以减小建立投屏过程的时延，也就是投屏首帧时延，从而提高2s投屏成功率。

根据本公开的一些实施例，上述投屏方法可以包括：第一终端的视频会议客户端发送投屏请求到视频会议服务端；接收到所述视频会议服务端反馈的会议信息之后，所述视频会议客户端根据所述会议信息加入与本次视频会议对应的RTC房间，向所述第一终端的RTC客户端发送发布屏幕的指令，向所述第一终端的屏幕采集模块发送开始屏幕采集指令，以使所述屏幕采集模块开始进行屏幕采集；以及在收到来自所述屏幕采集模块的首帧图像之后，向所述RTC客户端发布接收到的首帧图像，以使所述RTC客户端实现所述首帧图像的编码以及向第二终端的传输。

基于上述方法，本公开的实施例提供了一种投屏装置，包括：

投屏请求发送模块，用于发送投屏请求到视频会议服务端；

加入会议模块，用于在接收到所述视频会议服务端反馈的会议信息之后，根据所述会议信息加入与本次视频会议对应的RTC房间；

发布屏幕指令模块，用于向RTC客户端发送发布屏幕的指令；

屏幕采集控制模块，用于向屏幕采集模块发送开始屏幕采集指令，以使所述屏幕采集模块开始进行屏幕采集；以及

首帧发送模块，用于在收到来自所述屏幕采集模块的首帧图像之后，向所述RTC客户端发布所述首帧图像，以使所述RTC客户端实现所述首帧图像的编码以及向第二终端的传输。

此外，本公开的实施例还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述投屏方法。

本公开的实施例还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使计算机执行上述投屏方法。

本公开的实施例还提供了一种计算机程序产品，包括计算机程序指令，当所述计算机程序指令在计算机上运行时，使得计算机执行上述投屏方法。

通过上述投屏方法或者投屏装置，在建立投屏过程中，进行投屏的第一终端在接收到会议信息后，即可开始进行屏幕采集，而无需进行任何等待，从而可以大大压缩第一终端从开始请求投屏到发布首帧图像所用的耗时，从而可以尽可能快速地将采集的首帧图像发送至其他终端，以减少建立投屏过程的时延，也即减少首帧时延，从而有效提高2s投屏成功率。

附图说明

为了更清楚地说明本公开或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1显示了本公开一个实施例所述的用于投屏的系统100的内部结构示意图；

图2显示了现有建立投屏过程的交互示意图；

图3显示了现有在建立投屏的过程中第一终端102内部的具体操作流程；

图4显示了本公开实施例所述的由第一终端102执行的投屏方法的具体实现过程；

图5显示了现有在建立投屏的过程中第二终端104内部的具体操作流程；

图6显示了本公开实施例所述的由第二终端104执行的投屏方法的具体实现过程；

图7显示了本公开一些实施例所述投屏装置的内部结构示意图；以及

图8示出了本公开一些实施例所述的一种更为具体的电子设备硬件结构示意图。

具体实施方式

为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开进一步详细说明。

需要说明的是，除非另外定义，本公开实施例使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本公开实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。

如前所述，如何尽可能地降低投屏过程中的时延是当前需要解决的关键问题之一。为此，本公开的实施例提供一种投屏方法，可以有效降低建立投屏过程的时延。

在描述本公开实施例之前先对本公开实施例的描述中即将出现的部分名词或者术语进行如下简要说明：

1.实时通信(Real-time Communications，RTC)，狭义上一般将RTC称为实时音视频，其典型的应用为直播连麦、实时音视频通话、视频会议、交互式在线教育等等。RTC从功能流程上来说，一般包含音视频采集端(采集、前处理以及编码)、传输端(音视频采集端至服务器、服务器之间、服务器至播放端的传输)、音视频播放端(解码、缓冲以及渲染)等很多环节。投屏也是RTC的一种应用。在投屏业务中，音视频采集端一般是指投屏操作的发起端，音视频播放端一般是指投屏内容的显示端。

2.RTC引擎，是指基于RTC技术建立的音视频引擎，负责进行媒体流的编解码和媒体流传输。在投屏业务中，分别在投屏端和播放端建立的RTC引擎主要负责进行投屏端和播放端屏幕流的编解码和屏幕流传输。

3.首帧时延，也可称为建立投屏过程的时延，通常指从投屏端请求投屏开始直至播放端渲染完成第一个图像帧也就是渲染完成首帧图像的时间间隔。

4.2s投屏成功率，在投屏业务中是指建立投屏过程的时延小于等于2秒的概率，也就是指从投屏端请求投屏开始2秒钟之内投屏内容的播放端完成首帧图像渲染并显示的概率。2s投屏成功率是目前投屏业务投屏体验的重要指标之一。很明显，2s投屏成功率与建立投屏过程的时延有关，其中，建立投屏过程的时延越小，2s投屏成功率就越高。

图1显示了本申请一个实施例所述的用于投屏的系统100的内部结构示意图。如图1所示，上述系统100可以包括：用于采集并提供待投放屏幕流的第一终端102、用于接收待投放屏幕流的第二终端104、用于播放待投放屏幕流的显示设备106、用于在第一终端102以及第二终端104之间建立视频会议的视频会议服务端108以及用于在第一终端102以及第二终端104之间传输屏幕流的RTC服务端110。

其中，上述第一终端102通常可以是计算机或个人电脑(PC)、平板电脑或移动终端等终端设备。上述第二终端104可以是投屏盒子等终端设备。上述显示设备106可以是显示器或者电视机。上述第二终端104和上述显示设备106可以是独立的两个设备，例如，第二终端104和显示设备106可以通过HDMI线缆连接。此外，上述第二终端104和上述显示设备106也可以是集成在一起的一个设备。此外，第一终端102与视频会议服务端108之间、视频会议服务端108与第二终端104之间、第一终端102与RTC服务端110之间以及RTC服务端110与第二终端104之间可以通过网络连接。其中，上述网络可以是局域网也可以是互联网。

图2显示了现有建立投屏过程的交互示意图。如图2所示，现有的建立投屏过程可以包括如下交互过程。

在步骤202，第一终端102发送投屏请求到视频会议服务端108；其中，上述投屏请求中包括投屏码。

在本公开的实施例中，上述投屏码与第二终端104相关联。在实际的应用中，如果投屏系统100中包括多个第二终端104，则每个第二终端104将分别对应一个投屏码。在这种情况下，第一终端102的用户可以在第一终端102上输入或选择某个第二终端104对应的投屏码来确定即将用于接收和处理自身屏幕流的第二终端104。在接收到用户输入或者选择的投屏码之后，第一终端102将发送携带有上述投屏码的投屏请求至与其通过网络连接的视频会议服务端108。

在实际的应用中，第一终端102上可以安装有视频会议客户端。上述视频会议客户端可以为用户提供预约视频会议、参加视频会议、共享屏幕以及投屏等功能。具体地，在启动了安装在第一终端102上的视频会议客户端后，用户可以直接点击其中的会议室投屏选项，以直接选择加入某个视频会议并同时实现投屏。此时，视频会议客户端将在界面上显示一个输入框请用户输入投屏码。在收到用户输入的投屏码之后，视频会议客户端将发送携带有投屏码的投屏请求至视频会议服务端108，以选择加入该投屏码所对应第二终端104所在的视频会议并实现投屏。

此外，为了实现屏幕流的传输，上述第一终端102上还将安装有RTC客户端，例如，在本公开的一些实施例中，上述RTC客户端可以是RTC软件开发工具包(SDK)。上述RTC客户端用于建立RTC引擎以实现屏幕流的编解码和传输。在用户点击视频会议客户端中的会议室投屏选项后，视频会议客户端还将调用RTC客户端提供的初始化RTC引擎的方法来初始化一个RTC引擎。

需要说明的是，相对应的，为了实现屏幕流的传输，上述第二终端104也将安装有相应的视频会议客户端和RTC客户端。

在步骤204，在收到投屏请求之后，视频会议服务端108根据上述投屏请求中的投屏码确定对应的第二终端104，并生成会议信息。

在本公开的实施例中，由于每个投屏码均与一个第二终端104相关联，因此，上述视频会议服务端108可以根据上述投屏请求中的投屏码确定本次投屏请求对应的第二终端104。

在本公开的实施例中，上述会议信息可以包括：会议标识(Meeting ID)、会议的RTC环境属性(Vendor Type)以及参会人信息(包括：参会人标识以及姓名或名称等)。在本公开的另一些实施例中，上述会议信息还可以包括：会议状态信息(例如，结束或者开始)以及会议设置项等等。其中，上述RTC环境属性描述了会议所处的RTC环境，例如，是线上(online)RTC环境还是测试RTC环境。具体地，上述线上RTC环境可以根据具体使用的RTCSDK的不同分成多种，例如，自研RTC环境或者视频会议RTC环境等等；此外，上述测试RTC环境也可包括多种，例如，测试高斯环境或者测试视频会议RTC环境等等。

在步骤206，视频会议服务端108将生成的会议信息分别推送至上述第一终端102和确定的第二终端104。

在步骤208，收到上述会议信息之后，上述第一终端102和上述第二终端104分别根据收到的会议信息加入本次视频会议对应的RTC房间。

在本公开的实施例中，上述第一终端102中的视频会议客户端可以先从上述会议信息中获取会议标识，然后调用RTC客户端提供的加入RTC房间的方法(joinChannel)加入与上述会议标识对应的RTC房间。如前所述，上述第一终端102侧的RTC引擎可以在用户点击视频会议客户端中的会议室投屏选项后就预先初始化完成。具体方法包括：响应于用户点击视频会议客户端中的会议室投屏选项，视频会议客户端调用RTC客户端提供的初始化RTC引擎的方法来初始化一个RTC引擎。

在本公开的实施例中，上述第二终端104中的视频会议客户端则需要先调用自身的RTC客户端提供的初始化RTC引擎的方法来初始化一个RTC引擎；然后，再从上述会议信息中获取会议标识，并调用RTC客户端提供的加入RTC房间的方法加入与上述会议标识对应的RTC房间。可以理解，由于初始化的RTC引擎与会议所处的RTC环境有关，因此，在初始化RTC引擎时，需要将上述RTC环境属性(Vendor Type)提供给RTC客户端，以使RTC客户端可以在相应的RTC环境下初始化RTC引擎。

可见，上述第一终端102和第二终端104将加入同一个RTC房间。需要说明的是，上述描述仅是以一个第二终端104为例进行的说明，如果视频会议中有多个第二终端104，则在上述步骤中，每个第二终端104均将执行上述操作，也就是说，视频会议的所有参与者都将加入到同一个RTC房间内，从而通过RTC服务端实现屏幕流从第一终端102(投屏端)到所有第二终端104(播放端)之间的传输。

在步骤210，第一终端102开始屏幕采集得到屏幕的首帧图像，对上述首帧图像进行编码，并将经过编码得到的数据包发送至RTC服务端110。

在本公开的实施例中，上述数据包通常是实时传输协议(RTP)数据包。

此外，需要说明的是，在执行完上述步骤之后，上述第一终端102还将继续进行屏幕采集、图像编码和数据包发送的操作，直至投屏结束。

在步骤212，上述RTC服务端110将接收的数据包转发至上述第二终端104。

在步骤214，上述第二终端104对接收的数据包进行解码得到上述首帧图像，对上述首帧图像进行渲染，并将渲染后的图像发送至显示设备106。

在步骤216，上述显示设备106显示接收的图像。

可见，上述步骤210至步骤214描述的是第一终端102和第二终端104之间通过RTC服务端110传输屏幕流的情况。这种情况可以认为终端之间的投屏连接状态是点对服务器(P2S)的，也即终端之间的屏幕流是通过RTC服务器110转发的。需要说明的是，本公开的实施例并不限于上述一种投屏连接状态。在另一些实施例中，第一终端102和第二终端104之间还可以先通过RTC服务端110建立直接连接的传输信道，然后再通过直接连接的传输信道传输屏幕流。也就是说，此时屏幕流的传输并不需要RTC服务端110的中转。这种情况可以认为投屏连接状态是端到端(P2P)的。也就是说，在本公开的实施例中，终端之间的投屏连接状态主要包括P2P以及P2S两种。P2P的方式通常适用于第一终端102和第二终端104在同一个局域网的情况下，例如在同一个会议室中的情况。此时，在上述步骤212，第一终端102经过屏幕采集、编码等操作得到数据包后，将直接将数据包通过建立的直接连接的传输信道发送至第二终端104。

至此，第二终端104完成了对第一终端102采集的首帧图像的渲染以及显示。因此，可以看出，建立投屏过程的时延就是完成上述步骤202-214的耗时。

具体地，从上述流程可以看出，在建立投屏的过程中，由第一终端102的操作所造成的时延主要包括：执行上述步骤202至步骤210的耗时。因此，从第一终端102的角度来看，如果可以尽可能减少上述步骤202至步骤210的耗时，也即可以更早更快地将经过编码得到的数据包发送至RTC服务端110或者第二终端104，使得第二终端104可以更早地开始相应的解码和渲染操作，则可以有效减小建立投屏过程的时延，从而提高2s投屏成功率。

图3显示了现有在建立投屏的过程中第一终端102内部的具体操作流程。其中，如前所述，第一终端102内部按照功能划分可以包括视频会议客户端以及RTC客户端。此外，为了实现屏幕采集，第一终端102内部还进一步划分出一个屏幕采集模块。基于上述第一终端102的内部结构，如图3所示，上述在建立投屏的过程中由第一终端102执行的操作包括如下步骤。

在步骤302，视频会议客户端发送投屏请求到视频会议服务端108；其中，上述投屏请求中包括投屏码。

在步骤304，接收到视频会议服务端108反馈的会议信息之后，视频会议客户端根据收到的会议信息加入本次视频会议对应的RTC房间。

在本公开的实施例中，为了便于对RTC客户端进行操作，上述第一终端102中的视频会议客户端还将包括一个RTC客户端控制器。上述RTC客户端控制器主要用于提供RTC客户端之外的部分功能以及提供与RTC客户端交互的能力，进一步简化视频会议客户端的操作。

具体地，在本步骤中，视频会议客户端可以调用RTC客户端控制器提供的加入会议的接口(joinMeeting)，将会议信息中的会议标识传递给RTC客户端控制器。其中，上述加入会议的接口封装了RTC客户端提供的加入RTC房间的方法(joinChannel)。接下来，RTC客户端控制器将调用RTC客户端提供的加入RTC房间的方法加入与上述会议标识对应的RTC房间。

在步骤306，视频会议客户端发送共享屏幕消息到视频会议服务端108，由视频会议服务端标记视频会议客户端当前的状态为共享屏幕状态。

在本公开的实施例中，视频会议服务端在收到视频会议客户端发送共享屏幕消息后将标记对应的视频会议客户端当前的状态，并维护与上述视频会议客户端对应的状态机的流转。

在步骤308，在收到来自视频会议服务端108的状态确认消息后，视频会议客户端向屏幕采集模块发送开始屏幕采集指令，由屏幕采集模块开始进行屏幕采集。

其中，上述状态确认消息可以包含会议标识以及第一终端102的信息，例如也即第一终端102对应的视频会议客户端的标识及名称。

此外，具体地，在本步骤中，视频会议客户端可以调用RTC客户端控制器提供的共享桌面的接口，通过RTC客户端控制器向屏幕采集模块发送开始屏幕采集指令。其中，上述共享桌面的接口封装了向屏幕采集模块发送开始屏幕采集指令的方法、向RTC客户端发送发布屏幕指令的方法以及向RTC客户端发布所采集图像帧的方法。这样，在视频会议客户端调用RTC客户端控制器提供的共享桌面的接口后，RTC客户端控制器将首先向屏幕采集模块发送开始屏幕采集指令。

在步骤310，在收到来自屏幕采集模块的确认消息后，向RTC客户端发送发布屏幕的指令，告知RTC客户端即将开始屏幕流的发布。

如前所述，RTC客户端控制器提供的共享桌面的接口还封装了向RTC客户端发送发布屏幕指令的方法。如此，在收到来自屏幕采集模块的确认消息后，RTC客户端控制器将直接向RTC客户端发送发布屏幕的指令，告知RTC客户端即将开始屏幕流的发布。

在步骤312，在收到来自屏幕采集模块的首帧图像之后，向RTC客户端发布接收到的首帧图像。

如前所述，RTC客户端控制器提供的共享桌面的接口还封装了向RTC客户端发布所采集图像帧的方法。如此，在收到来自屏幕采集模块的首帧图像后，RTC客户端控制器将直接向RTC客户端发布接收到的首帧图像。

接下来，在接收到首帧图像后，将由RTC客户端完成对所采集首帧图像的编码和传输操作。

针对上述图3所示的过程，第一终端102中的视频会议客户端在屏幕采集之前会向视频会议服务端108发送共享屏幕消息，以告知其自身的状态，从而实现服务端对视频会议客户端状态的维护。并且只有在收到视频会议服务端108反馈的状态确认消息之后才开始进行屏幕采集的操作。通过研究可以发现，上述共享屏幕消息及状态确认消息的传输是视频会议流程中不可缺少的操作，可以有效保证视频会议的正常进行。然而，对于建立投屏的过程来讲，上述第一终端102的屏幕采集以及发布过程并不依赖于视频会议服务端108的状态确认消息，也即，即使没有收到视频会议服务端108反馈的状态确认消息，第一终端102也可以开始屏幕采集以及发布。换句话说，是否收到状态确认消息并不会影响建立投屏过程的执行。

基于上述研究结果，本公开的实施例给出了一种投屏方法，该投屏方法由第一终端102实现，可以减少上述建立投屏过程中从请求投屏到发送首帧图像对应数据包的时延，从而减少首帧时延。本公开实施例所述的投屏方法的具体实现过程可以参考图4，包括如下步骤。

在步骤402，视频会议客户端发送投屏请求到视频会议服务端108。

在本公开的实施例中，上述投屏请求中包括投屏码。具体地，上述步骤302的具体实现方法可以参考图2中的步骤202，在此不再重复说明。

在步骤404，接收到视频会议服务端108反馈的会议信息之后，视频会议客户端根据收到的会议信息加入本次视频会议对应的RTC房间，并向RTC客户端发送发布屏幕的指令，告知RTC客户端即将开始屏幕流的发布。

在本公开的实施例中，上述视频会议客户端可以先从上述会议信息中获取会议标识，然后调用RTC客户端控制器提供的开始屏幕采集的接口(StartScreenCast)，将会议信息中的会议标识传递给RTC客户端控制器。其中，开始屏幕采集接口封装了RTC客户端提供的加入RTC房间的方法(joinChannel)以及向RTC客户端发送发布屏幕指令的方法。这样，在视频会议客户端调用RTC客户端控制器提供的开始屏幕采集接口后，将会议信息中的会议标识传递给RTC客户端控制器后，RTC客户端控制器将首先控制RTC客户端加入与会议标识对应的RTC房间，并向RTC客户端发送发布屏幕的指令。其中，RTC客户端控制器可以调用RTC客户端提供的加入RTC房间的方法加入与会议标识对应的RTC房间，以及调用向RTC客户端发送发布屏幕指令的方法向RTC客户端发送发布屏幕的指令。

在步骤406，接收到视频会议服务端108反馈的会议信息之后，视频会议客户端向屏幕采集模块发送开始屏幕采集指令，以使屏幕采集模块开始进行屏幕采集。

具体地，在本步骤中，视频会议客户端可以调用RTC客户端控制器向屏幕采集模块发送开始屏幕采集指令。具体地，视频会议客户端可以调用RTC客户端控制器提供的共享采集桌面的接口(ShareDestop(ScreenCast))向屏幕采集模块发送开始屏幕采集指令。其中，上述共享采集桌面的接口封装了向屏幕采集模块发送开始屏幕采集指令的方法以及在收到所采集的图像帧后向RTC客户端发布图像帧的方法。这样，在视频会议客户端调用RTC客户端控制器提供的共享采集桌面的接口后，RTC客户端控制器将首先向屏幕采集模块发送开始屏幕采集指令。

需要说明的是，上述步骤标号并用于限制步骤的执行顺序，也即上述步骤404和步骤406可以按照任意顺序执行，或者上述步骤404和步骤406也可以是并行执行的。

在步骤408，在收到来自屏幕采集模块的首帧图像之后，向RTC客户端发布接收到的首帧图像。

如前所述，RTC客户端控制器提供的共享桌面的接口还封装了向RTC客户端发布所采集图像帧的方法。如此，在收到来自屏幕采集模块的首帧图像后，RTC客户端控制器将直接向RTC客户端发布接收到的首帧图像。

接下来，在接收到首帧图像后，将由RTC客户端完成对所采集首帧图像的编码和传输操作。

需要说明的是，在本公开的实施例中，视频会议客户端接收到会议信息后仍可以在上述流程的任意时刻发送共享屏幕消息到视频会议服务端108，由视频会议服务端标记视频会议客户端当前的状态为共享屏幕状态。但是上述建立投屏的过程与上述共享屏幕消息的发送以及状态确认消息的接收并无依赖关系。

可以看出，在本公开的实施例中，视频会议客户端在接收到会议信息后，即可开始进行屏幕采集，而无需进行任何等待，从而可以大大压缩第一终端102从开始请求投屏到发布首帧图像所用的耗时，从而可以尽可能快速地将采集的首帧图像发送至第二终端104，以减少建立投屏过程的总时延，也即减少首帧时延，提高2s投屏成功率。

进一步，从上述图2所示的流程可以看出，在建立投屏的过程中，由第二终端104的操作所造成的时延主要包括：执行上述步骤208以及执行上述步骤214的耗时，也即建立RTC引擎过程的耗时、等待首个数据包(简称为首包)以及接收到首包后处理过程的耗时。因此，从第二终端104的角度来看，如果可以尽可能减少上述步骤208或步骤214的耗时即可以减小建立投屏过程的时延，从而提高2s投屏成功率。

图5显示了现有在建立投屏的过程中第二终端104内部的具体操作流程。其中，如前所述，第二终端104内部按照功能划分可以包括视频会议客户端以及RTC客户端。

在步骤502，视频会议客户端在从视频会议服务端108收到会议信息后，调用RTC客户端提供的初始化RTC引擎的方法，初始化一个RTC引擎。

在步骤504，在RTC引擎初始化完成后，视频会议客户端调用RTC客户端提供的配置会议设置项方法(preJoinConfig)进行会议设置项的设置。

在步骤506，视频会议客户端调用RTC客户端提供的加入RTC房间的方法(joinChannel)加入与会议信息中会议标识对应的RTC房间。

在步骤508，在接收到来自第二终端104的数据包后，RTC客户端进行数据包的解码操作，得到首帧。

在步骤510，RTC客户端将上述首帧返回给视频会议客户端。

在步骤512，视频会议客户端对首帧进行渲染，得到可以显示在显示设备上的图像。

更进一步，上述方法在视频会议结束时还可以进一步包括如下步骤：

在步骤514，在接收到来自视频服务器的携带有会议标识的离会信息后，视频会议客户端调用RTC客户端提供的退出RTC房间的方法(leaveChannel)，退出与上述离会信息中会议标识对应的RTC房间。

在步骤516，视频会议客户端调用RTC客户端提供的重置RTC引擎的方法(reset)重置本次投屏过程所使用的RTC引擎。

针对上述图5所示的过程，在研发过程中发现，每次初始化RTC引擎都需要一些固定的耗时，而且在上述建立投屏过程中只有在RTC引擎初始化完成后，第二终端104才能成功加入与上述会议信息中会议标识对应的RTC房间，这无疑会增加建立投屏过程的时延。

基于此，本公开的实施例给出了一种投屏方法，该投屏方法由第二终端104实现，可以减少上述投屏过程的时延。本公开实施例所述的投屏方法的具体实现过程可以参考图6，包括如下步骤：

在步骤602，在从视频会议服务端108收到会议信息后，第二终端104确定所接收会议信息中的RTC环境属性与缓存中记录的RTC环境属性是否一致。

在本公开的实施例中，上述缓存中记录的RTC环境属性通常为上一次视频会议所使用RTC引擎对应的RTC环境属性。

在步骤604，响应于确定所接收会议信息中的RTC环境属性与缓存中记录的RTC环境属性一致，第二终端104根据会议信息进行会议设置项的设置。

具体而言，第二终端104中的视频会议客户端可以调用RTC客户端提供的配置会议设置项方法进行会议设置项的设置。如前所述，在本公开的实施例中，上述配置会议设置项包括设置RTC房间属性以及解码模式等等。

在步骤606，第二终端104加入与会议信息中会议标识对应的RTC房间。

具体而言，第二终端104中的视频会议客户端可以调用RTC客户端提供的加入RTC房间的方法加入与会议信息中会议标识对应的RTC房间。

在步骤608，在接收到来自第一终端102的数据包后，第二终端104进行数据包的解码以及渲染操作，得到可以显示在显示设备上的图像。

在本公开的另一些实施例中，上述方法在视频会议结束时还可以进一步包括如下步骤：

在步骤610，在接收到来自视频服务器的携带有会议标识的离会信息后，第二终端104退出与上述离会信息中会议标识对应的RTC房间。

在本公开的实施例中，由于在上述方法中建立的RTC引擎是复用的，因此在接收到来自视频服务器的携带有会议标识的离会信息后，第二终端104无需重置本次投屏过程所使用的RTC引擎。

可见，上述的建立投屏过程，可以在确定所接收会议信息中的RTC环境属性与缓存中记录的RTC环境属性一致的情况下，直接复用已经建立的RTC引擎。从而，可以极大地降低建立投屏过程的时延，从而提高2s投屏成功率。

进一步地，如果确定所接收会议信息中的RTC环境属性与缓存中记录的RTC环境属性不一致，还可以采用多种方法来建立适合的RTC引擎。

在本公开的一些实施例中，在所接收会议信息中的RTC环境属性与缓存中记录的RTC环境属性不一致时，第二终端104可以首先重置RTC引擎；然后，初始化新的RTC引擎，并进行会议设置项的设置；接下来，再继续执行上述步骤606及后续操作。

具体地，在上述实施例中，第二终端104中的视频会议客户端先调用RTC客户端提供的重置RTC引擎的方法重置上一次投屏过程所使用的RTC引擎。

在本公开的另一些实施例中，RTC客户端可以支持在RTC引擎创建后再去设置RTC环境属性的处理。在这种情况下，在确定所接收会议信息中的RTC环境属性与缓存中记录的RTC环境属性不一致时，第二终端104将首先依据会议信息种的RTC环境属性对当前RTC引擎所对应的RTC环境属性进行设置；然后，进行会议设置项的设置；接下来，再继续执行上述步骤606及后续操作。

具体地，在上述实施例中，第二终端104中的视频会议客户端可以调用RTC客户端提供的引擎建立后设置RTC环境属性的方法(setVendorTypeAfterCreatEngine)，根据所接收会议信息中的RTC环境属性对当前RTC引擎所对应的RTC环境属性进行设置。

由此可见，在上述实施例提供的方法中，即使所接收会议信息中的RTC环境属性与缓存中记录的RTC环境属性不一致，第二终端104也可以通修改当前RTC引擎的RTC环境属性，而无需重新初始化一个新的RTC引擎。从而，可以极大地降低建立投屏过程的时延。

需要说明的是，上述实施例所述的方法适用于已经创建过RTC引擎的情况，而当第二终端104第一次入会时，则仍需要初始化一个RTC引擎。

在本公开的实施例中，可以在第二终端104中设置一个引擎初始化计数变量来记录初始化RTC引擎的次数，且每初始化一次RTC引擎则将该引擎初始化计数器变量值加1。如此，上述方法中，第二终端104在从视频会议服务端108收到会议信息后，上述方法可以进一步包括：确定引擎初始化计数器变量的值是否为预先设置的初始值，响应于确定引擎初始化计数器变量的值不等于预先设置的初始值，继续执行上述步骤602中确定所接收会议信息中的RTC环境属性与缓存中记录的RTC环境属性是否一致的步骤及其后续步骤；而响应于确定引擎初始化计数器变量的值等于预先设置的初始值，第二终端104先初始化RTC引擎，再根据所接收会议信息进行会议设置项的设置。然后，再继续执行上述步骤606及后续操作。

更进一步，由于在上述方法中，在接收到来自视频服务器的携带有会议标识的离会信息后，第二终端104并没有重置本次投屏过程所使用的RTC引擎，因此，本次投屏过程对应的投屏连接状态是保留在RTC引擎中的。如前所述，在本公开的实施例中投屏连接状态主要包括P2P以及P2S两种。为了确保下一次投屏的成功率，则在上述步骤614之后，上述方法还应当包括：响应于确定本次RTC引擎的投屏连接状态为P2P，请求RTC服务端将其重置为P2S。

由此可见，在上述的建立投屏过程中，第二终端104可以复用已经建立的RTC引擎，从而降低建立投屏过程的时延，提高2s投屏成功率。

需要说明的是，上述对本公开的一些实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于上述实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

对应上述方法，本公开的实施例还公开了一种投屏装置，也即上述第一终端102或者也可称为投屏盒子。图7显示了本公开实施例所述的投屏装置的内部结构。如图7所示，该投屏装置可以包括：

投屏请求发送模块702，用于发送投屏请求到视频会议服务端；

加入会议模块704，用于在接收到所述视频会议服务端反馈的会议信息之后，根据所述会议信息加入与本次视频会议对应的RTC房间；

发布屏幕指令模块706，用于向RTC客户端发送发布屏幕的指令；

屏幕采集控制模块708，用于向屏幕采集模块发送开始屏幕采集指令，以使所述屏幕采集模块开始进行屏幕采集；以及

首帧发送模块710，用于在收到来自所述屏幕采集模块的首帧图像之后，向所述RTC客户端发布所述首帧图像，以使所述RTC客户端实现所述首帧图像的编码以及向第二终端的传输。

上述各个模块的具体实现可以参考前述方法以及附图，在此不再重复说明。为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本公开时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

上述实施例的装置用于实现前述任一实施例中相应的投屏方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例方法相对应的，本公开还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上任意一实施例所述的投屏方法。

图8示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图，该设备可以包括：处理器2010、存储器2020、输入/输出接口2030、通信接口2040和总线2050。其中处理器2010、存储器2020、输入/输出接口2030和通信接口2040通过总线2050实现彼此之间在设备内部的通信连接。

处理器2010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器2020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器2020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器2020中，并由处理器2010来调用执行。

输入/输出接口2030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口2040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线2050包括一通路，在设备的各个组件(例如处理器2010、存储器2020、输入/输出接口2030和通信接口2040)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器2010、存储器2020、输入/输出接口2030、通信接口2040以及总线2050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

上述实施例的电子设备用于实现前述任一实施例中相应的投屏方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例方法相对应的，本公开还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上任一实施例所述的投屏方法。

本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

上述实施例的存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的任务处理方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本公开的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本公开实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。

另外，为简化说明和讨论，并且为了不会使本公开实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本公开实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本公开实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本公开的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本公开实施例。因此，这些描述应被认为是说明性的而不是限制性的。

尽管已经结合了本公开的具体实施例对本公开进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态RAM(DRAM))可以使用所讨论的实施例。

本公开实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本公开实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (14)

1.一种投屏方法，包括：

第一终端的视频会议客户端发送投屏请求到视频会议服务端；

接收到所述视频会议服务端反馈的会议信息之后，所述视频会议客户端根据所述会议信息加入与本次视频会议对应的RTC房间，向所述第一终端的RTC客户端发送发布屏幕的指令，向所述第一终端的屏幕采集模块发送开始屏幕采集指令，以使所述屏幕采集模块开始进行屏幕采集；以及

在收到来自所述屏幕采集模块的首帧图像之后，向所述RTC客户端发布接收到的首帧图像，以使所述RTC客户端实现所述首帧图像的编码以及向第二终端的传输。

2.根据权利要求1所述的方法，其中，所述视频会议客户端根据所述会议信息加入与本次视频会议对应的RTC房间，向第一终端的RTC客户端发送发布屏幕的指令包括：

所述视频会议客户端从所述会议信息中获取会议标识；

所述视频会议客户端将会议信息中的会议标识传递给RTC客户端控制器，以使所述RTC客户端控制器控制所述RTC客户端加入与所述会议标识对应的RTC房间，以及向RTC客户端发送发布屏幕的指令。

3.根据权利要求1所述的方法，其中，所述向所述第一终端的屏幕采集模块发送开始屏幕采集指令包括：所述视频会议客户端将会议信息中的会议标识传递给RTC客户端控制器，以使所述RTC客户端控制器向屏幕采集模块发送开始屏幕采集指令。

4.根据权利要求3所述的方法，其中，所述向所述RTC客户端发布接收到的首帧图像包括：所述RTC客户端控制器在收到来自所述屏幕采集模块的首帧图像后，向所述RTC客户端发布接收到的首帧图像。

5.根据权利要求1所述的方法，进一步包括：

所述第二终端从视频会议服务端收到会议信息后，确定所述会议信息中的实时通信RTC环境属性与缓存中记录的RTC环境属性是否一致；

响应于确定所述会议信息中的RTC环境属性与缓存中记录的RTC环境属性一致，所述第二终端根据所述会议信息进行会议设置项的设置；

所述第二终端加入与会议信息中会议标识对应的RTC房间；以及

在接收到来自第一终端的数据包后，所述第二终端进行数据包的解码以及渲染操作，得到可以显示在显示设备上的图像。

6.根据权利要求5所述的投屏方法，在所述加入与会议信息中会议标识对应的RTC房间之前，所述方法进一步包括：

响应于确定所述会议信息中的RTC环境属性与缓存中记录的RTC环境属性不一致，所述第二终端重置RTC引擎；初始化新的RTC引擎；以及根据所述会议信息进行会议设置项的设置。

7.根据权利要求5所述的投屏方法，在所述加入与会议信息中会议标识对应的RTC房间之前，所述方法进一步包括：

响应于确定所述会议信息中的RTC环境属性与缓存中记录的RTC环境属性不一致，所述第二终端对当前RTC引擎所对应的RTC环境属性进行设置；以及根据所述会议信息进行会议设置项的设置。

8.根据权利要求4所述的投屏方法，进一步包括：

从视频会议服务端收到会议信息后，所述第二终端确定是否为第一次入会；

响应于确定是第一次入会，所述第二终端初始化新的RTC引擎，根据所述会议信息进行会议设置项的设置，并继续执行所述加入与会议信息中会议标识对应的RTC房间的步骤；以及

响应于确定不是第一次入会，所述第二终端执行所述确定所述会议信息中的实时通信RTC环境属性与缓存中记录的RTC环境属性是否一致的步骤。

9.根据权利要求8所述的投屏方法，其中，所述确定是否为第一次入会包括：确定引擎初始化计数器变量的值是否为预先设定的初始值，如果是预先设定的初始值，则确定为第一次入会；否则，确定为不是第一次入会。

10.根据权利要求5所述的投屏方法，进一步包括：在接收到来自视频服务器的携带有会议标识的离会信息后，所述第二终端退出与所述离会信息中会议标识对应的RTC房间，而不重置RTC引擎。

11.一种投屏装置，包括：

投屏请求发送模块，用于发送投屏请求到视频会议服务端；

加入会议模块，用于在接收到所述视频会议服务端反馈的会议信息之后，根据所述会议信息加入与本次视频会议对应的RTC房间；

发布屏幕指令模块，用于向RTC客户端发送发布屏幕的指令；

屏幕采集控制模块，用于向屏幕采集模块发送开始屏幕采集指令，以使所述屏幕采集模块开始进行屏幕采集；以及

首帧发送模块，用于在收到来自所述屏幕采集模块的首帧图像之后，向所述RTC客户端发布所述首帧图像，以使所述RTC客户端实现所述首帧图像的编码以及向第二终端的传输。

12.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如权利要求1-10中任意一项所述的投屏方法。

13.一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使计算机执行权利要求1-10中任意一项所述的投屏方法。

14.一种计算机程序产品，包括计算机程序指令，当所述计算机程序指令在计算机上运行时，使得计算机执行如权利要求1-10中任意一项所述的投屏方法。

Images