多人语音方法、服务器以及计算机存储介质与流程

文档序号:17844860发布日期:2019-06-11 21:36阅读:205来源:国知局

本申请涉及直播应用技术领域,特别是涉及一种多人语音方法、服务器以及计算机存储介质。



背景技术:

随着互联网技术的发展和智能设备的应用发展,直播平台具有多元化的直播内容,例如在线娱乐或者游戏直播。

现有的app直播方式一般为主播单人进行直播,将个人声音和直播视频展示给直播间中的观众的方式。在这种直播方式下,观众只能观看直播,无法参与其中。除此之外,直播间中的多个观众均为相互陌生的游客,观众与其他观众、主播之间只能通过文字弹幕交流。但是,采用文字弹幕交流方式一方面交流时效较慢,另一方面更有可能自己所发弹幕在短时间内就被大量他人弹幕冲走。



技术实现要素:

本申请提供了一种多人语音方法、服务器以及计算机存储介质,主要解决的技术问题是如何提高观众与观众、观众与主播之间的交流时效。

为解决上述技术问题,本申请提供了一种多人语音方法,所述多人语音方法包括:

在主播端进行直播时,接收所述主播端的连麦发起信息;

根据所述连麦发起信息生成第一直播数据,并将所述第一直播数据发送给观众端,以使所述观众端在第一直播界面上显示连麦界面;

接收第一观众端的连麦确认信息,并根据所述连麦确认信息将所述第一观众端和所述主播端建立连麦,其中所述第一观众端为与所述主播端建立连麦的观众端。

为解决上述技术问题,本申请还提供了另一种多人语音方法,所述多人语音方法应用于直播系统,所述直播系统包括主播端、观众端和服务器,所述主播端和所述观众端均与所述服务器连接;所述多人语音方法包括:

在所述主播端进行直播时,所述主播端发送连麦发起信息给所述服务器;

所述服务器根据所述连麦发起信息生成第一直播数据,并将所述第一直播数据发送给所述观众端;

所述观众端根据所述第一直播数据在第一直播界面上显示连麦界面,第一观众端发送连麦确认信息给所述服务器;

所述服务器根据所述连麦确认信息将所述第一观众端和所述主播端建立连麦,其中所述第一观众端为与所述主播端建立连麦的观众端。为解决上述技术问题,本申请还提供了一种服务器,所述服务器包括通信模块以及与所述通信模块耦接的处理模块;

所述通信模块用于在主播端进行直播时,接收所述主播端的连麦发起信息;

所述处理模块用于根据所述连麦请求生成第一直播数据;

所述通信模块还用于将所述第一直播数据发送给观众端,以使所述观众端在第一直播界面上显示连麦界面;

所述通信模块进一步用于接收所述第一观众端的连麦确认信息;

所述处理模块还用于根据所述连麦确认信息将所述第一观众端和所述主播端建立连麦,其中所述第一观众端为与所述主播端建立连麦的观众端。

为解决上述技术问题,本申请还提供了另一种服务器,所述服务器包括存储器以及与所述存储器耦接的处理器;

其中,所述存储器用于存储程序数据,所述处理器用于执行所述程序数据以实现如上述的多人语音方法。

为解决上述技术问题,本申请还提供了一种计算机存储介质,所述计算机存储介质用于存储程序数据,所述程序数据在被处理器执行时,用以实现如上述的多人语音方法。

与现有技术相比,本申请的有益效果是:在直播过程中,服务器接收主播端主动发送的连麦发起信息,以向主播端所在直播间内的所有观众端发送第一直播数据,观众端根据第一直播数据在第一直播界面上显示连麦界面;服务器可以接收第一观众端通过连麦界面发送的连麦确认信息,并根据连麦确认信息将对应的第一观众端和主播端建立连麦,其中第一观众端为与主播端建立连麦的观众端,由此,观众端与观众端之间、观众端与主播端之间就可以通过连麦进行多人语音,提高观众端在直播中的参与感。

附图说明

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

图1是本申请多人语音方法第一实施例的流程示意图;

图2是图1中直播系统的结构示意图;

图3是图1中观众端上麦界面的示意图;

图4是本申请多人语音方法第二实施例的流程示意图;

图5是图4中直播系统的结构示意图;

图6是本申请多人语音方法第三实施例的流程示意图;

图7是图6中下麦界面的示意图;

图8是本申请多人语音方法第四实施例的流程示意图;

图9是本申请直播系统一实施例的结构示意图;

图10是本申请服务器一实施例的结构示意图;

图11是本申请服务器另一实施例的结构示意图;

图12是本申请计算机存储介质一实施例的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅是本申请的一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。

本申请提出了一种多人语音方法,通过本申请的多人语音方法可以实现在直播过程中,主播与观看该主播对应直播间内的观众进行连麦的效果;具体请参见图1~图3,图1是本申请多人语音方法第一实施例的流程示意图,图2是图1中直播系统的结构示意图,图3是图1中观众端上麦界面的示意图。

本实施例的多人语音方法应用于直播服务器,本实施例的直播服务器可为直播系统200中的服务器21。如图2所示,直播系统200至少还包括主播端22和多个观众端23;其中,主播端22和多个观众端23分别与服务器21建立通信连接。

在终端的领域,主播端22和多个观众端23可为家用电脑、智能手机、平板电脑等智能终端;在操作系统的领域,主播端22和多个观众端23可为安卓客户端或ios客户端。

服务器21用于管理主播端22和多个观众端23的直播信息,其中,直播信息包括主播权限、观众权限和直播界面数据等。

如图1所示,结合图2的结构示意图,本实施例的多人语音方法包括以下步骤:

s11:在主播端进行直播时,接收主播端的连麦发起信息。

在直播过程中,当主播需要启用连麦功能时,主播端22发送连麦发起信息给服务器21,以申请开启连麦功能。连麦发起信息中至少包括主播信息和主播间id信息等信息。

s12:根据连麦发起信息生成第一直播数据,并将第一直播数据发送给观众端,以使观众端在第一直播界面上显示连麦界面。

其中,服务器21在接收到主播端22的连麦发起信息后,以主播信息或者主播端id信息作为标识,将连麦发起信息存储到数据库(图中未示出),然后存储到内存。存储成功后,服务器21需要将此次开启连麦功能的消息广播给主播端22对应直播间内的所有观众端23。

具体地,服务器21根据连麦发起信息生成第一直播数据,其中,第一直播数据包括第一直播界面数据和连麦接口数据。服务器21将第一直播数据推送给直播间内的所有观众端23。

其中,本实施例的观众端23可以为观看直播的所有观众端23;也可以包括观看直播的具有不同权限的观众端23。例如,在观看直播的所有观众端23中,部分观众端23通过服务器21的订阅服务关注主播端21的信息。此时,服务器21根据启用订阅服务的观众名单将第一直播数据推送给直播间内观众名单对应的部分观众端23,对于另一部分未关注直播间的观众端23,服务器21可以发送“若需要获取更多直播服务,请关注主播”等提醒性文字信息,以提醒观众端23启用该主播端21对应的订阅服务。

直播间内的观众端23根据第一直播数据显示第一直播界面。具体地,如图3所示,观众端23根据第一直播界面数据显示第一直播界面a,根据连麦接口数据在第一直播界面a上显示连麦界面b,其中,连麦界面b上可以进一步包括上麦按钮b1。

除上麦按钮b1外,连麦界面b上还包括参与连麦的成员信息c。其中,成员信息c至少包括主播信息c1和观众信息c2。如图3所示,观众信息c2中包括4个位置区域(图中未示出)或者其它数量的位置区域,当没有观众端23加入连麦服务时,位置区域显示“座位”图标,或者主播端22设置允许加入的观众端23数量少于位置区域数量时,其余位置区域显示“锁定”图标。

进一步地,服务器21在给直播间内的观众端23推送第一直播数据的同时,服务器21根据观众端23的权限数据给不同的观众端23设置不同的权限。例如,服务器21在发送第一直播数据给没有权限的观众端23时,第一直播数据中可以不包括连麦接口数据。具体地,权限数据可以为观众端23在观看直播中产生的礼物价值或者观众端23在直播间中的财富榜名次等。主播端22或者服务器21可以根据该权限数据限制部分观众端23使用连麦功能。例如,在直播间财富榜上的观众对应的观众端23获取第一直播数据后,连麦界面b中的上麦按钮b1显示为彩色图标;其余的观众端23获取第一直播数据后,连麦界面b中的上麦按钮b1显示为灰色图标,即处于无法选取状态。

s13:接收第一观众端的连麦确认信息,并根据连麦确认信息将第一观众端和主播端建立连麦,其中第一观众端为与主播端建立连麦的观众端。

其中,多个第一观众端23根据上麦按钮b1上的第一选择指令发送连麦确认信息给服务器21,连麦确认信息包括观众信息等。服务器21根据连麦确认信息将对应的第一观众端23和主播端22建立连麦。

在本实施例中,在直播过程中,主播端22可以主动发送连麦发起信息给服务器21,以使服务器21向主播端22所在直播间内的所有观众端23发送连麦界面;第一观众端23可以通过连麦界面b发送连麦确认信息给服务器21,以申请加入主播端22创建的连麦服务;服务器21根据连麦确认信息将对应的第一观众端23和主播端22建立连麦,由此,观众端23与观众端23之间、观众端23与主播端22之间就可以通过连麦进行多人语音,提高观众端23在直播中的参与感。

本申请还提供了另一种多人语音方法,具体请参见图4和图5,图4是本申请多人语音方法第二实施例的流程示意图,图5是图4中直播系统的结构示意图。

本实施例的多人语音方法应用于图5直播系统300的服务器30,如图5所示,直播系统300至少包括服务器30、主播端33、第一观众端34和第二观众端35,其中,服务器30包括第一服务器31和第二服务器32。

在本实施例中,第一服务器31可为业务服务器,第二服务器32可为音视频流服务器,其中,音视频流服务器用于管理连麦过程中的音视频数据。

第一观众端34为上述实施例中与主播端33建立连麦的观众端,第二观众端35为直播间内除第一观众端34以外的其余观众端。

结合图5的结构示意图,在上述多人语音方法第一实施例的步骤s13之后,本实施例的多人语音方法进一步还包括以下步骤:

s21:从主播端获取第一音频流。

其中,当主播端33发送连麦发起信息,并收到第一服务器21关于远程过程调用协议的成功应答后,主播端33上麦成功。主播端33向第二服务器32发起推流请求,以获取对应的推流id,即音视频推流的权限。

获取推流id后,主播端33通过终端的麦克风或其它拾音装置采集主播的第一音频流,并根据推流id将第一音频流发送给第二服务器32。

进一步地,获取推流id后,主播端33还可以将推流id发送给第一服务器31,并由第一服务器31将推流id广播给直播间内的第一观众端34和第二观众端35,以使第一观众端34和第二观众端35更新主播端33对应的推流id。

s22:从第一观众端获取第二音频流。

其中,当第一观众端34发送连麦确认信息,并收到第一服务器21关于远程过程调用协议的成功应答后,第一观众端34上麦成功。第一观众端34向第二服务器32发起推流请求,以获取对应的推流id或推流码,即音视频推流的权限。

获取推流id后,第一观众端34通过终端的麦克风或其它拾音装置采集观众的第二音频流,并根据推流id将第二音频流发送给第二服务器32。

进一步地,获取推流id后,第一观众端34还可以将推流id发送给第一服务器31,并由第一服务器31将推流id广播给直播间内的主播端33和直播间内的其余观众端,以使主播端33和其余观众端更新该第一观众端34对应的推流id。

s23:向主播端发送利用多个第二音频流混流生成的第三音频流,向第二观众端发送利用第一音频流和多个第二音频流混流生成的第四音频流。

其中,第二服务器32在接收第一音频流和第二音频流的同时,还可以接收分别来自主播端33和第二观众端35的混流请求信息。

具体地,主播端33向第二服务器32发送混流请求信息,以请求分配混流接口,该混流接口接入所有第一观众端34的第二音频流。当需要听到语音时,主播端33需要对对应的混流接口进行拉流,即可听到所有第一观众端34对应的观众的说话声音。

第二观众端35向第二服务器32发送混流请求信息,以请求分配混流接口,该混流接口接入主播端33的第一音频流和第一观众端34的第二音频流,并实时返回给所有第二观众端35,使得直播间内的所有第二观众端35的观众都可以听到连麦的语音内容。当需要听到语音时,该第二观众端35需要对对应的混流接口进行拉流,即可听到主播以及第一观众端34对应的观众的说话声音。

s24:向每个第一观众端发送利用第一音频流和其它第一观众端的第二音频流合成的第五音频流。

其中,第一观众端34向第二服务器32发送混流请求信息,以请求分配混流接口,该混流接口接入第一音频流和第二音频流。第一观众端34需要不间断向第二服务器32拉流,以请求第一音频流和第二音频流。

第二服务器32收到第一观众端34的混流请求信息后,将第一音频流和其余第一观众端34的第二音频流合成音频数据,实时返回给该第一观众端34,使得第一观众端34可以听到连麦的语音内容。

在本实施例中,第二服务器32根据不同的混流请求信息将采集到的第一音频流和第二音频流进行混流,然后分别推送主播端33、第一观众端34以及第二观众端35,以实现多人连麦的效果,使得观众端与观众端之间、观众端与主播端之间就可以通过连麦进行多人语音,提高观众端在直播中的参与感。

本申请还提供了又一种多人语音方法方法,具体请参见图6和图7,图6是本申请多人语音方法第三实施例的流程示意图,图7是图6中下麦界面的示意图。

同样地,本实施例的多人语音方法应用于图5直播系统300中的服务器30,具体请参见图5,在此不再赘述。

在上述多人语音方法第一实施例的基础上,本实施例的多人语音方法进一步还包括以下步骤:

s31:根据连麦确认信息生成第二直播数据,并将第二直播数据发送给主播端和第一观众端,以使主播端和第一观众端根据第二直播数据显示第二直播界面,其中,第二直播界面包括主播信息和第一观众端的观众信息。

其中,当第一观众端34发送连麦确认信息给第一服务器31后,第一观众端34在得到成功应答时,显示的界面由上述图3的上麦界面更新为图7的下麦界面。

具体地,第一服务器31根据第一观众端34的观众信息生成第二直播数据,并将第二直播数据发送给主播端33和第一观众端34。其中,第二直播数据包括第二直播界面数据和下麦接口数据。以第一观众端34为例,第一观众端34根据第二直播界面数据显示如图7的第二直播界面a,根据下麦接口数据在第二直播界面a上显示下麦界面b,其中,下麦界面b上可以进一步包括下麦按钮b1。下麦界面b还可以包括参与连麦的成员信息,如上述实施例步骤s12所述,在此不再赘述。

进一步地,同时,第一服务器31还可以根据上述连麦确认信息生成第三直播数据,并发送给第二观众端35。第二观众端35根据第三直播数据显示第三直播界面,其中,第三直播界面与上述图3所示的上麦界面类似,在此不再赘述。第三直播界面至少包括主播信息、多个第一观众信息和上麦按钮。

s32:从第一观众端接收到连麦停止信息,并根据连麦停止信息断开观众端与主播端的连麦。

其中,当某一个观众在第一观众端34的第二直播界面b上点击下麦按钮b1时,该第一观众端34给第一服务器31发送连麦停止信息,以退出在本直播间的连麦。此时,该第一观众端34的客户端类型演化为第二观众端35的客户端类型。

进一步地,第一服务器31清除存储在数据库的对应观众信息,并实时更新发送给主播端33、第一观众端34和第二观众端35的直播数据,相对于之前发送的直播数据,实时发送的直播数据中不包括该第一观众端34的观众信息。同理地,第二服务器32也可以清除该第一观众端34的推流id和混流接口,以使第一观众端34无法通过连麦功能输出音频流。

s33:从主播端接收到连麦终止信息,并根据连麦终止信息断开主播端与观众端的连麦。

其中,当主播通过选择主播端33上显示的下麦按钮b1选择结束连麦,即主播端33发送连麦终止信息给第一服务器31。第一服务器31根据连麦终止信息清除所有存储的主播信息和观众信息,并向直播间的所有观众端广播连麦结束的消息。

主播端33和第一观众端34将不再推流自身的音频流,同时也不再拉流其它客户端的音频流;第二观众端35也不再拉流连麦的音频流。

在本实施例中,多人语音方法根据某个第一观众端34的选择指令将该第一观众端34退出连麦,或者根据主播端33的选择指令将连麦终止,参与连麦的客户端均退出连麦,可以快速调整直播间的连麦状态,提高直播效果。

本申请还提供了另一种多人语音方法,具体请参见图8,图8是本申请多人语音方法第四实施例的流程示意图。

本实施例的多人语音方法应用于图5中的直播系统300,具体请参见图5,在此不再赘述。

本实施例的多人语音方法具体包括以下步骤:

s41:在主播端进行直播时,主播端发送连麦发起信息给服务器。

s42:服务器根据连麦发起信息生成第一直播数据,并将第一直播数据发送给观众端。

s43:观众端根据第一直播数据在第一直播界面上显示连麦界面,第一观众端发送连麦确认信息给服务器。

s44:服务器根据连麦确认信息将第一观众端和主播端建立连麦,其中第一观众端为与主播端建立连麦的观众端。

本申请还提供了一种直播系统,具体请参见图9,图9是本申请直播系统一实施例的结构示意图。

如图9所示,直播系统400至少包括服务器41、主播端42和多个观众端43,其中,主播端42和多个观众端43分别与服务器41建立通信连接。

其中,在主播端42进行直播时,主播端42用于发送连麦发起信息给服务器41。

服务器41用于根据连麦发起信息生成第一直播数据,并将第一直播数据发送给多个观众端43,以在观众端43的第一直播界面上显示连麦界面。

观众端43用于发送连麦确认信息给服务器41,服务器41根据连麦确认信息将观众端43和主播端42建立连麦。

本申请还提供了一种服务器,具体请参见图10,图10是本申请服务器一实施例的结构示意图。本实施例的服务器500可以为上述多人语音方法实施例中的服务器21或服务器31,在此不再赘述。

如图10所示,服务器500包括通信模块51和处理模块52,其中,通信模块51与处理模块52耦接。

其中,通信模块51用于在主播端进行直播时,接收主播端的连麦发起信息。

处理模块52用于根据连麦请求生成第一直播数据;

通信模块51还用于将第一直播数据发送给观众端,以使观众端在第一直播界面上显示连麦界面;

通信模块51进一步用于接收第一观众端的连麦确认信息;

处理模块52还用于根据连麦确认信息将第一观众端和主播端建立连麦,其中第一观众端为与主播端建立连麦的观众端。

本申请还提供了另一种服务器,具体请参见图11,图11是本申请服务器另一实施例的结构示意图。本实施例的服务器500可以为上述多人语音方法实施例中的服务器21或服务器31,在此不再赘述。

如图11所示,服务器600包括存储器61和处理器62,其中,存储器61与处理器62耦接。

其中,存储器51用于存储程序数据,处理器52用于执行所述程序数据以实现如上述实施例中的多人语音方法。

在本实施例中,处理器62还可以称为cpu(centralprocessingunit,中央处理单元)。处理器62可能是一种集成电路芯片,具有信号的处理能力。处理器62还可以是通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现成可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器62也可以是任何常规的处理器等。

本申请还提供一种计算机存储介质,如图12所示,计算机存储介质700存储有程序数据,程序数据在被处理器执行时,用以实现如上述实施例中的多人语音方法。

本申请多人语音方法实施例中所涉及到的方法,在实现时以软件功能单元的形式存在并作为独立的产品销售或使用时,可以存储在装置700中,例如一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器(processor)执行本发明各个实施方式所述方法的全部或部分步骤。而前述的存储介质包括:u盘、移动硬盘、只读存储器(rom,read-onlymemory)、随机存取存储器(ram,randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施方式,并非因此限制本申请的专利范围,凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本申请的专利保护范围内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1