CN115484468B - 一种连麦系统、方法、装置、设备及存储介质 - Google Patents

Abstract

本公开实施例提供了一种连麦系统、方法、装置、设备及存储介质，所述系统包括：第一连麦端、第二连麦端和连麦业务服务端；第一连麦端通过连麦业务服务端向第二连麦端发送连麦申请请求后，第二连麦端在接收到针对连麦申请请求的接受连麦操作时，向连麦业务服务端发送接受连麦消息，并同时向实时协作RTC服务端申请加入连麦房间。由于第二连麦端在接收到针对连麦申请请求的接受连麦操作时，提前了向连麦业务服务端发送接受连麦消息以及向实时协作RTC服务端申请加入连麦房间的时机，从而缩短了接收连麦的第二连麦端从接受连麦操作至接收到第一连麦端的首帧画面的耗时，提高了连麦的效率，也提升了接受连麦的第二连麦端用户的连麦体验。

Description

一种连麦系统、方法、装置、设备及存储介质

技术领域

本公开涉及数据处理领域，尤其涉及一种连麦系统、方法、装置、设备及存储介质。

背景技术

在网络直播功能中，连麦已经成为一种常见的直播形式。通常，连麦是指主播之间或者主播和嘉宾之间以类似视频电话的方式，实现实时通信互动。

连麦的建联耗时是影响参与连麦用户体验的重要因素之一，例如，在嘉宾端向主播端申请连麦的场景下，对于主播端用户而言，在点击同意嘉宾连麦申请之后，期待能够尽快在主播端显示嘉宾端的音视频数据。

因此，如何减少连麦的建联耗时，提升连麦效率，是目前亟需解决的技术问题。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种连麦系统、方法、装置、设备及存储介质，能够减少连麦的建联耗时，提升连麦效率，进而提升用户的连麦体验。

第一方面，本公开提供了一种连麦系统，所述系统包括第一连麦端、第二连麦端和连麦业务服务端；

所述第一连麦端，用于通过所述连麦业务服务端向所述第二连麦端发送连麦申请请求；

所述第二连麦端，用于在接收到针对所述连麦申请请求的接受连麦操作时，向所述连麦业务服务端发送接受连麦消息，并向实时协作RTC服务端申请加入连麦房间。

一种可选的实施方式中，所述第一连麦端，还用于在接收到来自所述连麦业务服务端的所述接受连麦消息时，向所述RTC服务端申请加入连麦房间。

一种可选的实施方式中，所述第二连麦端，还用于在接收到针对所述连麦申请请求的接受连麦操作时，展示倒计时窗口。

一种可选的实施方式中，所述第二连麦端，还用于在确定所述倒计时窗口的倒计时结束时，确定是否已接收到所述第一连麦端推送的音视频流，如果确定未接收到所述音视频流，则向所述连麦业务服务端和所述RTC服务端分别发送断开连麦链接请求。

一种可选的实施方式中，所述第一连麦端，还用于在接收到来自所述连麦业务服务端的所述接受连麦消息时，展示倒计时窗口。

一种可选的实施方式中，所述第一连麦端，还用于在确定所述倒计时窗口的倒计时结束时，向所述RTC服务端推送音视频流。

一种可选的实施方式中，所述第一连麦端包括嘉宾客户端，所述第二连麦端包括主播客户端。

第二方面，本公开提供了一种连麦方法，所述方法包括：

第二连麦端通过连麦业务服务端接收来自第一连麦端的连麦申请请求；

所述第二连麦端在接收到针对所述连麦申请请求的接受连麦操作时，向所述连麦业务服务端发送接受连麦消息，并向实时协作RTC服务端申请加入连麦房间。

一种可选的实施方式中，所述方法还包括：所述第二连麦端在接收到针对所述连麦申请请求的接受连麦操作时，展示倒计时窗口。

一种可选的实施方式中，所述方法还包括：所述第二连麦端在确定所述倒计时窗口的倒计时结束时，确定是否已接收到所述第一连麦端推送的音视频流，如果确定未接收到所述音视频流，则向所述连麦业务服务端和所述RTC服务端分别发送断开连麦链接请求。

第三方面，本公开提供了一种连麦方法，所述方法包括：

第一连麦端通过连麦业务服务端向第二连麦端发送连麦申请请求；其中，所述第二连麦端用于在接收到针对所述连麦申请请求的连麦接受操作时，向所述连麦业务服务端发送接受连麦消息，并向实时协作RTC服务端申请加入连麦房间；

所述第一连麦端从所述连麦业务服务端接收到所述接受连麦消息时，向所述RTC服务端申请加入连麦房间。

一种可选的实施方式中，所述方法还包括：所述第一连麦端从所述连麦业务服务端接收到所述接受连麦消息时，展示倒计时窗口。

一种可选的实施方式中，所述方法还包括：所述第一连麦端在确定所述倒计时窗口的倒计时结束时，向所述RTC服务端推送音视频流。

第四方面，本公开提供了一种连麦装置，所述装置包括：

接收模块，用于第二连麦端通过连麦业务服务端接收来自第一连麦端的连麦申请请求；

第一申请模块，用于所述第二连麦端在接收到针对所述连麦申请请求的接受连麦操作时，向所述连麦业务服务端发送接受连麦消息，并向实时协作RTC服务端申请加入连麦房间。

第五方面，本公开提供了一种连麦装置，所述装置包括：

发送模块，用于第一连麦端通过连麦业务服务端向第二连麦端发送连麦申请请求；其中，所述第二连麦端用于在接收到针对所述连麦申请请求的连麦接受操作时，向所述连麦业务服务端发送接受连麦消息，并向实时协作RTC服务端申请加入连麦房间；

第二申请模块，用于所述第一连麦端从所述连麦业务服务端接收到所述接受连麦消息时，向所述RTC服务端申请加入连麦房间。

第六方面，本公开提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在计算机设备上运行时，使得所述计算机设备实现上述的方法。

第七方面，本公开提供了一种设备，包括：存储器，处理器，及存储在所述存储器上的计算机程序，所述处理器执行所述计算机程序时，实现上述的方法。

第八方面，本公开提供了一种计算机程序产品，所述计算机程序产品包括计算机程序/指令，所述计算机程序/指令被处理器执行时实现上述的方法。

本公开实施例提供的技术方案与现有技术相比具有如下优点：

本公开实施例提供了一种连麦系统，所述系统包括第一连麦端、第二连麦端和连麦业务服务端；第一连麦端通过连麦业务服务端向第二连麦端发送连麦申请请求后，第二连麦端在接收到针对连麦申请请求的接受连麦操作时，向连麦业务服务端发送接受连麦消息，并同时向实时协作RTC服务端申请加入连麦房间。由于第二连麦端在接收到针对连麦申请请求的接受连麦操作时，提前了向连麦业务服务端发送接受连麦消息以及向实时协作RTC服务端申请加入连麦房间的时机，从而缩短了接受连麦的第二连麦端从接受连麦操作至接收到来自第一连麦端的首帧画面的耗时，提高了连麦的效率，也提升了接受连麦的第二连麦端用户的连麦体验。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

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

图1为目前的网络直播中的连麦方式的数据交互示意图；

图2为本公开实施例提供的一种嘉宾端向主播端申请连麦的信令交互图；

图3为本公开实施例提供的一种连麦系统的结构示意图；

图4为本公开实施例提供的一种连麦方法流程示意图；

图5为本公开实施例提供的另一种连麦方法流程示意图；

图6为本公开实施例提供的一种连麦装置的结构示意图；

图7为本公开实施例提供的另一种连麦装置的结构示意图；

图8为本公开实施例提供的一种连麦设备的结构示意图。

具体实施方式

为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。

在网络直播过程中，主播之间或者主播和嘉宾之间经常以类似视频电话的方式，实现实时通信互动，也被称作连麦。

目前，网络直播的连麦方式中，连麦两端的建联首帧耗时较长，影响用户的连麦体验。以主播与嘉宾之间的连麦为例，如图1所示，为目前的网络直播的连麦方式中的数据交互示意图。

其中，嘉宾端通过连麦业务服务端向主播端发送连麦申请请求，用于向主播端申请连麦，假设主播端用户针对来自嘉宾端的连麦申请请求触发接受连麦操作，则主播端向连麦业务服务端发送Join_channel请求，用于向连麦业务服务端请求加入连麦房间。如果主播端接收到连麦业务服务端的Join_channel返回消息，则主播端可以向实时协作(Real-Time Communications；RTC)服务端申请加入连麦房间，当接收到RTC服务端返回的成功加入连麦房间的通知消息后，主播端再向连麦业务服务端发送接受连麦消息(permit)，以通知连麦业务服务端已接受连麦申请。连麦业务服务端向嘉宾端转发permit消息，此时嘉宾端才获知主播端接受连麦申请。

事实上，主播端在接收到针对连麦申请请求的接受连麦操作后，首先向连麦业务服务端发送Join_channel请求，并在接收到连麦业务服务端返回的Join_channel返回消息后，向RTC服务端申请加入连麦房间，并在成功加入连麦房间后，才能够向连麦业务服务端发送permit消息，用于将对端已接受连麦申请的消息通知申请连麦的嘉宾端。此时，嘉宾端开始向RTC服务端申请加入连麦房间，并在成功加入连麦房间后，开始向RTC服务端推送音视频流。

在嘉宾端接收到主播端接受连麦申请的消息之后，嘉宾端向连麦业务服务端发送Join_channel请求，用于向连麦业务服务端请求同意其加入连麦房间。在嘉宾端接收到连麦业务服务端的Join_channel返回消息之后，嘉宾端可以向RTC服务端申请加入连麦房间，当接收到RTC服务端返回的成功加入连麦房间的通知消息后，开始向RTC服务端推送音视频流。

综上可知，接受连麦的第二连麦端从接受连麦操作至接收到第一连麦端的首帧画面的耗时是影响连麦效率的因素之一，发起连麦申请的第一连麦端从接收到第二连麦端的接受连麦消息到接收到对端的首帧画面的耗时也是影响连麦效率的因素之一。因此，发明人基于此提出了对连麦的优化方案。

如图2所示，为本公开实施例提供的一种嘉宾端向主播端申请连麦的信令交互图，其中，主播端接收到针对连麦申请请求的接受连麦操作时，向连麦业务服务端发送Join_channel请求，并向连麦业务服务端发送接受连麦消息(permit)，以及向实时协作RTC服务端申请加入连麦房间，而无需等待连麦业务服务端返回Join_channel返回消息后才向RTC服务端申请加入连麦房间。

由于主播端提前了向RTC服务端申请加入连麦房间的时机，即在接收到接受连麦操作时即可向RTC服务端申请加入连麦房间，从而使得主播端能够提前进入连麦房间。另外，由于主播端提前了向连麦业务服务端发送接受连麦消息的时机，即在接收到接受连麦操作时即可向连麦业务服务端发送permit消息，使得嘉宾端能够提前接收到由连麦业务服务端转发的permit消息，从而嘉宾端能够提前向RTC服务端申请加入连麦房间，并提前开始向RTC服务端推送音视频流，进而主播端能够提前拉取到嘉宾端的音视频流，并提前开启合流，因此，本公开实施例缩短了主播端从接受连麦操作至接收到嘉宾端的首帧画面的耗时，提高了连麦效率，也提升了主播端用户的连麦体验。

另外，由于主播端提前了向连麦业务服务端发送接受连麦消息(permit)的时机，使得嘉宾端能够提前接收到由连麦业务服务端向嘉宾端转发的permit消息，即嘉宾端能够提前接收到主播端接受连麦申请的消息，嘉宾端在接收到permit消息后，无需等待连麦业务服务端针对已发送的Join_channel请求的返回消息，即可向RTC服务端申请加入连麦房间，提前拉取到对端的音视频流，从而缩短了嘉宾端的连麦首帧耗时，提高了连麦效率，也提升了嘉宾端用户的连麦体验。

基于此，本公开实施例提供了一种连麦系统，参考图3，为本公开实施例提供的一种连麦系统的结构示意图，其中，连麦系统包括第一连麦端301、第二连麦端302和连麦业务服务端303。

所述第一连麦端301，用于通过所述连麦业务服务端向所述第二连麦端发送连麦申请请求。

本公开实施例中，连麦业务服务端分别与第一连麦端以及第二连麦端通信连接，第一连麦端通过连麦业务服务端向第二连麦端发送连麦申请请求，第二连麦端通过连麦业务服务端接受来自第一连麦端的连麦申请请求。其中，连麦申请请求用于请求第二连麦端接受第一连麦端的连麦申请。

实际应用中，第一连麦端向连麦业务服务端发送连麦申请请求，以请求第二连麦端接受连麦申请，连麦业务服务端在接收到连麦申请请求后，向第一连麦端返回响应消息，用于通知第一连麦端针对该连麦申请请求已接收成功。

一种可选的实施方式中，第一连麦端包括嘉宾客户端，第二连麦端包括主播客户端。嘉宾客户端通过连麦业务服务端向主播客户端发送连麦申请请求，主播客户端通过连麦业务服务端接受来自嘉宾客户端的连麦申请请求。

所述第二连麦端302，用于在接收到针对所述连麦申请请求的接受连麦操作时，向所述连麦业务服务端发送接受连麦消息，并向实时协作RTC服务端申请加入连麦房间。

本公开实施例中，接受连麦消息，用于通知连麦业务服务端第二连麦端已接受第一连麦端的连麦申请。

本公开实施例中，第一连麦端向连麦业务服务端发送连麦申请请求后，连麦业务服务端针对该连麦申请请求发送返回消息，以通知连麦申请请求被成功接收。连麦业务服务端向第二连麦端转发该连麦申请请求，在第二连麦端接收到针对该连麦申请请求的接受连麦操作时，第二连麦端向连麦业务服务端发送接受连麦消息，同时向实时协作RTC服务端申请加入连麦房间。例如，第二连麦端在接收到针对第一连麦端发送的连麦申请请求的接受连麦操作时，第二连麦端向连麦业务服务端发送permit消息，以通知连麦业务服务端已接受来自第一连麦端的连麦申请，同时向RTC服务端发送rtc_join_channel消息，以向RTC服务端申请加入连麦房间。

本公开实施例中，当第二连麦端接收到连麦业务服务端转发的来自第一连麦端的连麦申请请求时，可以通过任意一种方式触发针对连麦申请请求的接受连麦操作，例如，第二连麦端用户用于连麦的设备(如手机、电脑、平板电脑等)屏幕上弹出提示信息(如“XXX正在请求连麦，是否同意”)，如果第二连麦端用户点击“同意”，则此时第二连麦端接收到针对该连麦申请请求的接受连麦操作；等等。

一种可选的实施方式中，在第二连麦端接收到针对该连麦申请请求的接受连麦操作时，可以并行处理向连麦业务服务端发送接受连麦消息，即第二连麦端提前了向连麦业务服务端发送接受连麦消息的时机，使得第一连麦端能够提前接收到来自第二连麦端的接受连麦消息，也就是说，缩短了第一连麦端用户知悉对端用户是否同意连麦申请请求的耗时。

另外，第二连麦端在接收到针对连麦申请请求的接受连麦操作时，无需等待连麦业务服务端针对Join_channel消息的返回消息，即可向实时协作RTC服务端申请加入连麦房间，即提前了申请加入连麦房间的时机，缩短了第二连麦端的用户从接受连麦申请至收到第一连麦端的首帧画面的耗时，提高了连麦效率，提升了接受连麦申请方的连麦体验。

本公开实施例中，当实时协作RTC服务端向第二连麦端返回申请加入连麦房间成功消息后，第二连麦端向实时协作RTC服务端推送音视频流。当第一连麦端接收到连麦业务服务端转发的来自第二连麦端的接受连麦消息时，开始执行后续的RTC进房流程以及推送音视频流，直到收到对端首帧画面，实现第一连麦端与第二连麦端之间的连麦。

本公开实施例提供的连麦系统中，第一连麦端通过连麦业务服务端向第二连麦端发送连麦申请请求后，第二连麦端在接收到针对连麦申请请求的接受连麦操作时，向连麦业务服务端发送接受连麦消息，并同时向实时协作RTC服务端申请加入连麦房间。由于第二连麦端在接收到针对连麦申请请求的接受连麦操作时，提前了向连麦业务服务端发送接受连麦消息以及向实时协作RTC服务端申请加入连麦房间的时机，从而缩短了接受连麦的第二连麦端从接受连麦操作至接收到第一连麦端的首帧画面的耗时，提高了连麦的效率，也提升了接受连麦的第二连麦端用户的连麦体验。

如图1所示，主播端(即第二连麦端)在同意来自嘉宾端(即第一连麦端)的连麦申请请求后，首先向连麦业务服务端发送Join_channel请求，并在接收到连麦业务服务端返回的Join_channel返回消息后，向RTC服务端申请加入连麦房间，在成功加入连麦房间后，主播端向RTC服务端推送音视频流，并向连麦业务服务端发送permit消息，用于将对端已接受连麦申请的消息通知申请连麦的嘉宾端。此时，嘉宾端开始向RTC服务端申请加入连麦房间，并在成功加入连麦房间后，开始向RTC服务端推送音视频流。此时，主播端拉取到嘉宾端的音视频流，并开启合流。

如图1所示，在主播端接收到嘉宾端的首帧后，还需要再等待5秒倒计时时间，才能移除倒计时蒙层，真正实现双方的连麦。因此，导致主播端即使接收到嘉宾端的首帧画面，仍然需要多等待一段时间才能真正实现连麦，降低了连麦的效率，也降低了用户的连麦体验。

为了提升连麦效率，可以将第二连麦端展示倒计时窗口的时机提前，以减少连麦双方不必要的等待时间。

一种可选的实施方式中，第二连麦端还用于在接收到针对连麦申请请求的接受连麦操作时，展示倒计时窗口。

本公开实施例中，第二连麦端在接收到针对连麦申请请求的接受连麦操作时，可以展示倒计时窗口，也就是说，当第二连麦端接收到针对连麦申请请求的接受连麦操作时，第二连麦端的用户显示界面上开始显示倒计时窗口蒙层，并在该倒计时结束时，可以开始渲染对端的首帧画面。本公开实施例通过提前倒计时的时机，缩短首帧耗时，提升了连麦效率，从而提高了第二连麦端用户的连麦体验。

主播端接收到嘉宾端的首帧画面后，不仅主播端需要显示倒计时窗口，嘉宾端也需要显示倒计时窗口。如图1所示，嘉宾端(即第一连麦端)在接收到来自连麦业务服务端转发的接受连麦消息(permit)后，向连麦业务服务端发送Join_channel请求后，连麦业务服务端针对该Join_channel请求发送Join_channel返回消息，以通知嘉宾端是否同意加入连麦房间。然后，嘉宾端向RTC服务端申请加入连麦房间，在RTC服务端返回成功加入连麦房间的通知消息后，嘉宾端向RTC服务端推送音视频流，在主播端拉取到嘉宾端(即第二连麦端)的音视频流后，开启合流。在主播端接收到嘉宾端的首帧后，还需要再等待5秒倒计时时间，才能移除倒计时蒙层，真正实现双方的连麦。也就是说，嘉宾端即使已经接收到主播端的首帧画面，仍然需要再等待一段时间才能移除倒计时蒙层，真正和主播端实现连麦，使得连麦效率降低，并且嘉宾端用户的连麦体验感也不好。因此，为了提高连麦效率，可以将第一连麦端展示倒计时窗口的时机提前，以减少连麦双方不必要的等待时间。

一种可选的实施方式中，第一连麦端还用于在接收到来自连麦业务服务端的接受连麦消息时，展示倒计时窗口。

本公开实施例中，第一连麦端在接收到来自连麦业务服务端转发的接受连麦消息后，直接展示倒计时窗口，即此时第一连麦端的显示屏幕上显示倒计时窗口蒙层。如图2所示，嘉宾端(即第一连麦端)在接收到来自连麦业务服务端转发的接受连麦消息(permit)后，直接展示倒计时窗口，在倒计时的过程中，嘉宾端同时向RTC服务端申请加入连麦房间。本公开实施例中第一连麦端提前了展示倒计时窗口的时机，使得第一连麦端在接收到第二连麦端的首帧画面后，无需等待多余的倒计时时间，缩短了首帧耗时，提高了整体的连麦效率，从而提升了第一连麦端用户的连麦体验。

由于第二连麦端在接收到针对连麦申请请求的接受连麦操作时，不仅向连麦业务服务端发送接受连麦消息，还向实时协作RTC服务端申请加入连麦房间，也就是说，在向RTC服务端申请加入连麦房间时还未接收到连麦业务服务端的Join_channel返回消息，第二连麦端并未获知连麦业务服务端是否同意加入连麦房间，如果连麦业务服务端因为某种原因不同意第二连麦服务端加入连麦房间，而此时第二连麦端已经向RTC服务端申请加入连麦房间，则可能出现错误等，降低连麦用户体验。为了避免上述情况的发生，本公开实施例增加错误处理环节，以便在某些环节出错时第二连麦端能够及时断开与其他通信端的链接。

一种可选的实施方式中，第二连麦端还用于在确定倒计时窗口的倒计时结束时，确定是否已接收到第一连麦端推送的音视频流，如果确定未接收到音视频流，则向连麦业务服务端和RTC服务端分别发送断开连麦链接请求。

本公开实施例中，第二连麦端在接收到针对连麦申请请求的接受连麦操作时，向实时协作RTC服务端申请加入连麦房间，同时直接展示倒计时窗口，此时第二连麦端已经申请加入连麦房间并开始推送音视频流到实时协作RTC服务端。在第二连麦端倒计时期间，如果第二连麦端已成功加入连麦房间，则需要等待拉取第一连麦端推送的音视频流，因此，第二连麦端在确定倒计时窗口的倒计时结束时，还需要确定是否已接收到第一连麦端推送的音视频流，以便第二连麦端在倒计时结果时可以展示对端的首帧画面。

具体的，在倒计时窗口的倒计时结束时，如果第二连麦端确定已接收到第一连麦端推送的音视频流，则移除倒计时蒙层，在第二连麦端的显示屏幕上展示第一连麦端的首帧画面，实现与第一连麦端的连麦。在第二连麦端的倒计时窗口的倒计时结束时，如果第二连麦端执行的某些任务出现错误，例如向连麦业务服务端发送接受连麦消息出现错误或者向实时协作RTC服务端申请加入连麦房间等出现错误等，则第二连麦端无法接收到第一连麦端推送的音视频流，进而第二连麦端可以向连麦业务服务端和RTC服务端分别发送断开连麦链接请求，连麦业务服务端在接收到断开连麦链接请求后，将该断开连麦链接请求转发到第一连麦端，第一连麦端在接收到该断开连麦链接请求后，断开与第一连麦端的连线，从而在提高了连麦效率的同时，也能够提高连麦的稳定性。

如图1所示，嘉宾端(即第一连麦端)在接收到来自连麦业务服务端转发的接受连麦消息(permit)后，向连麦业务服务端发送Join_channel请求，用于向连麦业务服务端请求同意其加入连麦房间，连麦业务服务端针对该Join_channel请求发送Join_channel返回消息，以通知嘉宾端是否同意其加入连麦房间。假设Join_channel返回消息表明连麦业务服务端同意其加入连麦房间，则嘉宾端可以向RTC服务端申请加入连麦房间。当接收到RTC服务端返回的成功加入连麦房间消息后，嘉宾端开始向RTC服务端推送音视频流。

为了提升连麦效率，嘉宾端可以提前向RTC服务端申请加入连麦房间的时机，以缩短嘉宾端的连麦首帧耗时。

一种可选的实施方式中，第一连麦端还用于在接收到来自连麦业务服务端的接受连麦消息时，向RTC服务端申请加入连麦房间。

本公开实施例中，第一连麦端通过连麦业务服务端向第二连麦端发送连麦申请请求后，等待第二连麦端通过连麦业务服务端返回接受连麦消息后，向RTC服务端申请加入连麦房间。如图2所示，嘉宾端(即第一连麦端)在接收到来自连麦业务服务端转发的接受连麦消息(permit)后，直接向实时协作RTC服务端申请加入连麦房间，而无需优先执行向连麦业务服务端发送Join_channel请求，以及无需等待连麦业务服务端针对该Join_channel请求返回Join_channel返回消息。本公开实施例中的第一连麦端提前了申请加入连麦房间的时机，缩短了第一连麦端从接收到来自连麦业务服务端转发的接受连麦消息到接收对端首帧的连麦建联耗时，从而提升了整体的连麦效率。

如图1所示，在嘉宾端拉取到主播端(即第二连麦端)的首帧后，还需要再等待5秒倒计时，在倒计时结束后才能移除蒙层，即嘉宾端用户在倒计时结束后才能看到和主播端用户的连麦画面。显然，嘉宾端在接收到来自连麦业务服务端转发的接受连麦消息后到接收到对端首帧期间的建联耗时也是影响连麦效率的因素之一。由于嘉宾端在等待倒计时的过程中可能已经将音视频流成功推送至RTC服务端，因此主播端可以提前接收到嘉宾端的首帧画面，并对其进行展示，但此时嘉宾端用户并不知悉自己的动态已经在主播端上显示，对于嘉宾端用户而言存在隐私数据安全隐患。综上，发明人基于此提出了对连麦的进一步优化方案。

一种可选的实施方式中，第一连麦端还用于在确定倒计时窗口的倒计时结束时，向RTC服务端推送音视频流。

本公开实施例中，第一连麦端在接收到来自连麦业务服务端转发的接受连麦消息时，展示倒计时窗口，并在确定倒计时窗口的倒计时结束时，开始向RTC服务端推送音视频流，避免第一连麦端在倒计时期间将音视频流推送至RTC服务端。由于第一连麦端在确定倒计时窗口的倒计时结束之后，才向RTC服务端推送音视频流，因此在倒计时结束之前，RTC服务端不会接收到第一连麦端的音视频流，第二连麦端无法从RTC服务端拉取到第一连麦端的音视频流，因此，第二连麦端的显示屏幕上不会提前显示出第一连麦端用户的相关画面，提高了第一连麦端的连麦安全性，提升了用户连麦体验。

本公开实施例提供的连麦系统中，第一连麦端在接收到来自连麦业务服务端的接受连麦消息时，向RTC服务端申请加入连麦房间，同时展示倒计时窗口，并在确定倒计时窗口的倒计时结束时，向RTC服务端推送音视频流。由于第一连麦端在接收到来自连麦业务服务端的接受连麦消息时，提前了展示倒计时窗口以及申请加入连麦房间的时机，因此，缩短了第一连麦端从接收到接受连麦消息至接收到第二连麦端首帧画面的耗时，提高了连麦的效率。

另外，由于第一连麦端在确定倒计时结束后才向RTC服务端推送音视频流，因此，确保了在第一连麦端的倒计时期间，不会在第二连麦端显示第一连麦端用户的相关画面，提高了第一连麦端的连麦安全性，提升了用户连麦体验。

基于上述系统实施例，本公开还提供了一种连麦方法，参考图4，为本公开实施例提供的一种连麦方法流程图，方法包括：

S401：第二连麦端通过连麦业务服务端接收来自第一连麦端的连麦申请请求。

本公开实施例中，连麦业务服务端分别与第一连麦端以及第二连麦端通信连接，第二连麦端通过连麦业务服务端接受来自第一连麦端的连麦申请请求。其中，连麦申请请求用于请求第二连麦端接受第一连麦端的连麦申请。

S402：第二连麦端在接收到针对连麦申请请求的接受连麦操作时，向连麦业务服务端发送接受连麦消息，并向实时协作RTC服务端申请加入连麦房间。

本公开实施例中，接受连麦消息，用于通知连麦业务服务端第二连麦端已接受第一连麦端的连麦申请。

本公开实施例中，第二连麦端在接收到针对连麦申请请求的接受连麦操作时，向连麦业务服务端发送接受连麦消息，同时向实时协作RTC服务端申请加入连麦房间。

本公开实施例中，第二连麦端在接收到针对连麦申请请求的接受连麦操作时，提前了向连麦业务服务端发送接受连麦消息的时机，以使第一连麦端能够提前接收到来自第二连麦端的接受连麦消息，缩短了第一连麦端知悉对端是否已经同意连麦申请请求的耗时。另外，第二连麦端在接收到针对连麦申请请求的接受连麦操作时，无需等待连麦业务服务端针对Join_channel消息的返回消息，即可向RTC服务端申请加入连麦房间，即提前了申请加入连麦房间的时机，缩短了接受连麦的第二连麦端从接受连麦操作至接收到来自第一连麦端的首帧画面的耗时，提高了连麦效率。

一种可选的实施方式中，所述方法还包括：第二连麦端在接收到针对连麦申请请求的接受连麦操作时，展示倒计时窗口。

一种可选的实施方式中，所述方法还包括：第二连麦端在确定倒计时窗口的倒计时结束时，确定是否已接收到第一连麦端推送的音视频流，如果确定未接收到音视频流，则向连麦业务服务端和RTC服务端分别发送断开连麦链接请求。

本公开实施例提供的连麦方法中，第一连麦端通过连麦业务服务端向第二连麦端发送连麦申请请求后，第二连麦端在接收到针对连麦申请请求的接受连麦操作时，向连麦业务服务端发送接受连麦消息，并同时向实时协作RTC服务端申请加入连麦房间。由于第二连麦端在接收到针对连麦申请请求的接受连麦操作时，提前了向连麦业务服务端发送接受连麦消息以及向实时协作RTC服务端申请加入连麦房间的时机，从而缩短了接受连麦的第二连麦端从接受连麦操作至接收到第一连麦端的首帧画面的耗时，提高了连麦的效率，也提升了接受连麦的第二连麦端用户的连麦体验。

基于上述系统实施例，本公开还提供了另一种连麦方法，参考图5，为本公开实施例提供的另一种连麦方法流程图，方法包括：

S501：第一连麦端通过连麦业务服务端向第二连麦端发送连麦申请请求。

其中，第二连麦端用于在接收到针对连麦申请请求的连麦接受操作时，向连麦业务服务端返回发送接受连麦消息，并向实时协作RTC服务端申请加入连麦房间。

本公开实施例中，连麦业务服务端分别与第一连麦端以及第二连麦端通信连接，第一连麦端通过连麦业务服务端向第二连麦端发送连麦申请请求。其中，连麦申请请求用于请求第二连麦端接受第一连麦端的连麦申请。

S502：第一连麦端从连麦业务服务端接收到接受连麦消息时，向RTC服务端申请加入连麦房间。

本公开实施例中，接受连麦消息，用于通知连麦业务服务端第二连麦端已接受第一连麦端的连麦申请。

本公开实施例中，第一连麦端通过连麦业务服务端向第二连麦端发送连麦申请请求后，等待第二连麦端通过连麦业务服务端返回接受连麦消息后，向RTC服务端申请加入连麦房间。在第一连麦端从连麦业务服务端接收到接受连麦消息时，直接向RTC服务端申请加入连麦房间，而无需优先执行向连麦业务服务端发送Join_channel请求，以及无需等待连麦业务服务端针对该Join_channel请求返回消息。本公开实施例中的第一连麦端提前了申请加入连麦房间的时机，提前拉取到对端的音视频流，从而缩短了第一连麦端从接收到来自连麦业务服务端转发的接受连麦消息到接收对端首帧的连麦建联耗时，从而提升了整体的连麦效率。

一种可选的实施方式中，所述方法还包括：第一连麦端从连麦业务服务端接收到接受连麦消息时，展示倒计时窗口。

一种可选的实施方式中，所述方法还包括：第一连麦端在确定倒计时窗口的倒计时结束时，向RTC服务端推送音视频流。

本公开实施例提供的连麦方法中，第一连麦端从连麦业务服务端接收到接受连麦消息时，向RTC服务端申请加入连麦房间。由于第一连麦端在接收到来自连麦业务服务端的接受连麦消息时，提前了申请加入连麦房间的时机，因此，缩短了发起连麦的第一连麦端从接收到接受连麦消息到接收对端首帧的连麦建联耗时，提高了连麦的效率，也提升了用户的连麦体验。

与上述方法实施例基于同一个发明构思，本公开还提供了一种连麦装置，参考图6，为本公开实施例提供的一种连麦装置的结构示意图，所述装置包括：

接收模块601，用于第二连麦端通过连麦业务服务端接收来自第一连麦端的连麦申请请求；

第一申请模块602，用于所述第二连麦端在接收到针对所述连麦申请请求的接受连麦操作时，向所述连麦业务服务端发送接受连麦消息，并向实时协作RTC服务端申请加入连麦房间。

一种可选的实施方式中，所述装置还包括：

第一展示模块，用于所述第二连麦端在接收到针对所述连麦申请请求的接受连麦操作时，展示倒计时窗口。

一种可选的实施方式中，所述装置还包括：

断开模块，用于所述第二连麦端在确定所述倒计时窗口的倒计时结束时，确定是否已接收到所述第一连麦端推送的音视频流，如果确定未接收到所述音视频流，则向所述连麦业务服务端和所述RTC服务端分别发送断开连麦链接请求。

与上述方法实施例基于同一个发明构思，本公开还提供了一种连麦装置，参考图7，为本公开实施例提供的另一种连麦装置的结构示意图，所述装置包括：

发送模块701，用于第一连麦端通过连麦业务服务端向第二连麦端发送连麦申请请求；其中，所述第二连麦端用于在接收到针对所述连麦申请请求的连麦接受操作时，向所述连麦业务服务端返回接受连麦消息，并向实时协作RTC服务端申请加入连麦房间；

第二申请模块702，用于所述第一连麦端从所述连麦业务服务端接收到所述接受连麦消息时，向所述RTC服务端申请加入连麦房间。

一种可选的实施方式中，所述装置还包括：

第二展示模块，用于所述第一连麦端从所述连麦业务服务端接收到所述接受连麦消息时，展示倒计时窗口。

一种可选的实施方式中，所述装置还包括：

推送模块，用于所述第一连麦端在确定所述倒计时窗口的倒计时结束时，向所述RTC服务端推送音视频流。

本公开实施例提供的连麦装置中，由于第二连麦端在接收到针对连麦申请请求的接受连麦操作时，提前了向连麦业务服务端发送接受连麦消息以及向实时协作RTC服务端申请加入连麦房间的时机，从而缩短了接受连麦的第二连麦端从接受连麦操作至接收到第一连麦端的首帧画面的耗时。并且，由于第一连麦端在接收到来自连麦业务服务端的接受连麦消息时，提前了申请加入连麦房间的时机，因此，缩短了第一连麦端从接收到接受连麦消息至在第二连麦端显示首帧画面的耗时，提高了连麦的效率，也提升了用户的连麦体验。

除了上述方法和装置以外，本公开实施例还提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当所述指令在终端设备上运行时，使得所述终端设备实现本公开实施例所述的连麦方法。

另外，本公开实施例还提供了一种连麦设备，参见图8所示，可以包括：

处理器801、存储器802、输入装置803和输出装置804。连麦设备中的处理器801的数量可以一个或多个，图8中以一个处理器为例。在本公开的一些实施例中，处理器801、存储器802、输入装置803和输出装置804可通过总线或其它方式连接，其中，图8中以通过总线连接为例。

存储器802可用于存储软件程序以及模块，处理器801通过运行存储在存储器802的软件程序以及模块，从而执行连麦设备的各种功能应用以及数据处理。存储器802可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等。此外，存储器802可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。输入装置803可用于接收输入的数字或字符信息，以及产生与连麦设备的用户设置以及功能控制有关的信号输入。

具体在本实施例中，处理器801会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器802中，并由处理器801来运行存储在存储器802中的应用程序，从而实现上述连麦设备的各种功能。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (16)

1.一种连麦系统，其特征在于，所述系统包括第一连麦端、第二连麦端和连麦业务服务端；

所述第一连麦端，用于通过所述连麦业务服务端向所述第二连麦端发送连麦申请请求；

所述第二连麦端，用于在接收到针对所述连麦申请请求的接受连麦操作时，向所述连麦业务服务端发送接受连麦消息，并在接收到针对所述连麦申请请求的接受连麦操作时，向实时协作RTC服务端申请加入连麦房间，以及，在接收到来自所述RTC服务端的申请加入连麦房间成功消息时，向所述RTC服务端推送音视频流；

所述第一连麦端，还用于在接收到来自所述连麦业务服务端的所述接受连麦消息时，向所述RTC服务端申请加入连麦房间。

2.根据权利要求1所述的系统，其特征在于，

所述第二连麦端，还用于在接收到针对所述连麦申请请求的接受连麦操作时，展示倒计时窗口。

3.根据权利要求2所述的系统，其特征在于，

所述第二连麦端，还用于在确定所述倒计时窗口的倒计时结束时，确定是否已接收到所述第一连麦端推送的音视频流，如果确定未接收到所述音视频流，则向所述连麦业务服务端和所述RTC服务端分别发送断开连麦链接请求。

4.根据权利要求1所述的系统，其特征在于，

所述第一连麦端，还用于在接收到来自所述连麦业务服务端的所述接受连麦消息时，展示倒计时窗口。

5.根据权利要求4所述的系统，其特征在于，

所述第一连麦端，还用于在确定所述倒计时窗口的倒计时结束时，向所述RTC服务端推送音视频流。

6.根据权利要求1所述的系统，其特征在于，所述第一连麦端包括嘉宾客户端，所述第二连麦端包括主播客户端。

7.一种连麦方法，其特征在于，所述方法包括：

第二连麦端通过连麦业务服务端接收来自第一连麦端的连麦申请请求；

所述第二连麦端在接收到针对所述连麦申请请求的接受连麦操作时，向所述连麦业务服务端发送接受连麦消息，并在接收到针对所述连麦申请请求的接受连麦操作时，向实时协作RTC服务端申请加入连麦房间；其中，所述第一连麦端用于在接收到来自所述连麦业务服务端的所述接受连麦消息时，向所述RTC服务端申请加入连麦房间；

所述第二连麦端在接收到来自所述RTC服务端的申请加入连麦房间成功消息时，向所述RTC服务端推送音视频流。

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：

所述第二连麦端在接收到针对所述连麦申请请求的接受连麦操作时，展示倒计时窗口。

9.根据权利要求8所述的方法，其特征在于，所述方法还包括：

所述第二连麦端在确定所述倒计时窗口的倒计时结束时，确定是否已接收到所述第一连麦端推送的音视频流，如果确定未接收到所述音视频流，则向所述连麦业务服务端和所述RTC服务端分别发送断开连麦链接请求。

10.一种连麦方法，其特征在于，所述方法包括：

第一连麦端通过连麦业务服务端向第二连麦端发送连麦申请请求；其中，所述第二连麦端用于在接收到针对所述连麦申请请求的连麦接受操作时，向所述连麦业务服务端发送接受连麦消息，并在接收到针对所述连麦申请请求的接受连麦操作时，向实时协作RTC服务端申请加入连麦房间，以及，在接收到来自所述RTC服务端的申请加入连麦房间成功消息时，向所述RTC服务端推送音视频流；

所述第一连麦端从所述连麦业务服务端接收到所述接受连麦消息时，向所述RTC服务端申请加入连麦房间。

11.根据权利要求10所述的方法，其特征在于，所述方法还包括：

所述第一连麦端从所述连麦业务服务端接收到所述接受连麦消息时，展示倒计时窗口。

12.根据权利要求11所述的方法，其特征在于，所述方法还包括：

所述第一连麦端在确定所述倒计时窗口的倒计时结束时，向所述RTC服务端推送音视频流。

13.一种连麦装置，其特征在于，所述装置包括：

接收模块，用于第二连麦端通过连麦业务服务端接收来自第一连麦端的连麦申请请求；

第一申请模块，用于所述第二连麦端在接收到针对所述连麦申请请求的接受连麦操作时，向所述连麦业务服务端发送接受连麦消息，并在接收到针对所述连麦申请请求的接受连麦操作时，向实时协作RTC服务端申请加入连麦房间；其中，所述第一连麦端用于在接收到来自所述连麦业务服务端的所述接受连麦消息时，向所述RTC服务端申请加入连麦房间；

推送模块，用于所述第二连麦端在接收到来自所述RTC服务端的申请加入连麦房间成功消息时，向所述RTC服务端推送音视频流。

14.一种连麦装置，其特征在于，所述装置包括：

发送模块，用于第一连麦端通过连麦业务服务端向第二连麦端发送连麦申请请求；其中，所述第二连麦端用于在接收到针对所述连麦申请请求的连麦接受操作时，向所述连麦业务服务端发送接受连麦消息，并在接收到针对所述连麦申请请求的接受连麦操作时，向实时协作RTC服务端申请加入连麦房间，以及，在接收到来自所述RTC服务端的申请加入连麦房间成功消息时，向所述RTC服务端推送音视频流；

第二申请模块，用于所述第一连麦端从所述连麦业务服务端接收到所述接受连麦消息时，向所述RTC服务端申请加入连麦房间。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当所述指令被处理器执行时，使得计算机设备实现如权利要求8-12任一项所述的方法。

16.一种连麦设备，其特征在于，包括：存储器，处理器，及存储在所述存储器上的计算机程序，所述处理器执行所述计算机程序时，实现如权利要求8-12任一项所述的方法。