CN113630610A - 多人连麦的状态控制方法、存储介质、电子设备及系统 - Google Patents
多人连麦的状态控制方法、存储介质、电子设备及系统 Download PDFInfo
- Publication number
- CN113630610A CN113630610A CN202110751155.9A CN202110751155A CN113630610A CN 113630610 A CN113630610 A CN 113630610A CN 202110751155 A CN202110751155 A CN 202110751155A CN 113630610 A CN113630610 A CN 113630610A
- Authority
- CN
- China
- Prior art keywords
- wheat
- signaling
- data
- microphone
- invitation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 64
- 241000209140 Triticum Species 0.000 claims abstract description 222
- 235000021307 Triticum Nutrition 0.000 claims abstract description 222
- 230000011664 signaling Effects 0.000 claims abstract description 184
- 238000004590 computer program Methods 0.000 claims description 22
- 238000001514 detection method Methods 0.000 claims description 5
- 230000006870 function Effects 0.000 description 15
- 238000010586 diagram Methods 0.000 description 11
- 230000008569 process Effects 0.000 description 10
- 230000000694 effects Effects 0.000 description 4
- 238000004519 manufacturing process Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 239000000203 mixture Substances 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000004075 alteration Effects 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 238000007792 addition Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 239000003999 initiator Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/21—Server components or server architectures
- H04N21/218—Source of audio or video content, e.g. local disk arrays
- H04N21/2187—Live feed
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/21—Server components or server architectures
- H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
- H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/422—Input-only peripherals, i.e. input devices connected to specially adapted client devices, e.g. global positioning system [GPS]
- H04N21/42203—Input-only peripherals, i.e. input devices connected to specially adapted client devices, e.g. global positioning system [GPS] sound input device, e.g. microphone
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
- H04N21/4425—Monitoring of client processing errors or hardware failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
- H04N21/4788—Supplemental services, e.g. displaying phone caller identification, shopping application communicating with other users, e.g. chatting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/85—Assembly of content; Generation of multimedia applications
- H04N21/854—Content authoring
- H04N21/8547—Content authoring involving timestamps for synchronizing content
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Telephonic Communication Services (AREA)
Abstract
本发明公开了一种多人连麦的状态控制方法、存储介质、电子设备及系统,涉及视频直播技术领域。该方法包括:在预设的数据库中创建三类数据集,第一类数据集用于存储所有参与到多人连麦的连麦对象数据,第二类数据集用于存储参与到某一场连麦的连麦对象数据,第三类数据集用于存储连麦对象的基础信息;当进行多人连麦时,连麦服务端接收客户端发来的连麦信令,并根据接收到的不同连麦信令进行相应的连麦处理,同时在预设数据库中对三类数据集进行相应的数据更新操作。本发明不仅能够逻辑简洁的实现多人连麦的信令及状态处理,还能实时、便捷地查看和使用连麦状态数据,且数据安全性高、支持服务热更新,满足实际应用需求。
Description
技术领域
本发明涉及视频直播技术领域,具体来讲是一种多人连麦的状态控制方法、存储介质、电子设备及系统。
背景技术
传统的视频直播形式通常是指一个主播在自己直播间面向用户直播。而随着用户日益增长的观看需求,之后还出现了让两个主播进行连麦,以便在客户端的显示界面中同时展现两个主播的视频画面,使得用户可以同时观看两个主播的直播内容。由于该直播形式受到主播和用户的极大欢迎,直播效果非常好,因此在业界得到广泛使用,基本上各个直播平台都有两人连麦的功能。
目前,为了在两人连麦的基础上进一步提升互动直播的趣味性,业内开始提出让多个主播同时进行连麦,多人同时在线互动的直播场景。但是,让多个主播同时进行连麦,需要涉及到多个主播的连麦状态变更,且业务场景和信令交互流程都更加复杂,而目前还未有一套逻辑较为简洁的针对多人视频连麦的信令及状态处理方法。除此之外,现有的连麦技术中,也未对多人视频连麦的状态数据进行特别处理,无法随意查看或使用当前的连麦状态数据;而且服务重启时,临时缓存的连麦状态数据还易出现数据丢失或数据错误等情况,更无法方便的支持服务热更新。
发明内容
本发明的目的是为了克服上述背景技术的不足,提供一种多人连麦的状态控制方法、存储介质、电子设备及系统,不仅能够逻辑简洁的实现多人连麦的信令及状态处理,还能实时、便捷地查看和使用连麦状态数据,且数据安全性高、支持服务热更新,满足实际应用需求。
为达到以上目的,第一方面,本发明实施例提供一种多人连麦的状态控制方法,其包括:
S1、在预设的数据库中创建三类数据集,第一类数据集用于存储所有参与到多人连麦的连麦对象数据,第二类数据集用于存储参与到某一场连麦的连麦对象数据,第三类数据集用于存储连麦对象的基础信息;
S2、当进行多人连麦时,连麦服务端接收客户端发来的连麦信令,所述客户端发来的连麦信令为预先设置的多种连麦信令中的一种,且预先设置的多种连麦信令与连麦处理流程相对应;所述连麦服务端根据接收到的不同连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作。
作为一个优选的实施方案,步骤S1中,所述第一类数据集所存储的连麦对象数据包括:所有参与到多人连麦的连麦对象的唯一标识,及其对应的房主房间号;
所述第二类数据集所存储的连麦对象数据包括:参与到某一场连麦的连麦对象的唯一标识,及其对应的心跳保活时间戳;
所述第三类数据集所存储的连麦对象的基础信息包括:连麦对象的唯一标识、连麦对象上麦时间戳、连麦对象状态以及房主房间号;
步骤S2中,所述预先设置的多种连麦信令包括:房主发送邀请信令、参与者拒绝邀请信令、参与者接受邀请信令、房主取消邀请信令、房主移除参与者信令、退出连麦信令以及心跳消息信令。
作为一个优选的实施方案,步骤S2中,若客户端发来的连麦信令为房主发送邀请信令,所述连麦服务端根据该连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作,包括以下步骤:
所述连麦服务端根据客户端发来的所述房主发送邀请信令,确定被邀请的连麦对象;并在所述第一类数据集中进行查询,判断被邀请的连麦对象是否已存在;若不存在,则向被邀请的连麦对象发出连麦邀请,并在所述预设数据库中对三类数据集进行以下数据更新操作:
将发送邀请的客户端的唯一标识、被邀请的连麦对象的唯一标识以及对应的房主房间号均记录到第一类数据集中;
将发送邀请的客户端的唯一标识以及被邀请的连麦对象的唯一标识均记录到第二类数据集中,并以发送邀请的客户端的唯一标识作为本场连麦的关键字信息,且使用当前时间作为心跳保活时间戳;
将发送邀请的客户端的基础信息以及被邀请的连麦对象的基础信息均记录到第三类数据集中,并分别以自身的唯一标识作为各自数据的关键字信息;同时,分别设置两者的连麦对象状态。
作为一个优选的实施方案,被邀请的连麦对象收到连麦邀请后,若接受邀请,则发送所述参与者接受邀请信令,连麦服务端收到该信令后向客户端回复邀请成功信息,并在第三类数据集中更新被邀请的连麦对象的状态;
若拒绝邀请,则发送所述参与者拒绝邀请信令,连麦服务端收到该信令后向客户端回复邀请被拒信息,并分别在三类数据集中删除有关被邀请的连麦对象的数据;同时,若连麦服务端判断当前没有其他参与者在麦,则判定本场连麦结束,将分别在三类数据集中删除有关发送邀请的客户端的数据;
若超过指定回复时间未处理,则连麦服务端通知双方邀请超时的信息,并分别在三类数据集中删除有关被邀请的连麦对象的数据;同时,若连麦服务端判断当前没有其他参与者在麦,则判定本场连麦结束,将分别在三类数据集中删除有关发送邀请的客户端的数据。
作为一个优选的实施方案,步骤S2中,若客户端发来的连麦信令为房主取消邀请信令/房主移除参与者信令,所述连麦服务端根据该连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作,包括以下步骤:
所述连麦服务端根据客户端发来的所述房主取消邀请信令/所述房主移除参与者信令,确定被取消邀请的连麦对象/被移除的连麦对象;并分别在三类数据集中删除有关被取消邀请的连麦对象/被移除的连麦对象的数据;
同时,若连麦服务端判断当前没有其他参与者在麦,则判定本场连麦结束,将分别在三类数据集中删除有关发送邀请的客户端的数据。
作为一个优选的实施方案,步骤S2中,若客户端发来的连麦信令为退出连麦信令,所述连麦服务端根据该连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作,包括以下步骤:
所述连麦服务端根据客户端发来的所述退出连麦信令,确定要求退出的连麦对象;
若要求退出的连麦对象为参与者,则分别在三类数据集中删除有关要求退出的连麦对象的数据;同时,若连麦服务端判断当前没有其他参与者在麦,则判定本场连麦结束,将分别在三类数据集中删除有关发送邀请的客户端的数据;
若要求退出的连麦对象为房主,则判定本场连麦结束,连麦服务端向所有当前在麦的参与者通知连麦结束的信息,并分别在三类数据集中删除有关本场连麦的所有连麦对象的数据。
作为一个优选的实施方案,步骤S2中,若客户端发来的连麦信令为心跳消息信令,所述连麦服务端根据该连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作,包括以下步骤:
所述连麦服务端收到客户端定时发来的心跳消息信令后,在第二类数据集中更新与该客户端对应的心跳保活时间戳;
所述连麦服务端按照指定的检测时间,在第二类数据集中检查与该客户端对应的心跳保活时间戳,一旦检测到保活时间超过指定阈值,则判定该客户端掉线需要移除,将在三类数据集中删除有关该客户端的数据;同时,若连麦服务端判断当前没有其他参与者在麦,则判定本场连麦结束,将分别在三类数据集中删除有关房主的数据。
第二方面,本发明实施例提供一种多人连麦的状态控制系统,其包括连麦服务端、预设的数据库和至少两个客户端;
所述预设的数据库包括三类数据集,第一类数据集用于存储所有参与到多人连麦的连麦对象数据,第二类数据集用于存储参与到某一场连麦的连麦对象数据,第三类数据集用于存储连麦对象的基础信息;
所述连麦服务端用于:当进行多人连麦时,接收客户端发来的连麦信令,所述客户端发来的连麦信令为预先设置的多种连麦信令中的一种,且预先设置的多种连麦信令与连麦处理流程相对应;所述连麦服务端根据接收到的不同连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作。
第三方面,本发明实施例还提供一种存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现第一方面实施例中的方法。
第四方面,本发明实施例还提供一种电子设备,包括存储器和处理器,存储器上储存有在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现第一方面实施例中的方法。
本发明的有益效果在于:
本发明中采用专门的数据库来单独存储多人视频连麦的状态数据,可方便在数据库中随时查看当前的各种连麦状态数据;与此同时,将数据的存储功能从连麦服务端剥离,使得连麦服务端只对外提供信令的接口处理能力,可有效地提高连麦服务端的处理效率和资源利用率;并且,采用专门数据库来单独存储多人视频连麦的状态数据而非临时缓存数据,使得服务重启时连麦状态数据不会丢失,可以很方便的支持服务热更新。
除此之外,本方案还会预先设置多种与连麦处理流程相对应的连麦信令,连麦服务端根据接收到的不同连麦信令可进行相应的连麦处理,并会在预设数据库中对三类数据集进行相应的数据更新操作,不仅能够逻辑简洁的实现多人连麦的信令及状态处理,还能实现对多人连麦状态的有效控制,满足实际应用需求。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面对实施例对应的附图作一简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例中多人连麦的状态控制方法的流程图;
图2为本发明实施例中多人连麦的状态控制系统的结构框图。
图中:10-连麦服务端,20-数据库,30-客户端。
具体实施方式
针对现有技术中,未有一套逻辑较为简洁的针对多人视频连麦的信令及状态处理方法,且目前还存在无法随意查看或使用当前连麦状态数据,以及服务重启时临时缓存的连麦状态数据易丢失,无法方便的支持服务热更新等问题。本发明旨在提供一种多人连麦的状态控制方法、存储介质、电子设备及系统,不仅能够逻辑简洁的实现多人连麦的信令及状态处理,还能实时、便捷地查看和使用连麦状态数据,且数据安全性高、支持服务热更新,满足实际应用需求。
为达到上述技术效果,本发明的主要设计思路为:
在预设的数据库中创建三类数据集,第一类数据集用于存储所有参与到多人连麦的连麦对象数据,第二类数据集用于存储参与到某一场连麦的连麦对象数据,第三类数据集用于存储连麦对象的基础信息;
当进行多人连麦时,连麦服务端接收客户端发来的连麦信令,所述客户端发来的连麦信令为预先设置的多种连麦信令中的一种,且预先设置的多种连麦信令与连麦处理流程相对应;所述连麦服务端根据接收到的不同连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作。
由上述内容可知,本发明中采用专门的数据库来单独存储多人视频连麦的状态数据,可方便在数据库中随时查看当前的各种连麦状态数据;与此同时,将数据的存储功能从连麦服务端剥离,使得连麦服务端只对外提供信令的接口处理能力,可有效地提高连麦服务端的处理效率和资源利用率;并且,采用专门数据库来单独存储多人视频连麦的状态数据而非临时缓存数据,使得服务重启时连麦状态数据不会丢失,可以很方便的支持服务热更新。
除此之外,本方案还会预先设置多种与连麦处理流程相对应的连麦信令,连麦服务端根据接收到的不同连麦信令可进行相应的连麦处理,并会在预设数据库中对三类数据集进行相应的数据更新操作,不仅能够逻辑简洁的实现多人连麦的信令及状态处理,还能实现对多人连麦状态的有效控制,满足实际应用需求。
为使本发明要解决的技术问题、技术方案和优点更加清楚,下面将结合说明书附图以及具体的实施例对本发明的技术方案进行详细的说明。
但需说明的是:接下来要介绍的示例仅是一些具体的例子,而不作为限制本发明的实施例必须为如下具体的步骤、数值、条件、数据、顺序等。本领域技术人员可以通过阅读本说明书来运用本发明的构思来构造本说明书中未提到的更多实施例。
实施例一
参见图1所示,本实施例提供了一种多人连麦的状态控制方法,可适用于至少两个客户端进行视频连麦时的状态控制处理的情况。但可以理解的是,所述客户端包括主播使用的客户端(也称为主播端)以及一般用户使用的客户端(也称为用户端)。即,该方法适用场景不仅包括直播网络平台中主播与主播间的多人视频连麦场景,还可扩展至用户与用户间的多人视频连麦场景以及主播与多用户间的多人视频连麦场景等。并且,该方法可以由连麦服务端来执行,该连麦服务端可以由软件和/或硬件的方式来实现,可以集成于平台服务器中。具体来说,该方法包括以下步骤:
S1、在预设的数据库中创建三类数据集,第一类数据集用于存储所有参与到多人连麦的连麦对象数据,第二类数据集用于存储参与到某一场连麦的连麦对象数据,第三类数据集用于存储连麦对象的基础信息。
可以理解的是,本实施例设计使用专门数据库来单独存储多人视频连麦的状态数据,可方便在数据库中随时查看当前的各种连麦状态数据。例如,优选的可采用Redis作为预设的数据库来单独存储多人视频连麦的状态数据。与此同时,将数据的存储功能从连麦服务端剥离,使得连麦服务端只对外提供信令的接口处理能力,可有效地提高连麦服务端的处理效率和资源利用率;并且,采用专门数据库来单独存储多人视频连麦的状态数据而非临时缓存数据,使得服务重启时连麦状态数据不会丢失,可以很方便的支持服务热更新。
进一步地,本实施例为了能够逻辑简洁的实现多人连麦的信令及状态处理,特别设计将多人视频连麦的状态数据划分为三类数据集来分类存储。其中,第一类数据集用于存储所有参与到多人连麦的连麦对象数据,创建该数据集的目的是当某个连麦对象(如房主)发起邀请时,可通过查找该数据集来判断被邀请的连麦对象是否已经参与其他连麦中(由于一个主播或用户同时只能参与一场连麦,因此若该主播或用户已经存储在第一类数据集中则说明其已参与其它连麦)。也就是说,通过第一类数据集可获知连麦对象是否已参与连麦的状态信息。第二类数据集用于存储参与到某一场连麦的连麦对象数据,创建该数据集的目的是为了记录每场多人连麦中,参与到该场连麦的所有连麦对象的信息。优选的,还可在该第二类数据集中记录参与该场连麦的所有连麦对象的心跳保活时间戳,该心跳保活时间戳用以校验该连麦对象是否心跳超时,从而判断该连麦对象是否掉线需要移除。第三类数据集用于存储连麦对象的基础信息,创建该数据集的目的是为了记录所有连麦对象的基础信息,可包括:连麦对象唯一标识(如主播房间ID或用户身份ID)、连麦对象上麦时间戳、连麦对象状态(如0-待上麦,1-已上麦)以及房主房间号等信息。可以理解的是,房主是指在一场多人连麦中,有一个发起方作为这场连麦的房主,该房主可以邀请其他主播或用户上麦,其他主播或用户接受房主的邀请即会上麦,则受邀上麦者作为参与者。
具体来说,作为一种可选的实施方式,本实施例中所述第一类数据集所存储的连麦对象数据包括:所有参与到多人连麦的连麦对象的唯一标识,及其对应的房主房间号。所述第二类数据集所存储的连麦对象数据包括:参与到某一场连麦的连麦对象的唯一标识,及其对应的心跳保活时间戳。所述第三类数据集所存储的连麦对象的基础信息包括:连麦对象的唯一标识、连麦对象昵称、连麦对象头像、连麦对象上麦时间戳、连麦对象状态以及房主房间号。
示例性地,实际应用中,所创建的第一类数据集可如下表1所示:
属性 | 说明 |
存储位置 | REDIS |
存储类型 | HASH |
KEY | #multi_anchor#all_room_ids |
KEY TYPE | 完整KEY |
FIELD | 主播房间ID或用户身份ID |
VALUE | 房主房间号 |
所创建的第二类数据集可如下表2所示:
属性 | 说明 |
存储位置 | REDIS |
存储类型 | ZSET |
KEY | #multi_anchor#group#{MASTER_ROOM_ID} |
KEY TYPE | 前缀KEY,拼接房主房间ID成为完整KEY |
SCORE | 主播或用户的心跳保活时间戳 |
MEMBER | 主播房间ID或用户身份ID |
所创建的第三类数据集可如下表3所示:
表4:
字段 | 说明 |
room_id/user_id | 主播房间ID或用户身份ID |
nick | 昵称 |
icon | 头像 |
online_time | 上麦时间戳 |
status | 状态,0-待上麦,1-以上麦 |
master | 房主房间号 |
S2、当进行多人连麦时,连麦服务端接收客户端发来的连麦信令,所述客户端发来的连麦信令为预先设置的多种连麦信令中的一种,且预先设置的多种连麦信令与连麦处理流程相对应;所述连麦服务端根据接收到的不同连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作。
其中,预先设置的多种连麦信令与连麦处理流程相对应是指:不同的连麦处理流程可对应一种或几种连麦信令。例如,假设连麦处理流程包括连麦邀请流程和取消邀请流程,且预先设置的多种连麦信令包括房主发送邀请信令、参与者接受邀请信令、参与者拒绝邀请信令以及房主取消邀请信令。那么,其中的连麦邀请流程可对应房主发送邀请信令、参与者接受邀请信令以及参与者拒绝邀请信令;而取消邀请流程则可对应房主取消邀请信令。具体应用中,可根据实际的连麦处理流程情况来进行对应的连麦信令的预先设置,本实施例不做具体限定。
但为了能够逻辑简洁的实现多人连麦的信令及状态处理,作为一种优选的示例性实施方式,本实施例中所述预先设置的多种连麦信令可包括:房主发送邀请信令、参与者拒绝邀请信令、参与者接受邀请信令、房主取消邀请信令、房主移除参与者信令、退出连麦信令以及心跳消息信令。
示例性地,预先设置的多种连麦信令的设计代码可如下:
{
MAC_INVITE=1, //房主发送邀请信令
MAC_DENY=2, //参与者拒绝邀请信令
MAC_ACCEPT=3, //参与者接受邀请信令
MAC_CANCEL=4, //房主取消邀请信令
MAC_KICK=5, //房主移除参与者信令
MAC_LEAVE=6, //退出连麦信令
MAC_HEARTBEAT=7, //心跳消息信令
}
基于上述连麦信令设置可知,其中房主发送邀请信令、参与者拒绝邀请信令、参与者接受邀请信令,可对应连麦邀请流程;房主取消邀请信令可对应房主取消连麦邀请流程;房主移除参与者信令可对应房主移除某个连麦参与者流程;退出连麦信令可对应某个连麦参与者或房主主动退出连麦的流程;心跳消息信令则可对应超时检测流程。
进一步地,作为一种可选的实施方式,步骤S2中,若客户端发来的连麦信令为房主发送邀请信令,所述连麦服务端根据该连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作,具体包括以下操作:
S2-10、所述连麦服务端根据客户端发来的房主发送邀请信令(如MAC_INVITE),确定被邀请的连麦对象;并在所述第一类数据集中进行查询,判断被邀请的连麦对象是否已经在所述第一类数据集中,若存在,则认为被邀请的连麦对象已在其他连麦中,连麦服务端将向客户端回复邀请失败信息,结束操作;若不存在,则认为被邀请的连麦对象还未参与任何连麦中,转入步骤S2-11。
S2-11、连麦服务端向被邀请的连麦对象发出连麦邀请,并在所述预设数据库中对三类数据集进行以下数据更新操作:
将发送邀请的客户端的唯一标识、被邀请的连麦对象的唯一标识以及对应的房主房间号(当发送连麦邀请后,系统会自动为该场连麦分配房主房间号),均记录到第一类数据集中,用于标记当前两个连麦对象均已参与了多人连麦;例如,主播A向主播B发送邀请,则将主播A的房间ID、主播B的房间ID以及系统生成的房主房间号都记录到第一类数据集#multi_anchor#all_room_ids中;
将发送邀请的客户端的唯一标识以及被邀请的连麦对象的唯一标识均记录到第二类数据集中,并以发送邀请的客户端的唯一标识作为本场连麦的关键字信息(KEY),且使用当前时间作为心跳保活时间戳;例如,将主播A的房间ID、主播B的房间ID都记录到第二类数据集中KEY为#multi_anchor#group#A的数据中,且心跳保活时间戳score使用当前时间;
将发送邀请的客户端的基础信息以及被邀请的连麦对象的基础信息均记录到第三类数据集中,并分别以自身的唯一标识作为各自数据的关键字信息(KEY);同时,分别设置两者的连麦对象状态,例如:可将发送邀请的客户端的状态设置为“已上麦”,将被邀请的连麦对象的状态设置为“待上麦”;例如,可将主播A和主播B的基础信息,分别记录到第三类数据集中KEY为#multi_anchor#info#A和#multi_anchor#info#B的数据中,且主播A的状态status置为1(已上麦)、主播B的状态status置为0(待上麦)。
S2-12、被邀请的连麦对象收到连麦邀请后,若接受邀请,则向连麦服务端发送参与者接受邀请信令(如MAC_ACCEPT),连麦服务端收到该信令后将向客户端回复邀请成功信息,并在第三类数据集中将被邀请的连麦对象的状态更新为“已上麦”;例如,在第三类数据集中将KEY为#multi_anchor#info#B的状态status置为1,表示已成功上麦;
若拒绝邀请,则向连麦服务端发送参与者拒绝邀请信令(如MAC_DENY),连麦服务端收到该信令后将向客户端回复邀请被拒信息,并分别在三类数据集中删除有关被邀请的连麦对象的数据,例如:在第三类数据集中删除KEY为#multi_anchor#info#B的数据,在第一类数据集#multi_anchor#all_room_ids和第二类数据集的KEY为#multi_anchor#group#A的数据中删除主播B;同时,若连麦服务端判断当前没有其他参与者在麦,则判定本场连麦结束,将分别在三类数据集中删除有关发送邀请的客户端的数据,例如:在第二类数据集中删除KEY为#multi_anchor#group#A的数据,在第三类数据集中删除KEY为#multi_anchor#info#A的数据,并在第一类数据集#multi_anchor#all_room_ids中删除主播A。
若超过指定的回复时间(例如超过5秒)未处理,则连麦服务端通知双方邀请超时的信息,并分别在三类数据集中删除有关被邀请的连麦对象的数据;同时,若连麦服务端判断当前没有其他参与者在麦,则判定本场连麦结束,将分别在三类数据集中删除有关发送邀请的客户端的数据。
进一步地,作为一种可选的实施方式,步骤S2中,若客户端发来的连麦信令为房主取消邀请信令,所述连麦服务端根据该连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作,具体包括以下操作:
S2-20、所述连麦服务端根据客户端发来的房主取消邀请信令(如MAC_CANCEL),确定被取消邀请的连麦对象;并分别在三类数据集中删除有关被取消邀请的连麦对象的数据;同时,若连麦服务端判断当前没有其他参与者在麦,则判定本场连麦结束,将分别在三类数据集中删除有关发送邀请的客户端的数据。可以理解的是,在三类数据集中删除有关被取消邀请的连麦对象的数据时,其具体操作的内容同上述步骤S2-12中在三类数据集中删除有关被邀请的连麦对象的数据时的一样,详细内容可参见上文描述,此处不再赘述。
进一步地,作为一种可选的实施方式,步骤S2中,若客户端发来的连麦信令为房主移除参与者信令,所述连麦服务端根据该连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作,具体包括以下操作:
S2-30、所述连麦服务端根据客户端发来的房主移除参与者信令(如MAC_KICK),确定被移除的连麦对象;并分别在三类数据集中删除有关被移除的连麦对象的数据;同时,若连麦服务端判断当前没有其他参与者在麦,则判定本场连麦结束,将分别在三类数据集中删除有关发送邀请的客户端的数据。同样可以理解的是,在三类数据集中删除有关被移除的连麦对象的数据时,其具体操作的内容同步骤S2-12中在三类数据集中删除有关被邀请的连麦对象的数据时的一样,详细内容可参见上文描述,此处不再赘述。
进一步地,作为一种可选的实施方式,步骤S2中,若客户端发来的连麦信令为退出连麦信令,所述连麦服务端根据该连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作,具体包括以下操作:
S2-40、所述连麦服务端根据客户端发来的退出连麦信令(如MAC_LEAVE),确定要求退出的连麦对象;
若要求退出的连麦对象为参与者,则分别在三类数据集中删除有关要求退出的连麦对象的数据;同时,若连麦服务端判断当前没有其他参与者在麦,则判定本场连麦结束,将分别在三类数据集中删除有关发送邀请的客户端的数据;同样可以理解的是,在三类数据集中删除要求退出的连麦对象的数据时,其具体操作的内容同步骤S2-12中在三类数据集中删除有关被邀请的连麦对象的数据时的一样,详细内容可参见上文描述,此处不再赘述;
若要求退出的连麦对象为房主,则判定本场连麦结束,连麦服务端向所有当前在麦的参与者通知连麦结束的信息,并分别在三类数据集中删除有关本场连麦的所有连麦对象的数据。
进一步地,作为一种可选的实施方式,步骤S2中,若客户端发来的连麦信令为心跳消息信令,所述连麦服务端根据该连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作,具体包括以下操作:
S2-50、所述连麦服务端收到客户端定时发来的心跳消息信令(如MAC_KICK)后,将在第二类数据集中更新与该客户端对应的心跳保活时间戳(如score字段);可以理解的是,为了判断参与连麦的连麦对象是否正常在麦,所有参与多人连麦的连麦对象都会定时向连麦服务端发送心跳消息信令,以使得连麦服务端能在第二类数据集中对其心跳保活时间戳(score字段)进行更新,该心跳保活时间戳可用以校验该连麦对象是否心跳超时,从而判断该连麦对象是否掉线需要移除。
S2-51、所述连麦服务端按照指定的检测时间(如每秒检测一次),在第二类数据集中检查与该客户端对应的心跳保活时间戳(score字段),一旦检测到保活时间超过指定阈值(例如超过40秒),则判定该客户端掉线需要移除,将分别在三类数据集中删除有关该客户端的数据;同时,若连麦服务端判断当前没有其他参与者在麦,则判定本场连麦结束,将分别在三类数据集中删除有关房主的数据。
综上所述,通过上述步骤S1~S2的操作可以看出,本方案采用专门的数据库来单独存储多人视频连麦的状态数据,可方便在数据库中随时查看当前的各种连麦状态数据;与此同时,将数据的存储功能从连麦服务端剥离,使得连麦服务端只对外提供信令的接口处理能力,可有效地提高连麦服务端的处理效率和资源利用率;并且,采用专门数据库来单独存储多人视频连麦的状态数据而非临时缓存数据,使得服务重启时连麦状态数据不会丢失,可以很方便的支持服务热更新。
除此之外,本方案还会预先设置多种与连麦处理流程相对应的连麦信令,连麦服务端根据接收到的不同连麦信令可进行相应的连麦处理,并会在预设数据库中对三类数据集进行相应的数据更新操作,不仅能够逻辑简洁的实现多人连麦的信令及状态处理,还能实现对多人连麦状态的有效控制,满足实际应用需求。
实施例二
基于同一发明构思,如图2所示,本发明第二实施例提供一种多人连麦的状态控制系统,其包括连麦服务端10、预设的数据库20和至少两个客户端30。
其中,预设的数据库20包括三类数据集,第一类数据集用于存储所有参与到多人连麦的连麦对象数据,第二类数据集用于存储参与到某一场连麦的连麦对象数据,第三类数据集用于存储连麦对象的基础信息;
连麦服务端10用于:当进行多人连麦时,接收客户端30发来的连麦信令,所述客户端发来的连麦信令为预先设置的多种连麦信令中的一种,且预先设置的多种连麦信令与连麦处理流程相对应;所述连麦服务端根据接收到的不同连麦信令进行相应的连麦处理,并在所述预设数据库20中对三类数据集进行相应的数据更新操作。
前述方法实施例中的各种变化方式和具体实例同样适用于本实施例的系统,通过前述方法的详细描述,本领域技术人员可以清楚的知道本实施例中系统的实施方法,所以为了说明书的简洁,在此不再详述。
实施例三
基于同一发明构思,本发明第三实施例提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现如本发明任意实施例所提供的一种多人连麦的状态控制方法,该方法包括:
在预设的数据库中创建三类数据集,第一类数据集用于存储所有参与到多人连麦的连麦对象数据,第二类数据集用于存储参与到某一场连麦的连麦对象数据,第三类数据集用于存储连麦对象的基础信息;
当进行多人连麦时,连麦服务端接收客户端发来的连麦信令,所述客户端发来的连麦信令为预先设置的多种连麦信令中的一种,且预先设置的多种连麦信令与连麦处理流程相对应;所述连麦服务端根据接收到的不同连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作。
本发明实施例的计算机存储介质,可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是但不限于:电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、电线、光缆、RF等等,或者上述的任意合适的组合。
可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码,所述程序设计语言包括面向对象的程序设计语言,诸如Java、Smalltalk、C++,还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络,包括局域网(LAN)或广域网(WAN),连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
实施例四
基于同一发明构思,本发明第四实施例还提供一种电子设备,包括存储器和处理器,存储器上储存有在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现第一实施例中的所有方法步骤或部分方法步骤。
所称处理器可以是中央处理单元(Central Processing Unit,CPU),还可以是其他通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现成可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等,所述处理器是所述计算机装置的控制中心,利用各种接口和线路连接整个计算机装置的各个部分。
所述存储器可用于存储所述计算机程序和/或模块,所述处理器通过运行或执行存储在所述存储器内的计算机程序和/或模块,以及调用存储在存储器内的数据,实现所述计算机装置的各种功能。所述存储器可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等;存储数据区可存储根据手机的使用所创建的数据(比如音频数据、视频数据等)等。此外,存储器可以包括高速随机存取存储器,还可以包括非易失性存储器,例如硬盘、内存、插接式硬盘,智能存储卡(Smart Media Card,SMC),安全数字(Secure Digital,SD)卡,闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
总体来说,本发明实施例提供的一种多人连麦的状态控制方法、存储介质、电子设备及系统,不仅能够逻辑简洁的实现多人连麦的信令及状态处理,还能实时、便捷地查看和使用连麦状态数据,且数据安全性高、支持服务热更新,满足实际应用需求。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
注意:上述的具体实施例仅是例子而非限制,且本领域技术人员可以根据本发明的构思从上述分开描述的各个实施例中合并和组合一些步骤和装置来实现本发明的效果,这种合并和组合而成的实施例也被包括在本发明中,在此不一一描述这种合并和组合。
本发明实施例中提及的优点、优势、效果等仅是示例,而非限制,不能认为这些优点、优势、效果等是本发明的各个实施例必须具备的。另外,本发明实施例公开的上述具体细节仅是为了示例的作用和便于理解的作用,而非限制,上述细节并不限制本发明实施例必须采用上述具体的细节来实现。
本发明实施例中涉及的器件、装置、设备、系统的方框图仅作为例示性的例子,并且不意图要求或暗示必须按照方框图示出的方式进行连接、布置、配置。如本领域技术人员将认识到的,可以按任意方式连接、布置、配置这些器件、装置、设备、系统。诸如“包括”、“包含”、“具有”等等的词语是开放性词汇,指“包括但不限于”,且可与其互换使用。本发明实施例所使用的词汇“或”和“和”指词汇“和/或”,且可与其互换使用,除非上下文明确指示不是如此。本发明实施例所使用的词汇“诸如”指词组“诸如但不限于”,且可与其互换使用。
本发明实施例中的步骤流程图以及以上方法描述仅作为例示性的例子,并且不意图要求或暗示必须按照给出的顺序进行各个实施例的步骤。如本领域技术人员将认识到的,可以按任意顺序进行以上实施例中的步骤的顺序。诸如“其后”、“然后”、“接下来”等等的词语不意图限制步骤的顺序;这些词语仅用于引导读者通读这些方法的描述。此外,例如使用冠词“一个”、“一”或者“该”对于单数的要素的任何引用不被解释为将该要素限制为单数。
另外,本发明各个实施例中的步骤和装置并非仅限定于某个实施例中实行,事实上,可以根据本发明的概念来结合本文中的各个实施例中相关的部分步骤和部分装置,以构思新的实施例,而这些新的实施例也包括在本发明的范围内。
本发明实施例中的各个操作可以通过能够进行相应的功能的任何适当的手段而进行。该手段可以包括各种硬件和/或软件组件和/或模块,包括但不限于硬件的电路或处理器。
本发明实施例的方法包括用于实现上述的方法的一个或多个动作。方法和/或动作可以彼此互换而不脱离权利要求的范围。换句话说,除非指定了动作的具体顺序,否则可以修改具体动作的顺序和/或使用而不脱离权利要求的范围。
本领域技术人员可以不脱离由所附权利要求定义的教导的技术而进行对在此所述的技术的各种改变、替换和更改。此外,本公开的权利要求的范围不限于以上所述的处理、机器、制造、事件的组成、手段、方法和动作的具体方面。可以利用与在此所述的相应方面进行基本相同的功能或者实现基本相同的结果的当前存在的或者稍后要开发的处理、机器、制造、事件的组成、手段、方法或动作。因而,所附权利要求包括在其范围内的这样的处理、机器、制造、事件的组成、手段、方法或动作。
提供所公开的方面的以上描述以使本领域的任何技术人员能够做出或者使用本发明。对这些方面的各种修改对于本领域技术人员而言是非常显而易见的,并且在此定义的一般原理可以应用于其他方面而不脱离本发明的范围。因此,本发明不意图被限制到在此示出的方面,而是按照与在此公开的原理和新颖的特征一致的最宽范围。
为了例示和描述的目的已经给出了以上描述。此外,此描述不意图将本发明的实施例限制到在此公开的形式。尽管以上已经讨论了多个示例方面和实施例,但是本领域技术人员将认识到其某些变型、修改、改变、添加和子组合。且本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。
Claims (10)
1.一种多人连麦的状态控制方法,其特征在于,包括以下步骤:
S1、在预设的数据库中创建三类数据集,第一类数据集用于存储所有参与到多人连麦的连麦对象数据,第二类数据集用于存储参与到某一场连麦的连麦对象数据,第三类数据集用于存储连麦对象的基础信息;
S2、当进行多人连麦时,连麦服务端接收客户端发来的连麦信令,所述客户端发来的连麦信令为预先设置的多种连麦信令中的一种,且预先设置的多种连麦信令与连麦处理流程相对应;所述连麦服务端根据接收到的不同连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作。
2.如权利要求1所述的多人连麦的状态控制方法,其特征在于,步骤S1中,所述第一类数据集所存储的连麦对象数据包括:所有参与到多人连麦的连麦对象的唯一标识,及其对应的房主房间号;
所述第二类数据集所存储的连麦对象数据包括:参与到某一场连麦的连麦对象的唯一标识,及其对应的心跳保活时间戳;
所述第三类数据集所存储的连麦对象的基础信息包括:连麦对象的唯一标识、连麦对象上麦时间戳、连麦对象状态以及房主房间号;
步骤S2中,所述预先设置的多种连麦信令包括:房主发送邀请信令、参与者拒绝邀请信令、参与者接受邀请信令、房主取消邀请信令、房主移除参与者信令、退出连麦信令以及心跳消息信令。
3.如权利要求2所述的多人连麦的状态控制方法,其特征在于,步骤S2中,若客户端发来的连麦信令为房主发送邀请信令,所述连麦服务端根据该连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作,包括以下步骤:
所述连麦服务端根据客户端发来的所述房主发送邀请信令,确定被邀请的连麦对象;并在所述第一类数据集中进行查询,判断被邀请的连麦对象是否已存在;若不存在,则向被邀请的连麦对象发出连麦邀请,并在所述预设数据库中对三类数据集进行以下数据更新操作:
将发送邀请的客户端的唯一标识、被邀请的连麦对象的唯一标识以及对应的房主房间号均记录到第一类数据集中;
将发送邀请的客户端的唯一标识以及被邀请的连麦对象的唯一标识均记录到第二类数据集中,并以发送邀请的客户端的唯一标识作为本场连麦的关键字信息,且使用当前时间作为心跳保活时间戳;
将发送邀请的客户端的基础信息以及被邀请的连麦对象的基础信息均记录到第三类数据集中,并分别以自身的唯一标识作为各自数据的关键字信息;同时,分别设置两者的连麦对象状态。
4.如权利要求3所述的多人连麦的状态控制方法,其特征在于:
被邀请的连麦对象收到连麦邀请后,若接受邀请,则发送所述参与者接受邀请信令,连麦服务端收到该信令后向客户端回复邀请成功信息,并在第三类数据集中更新被邀请的连麦对象的状态;
若拒绝邀请,则发送所述参与者拒绝邀请信令,连麦服务端收到该信令后向客户端回复邀请被拒信息,并分别在三类数据集中删除有关被邀请的连麦对象的数据;同时,若连麦服务端判断当前没有其他参与者在麦,则判定本场连麦结束,将分别在三类数据集中删除有关发送邀请的客户端的数据;
若超过指定回复时间未处理,则连麦服务端通知双方邀请超时的信息,并分别在三类数据集中删除有关被邀请的连麦对象的数据;同时,若连麦服务端判断当前没有其他参与者在麦,则判定本场连麦结束,将分别在三类数据集中删除有关发送邀请的客户端的数据。
5.如权利要求2所述的多人连麦的状态控制方法,其特征在于,步骤S2中,若客户端发来的连麦信令为房主取消邀请信令/房主移除参与者信令,所述连麦服务端根据该连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作,包括以下步骤:
所述连麦服务端根据客户端发来的所述房主取消邀请信令/所述房主移除参与者信令,确定被取消邀请的连麦对象/被移除的连麦对象;并分别在三类数据集中删除有关被取消邀请的连麦对象/被移除的连麦对象的数据;
同时,若连麦服务端判断当前没有其他参与者在麦,则判定本场连麦结束,将分别在三类数据集中删除有关发送邀请的客户端的数据。
6.如权利要求2所述的多人连麦的状态控制方法,其特征在于,步骤S2中,若客户端发来的连麦信令为退出连麦信令,所述连麦服务端根据该连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作,包括以下步骤:
所述连麦服务端根据客户端发来的所述退出连麦信令,确定要求退出的连麦对象;
若要求退出的连麦对象为参与者,则分别在三类数据集中删除有关要求退出的连麦对象的数据;同时,若连麦服务端判断当前没有其他参与者在麦,则判定本场连麦结束,将分别在三类数据集中删除有关发送邀请的客户端的数据;
若要求退出的连麦对象为房主,则判定本场连麦结束,连麦服务端向所有当前在麦的参与者通知连麦结束的信息,并分别在三类数据集中删除有关本场连麦的所有连麦对象的数据。
7.如权利要求2所述的多人连麦的状态控制方法,其特征在于,步骤S2中,若客户端发来的连麦信令为心跳消息信令,所述连麦服务端根据该连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作,包括以下步骤:
所述连麦服务端收到客户端定时发来的心跳消息信令后,在第二类数据集中更新与该客户端对应的心跳保活时间戳;
所述连麦服务端按照指定的检测时间,在第二类数据集中检查与该客户端对应的心跳保活时间戳,一旦检测到保活时间超过指定阈值,则判定该客户端掉线需要移除,将在三类数据集中删除有关该客户端的数据;同时,若连麦服务端判断当前没有其他参与者在麦,则判定本场连麦结束,将分别在三类数据集中删除有关房主的数据。
8.一种存储介质,其上存储有计算机程序,其特征在于:所述计算机程序被处理器执行时实现权利要求1至7任一项所述的方法。
9.一种电子设备,包括存储器和处理器,存储器上存储有在所述处理器上运行的计算机程序,其特征在于:所述处理器执行所述计算机程序时实现权利要求1至7任一项所述的方法。
10.一种多人连麦的状态控制系统,其特征在于,所述系统包括连麦服务端、预设的数据库和至少两个客户端;
所述预设的数据库包括三类数据集,第一类数据集用于存储所有参与到多人连麦的连麦对象数据,第二类数据集用于存储参与到某一场连麦的连麦对象数据,第三类数据集用于存储连麦对象的基础信息;
所述连麦服务端用于:当进行多人连麦时,接收客户端发来的连麦信令,所述客户端发来的连麦信令为预先设置的多种连麦信令中的一种,且预先设置的多种连麦信令与连麦处理流程相对应;所述连麦服务端根据接收到的不同连麦信令进行相应的连麦处理,并在所述预设数据库中对三类数据集进行相应的数据更新操作。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110751155.9A CN113630610A (zh) | 2021-07-02 | 2021-07-02 | 多人连麦的状态控制方法、存储介质、电子设备及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110751155.9A CN113630610A (zh) | 2021-07-02 | 2021-07-02 | 多人连麦的状态控制方法、存储介质、电子设备及系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN113630610A true CN113630610A (zh) | 2021-11-09 |
Family
ID=78378882
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110751155.9A Pending CN113630610A (zh) | 2021-07-02 | 2021-07-02 | 多人连麦的状态控制方法、存储介质、电子设备及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113630610A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114125486A (zh) * | 2021-12-01 | 2022-03-01 | 杭州米络星科技(集团)有限公司 | 连麦调度方法、装置及电子设备 |
CN114189702A (zh) * | 2021-12-07 | 2022-03-15 | 广州市百果园网络科技有限公司 | 基于直播间的资源对象分配方法、装置、设备及存储介质 |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109040980A (zh) * | 2018-08-10 | 2018-12-18 | 苏州塔林博卡信息科技有限公司 | 电子信息分发系统及方法 |
CN109413455A (zh) * | 2018-09-30 | 2019-03-01 | 武汉斗鱼网络科技有限公司 | 一种用于语音连麦互动的用户信息显示方法及装置 |
CN109995741A (zh) * | 2018-01-02 | 2019-07-09 | 武汉斗鱼网络科技有限公司 | 一种网络直播中连麦实现方法及系统 |
CN110225375A (zh) * | 2018-03-01 | 2019-09-10 | 武汉斗鱼网络科技有限公司 | 一种直播间连麦权限检测方法、存储介质、设备及系统 |
CN111372090A (zh) * | 2020-02-25 | 2020-07-03 | 北京达佳互联信息技术有限公司 | 一种连麦的实现方法、装置、电子设备及存储介质 |
CN111836068A (zh) * | 2020-07-24 | 2020-10-27 | 北京达佳互联信息技术有限公司 | 直播互动方法、装置、服务器及存储介质 |
CN112003711A (zh) * | 2020-07-31 | 2020-11-27 | 北京达佳互联信息技术有限公司 | 连麦方法及装置 |
CN112040259A (zh) * | 2020-08-28 | 2020-12-04 | 广州华多网络科技有限公司 | 一种连麦开播的方法、服务端、系统、存储介质及设备 |
US20210103610A1 (en) * | 2019-10-07 | 2021-04-08 | Platfarm Inc. | Apparatus and a method for providing expression item services which constructing digital communication environments |
-
2021
- 2021-07-02 CN CN202110751155.9A patent/CN113630610A/zh active Pending
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109995741A (zh) * | 2018-01-02 | 2019-07-09 | 武汉斗鱼网络科技有限公司 | 一种网络直播中连麦实现方法及系统 |
CN110225375A (zh) * | 2018-03-01 | 2019-09-10 | 武汉斗鱼网络科技有限公司 | 一种直播间连麦权限检测方法、存储介质、设备及系统 |
CN109040980A (zh) * | 2018-08-10 | 2018-12-18 | 苏州塔林博卡信息科技有限公司 | 电子信息分发系统及方法 |
CN109413455A (zh) * | 2018-09-30 | 2019-03-01 | 武汉斗鱼网络科技有限公司 | 一种用于语音连麦互动的用户信息显示方法及装置 |
US20210103610A1 (en) * | 2019-10-07 | 2021-04-08 | Platfarm Inc. | Apparatus and a method for providing expression item services which constructing digital communication environments |
CN111372090A (zh) * | 2020-02-25 | 2020-07-03 | 北京达佳互联信息技术有限公司 | 一种连麦的实现方法、装置、电子设备及存储介质 |
CN111836068A (zh) * | 2020-07-24 | 2020-10-27 | 北京达佳互联信息技术有限公司 | 直播互动方法、装置、服务器及存储介质 |
CN112003711A (zh) * | 2020-07-31 | 2020-11-27 | 北京达佳互联信息技术有限公司 | 连麦方法及装置 |
CN112040259A (zh) * | 2020-08-28 | 2020-12-04 | 广州华多网络科技有限公司 | 一种连麦开播的方法、服务端、系统、存储介质及设备 |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114125486A (zh) * | 2021-12-01 | 2022-03-01 | 杭州米络星科技(集团)有限公司 | 连麦调度方法、装置及电子设备 |
CN114125486B (zh) * | 2021-12-01 | 2023-11-07 | 杭州米络星科技(集团)有限公司 | 连麦调度方法、装置及电子设备 |
CN114189702A (zh) * | 2021-12-07 | 2022-03-15 | 广州市百果园网络科技有限公司 | 基于直播间的资源对象分配方法、装置、设备及存储介质 |
WO2023103846A1 (zh) * | 2021-12-07 | 2023-06-15 | 广州市百果园网络科技有限公司 | 基于直播间的资源对象分配方法、装置、设备及存储介质 |
CN114189702B (zh) * | 2021-12-07 | 2023-09-26 | 广州市百果园网络科技有限公司 | 基于直播间的资源对象分配方法、装置、设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109756504B (zh) | 一种基于直播平台的通信方法及相关装置 | |
CN100395766C (zh) | 对网络游戏用户进行时间限制的方法和系统 | |
CN113630610A (zh) | 多人连麦的状态控制方法、存储介质、电子设备及系统 | |
CN106685971A (zh) | 客户端连麦直播处理方法和装置 | |
CN105933375B (zh) | 一种连麦会话的监测方法、装置和服务器 | |
KR101859235B1 (ko) | 범용 플러그 앤 플레이 가능 텔레포니 장치들과 무선 영역 네트워크 장치들 사이의 멀티미디어 회의 시스템 및 방법 | |
JP2007534076A (ja) | ネットワークチャット環境におけるチャット負荷管理のためのシステム及び方法 | |
CN111107441B (zh) | 一种连麦通信建立方法、存储介质、电子设备及系统 | |
CN110856011A (zh) | 一种分组进行直播互动的方法、电子设备及存储介质 | |
CN112040259A (zh) | 一种连麦开播的方法、服务端、系统、存储介质及设备 | |
WO2015096802A1 (zh) | 消息发送方法、装置及服务器 | |
CN103905430B (zh) | 一种实名认证的方法及系统 | |
CN111432228A (zh) | 匹配主播的方法、装置、设备及存储介质 | |
CN106162042A (zh) | 一种视频会议的方法、服务器及终端 | |
CN106131602B (zh) | 基于主播端的交互系统及其方法 | |
CN105323537A (zh) | 使用移动平台的视频会议 | |
CN113489736A (zh) | 多媒体会议的实现方法、装置、设备及存储介质 | |
CN110708493B (zh) | 一种获取参与视联网会议的权限的方法及装置 | |
CN105828110A (zh) | 业务对象投放方法、装置以及服务器 | |
CN108668151B (zh) | 音视频交互方法及装置 | |
CN111355919B (zh) | 一种通信会话控制方法及装置 | |
US20130041491A1 (en) | Communication system and communication method | |
CN103684804A (zh) | 一种会议订阅的方法及装置 | |
CN111195434A (zh) | 一种游戏云公共服务平台 | |
CN114499827B (zh) | 一种评标方法、装置及电子设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |