CN115499417A - 一种数据分发方法、服务端和电子设备 - Google Patents
一种数据分发方法、服务端和电子设备 Download PDFInfo
- Publication number
- CN115499417A CN115499417A CN202110676455.5A CN202110676455A CN115499417A CN 115499417 A CN115499417 A CN 115499417A CN 202110676455 A CN202110676455 A CN 202110676455A CN 115499417 A CN115499417 A CN 115499417A
- Authority
- CN
- China
- Prior art keywords
- service
- client
- sfu
- room
- information
- 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
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
Abstract
本申请公开了一种数据分发方法、服务端和电子设备。本申请的数据分发方法包括:利用SFU服务获取客户端信息,以及利用SFU服务获取来自客户端的媒体流;利用SFU服务将所述媒体流发布到与所述客户端信息对应的PipeTopic中;利用SFU服务从MCU处确定客户端可订阅的其他客户端信息,根据可订阅的其他客户端信息从PDC服务中订阅PipeTopic,并将从订阅的PipeTopic中获得的媒体流转发给客户端。本申请可以提高实时通信场景下媒体流传输的实时性,降低服务器资源的占用率。
Description
技术领域
本申请涉及数据处理技术领域,尤其涉及一种数据分发方法、服务端和电子设备。
背景技术
互联网的进步和5G(5th Generation Mobile Communication Technology,第五代移动通信技术,简称为5G)技术的普及,促进了线上实时互动领域蓬勃的发展,在线教育、视频会议、电商直播等诸多实时互动场景需求激增,在迅速推动实时音视频发展的同时,也对实时音视频技术提出了更高的要求。
在大规模实时音视频的场景下,要保证用户的良好体验,不仅考验客户端的音视频处理能力,对服务端的架构设计也是一个重大的挑战。若设计高可用的实时音视频的流媒体服务,需要解决的一个核心问题就是单点和集群模式下的媒体分发方案选择,市场上现有的流媒体服务架构主要有以下两种。
第一种流媒体服务架构:
单一媒体服务架构,该架构是较为简单的一种设计。如图1所示,多个客户端Client分别与媒体服务MediaServer建立连接,加入到同一个房间内。客户端Client向媒体服务MediaServer发送媒体流,媒体服务MediaServer将接收到的媒体流转发给其他客户端Client,实现音视频通话。该方案至少存在以下缺陷:
不同客户端必须连接到同一个媒体服务上才能通话,如果客户端的地理位置相距较远,可能造成明显的延迟、卡顿现象;且该流媒体服务架构不符合弹性、高可用架构的设计理念,当一台服务出现问题,这个服务上的所有数据业务,例如所有的音视频通话将无法继续进行,客户端需要退出通话重新连接其他服务器。
第二种流媒体服务架构:
级联媒体服务架构,是通过信令调度服务(以下简称MCU)来控制多台媒体服务之间的媒体流转发,使得一台媒体服务上的客户端可以从另一台媒体服务上订阅到其他客户端的媒体流。如图2所示,MCU通过信令控制媒体服务MediaServer两两之间建立媒体链路,通过媒体链路在媒体服务MediaServer间传输音视频流,以客户端Client1、Client2分别连接两个媒体服务MediaServer为例,若客户端Client1在先加入媒体服务MediaServer1,客户端Client2在后加入媒体服务MediaServer2,此时需要MCU通知媒体服务MediaServer2将客户端Client2的媒体流转发到媒体服务MediaServer1,由媒体服务MediaServer1将接收到的媒体流转发给客户端Client1,从而实现两个媒体服务MediaServer、不同客户端之间的音视频通话。该方案至少存在以下缺陷:
集群模式下服务间媒体传输链路较长,导致音视频延迟变大,且多台媒体服务间两两之间建立连接,形成网状结构,整体架构复杂度较高,不易维护,此外服务器间传输音视频占用的带宽资源较多。
发明内容
本申请的目的旨在至少能解决上述的技术缺陷之一,特提出以下技术方案,基于发布订阅模式重新构建流媒体服务架构,提高实时通信场景下媒体流传输的实时性,降低服务器资源的占用率。
本申请实施例采用下述技术方案:
本申请的一方面,提供一种数据分发方法,由服务端执行,所述服务端上部署有SFU服务、PDC服务和MCU,PDC服务中设置有PipeTopic,所述方法包括:利用SFU服务获取客户端信息,以及利用SFU服务获取来自客户端的媒体流;利用SFU服务从MCU处确定客户端可订阅的其他客户端信息,根据可订阅的其他客户端信息从PDC服务中订阅PipeTopic,并将从订阅的PipeTopic中获得的媒体流转发给客户端。
本申请的另一方面,提供一种数据分发服务端,所述服务端上部署有SFU服务、PDC服务和MCU,PDC服务中设置有PipeTopic;所述数据分发服务端用于实现数据分发方法。
本申请的又一方面,还提供一种电子设备,包括处理器;以及被安排成存储计算机可执行指令的存储器,所述可执行指令在被执行时使所述处理器执行数据分发方法。
本申请实施例采用的上述至少一个技术方案能够达到以下有益效果:
本申请通过在服务端上部署了SFU服务、PDC服务和MCU服务重新设计了服务架构,通过SFU服务和PDC服务进行媒体流的转发与控制,通过MCU进行媒体流分发过程中的信令控制,将媒体流和信令分开处理,提高数据分发的处理效率;
在数据分发过程中,利用SFU服务与PDC服务之间的发布订阅模式,实现不同SFU服务之间媒体数据的互通,显著减少了传输媒体数据所占用的带宽资源和端口资源,并且在传输媒体数据时,是通过MCU确定SFU服务可订阅的其他客户端信息,使得SFU服务对下行的媒体数据具有选择权,从而能够节省服务端和客户端下行带宽资源,降低客户端的解码压力,提高数据分发的时效性,使得在大规模实时通信场景下媒体流的传输具有较高的实时性,为音视频通话的实时性奠定基础。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1为单一媒体服务架构示意图;
图2为级联媒体服务架构示意图;
图3为本申请实施例示出的数据分发方法流程图;
图4为本申请实施例示出的基于发布订阅模式的流媒体服务架构示意图;
图5为本申请实施例示出的数据发布示意图;
图6为本申请实施例示出的数据分发示意图;
图7为本申请实施例示出的数据订阅示意图;
图8为本申请实施例示出的数据分发服务端的结构框图;
图9为本申请实施例示出的电子设备示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
针对现有技术中流媒体服务架构,在大规模实时通信场景下,音视频传输的实时性及服务器资源占用等问题,本申请实施例采用发布订阅模式重新设计了流媒体服务架构,即在服务端上部署了SFU(Stream Forwarding Unit,媒体转发单元)服务,PDC(Pipeline Distribution Center,媒体分发中心)服务和MCU(Message-signalling unitControl Unit,信令控制单元),PDC服务中设置有PipeTopic,利用SFU服务负责媒体流转发、利用PDC服务负责媒体数据的分发与控制,利用MCU负责信令调度,通过SFU服务、PDC服务和MCU三者间的相互配合完成数据的分发,使得大规模实时通信场景下具有较高时效性的音视频通话。
以下结合附图,详细说明本申请实施例提供的技术方案。
图3为本申请实施例示出的数据分发方法流程图,本实施例以数据分发方法由服务端执行为例,其中服务端在硬件上可以例如为服务器或者电子设备中的中央处理器,在软件上可以例如为服务器或者电子设备中的相关后台服务。
在本申请实施例重新设计的流媒体服务架构中,服务端上部署有SFU服务、PDC服务和MCU,这里SFU服务、PDC服务和MCU可以部署在同一服务端也可以部署在不同服务端,本申请实施例对此不作限定。一般地,在流媒体服务架构中,会涉及多个SFU服务,多个SFU服务可以部署在同一服务端,也可以部署在不同服务端。
如图3所示,本实施例的方法包括下述步骤:
步骤S310,利用SFU服务获取客户端信息,以及利用SFU服务获取来自客户端的媒体流。
一般地,在客户端加入房间时,客户端会通过所加入的房间向SFU服务发送客户端信息,在客户端接收到待发出到房间中的媒体流时,客户端会将该媒体流发送给SFU服务,由此,SFU服务会从客户端获取到客户端信息和来自客户端的媒体流。
步骤S320,利用SFU服务将所述媒体流发布到与客户端信息对应的PipeTopic中。
这里客户端信息可以理解为客户端标识和客户端所加入房间的房间信息,基于房间信息确定出发布媒体流的PipeTopic和PipePartition,基于客户端标识确定出用于缓存媒体流的Pipe。
步骤S330,利用SFU服务从MCU处确定客户端可订阅的其他客户端信息,根据可订阅的其他客户端信息从PDC服务中订阅PipeTopic,并将从订阅的PipeTopic中获得的媒体流转发给客户端。
由图3所示可知,本实施例通过在服务端上部署了SFU服务、PDC服务和MCU服务重新设计了服务架构,通过SFU服务和PDC服务进行媒体流的转发与控制,通过MCU进行媒体流分发过程中的信令控制,将媒体流和信令分开处理,提高数据分发的处理效率;在数据分发过程中,利用SFU服务与PDC服务之间的发布订阅模式,实现不同SFU服务之间媒体数据的互通,显著减少了传输媒体数据所占用的带宽资源和端口资源,并且在传输媒体数据时,是通过MCU确定SFU服务可订阅的其他客户端信息,使得SFU服务对下行的媒体数据具有选择权,从而能够节省服务端和客户端下行带宽资源,降低客户端的解码压力,提高数据分发的时效性,使得在大规模实时通信场景下媒体流的传输具有较高的实时性,为音视频通话的实时性奠定基础。
本实施例中的服务端主要采用发布订阅模式进行数据分发处理,在客户端加入房间后,会触发媒体流的发布过程和媒体流的订阅过程。参考图4,媒体流的发布过程包括:
客户端加入房间后,客户端会将客户端信息发送给相应的SFU服务,这里客户端信息包括客户端标识和客户端所加入房间的房间信息,房间信息包括房间类型和房间ID。
客户端所加入的房间可能连接一个或多个SFU服务,通过客户端的选择将客户端信息发送到相应的SFU服务中,若用户想要向其加入的房间内发送音频或视频,此时用户会通过客户端将由音频和/或视频形成的媒体流发送给SFU服务。
SFU服务获取到客户端信息和媒体流之后,一方面创建Producer,将客户端发送的媒体流发布到与房间类型对应的PipeTopic下,PDC服务会根据与房间ID对应的PipePartition对SFU服务发布的媒体流进行数据分区,即PDC服务在PipePartition建立管道Pipe,将客户端发布的媒体数据输入到与客户端标识对应的Pipe中。另一方面,SFU服务还将获取到的客户端信息发送给MCU,由MCU基于客户端信息对客户端进行管理。
继续参考图4,媒体流的订阅过程包括:
在SFU服务将客户端信息发送给MCU之后,MCU基于客户端所加入房间的房间信息确认出该客户端可订阅的其他客户端信息并发送给SFU服务,SFU服务在得到客户端可订阅的其他客户端信息之后,生成Consumer对象从PipeTopic中拉取PipePartition下一个或多个Pipe中的媒体数据进行消费,通过消费将其他客户端发布的媒体流通过SFU服务发送给客户端,实现媒体流的订阅。
在上述实施例中,Pipe表示数据传输管道,是PDC服务中最小传输单元,可实时传输媒体数据,也可对媒体数据进行指定长度的缓存;PipeTopic表示管道模式或管道主题,例如在实时通信场景下一般划分为通话模式、直播模式、监控模式,利用PipeTopic可以较为方便地标识不同类型的媒体流需求;PipePartition表示管道分区,用于分隔PipeTopic下的媒体数据,一个管道模式下可以有多个PipePartition,一个PipePartition下可以有多个Pipe;Producer表示生产者,主要用于生产媒体数据到PipeTopic中;Consumer从订阅的PipeTopic中拉取媒体数据进行消费,所述消费即对数据进行处理,以使媒体数据格式等兼容拉取端或接收端的要求,包括对数据格式的转换处理等。
下面结合图5至图7,详细说明媒体流的上行发布过程、媒体分发中心的控制过程和媒体流的下行订阅过程。
在一些实施例中,在服务端上部署负载媒体流转发的SFU服务、负责媒体数据的分发与控制的PDC服务和负责信令调度的MCU时,还部署SFU服务和客户端之间的第一连接通道,第一连接通道包括基于TCP协议的第一链路和基于UDP协议的第二链路,第一链路用于客户端和服务端之间的信令交互,第二链路用于传输客户端和服务端之间的媒体流;以及部署SFU服务和PDC服务之间的第二连接通道,第二连接通道包括基于UDP协议的第三链路,第三链路用于传输所有发布的媒体数据;部署SFU服务和MCU之间的第三连接通道,第三连接通道基于Http协议进行通信。
如图5所示,在部署好服务端之后,媒体流的上行发布过程包括:
客户端Client1通过TCP信令加入房间A后,通过第一链路向SFU1服务发送客户端Client1的客户端信息,以及通过第二链路向SFU1服务发送媒体流。这里,客户端Client1向SFU1服务发送客户端信息和媒体流的顺序不分先后,可以按需发送。例如在客户端Client1加入房间A时,即向SFU1服务发送客户端Client1的客户端信息,在客户端Client1接收到音频或视频数据时,客户端Client1将接收到的音频或视频数据以媒体流的形式发送给SFU1服务。
在SFU1服务获取到客户端Client1的客户端信息之后,SFU1服务根据PipeTopic、PipePartition、Pipe和媒体流生成一个Producer对象,其中,PipeTopic与房间类型具有对应关系,PipePartition与房间ID具有对应关系,Pipe与客户端标识具有对应关系,由该Producer生产媒体数据并发布到与房间类型对应的PipeTopic中,由PDC服务根据房间ID对应的PipePartition对媒体数据进行分区,将媒体数据输入到与客户端标识对应的Pipe中。
此外,SFU1服务在接收到的客户端Client1的客户端信息时,还通过第三连接通道将客户端Client1的客户端信息发送给MCU,由MCU根据接收到的客户端信息对客户端进行管理,例如将客户端Client1所加入房间的房间类型、房间ID,客户端Client1的标识写入到客户端信息表中。
参考图5,本实施例中的MCU在数据分发过程中,MCU基于客户端信息表对客户端进行管理,例如在客户端加入房间时、在客户端发布媒体流时,在客户端发布媒体流异常时,都会更新客户端信息表,此外本实施例中的MCU还负责房间管理和SFU管理,房间管理包括但不限于房间创建管理、房间删除管理、房间广播管理等;SFU管理包括但不限于服务注册、服务发现等管理。
如图6所示,在媒体数据发布到PDC服务后,进入媒体分发中心的控制过程:
本实施例中的PDC服务是基于发布订阅模式设计的,PDC服务内部根据PipeTopic对媒体数据进行分类,Producer对象只需将媒体数据发布到PipeTopic上,Consumer从订阅的PipeTopic中消费媒体数据即可。
PipeTopic依据PipePartition对媒体数据进行分区,每个PipeTopic可包含一个或多个PipePartition,PipePartition中创建有传输媒体数据的Pipe,并以具有唯一性的ID标识各个Pipe,这里Pipe唯一性的ID可以为客户端标识,例如为客户端ID,一个Pipe对应客户端发布的一条媒体流。
参考图6,PDC服务在接收到SFU1服务发布到指定PipeTopic的媒体数据之后,先基于PipePartition对媒体数据进行分区,再将媒体数据输入到PipePartition下的Pipe中,即所有发布的媒体数据都被输入到指定PipeTopic下指定PipePartition的Pipe中。当有SFU订阅了该PipeTopic后,可选择将PipePartition下的指定Pipe或者所有Pipe进行媒体数据的消费。
如图7所示,在PDC服务中存在媒体数据之后,进入媒体流的下行订阅过程:
在本实施例的一个应用实例中,以客户端Client1通过TCP信令加入房间A为例,此时客户端Client1通过房间A连接到SFU1服务,参考上文图5所示的实施例,SFU1通过第一链路获取客户端Client1的客户端信息,所述客户端信息包括客户端Client1所加入房间的房间信息和客户端标识,此时SFU1服务根据客户端Client1所加入房间的房间信息从MCU处确定PDC服务中客户端Client1可订阅的其他客户端信息。
这里,可订阅的其他客户端信息的确定过程包括:
首先,SFU1服务接收来自MCU的其他客户端信息,这里的其他客户端信息是MCU接收到客户端Client1所加入房间的房间信息之后,根据其管理的客户端信息表筛选出与客户端Client1所加入房间的房间类型和房间ID相同的其他客户端的信息。
此时,筛选出的其他客户端可以理解为,与客户端Client1处于同一房间内的其他客户端。
在得到其他客户端之后,可以从客户端信息表中得到其他客户端信息,其中其他客户端信息包括:每个其他客户端发布媒体流的情况,例如是否发布过媒体流,所发布媒体流的状态,包括正在发布状态、暂停发布状态、发布异常状态等等。
其他客户端信息还包括:每个其他客户端所发布媒体流对应的PipeTopic、PipePartition和Pipe。
本实施例是基于客户端所加入房间的房间类型生成对应的PipeTopic、基于客户端所加入房间的房间ID生成对应的PipePartition,基于客户端标识生成对应的Pipe,也就是说,PipeTopic与房间类型具有对应关系,PipePartition与房间ID具有对应关系,客户端标识与Pipe具有对应关系,这样可以基于房间类型、房间ID和客户端标识从PDU服务中订阅媒体数据。
其次,SFU1服务根据接收到的其他客户端信息确定出可订阅的其他客户端信息。
由于MCU筛选出的其他客户端信息包括每个其他客户端发布媒体流的情况,以及每个其他客户端对应的PipeTopic、PipePartition和Pipe,因此,SFU1服务可以从接收到的其他客户端信息中确定出成功发布过媒体流的其他客户端信息为可订阅的其他客户端信息。即SFU1服务根据每个其他客户端发布媒体流的情况确定出可以被订阅的其他客户端,根据可以被订阅的其他客户端对应的PipeTopic、PipePartition和Pipe,从PDC服务中订阅媒体数据。
一个示例中,SFU服务创建一个对象Consumer,利用Consumer从目标PipeTopic中拉取目标PipePartition下目标Pipe中的媒体数据进行消费,其中目标PipeTopic为可订阅的其他客户端对应的PipeTopic,目标PipePartition为可订阅的其他客户端对应的PipePartition,目标Pipe为可订阅的其他客户端对应的Pipe。
本应用实例在此示出了基于客户端Client1所加入房间的房间信息确定可订阅的其他客户端信息一种具体实现方式。当然应理解,基于客户端Client1所加入房间的房间信息确定可订阅的其他客户端信息也可以采用其它的方式实现,本申请实施例对此不作限制。例如MCU在基于客户端Client1所加入房间的房间信息筛选出其他客户端得到初步筛选结果之后,还可以基于客户端是否成功发布过媒体流,客户端优先级,客户端地理位置等信息对初步筛选结果进一步筛选,将二次筛选后的其他客户端信息作为可订阅的其他客户端信息。
在通过Consumer对象从PDC服务中消费媒体数据之后,利用SFU1服务将通过消费得到的媒体数据发送给客户端Client1。
应当理解的是,在数据的分发过程中,媒体流的上行发布过程和媒体流的下行订阅过程并没有顺序上的限定,SFU1服务在接收到客户端发送的媒体流时就执行媒体流的上行发布过程,SFU1服务在接收到MCU发送的客户端可订阅的房间信息时就执行媒体流的下行订阅过程。
在本应用实例的另一个实例中,以客户端Client2通过TCP信令加入房间A为例,此时客户端Client2通过房间A连接到SFU2服务,SFU2服务基于TCP协议获取到客户端Client2的客户端信息,此时SFU2服务根据客户端Client2所加入房间的房间信息从MCU处确定PDC服务中客户端Client2可订阅的其他客户端信息,假设此时确定出可订阅的其他客户端信息包括客户端Client1的客户端信息。
SFU2服务创建Consumer,利用Consumer从目标PipeTopic中拉取目标PipePartition下目标Pipe中的媒体数据进行消费,以拉取客户端Client1发布的媒体流为例,Consumer从与客户端Client1所加入房间的房间类型对应的PipeTopic中拉取与客户端Client1所加入房间的房间ID对应的PipePartition下的与客户端Client1标识对应的Pipe中的媒体数据进行消费,SFU2服务将通过消费得到的客户端Client1的媒体数据发送给客户端Client2,由此实现客户端Client1与客户端Client2之间的媒体通话。
对比上述两个实例,不同SFU服务可以借助PDC服务,间接地实现媒体流的流通,相比于图2所示的方法,本实施例重新设计的服务架构更加简单。
基于以上实施例的描述,本申请提出的数据分发方法至少存在以下优势:
第一,引入发布订阅模式设定PDC服务,使SFU服务对下行的媒体流具有选择权,房间内的客户端可根据实际情况选择是否订阅全部远端用户的媒体流,合理利用服务器和客户端之间的下行带宽资源。
第二,本实施例要实现不同SFU服务之间媒体流的互通,PDC服务只需分别和N个SFU服务建立N条连接,而现有方案中需要SFU两两之间建立(N(N-1)/2)条连接,相比而言,本实施例的服务架构要更简单,SFU服务之间传输媒体数据所占用的带宽资源和端口资源也会更少。
第三,大规模音视频的场景需求下,发布订阅模式的数据分发方法,媒体数据只需通过SFU—>PDC—>SFU的服务转发流程就能实现多个客户端之间的媒体通话,而现有方案中,想要多个连接在不同SFU服务上的客户端进行媒体通话,可能需要多个SFU服务之间相互转发多个客户端大量的媒体流,对比之下,本实施例的方法传输效率要更高,可降低多次转发导致的音视频延迟。
基于与上述方法相同的思想,本申请实施例提供了一种数据分发服务端,所述服务端上部署有负载媒体流转发的SFU服务、负责媒体数据的分发与控制的PDC服务和负责信令调度的MCU,其中PDC服务中设置有PipeTopic;如图8所示,本实施例的数据分发服务端包括:
SFU服务810,用于获取客户端信息和来自客户端的媒体流,将所述媒体流发布到与所述客户端信息对应的PipeTopic中;以及从MCU处确定客户端可订阅的其他客户端信息,根据可订阅的其他客户端信息从PDC服务中订阅PipeTopic,并将从订阅的PipeTopic中获得的媒体流转发给客户端;
所述PDC服务820,用于通过PipeTopic对SFU发布的媒体流进行分类;在有SFU订阅PipeTopic时,消费被订阅的PipeTopic下的媒体数据;
所述MCU 830,用于确定客户端可订阅的其他客户端信息。
在一些实施例中,所述客户端信息包括客户端标识和客户端所加入房间的房间信息,所述房间信息包括房间类型和房间ID。
在一些实施例中,SFU服务810,用于根据所述PipeTopic、PipePartition、Pipe和所述媒体流生成Producer,其中,所述PipeTopic与房间类型具有对应关系,所述PipePartition与房间ID具有对应关系,所述Pipe与客户端标识具有对应关系;由所述Producer生产媒体数据并发布到与所述房间类型对应的PipeTopic中;
所述PDC服务820,用于根据房间ID对应的PipePartition对媒体数据进行分区,将所述媒体数据输入到与客户端标识对应的Pipe中。
在一些实施例中,SFU服务810还用于在获取到客户端信息之后,将客户端信息发送给MCU;
相应的,所述MCU 830,用于根据接收到的客户端信息对客户端进行管理。
在一些实施例中,SFU服务810,还用于利用SFU服务根据客户端所加入房间的房间信息,从MCU处确定PDC服务中客户端可订阅的其他客户端信息。
在一些实施例中,MCU 830,用于在接收到客户端所加入房间的房间信息之后,根据其管理的客户端信息表筛选出与客户端所加入房间的房间类型和房间ID相同的其他客户端的信息并发送给SFU服务;
SFU服务810,用接收来自MCU的其他客户端信息,根据接收到的其他客户端信息确定出可订阅的其他客户端信息。
在一些实施例中,MCU筛选出的其他客户端信息包括:每个其他客户端发布媒体流的情况,以及每个其他客户端对应的PipeTopic、PipePartition和Pipe;相应的,
SFU服务810,还用于从接收到的其他客户端信息中确定出成功发布过媒体流的其他客户端信息为可订阅的其他客户端信息。
在一些实施例中,SFU服务810,还用于创建Consumer,利用Consumer从目标PipeTopic中拉取目标PipePartition下目标Pipe中的媒体数据进行消费,所述目标PipeTopic为可订阅的其他客户端对应的PipeTopic,所述目标PipePartition为可订阅的其他客户端对应的PipePartition,所述目标Pipe为可订阅的其他客户端对应的Pipe;利用SFU服务将通过消费得到的媒体数据发送给客户端。
能够理解,上述数据分发服务端,能够实现前述实施例中提供的数据分发方法的各个步骤,关于数据分发方法的相关阐释均适用于数据分发服务端,此处不再赘述。
图9是本申请的一个实施例电子设备的结构示意图。请参考图9,在硬件层面,该电子设备包括处理器和存储器,可选地还包括内部总线、网络接口。其中,存储器可能包含内存,例如高速随机存取存储器(Random-Access Memory,RAM),也可能还包括非易失性存储器(non-volatile memory),例如至少1个磁盘存储器等。当然,该电子设备还可能包括其他业务所需要的硬件。
处理器、网络接口和存储器可以通过内部总线相互连接,该内部总线可以是ISA(Industry Standard Architecture,工业标准体系结构)总线、PCI(PeripheralComponent Interconnect,外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture,扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图3中仅用一个双向箭头表示,但并不表示仅有一根总线或一种类型的总线。
存储器,用于存放程序。具体地,程序可以包括程序代码,所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器,并向处理器提供指令和数据。
处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行,在逻辑层面上形成数据分发服务端。处理器,执行存储器所存放的程序,并具体用于执行上文的数据分发方法。
上述如本申请图3所示实施例揭示的数据分发服务端执行的方法可以应用于处理器中,或者由处理器实现。处理器可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(Digital SignalProcessor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。
该电子设备还可执行图3中数据分发服务端执行的方法,并实现数据分发服务端在图3所示实施例的功能,本申请实施例在此不再赘述。
本申请实施例还提出了一种计算机可读存储介质,该计算机可读存储介质存储一个或多个程序,该一个或多个程序包括指令,该指令当被包括多个应用程序的电子设备执行时,能够使该电子设备执行图3所示实施例中数据分发服务端执行的方法。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。
Claims (10)
1.一种数据分发方法,由服务端执行,其特征在于,所述服务端上部署有SFU服务、PDC服务和MCU,PDC服务中设置有PipeTopic,所述方法包括:
利用SFU服务获取客户端信息,以及利用SFU服务获取来自客户端的媒体流;
利用SFU服务将所述媒体流发布到与所述客户端信息对应的PipeTopic中;
利用SFU服务从MCU处确定客户端可订阅的其他客户端信息,根据可订阅的其他客户端信息从PDC服务中订阅PipeTopic,并将从订阅的PipeTopic中获得的媒体流转发给客户端。
2.如权利要求1所述的方法,其特征在于,所述客户端信息包括客户端标识和客户端所加入房间的房间信息,所述房间信息包括房间类型和房间ID。
3.如权利要求2所述的方法,其特征在于,利用SFU服务将所述媒体流发布到与所述客户端信息对应的PipeTopic中,包括:
SFU服务根据所述PipeTopic、PipePartition、Pipe和所述媒体流生成Producer,其中,所述PipeTopic与房间类型具有对应关系,所述PipePartition与房间ID具有对应关系,所述Pipe与客户端标识具有对应关系;
由所述Producer生产媒体数据并发布到与所述房间类型对应的PipeTopic中,由所述PDC服务根据房间ID对应的PipePartition对媒体数据进行分区,将所述媒体数据输入到与客户端标识对应的Pipe中。
4.如权利要求1所述的方法,其特征在于,在利用SFU服务获取客户端信息之后,还包括:
利用SFU服务将客户端信息发送给MCU,由MCU根据接收到的客户端信息对客户端进行管理。
5.如权利要求2所述的方法,其特征在于,利用SFU服务从MCU处确定客户端可订阅的其他客户端信息,包括:
利用SFU服务根据客户端所加入房间的房间信息,从MCU处确定PDC服务中客户端可订阅的其他客户端信息。
6.如权利要求5所述的方法,其特征在于,利用SFU服务根据客户端所加入房间的房间信息,从MCU处确定PDC服务中客户端可订阅的其他客户端信息,包括:
SFU服务接收来自MCU的其他客户端信息,所述其他客户端信息是MCU接收到客户端所加入房间的房间信息之后,根据其管理的客户端信息表筛选出与客户端所加入房间的房间类型和房间ID相同的其他客户端的信息;
SFU服务根据接收到的其他客户端信息确定出可订阅的其他客户端信息。
7.如权利要求6所述的方法,其特征在于,MCU筛选出的其他客户端信息包括:每个其他客户端发布媒体流的情况,以及每个其他客户端对应的PipeTopic、PipePartition和Pipe;SFU服务根据接收到的其他客户端信息确定出可订阅的客户端信息,包括:
SFU服务从接收到的其他客户端信息中确定出成功发布过媒体流的其他客户端信息为可订阅的其他客户端信息。
8.如权利要求7所述的方法,其特征在于,根据可订阅的其他客户端信息从PDC服务中订阅PipeTopic,并将从订阅的PipeTopic中获得的媒体流转发给客户端,包括:
利用SFU服务创建Consumer;
利用Consumer从目标PipeTopic中拉取目标PipePartition下目标Pipe中的媒体数据进行消费,所述目标PipeTopic为可订阅的其他客户端对应的PipeTopic,所述目标PipePartition为可订阅的其他客户端对应的PipePartition,所述目标Pipe为可订阅的其他客户端对应的Pipe;
利用SFU服务将通过消费得到的媒体数据发送给客户端。
9.一种数据分发服务端,其特征在于,所述服务端上部署有SFU服务、PDC服务和MCU,PDC服务中设置有PipeTopic;所述数据分发服务端用于实现权利要求1~8之任一所述方法。
10.一种电子设备,其特征在于,包括:
处理器;以及
被安排成存储计算机可执行指令的存储器,所述可执行指令在被执行时使所述处理器执行所述权利要求1~8之任一所述方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110676455.5A CN115499417A (zh) | 2021-06-18 | 2021-06-18 | 一种数据分发方法、服务端和电子设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110676455.5A CN115499417A (zh) | 2021-06-18 | 2021-06-18 | 一种数据分发方法、服务端和电子设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115499417A true CN115499417A (zh) | 2022-12-20 |
Family
ID=84464495
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110676455.5A Pending CN115499417A (zh) | 2021-06-18 | 2021-06-18 | 一种数据分发方法、服务端和电子设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115499417A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116938897A (zh) * | 2023-09-19 | 2023-10-24 | 好信云(北京)网络通信有限公司 | 一种用于会议的实时通信的方法和装置 |
-
2021
- 2021-06-18 CN CN202110676455.5A patent/CN115499417A/zh active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116938897A (zh) * | 2023-09-19 | 2023-10-24 | 好信云(北京)网络通信有限公司 | 一种用于会议的实时通信的方法和装置 |
CN116938897B (zh) * | 2023-09-19 | 2023-12-15 | 好信云(北京)网络通信有限公司 | 一种用于会议的实时通信的方法和装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6389573B2 (ja) | データ送信方法及びシステム並びに関連装置 | |
CN110971863B (zh) | 一种多点控制单元跨区会议运行方法、装置、设备及系统 | |
CN108063911B (zh) | 一种视频会议扩容方法 | |
CN112511783A (zh) | 音视频流的混合显示方法、装置、服务器和存储介质 | |
CN111131759B (zh) | 一种实时多媒体传输系统及其使用方法 | |
US9264662B2 (en) | Chat preauthorization | |
CN115499417A (zh) | 一种数据分发方法、服务端和电子设备 | |
CN108156413B (zh) | 视频会议的传输方法及装置、mcu | |
CN109510868A (zh) | 一种建立p2p网络的方法、装置、终端设备及存储介质 | |
CN109587433A (zh) | 一种点调方法和点调装置 | |
CN113490155B (zh) | 多播广播业务的通信方法、装置、介质及电子设备 | |
CN113115065B (zh) | 一种基于直播的数据处理方法及装置 | |
CN111586339B (zh) | 一种会议调度方法、服务器、电子设备及存储介质 | |
CN112511884A (zh) | 一种音视频流的混流控制方法、系统和存储介质 | |
Ha et al. | Topology and architecture design for peer to peer video live streaming system on mobile broadcasting social media | |
CN113098914B (zh) | 消息总线系统及消息传输方法、装置、电子设备 | |
CN114827097B (zh) | 通信网络构建方法、装置及计算机设备 | |
CN116938897B (zh) | 一种用于会议的实时通信的方法和装置 | |
CN115776554A (zh) | 会议处理方法、装置、电子设备以及存储介质 | |
CN113612728B (zh) | 流媒体播放方法、传输设备和系统 | |
CN114979692B (zh) | 音视频拉流模式的切换方法、装置、系统和存储介质 | |
CN115915382A (zh) | 多媒体流同步的通信方法和相关设备、通信系统 | |
CN114189649A (zh) | 一种视频会议直播方法和装置 | |
CN117914633A (zh) | 会议接入方法、装置、电子设备及存储介质 | |
CN117793071A (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 |