CN116156099A - 一种网络传输方法、装置和系统 - Google Patents
一种网络传输方法、装置和系统 Download PDFInfo
- Publication number
- CN116156099A CN116156099A CN202310108401.8A CN202310108401A CN116156099A CN 116156099 A CN116156099 A CN 116156099A CN 202310108401 A CN202310108401 A CN 202310108401A CN 116156099 A CN116156099 A CN 116156099A
- Authority
- CN
- China
- Prior art keywords
- media server
- mode
- target
- audio code
- terminal device
- 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
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/14—Systems for two-way working
- H04N7/15—Conference systems
- H04N7/152—Multipoint control units therefor
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
Abstract
一种网络传输方法、装置和系统,涉及通信技术领域。该方法可以包括:接收来自至少一个终端设备的音频码流;从所述第一媒体服务器支持的至少一种处理模式中,确定目标处理模式,所述目标处理模式关联所述至少一个终端设备中的目标终端设备;基于所述目标处理模式,对所述至少一个终端设备的音频码流进行处理,获得目标音频码流;向所述目标终端设备发送所述目标音频码流。该方法有助于兼顾媒体服务器的计算资源以及媒体服务器与终端设备之间的网络带宽。
Description
技术领域
本申请实施例涉及通信技术领域,特别涉及一种网络传输方法、装置和系统。
背景技术
随着第五代(5G)通信技术的成熟,网络的传输带宽成倍增加,音频/视频通信相关业务得到迅猛发展。在音频/视频通信领域,需要媒体服务器对各个参与方的音频码流或者视频码流进行处理,让每个参与方能听到/看到期望的用户声音/视频。
目前,媒体服务器对音频码流的处理,要么占用该媒体服务器的实时资源过多使得该媒体服务器接入的音频码流的总量受限,要么占用该媒体服务器到终端设备的网络带宽过高影响音视频体验效果。
发明内容
本申请实施例提供一种网络传输方法、装置和系统,有助于兼顾媒体服务器的实时资源以及媒体服务器与终端设备之间的网络带宽。
第一方面,本申请实施例提供了一种网络传输方法,该方法可以应用于第一媒体服务器,方法包括:接收来自至少一个终端设备的音频码流;从所述第一媒体服务器支持的至少一种处理模式中,确定目标处理模式,其中,所述目标处理模式关联所述至少一个终端设备中的目标终端设备;基于所述目标处理模式,对所述至少一个终端设备的音频码流进行处理,获得目标音频码流;向所述目标终端设备发送所述目标音频码流。
上述方案,第一媒体服务器可以根据自身能力,灵活地为不同终端设备选择相应的目标处理模式并动态地切换相应的目标处理模式,使得既可以减少对第一媒体服务器的实时资源的过多占用,又可以减少对网络带宽的占用。
结合第一方面,在一种可能的设计中,所述从所述第一媒体服务器支持的至少一种处理模式中,确定目标处理模式,包括:根据所述第一媒体服务器的负载,和所述第一媒体服务器与所述目标终端设备之间的备用网络带宽,从所述第一媒体服务器支持的至少一种处理模式中确定所述目标终端设备关联的所述目标处理模式。
上述方案,根据业务需要,第一媒体服务器可以被设计为通过监控自身的负载情况,以及第一媒体服务器与不同终端设备之间的备用网络带宽,来动态地确定适于不同终端设备的处理模式,从而在整个网络传输系统中,兼顾第一媒体服务器的实时资源以及第一媒体服务器与终端设备之间的网络带宽。应理解,该方案也可以使用于系统中的其它媒体服务器,本申请实施例对此不做限定。并且,若在其它实施例中,需要考虑媒体服务器的其它性能,上述负载和备用网络带宽还可以替换为其它性能指标,本申请实施例对此不做限定。
结合第一方面,在一种可能的设计中,所述根据所述第一媒体服务器的负载,和所述第一媒体服务器与所述目标终端设备之间的备用网络带宽,从所述第一媒体服务器支持的至少一种处理模式中确定所述目标终端设备关联的所述目标处理模式,包括:若所述第一媒体服务器的负载小于或等于第一阈值、且所述第一媒体服务器与所述目标终端设备之间的备用网络带宽大于或等于第二阈值,确定所述目标处理模式包括选择性转发单元SFU模式或者多点控制单元MCU模式;或者,若所述第一媒体服务器的负载大于第一阈值、且所述第一媒体服务器与所述目标终端设备之间的备用网络带宽大于或等于第二阈值,确定所述目标处理模式包括所述SFU模式;或者,若所述第一媒体服务器的负载小于或等于第一阈值、且所述第一媒体服务器与所述目标终端设备之间的备用网络带宽小于第二阈值,确定所述目标处理模式包括所述MCU模式。
结合第一方面,在一种可能的设计中,所述第一媒体服务器支持的至少一种处理模式包括:SFU模式和/或MCU模式;所述第一媒体服务器支持SFU模式和/或MCU模式,通过下述方式实现:所述第一媒体服务器提供所述SFU模式的媒体服务和所述MCU模式的媒体服务;或者,所述第一媒体服务器提供所述SFU模式的媒体服务,所述第一媒体服务器连接第二媒体服务器,所述第二媒体服务器提供所述MCU模式的媒体服务;或者,所述第一媒体服务器提供所述MCU模式的媒体服务,所述第一媒体服务器连接第三媒体服务器,所述第三媒体服务器提供所述SFU模式的媒体服务。
上述方案,第一媒体服务器可以是自身支持不同的处理模式,也可以是借助于其它媒体服务器支持不同的处理模式,以实现对自身能力的扩展,使得第一媒体服务器可以实时地根据自身的资源占用情况,动态地切换不同的处理模式,以兼顾媒体服务器的资源以及媒体服务器与终端设备之间的网络带宽。
结合第一方面,在一种可能的设计中,若所述第一媒体服务器提供所述SFU模式的媒体服务,所述第一媒体服务器连接第二媒体服务器,所述第二媒体服务器提供所述MCU模式的媒体服务时,所述基于所述目标处理模式,对所述至少一个终端设备的音频码流进行处理,获得目标音频码流,包括:在所述目标处理模式为所述SFU模式时,以所述至少一个终端设备的音频码流中的N路音频码流作为所述目标音频码流,所述N为大于或等于1的正整数;或者,在所述目标处理模式为所述MCU模式时,将所述至少一个终端设备的音频码流中的N路音频码流发送给所述第二媒体服务器,并接收来自所述第二媒体服务器的所述目标音频码流,其中,来自所述第二媒体服务器的所述目标音频码流由所述N路音频码流进行混音得到,所述N为大于或等于1的正整数。
结合第一方面,在另一种可能的设计中,若所述第一媒体服务器提供所述MCU模式的媒体服务,所述第一媒体服务器连接第三媒体服务器,所述第三媒体服务器提供所述SFU模式的媒体服务时,所述基于所述目标处理模式,对所述至少一个终端设备的音频码流进行处理,获得目标音频码流,包括:在所述目标处理模式为所述MCU模式时,将所述至少一个终端设备的音频码流中的N路音频码流进行混音处理后得到所述目标音频码流,所述N为大于或等于1的正整数;或者,在所述目标处理模式为所述SFU模式时,将所述至少一个终端设备的音频码流中的N路音频码流作为所述目标音频码流,相应的,在后者方案实施的基础上,所述向所述目标终端设备发送所述目标音频码流,可以为通过所述第三媒体服务器向所述目标终端设备发送所述目标音频码流。
上述提供了两种在第一媒体服务器提供不同模式的媒体服务的情况下,确定目标音频码流的方案,使得确定目标音频码流的实现方式和第一媒体服务器提供不同模式的媒体服务的情况更相适应,实现方式也更为灵活。
第二方面,本申请实施例提供了一种网络传输装置,应用于第一媒体服务器,所述装置包括:通信接口,用于接收来自至少一个终端设备的音频码流;处理单元,用于从所述第一媒体服务器支持的至少一种处理模式中,确定目标处理模式,其中,所述目标处理模式关联所述至少一个终端设备中的目标终端设备;基于所述目标处理模式,对所述至少一个终端设备的音频码流进行处理,获得目标音频码流;所述通信接口还用于向所述目标终端设备发送所述目标音频码流。
结合第二方面,在一种可能的设计中,所述确定单元确定目标处理模式时,具体用于:根据所述第一媒体服务器的负载,和所述第一媒体服务器与所述目标终端设备之间的备用网络带宽,从所述第一媒体服务器支持的至少一种处理模式中确定所述目标终端设备关联的所述目标处理模式。更进一步地,在一种可能的设计中,所述处理单元确定目标处理模式时,具体用于:若所述第一媒体服务器的负载小于或等于第一阈值、且所述第一媒体服务器与所述目标终端设备之间的备用网络带宽大于或等于第二阈值,确定所述目标处理模式包括选择性转发单元SFU模式或者多点控制单元MCU模式;或者,若所述第一媒体服务器的负载大于第一阈值、且所述第一媒体服务器与所述目标终端设备之间的备用网络带宽大于或等于第二阈值,确定所述目标处理模式包括所述SFU模式;或者,若所述第一媒体服务器的负载小于或等于第一阈值、且所述第一媒体服务器与所述目标终端设备之间的备用网络带宽小于第二阈值,确定所述目标处理模式包括所述MCU模式。
结合第二方面,在一种可能的设计中,所述第一媒体服务器支持的至少一种处理模式包括:SFU模式和/或MCU模式;所述第一媒体服务器支持SFU模式和/或MCU模式,通过下述方式实现:所述第一媒体服务器提供所述SFU模式的媒体服务和所述MCU模式的媒体服务;或者,所述第一媒体服务器提供所述SFU模式的媒体服务,所述第一媒体服务器连接第二媒体服务器,所述第二媒体服务器提供所述MCU模式的媒体服务;或者,所述第一媒体服务器提供所述MCU模式的媒体服务,所述第一媒体服务器连接第三媒体服务器,所述第三媒体服务器提供所述SFU模式的媒体服务。
结合第二方面,在一种可能的设计中,若所述第一媒体服务器提供所述SFU模式的媒体服务,所述第一媒体服务器连接第二媒体服务器,所述第二媒体服务器提供所述MCU模式的媒体服务时,所述处理单元获得目标音频码流时具体用于:在所述目标处理模式为所述SFU模式时,以所述至少一个终端设备的音频码流中的N路音频码流作为所述目标音频码流,所述N为大于或等于1的正整数;或者,在所述目标处理模式为所述MCU模式时,将所述至少一个终端设备的音频码流中的N路音频码流发送给所述第二媒体服务器,并接收来自所述第二媒体服务器的所述目标音频码流,其中,来自所述第二媒体服务器的所述目标音频码流由所述N路音频码流进行混音得到,所述N为大于或等于1的正整数。
结合第二方面,在一种可能的设计中,若所述第一媒体服务器提供所述MCU模式的媒体服务,所述第一媒体服务器连接第三媒体服务器,所述第三媒体服务器提供所述SFU模式的媒体服务时,所述处理单元获得目标音频码流时,具体用于:在所述目标处理模式为所述MCU模式时,将所述至少一个终端设备的音频码流中的N路音频码流进行混音处理后得到所述目标音频码流,所述N为大于或等于1的正整数;或者,在所述目标处理模式为所述SFU模式时,将所述至少一个终端设备的音频码流中的N路音频码流作为所述目标音频码流。相应的,在所述目标处理模式为所述SFU模式时,将所述至少一个终端设备的音频码流中的N路音频码流作为所述目标音频码流时,所述通信接口具体可以通过所述第三媒体服务器向所述目标终端设备发送所述目标音频码流。
第三方面,本申请实施例提供了一种通信装置,包括处理器和存储器,所述处理器与所述存储器耦合;所述存储器,用于存储程序指令;所述处理器,用于读取所述存储器中存储的所述程序指令,以实现如上述第一方面以及第一方面任一可能设计所述的方法。
第四方面,本申请实施例提供了一种通信系统,包括第一媒体服务器和至少一个终端设备,其中,所述至少一个终端设备用于向所述第一媒体服务器发送音频码流;所述第一媒体服务器用于基于所述至少一个终端设备发送的音频码流,执行如上第一方面以及第一方面任一可能设计所述的方法。
第五方面,本申请实施例提供了一种计算机可读存储介质,所述计算机可读介质存储有程序代码,当所述程序代码在计算机上运行时,使得计算机执行如上述第一方面以及第一方面任一可能设计所述的方法。
第六方面,本申请实施例提供了一种计算机程序产品,当所述计算机程序产品在计算机上运行时,使得所述计算机执行如上述第一方面以及第一方面任一可能设计所述的方法。
本申请实施例在上述各方面提供的实现的基础上,还可以进行进一步组合以提供更多实现。
上述第二方面至第六方面中任一方面中的任一可能实现方式可以达到的技术效果,可以相应参照上述第一方面中的任一可能实现方式可以达到的技术效果描述,重复之处不予论述。
附图说明
图1示出了本申请实施例适用的系统架构示意图;
图2示出了本申请实施例的SFU模式下对多路音频码流的处理原理示意图;
图3示出了本申请实施例的MCU模式下对多路音频码流的处理原理示意图;
图4示出了本申请实施例的SFU模式下或MCU模式下的收端音频码流;
图5示出了本申请实施例的网络传输方法的流程示意图;
图6示出了本申请实施例的第一媒体服务器的一种实现方式的示意图;
图7示出了本申请实施例的第一媒体服务器的另一种实现方式的示意图;
图8示出了本申请实施例的第一媒体服务器的另一种实现方式的示意图;
图9示出了本申请实施例的网络传输装置的示意图;
图10示出了本申请实施例的通信装置的示意图;
图11示出了本申请实施例的通信设备的示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
下面对本申请涉及的技术概念进行描述。
1、音频码流处理模式包括选择性转发单元(selective forwarding unit,SFU)模式和多点控制单元(multipoint conferencing unit,MCU)模式。下面分别对SFU模式和MCU模式的定义进行描述:
1)SFU模式也可以称为流转发模式或者选择性转发模式。在SFU模式下,可以通过一个媒体服务器和多个终端设备组成一个通信系统。媒体服务器收到某个终端设备共享的音视频流后,直接将该音视频流转发给会议中的其他终端设备。媒体服务器实际上就是一个音视频路由转发器。在SFU模式下,媒体服务器也可以称为SFU会议服务器或者简称为SFU。SFU无需做音视频转码。
2)MCU模式也可以称为多点控制模式或者混合模式。在MCU模式下,可以通过一个媒体服务器和多个终端设备组成一个通信系统。媒体服务器对同一个会议中的所有终端设备产生的音视频流进行混合,生成一个混合后的音视频流再发给各个终端设备,各个终端设备可以显示其它终端设备的视频流和播放其它终端设备的音频流。在MCU模式下,媒体服务器是一个音视频混合器,媒体服务器也可以称为MCU会议服务器或者简称为MCU。
在后续描述中,为方便区分,将SFU会议模式对应的媒体服务器称为SFU会议服务器、将MCU会议模式对应的媒体服务器称为MCU会议服务器,将在SFU会议服务器上分配的会议资源称为SFU会议资源、将在MCU会议服务器上分配的会议资源称为MCU会议资源。
2、用户,本申请这里指进行视频会议的用户。该用户可以包括普通的终端设备的用户。或者,该用户也可以包括呼叫中心的话务员,主要处理用户的业务咨询、业务办理等。或者,该用户也可以包括呼叫中心的高级话务员,可以简称为专家。
用户接入会议的方式可以采用电话应用程序(telephony application)拨号盘、非系统默认的其他应用程序(application,APP)等。用户采用的终端设备可以称为用户终端设备。用户终端设备可以是移动电话(比如手机)、平板电脑、笔记本电脑等设备。
用户终端设备可以是长期演进语音承载(voice over long-term evolution,VoLTE)用户设备。VoLTE终端设备可以是接入LTE网络的手机/平板电脑等终端设备,比如可以采用安卓或者/>系统自带的拨号盘(application,APP)拨打电话。
用户终端设备可以采用基于网络协议(internet protocol IP)的语音传输(voice over internet protocol,VoIP)终端设备。VoIP终端设备通过自行安装的应用APP拨号盘拨打VoIP电话;VoIP终端设备,比如可以是接入互联网的个人计算机(personcomputer,PC)PC/手机/平板电脑等终端设备。
用户终端设备比如可以是安装在PC上的会话初始协议(session initiationprotocol,SIP)软电话、瘦客户机(Thin Client,TC)终端设备等。一些可能的场景中,业务代表终端设备上有控制端,业务代表通过该控制端可实现呼叫控制、录制控制、话务转接、求助等功能。
需要说明的是,本申请中“VoLTE终端设备”,实际上所能接入的电信网络不限于LTE网络,还可以是5G网络、6G网络等,本申请实施例对此不作限定。
3、弱网场景:主要是网络信号较差的场景,在弱网场景中常见的情形包括网络带宽(即上行/下行数据传输速率)较低、丢包率(丢失数据包数量占所传输的数据组的比率)较高、网络延时较高、网络抖动(即网络延时的变化)等。
4、弱网处理(或者称为弱网优化):是对弱网场景下接收/待发送的媒体数据包的处理,包括但不限于自适应带宽、数据包重传等。
5、备用网络带宽:本申请实施例中,备用网络带宽为媒体服务器与终端设备之间的可用网络带宽。在具体实施时,该媒体服务器可以综合各种指标(例如远端网损信息、传输速率等)评估媒体服务器与终端设备之间传输某个媒体流所需的总带宽,以及计算媒体服务器与终端设备之间的可用网络带宽,可以以所需的总带宽作为阈值(例如第二阈值),确定该可用网络带宽是否允许传输该媒体流。例如,若媒体服务器与终端设备之间的备用网络带宽大于或等于该阈值,则表示网络带宽较为充足,可以传输该媒体流。反之,若媒体服务器与终端设备之间的备用网络带宽小于该阈值,则表示网络带宽较为缺乏,不可以传输该媒体流。
如背景技术所述,目前,媒体服务器对音频码流的处理,要么占用该媒体服务器的实时资源过多使得该媒体服务器接入的音频码流的总量受限,要么占用该媒体服务器到终端设备的网络带宽过高影响音视频体验效果。
针对以上问题,本申请实施例提供了一种网络传输方法、装置和系统,有助于兼顾媒体服务器的实时资源以及媒体服务器与终端设备之间的网络带宽。其中,方法和装置是基于同一技术构思的,由于方法及装置解决问题的原理相似,因此装置与方法的实施可以相互参见,重复之处不再赘述。并且,在本申请的各个实施例中,如果没有特殊说明以及逻辑冲突,各个实施例之间的术语和/或描述具有一致性、且可以相互引用,不同实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。
需要说明的是,本申请实施例中“至少一个”是指一个或者多个,“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B的情况,其中A,B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达,是指的这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a,b,或c中的至少一项(个),可以表示:a,b,c,a和b,a和c,b和c,或a和b和c,其中a,b,c可以是单个,也可以是多个。
以及,除非有特别说明,本申请实施例提及“第一”、“第二”等序数词是用于对多个对象进行区分,不用于限定多个对象的优先级或者重要程度。例如,第一媒体服务器、第二媒体服务器,只是为了区分不同的媒体服务器,而不是表示这两个媒体服务器的优先级或者重要程度等的不同。例如,在一些实施例中,第一媒体服务器与第二媒体服务器所执行的方法步骤可以互换。
下面结合附图及实施例进行介绍。
图1示出了本申请实施例适用的系统架构示意图。参阅图1所示,该系统(例如称为通信系统或者网络传输系统)中可以包括第一媒体服务器10和至少一个终端设备20(例如表示为终端20_1、终端20_2或者终端20_3)。
其中,该第一媒体服务器10可以为该至少一个终端设备20提供在网际互连协议(internet protocol,IP)网络上实现各种业务所需的媒体资源功能,包括但不限于视频会议、交互式应答(interactive voice response,IVR)、通知、统一消息、高级语音业务等。
在实际应用中,该第一媒体服务器10可以支持至少一种处理模式,包括但不限于SFU模式和/或MCU模式,该第一媒体服务器10可以基于所支持的至少一种处理模式,为相应的终端设备提供所需的媒体资源功能。
在一个示例中,以待处理的媒体流为音频码流为例,在第一媒体服务器10提供SFU模式的媒体服务的情形下,终端设备可以向第一媒体服务器订阅该服务,该示例中,第一媒体服务器10一般使用多流转发模式,会给每个终端设备发送N路音频码流,N为正整数。
如图2所示,以图1所示的至少一个终端设备20包括终端A、终端B、终端C、终端D、终端E和终端F均参与视频会议、第一媒体服务器10提供SFU模式的媒体服务为例,第一媒体服务器针对终端A、终端B、终端C、终端D、终端E或者终端F中的任一终端,可以接收来自该终端的音频码流(简称为收包),该音频码流可以采用RTP格式发送,RTP扩展头中可以携带音频音量等信息。第一媒体服务器可以根据需要对来自任一终端的音频码流进行弱网处理后,将这些音频码流提供给第一媒体服务器的音量最大方数决策模块(例如表示为audmax),以便该音量最大方数决策模块根据各个音频码流的音量等信息决策出音量从大到小排序在前面的N方参会者的音频码流,即音量较高的N路音频码流。一般地,在2人会议中,N=1。在3人会议中,N=2。在参会方数量大于或等于4时,N≥3。
决策出音量较高的N方参会者后,第一媒体服务器可以将音量较高的N方参会者对应的音频码流分别发送给其它终端设备。或者,第一媒体服务器还可以根据业务需求,在向某个终端设备发送音量较高的N方参会者的音频码流时,按需剔除来自这个终端设备自身的音频码流。
例如,若在视频会议的某一时刻,来自终端A、终端B、终端C和终端D四方是最后决策出的音量较高的4方,第一媒体服务器10在向终端A发送音量较高的N路音频码流时,可以根据业务场景向终端A发送来自终端A、终端B、终端C和终端D的4路音频码流,表示为A+B+C+D。或者,第一媒体服务器在向终端A发送音量较高的N路音频码流时,也可以根据业务场景向终端A发送来自终端B、终端C和终端D的3路音频码流,表示为B+C+D。
相似地,对于终端B、终端C和终端D,第一媒体服务器可以向该终端B、终端C和终端D发送音量较高的4方的音频码流,或者向该终端B、终端C和终端D发送剔除了自身音频码流的剩余音量较高的3方音频码流,例如向终端B发送来自终端A、终端C和终端D的3路音频码流,表示为A+C+D,向终端C发送来自终端A、终端B和终端D的3路音频码流,表示为A+B+D,向终端D发送来自终端A、终端B和终端C的3路音频码流,表示为A+B+C。
对于终端E和终端F,由于该终端E和终端F不属于决策出的音量较高的4方,第一媒体服务器10可以向终端E和终端F发送来自终端A、终端B、终端C和终端D的4路音频码流,表示为A+B+C+D。或者,第一媒体服务器也可以向终端E和终端F发送来自终端A、终端B、终端C和终端D的任意3路音频码流,例如表示为A+B+C,或者A+B+D,或者A+C+D,或者B+C+D。
在另一个示例中,仍以待处理的媒体流为音频码流为例,在第一媒体服务器10提供MCU模式的媒体服务的情形下,终端设备可以向第一媒体服务器10订阅该服务,该示例中,第一媒体服务器10一般使用混音模式,第一媒体服务器10会对每个终端设备的音频码流进行解码,然后根据需要选择会议中音量较高的N方的参会者的音频码流进行混音处理为一路音频码流,然后将混音后的一路音频码流进行编码,最后将编码后的音频码流发送给相应的终端设备。
如图3所示,第一媒体服务器10提供MCU模式的媒体服务时,该第一媒体服务器10可以包括音频混音模块(例如表示为audmix)、对应每个终端设备的解码器(例如表示为auddec)和编码器(例如表示为audenc)。第一媒体服务器针对终端A、终端B、终端C、终端D、终端E或者终端F中的任一终端,可以接收来自该终端的音频码流(简称为收包),该音频码流可以采用RTP格式发送,RTP扩展头中可以携带音频音量等信息。第一媒体服务器10可以根据需要对来自任一终端的音频码流进行弱网处理后,将这些音频码流提供给相应的解码器,各个解码器对获取到的音频码流进行解码处理。解码后的音频码流可以提供给音量混音模块,该音量混音模块会根据各个音频码流的音量等信息决策出音量从大到小排序在前的N方参会者的音频码流,即音量较高的N路音频码流。该音量混音模块会对决策出的音量较高的N方参会者的音频码流进行混音处理,得到一路音频码流。或者,该音量混音模块会根据需要对决策出的音量较高的N方参会者的音频码流进行多份混音处理,例如针对每个终端设备剔除自身的音频码流。
例如,若在视频会议的某一时刻,来自终端A、终端B、终端C和终端D四方是最后决策出的音量较高的4方,第一媒体服务器10在获取终端A/终端B/终端C/终端D的混音音频码流时,可以将来自终端A、终端B、终端C和终端D的4路音频码流混音处理为一路音频码流,表示为A+B+C+D。或者,第一媒体服务器10在获取终端A的混音音频码流时,可以根据业务场景剔除终端A自身的音频码流,将来自终端B、终端C和终端D的3路音频码流混音处理为一路音频码流,表示为B+C+D。
相似地,第一媒体服务器10在获取终端B的混音音频码流时,可以根据业务场景剔除终端B自身的音频码流,将来自终端A、终端C和终端D的3路音频码流混音处理为一路音频码流,表示为A+C+D。或者,第一媒体服务器10在获取终端C的混音音频码流时,可以根据业务场景剔除终端C自身的音频码流,将来自终端A、终端B和终端D的3路音频码流混音处理为一路音频码流,表示为A+B+D。或者,第一媒体服务器10在获取终端D的混音音频码流时,可以根据业务场景剔除终端D自身的音频码流,将来自终端A、终端B和终端C的3路音频码流混音处理为一路音频码流,表示为A+B+C。
对于终端E和终端F,由于该终端E和终端F不属于决策出的音量较高的4方,第一媒体服务器10可以向终端E和终端F发送来自终端A、终端B、终端C和终端D的4路音频码流的混音音频码流,表示为A+B+C+D。或者,第一媒体服务器10也可以向终端E和终端F发送来自终端A、终端B、终端C和终端D的任意3路音频码流的混音音频码流,例如表示为A+B+C,或者A+B+D,或者A+C+D,或者B+C+D。
音量混音模块在通过以上方式获得待发送给不同终端设备的混音音频码流后,将为不同终端设备准备的混音音频码流提供给相应的编码器,各个编码器会对获得的混音音频码流进行编码处理,之后,第一媒体服务器10将重新编码后的混音音频码流经过发送侧的弱网处理后,发送给相应的终端设备。
如图4所示,该终端A、终端B、终端C、终端D、终端E或者终端F中的任一终端可以接收到相应的采用多流/混音方式处理的音频码流。
本申请实施例中,为了兼顾第一媒体服务器的计算资源以及第一媒体服务器与该至少一个终端设备中的目标终端设备之间的网络带宽,该第一媒体服务器可以设计为以下任一种实现方式:
(1)第一媒体服务器为独立设备,提供所述SFU模式的媒体服务和所述MCU模式的媒体服务;
(2)第一媒体服务器为不同于第二媒体服务器的独立设备,该第一媒体服务器可以提供所述SFU模式的媒体服务,第一媒体服务器连接第二媒体服务器,所述第二媒体服务器提供所述MCU模式的媒体服务;
(3)第一媒体服务器为不同于第二媒体服务器的独立设备,该第一媒体服务器可以提供所述MCU模式的媒体服务,所述第一媒体服务器连接第三媒体服务器,所述第三媒体服务器提供所述SFU模式的媒体服务。
第一媒体服务器根据自身所支持的处理模式,可以与图1-图4所示的至少一个终端设备协同执行本申请实施例的网络传输方法。
结合上述图1至图4的介绍,参阅图5所示,该网络传输方法可以包括以下步骤:
S510:至少一个终端设备向第一媒体服务器发送音频码流。相应地,该第一媒体服务器接收来自至少一个终端设备的音频码流。
S520:第一媒体服务器从所述第一媒体服务器支持的至少一种处理模式中,确定目标处理模式。
本申请实施例中,该至少一种处理模式可以包括SFU模式和/或MCU模式,该目标处理模式可以关联至少一个终端设备中的目标终端设备,该目标终端设备可以是该至少一个终端设备中的任一终端设备。也就是说,第一媒体服务器可以为不同的终端设备选择不同的处理模式。
在具体实施时,作为示例,该第一媒体服务器例如可以根据第一媒体服务器的负载,和第一媒体服务器与目标终端设备之间的备用网络带宽,从该第一媒体服务器支持的至少一种处理模式中确定目标终端设备关联的目标处理模式。
其中,该第一媒体服务器的总体负载可以通过该第一媒体服务器的以下至少一项信息表征:处理器(central processing unit,CPU)负载、内存负载或者磁盘读/写(IO)负载,该第一媒体服务器可以综合各种不同的负载信息计算该第一媒体服务器的负载,并将该负载与预设的第一阈值进行比较,以评估该第一媒体服务器的剩余资源是否支持混音处理。第一媒体服务器与目标终端之间进行媒体流传输所需要的网络带宽可以通过以下至少一项带宽信息表征:有效音频数据量、冗余音频数据两、音频采样率、远端网损信息或者媒体流传输速率等,第一媒体服务器可以综合各种不同的带宽信息计算该第一媒体服务器与目标终端进行媒体流传输所需的总带宽,并以该总带宽作为第二阈值,用于评估第一媒体服务器与目标终端之间的备用网络带宽是否支持多流转发。
若该第一媒体服务器的负载小于或等于第一阈值,表明该第一媒体服务器的剩余负载能力较高,可以承担一些对第一媒体服务器的实时资源(例如CPU资源)占用较大的处理任务,例如采用MCU模式的媒体流混音任务。在该情形下,第一媒体服务器可以确定目标处理模式包括MCU模式。
若该第一媒体服务器与目标终端设备之间的备用网络带宽大于或等于第二阈值,则表明第一媒体服务器与目标终端设备之间的未被占用的网络带宽较为充足,该第一媒体服务器可以承担一些对网络带宽的占用较多的处理任务,例如采用SFU模式的媒体流多流转发任务。在该情形下,第一媒体服务器可以确定目标处理模式包括SFU模式。
若该第一媒体服务器的负载小于或等于第一阈值、且所述第一媒体服务器与所述目标终端设备之间的备用网络带宽大于或等于第二阈值,则表明该第一媒体服务器既可以承担一些对第一媒体服务器的实时资源(例如CPU资源)占用较大的处理任务,例如采用MCU模式的媒体流混音任务,也可以承担一些对网络带宽的占用较多的处理任务,例如采用SFU模式的媒体流多流转发任务。在该情形下,第一媒体服务器可以确定该目标处理模式包括SFU模式或者MCU模式。
上述S510和S520的执行顺序不做限定,可以先执行S510再执行S520,或者也可以先执行S520再执行S510,或者还可以同步(或者说并行)执行S510和执行S520。
S530:第一媒体服务器基于所述目标处理模式,对所述至少一个终端设备的音频码流进行处理,获得目标音频码流。
本申请实施例中,第一媒体服务器在对该至少一个终端设备的音频码流的处理时,为保障最终得到的目标音频码流的质量,可以先确定该至少一个终端设备的音频码流中的N个待处理音频码流,N为大于或等于1的正整数。
其中,该待处理音频码流一般可以根据该至少一个终端设备的数量和各个音频码流的音量等信息确定。例如,以该至少一个终端设备参与视频会议为例,为保障参会方均可以清晰地听到期望的声音,一般在2人会议中,N=1。在3人会议中,N=2。在参会终端设备的数量大于或等于4时,N≥3。该视频会议的媒体服务器可以根据参会的各个终端设备提供的音频码流的音量,从该至少一个终端设备的音频码流中选择音量从大到小排序在前面的N路音频码流。因此,在实施S530时,第一媒体服务器可以先根据该至少一个终端设备的音频码流的音量等信息决策出音量较高的N方参会者,即音量较高的N路音频码流,然后基于目标处理模式,对该N路音频码流进行处理,获得目标音频码流。
示例地,参阅前文中的技术概念的相关描述,以该目标处理模式包括SFU模式为例,在具体实施该S530时,第一媒体服务器可以以该N路音频码流作为所述目标音频码流,N为大于或等于1的正整数。或者,以该目标处理模式包括MCU模式为例,在具体实施该S530时,该第一媒体服务器可以将该N路音频码流进行混音处理后得到所述目标音频码流,N为大于或等于1的正整数。
S540:第一媒体服务器向所述目标终端设备发送所述目标音频码流。相应地,该目标终端设备可以接收该目标音频码流,并可以根据需要播放该目标音频码流,使得该目标终端设备侧的用户可以听到期望的参会用户的声音。
由此,通过以上方法,第一媒体服务器可以根据自身所支持的至少一种处理模式,动态地切换不同终端设备的目标处理模式,使得在第一媒体服务器与目标终端之间进行媒体流传输所需的总带宽过高时,在本机CPU允许的情况下(例如CPU的可用资源充足),通过MCU模式将待处理的多路音频码流进行混音和编码后发送给目标终端设备,否则,则动态切换为SFU模式,以决策出的音量较高的N方参会者的原始音频码流作为目标音频码流,多流转发给相应的目标终端设备。进一步地,在网络质量好转且第一媒体服务器与目标终端之间的备用网络带宽提升后,还可以动态地从MCU模式切换为SFU模式,将目标音频码流通过多流转发给相应的目标终端设备。
此外,本申请实施例中,由于第一媒体服务器的不同产品实现方式,在具体实施上述S530和S540时,还可以具体结合该第一媒体服务器的产品形态执行相应的方法步骤,为了便于理解,下面结合不同的产品实现方式对S530和S540的实施细节进行介绍。
在实现方式(1)中,若该第一媒体服务器是可以提供SFU模式的媒体服务和所述MCU模式的媒体服务的独立计算设备,则在实施上述S530时,对于以SFU模式作为目标处理模式的目标终端设备,按照图2所示的方案,以决策出的该至少一个终端设备的音频码流中的音量从大到小的N路音频码流作为目标音频码流,经过弱网处理后,在实施S540时,通过多流转发处理发送给相应的目标终端设备。对于以MCU模式作为目标处理模式的目标终端设备,按照图3所示的方案,对决策出的该至少一个终端设备的音频码流中的音量从大到小的N路音频码流进行解码、混音处理和编码,经过弱网处理后,在实施S540时发送给相应的目标终端设备。如图6所示,终端A、终端B、终端D和终端F作为目标终端设备接收到的为多流转发的音频码流,终端C和终端E作为目标终端设备接收到的为混音的音频码流。
在实现方式(2)中,若该第一媒体服务器为不同于第二媒体服务器的独立设备,该第一媒体服务器可以提供所述SFU模式的媒体服务,第一媒体服务器连接第二媒体服务器,所述第二媒体服务器提供所述MCU模式的媒体服务时,那么在实施S530时,对于以SFU模式作为目标处理模式的目标终端设备,按照图2所示的方案,以决策出的该至少一个终端设备的音频码流中的音量从大到小的N路音频码流作为目标音频码流,经过弱网处理后,在实施S540时,通过多流转发处理发送给相应的目标终端设备。对于以MCU模式作为目标处理模式的目标终端设备,第一媒体服务器可以将决策出的音量从大到小的N方参会者的多路音频码流(例如终端A、终端B、终端C和终端D的原始音频码流)发送给第二媒体服务器,该第二媒体服务器可以按照图3所示的方案,对决策出的该至少一个终端设备的音频码流中的音量从大到小的N路音频码流进行解码、混音处理和编码并反馈给第一媒体服务器。第一媒体服务器对来自于第二媒体服务器的混音音频码流经过弱网处理后,在实施S540时发送给相应的目标终端设备。如图7所示,终端A、终端B、终端C和终端D作为目标终端设备接收到的为混音的音频码流,终端E和终端F作为目标终端设备接收到的为多流转发的音频码流。
在实现方式(3)中,若该第一媒体服务器为不同于第二媒体服务器的独立设备,该第一媒体服务器可以提供所述MCU模式的媒体服务,所述第一媒体服务器连接第三媒体服务器,所述第三媒体服务器提供所述SFU模式的媒体服务时,那么在实施S530时,对于以MCU模式作为目标处理模式的目标终端设备,第一媒体服务器可以按照图3所示的方案,对决策出的音量从大到小的N方参会者的多路音频码流(例如终端A、终端B、终端C和终端D的原始音频码流)进行解码、混音处理和编码,经过弱网处理后,发送给相应的目标终端设备。对于以SFU模式作为目标处理模式的目标终端设备,第一媒体服务器可以将决策出的音量从大到小的N方参会者的多路音频码流(例如终端A、终端B、终端C和终端D的原始音频码流)发送给第三媒体服务器,该第三媒体服务器可以按照图2所示的方案,以决策出的该至少一个终端设备的音频码流中的音量从大到小的N路音频码流作为目标音频码流,经过弱网处理后,在实施S540时,通过第三媒体服务器经过多流转发处理发送给相应的目标终端设备。如图8所示,终端A、终端B和终端C作为目标终端设备接收到的为混音的音频码流,终端D、终端E和终端F作为目标终端设备接收到的为多流转发的音频码流。
上述提供的三种实现方式中,第一媒体服务器可以自身支持不同的处理模式,也可以是借助于其它媒体服务器支持不同的处理模式,以实现对自身能力的扩展,使得第一媒体服务器可以实时地根据自身的资源占用情况,动态地切换不同的处理模式,以兼顾媒体服务器的资源以及媒体服务器与终端设备之间的网络带宽。并且,在第一媒体服务器提供不同模式的媒体服务的情况下,S530中确定目标音频码流的方案,使得确定目标音频码流的实现方式和第一媒体服务器提供不同模式的媒体服务的情况更相适应,实现方式也更为灵活。S540中向目标终端设备发送目标音频码流的方案,也与第一媒体服务器提供的不同模式的媒体服务相适应,可以尽量减少在不同媒体服务器之间的非必要传输,减少网络传输开销。应理解,本申请实施例中,对于在前文中描述的该第一媒体服务器的三种不同的实现方式中,最大方数决策模块所实现的决策功能不限定于应用在提供SFU模式的媒体服务器,对于提供MCU模式的媒体服务器同样适用(图6或图8未示出),本申请实施例对此不做限定。
并且在以上结合图7或图8描述的实现方式中,由于第一媒体服务器与第二媒体服务器/第三媒体服务器进行跨媒体服务器通信,为了方便识别和处理,该第一媒体服务器可以在向第二媒体服务器/第三媒体服务器发送决策出的音量从大到小的N路音频码流(例如终端A、终端B、终端C和终端D的原始音频码流)时,还可以在各音频码流中携带相应的标识(例如是终端标识、用户标识或者为不同终端分配的会场标识等)。在图7所示的实现方式(2)中,从第二媒体服务器返回的混音音频码流也可以携带同样的标识,以区分每个混音音频码流中包括哪些终端设备提供的音频码流。进一步,在图7所示的实现方式(2)中,第一媒体服务器在向相应的目标终端设备发送混音音频码流时,可以根据需要选择合适的音频码流(例如按需剔除目标终端设备自身的音频码流)。
同时,为了实现对媒体服务器的资源的高效利用,在提供MCU模式的媒体服务器中,还可以尽量保持来自每个终端设备的音频码流与每个解码器或者每个编码器的粘滞关系,以及编码器与解码器的粘滞关系。
例如,如图9所示,在图7所示的实现方式(2)中,假设在第n个周期决策出的音量从大到小的N方参会者为终端A、终端B、终端C和终端D,在第n+1个周期决策出的音量较高的N方为终端A、终端B、终端E和终端F,在第n+2个周期决策出的音量从大到小的N方参会者为终端E、终端D、终端A和终端B,那么可以尽量保持来自同一终端设备的音频码流提供给相同的解码器或者编码器,以保持每个终端设备的音频码流与每个解码器或者每个编码器的粘滞关系,以及编码器与解码器的粘滞关系,以减少解码处理或编码处理等过程中出现错误的情况。其中,图9中,符号“->”表示时间的变化。
本申请实施例还提供了一种网络传输装置,用于执行上述方法实施例中第一媒体服务器所执行的方法,相关特征可以参见上述方法实施例,在此不再赘述。
如图10所示,该装置1000可以包括:通信接口1001,用于接收来自至少一个终端设备的音频码流;处理单元1002,用于从所述第一媒体服务器支持的至少一种处理模式中,确定目标处理模式,其中,所述目标处理模式关联所述至少一个终端设备中的目标终端设备;基于所述目标处理模式,对所述至少一个终端设备的音频码流进行处理,获得目标音频码流;所述通信接口1001还用于向所述目标终端设备发送所述目标音频码流。具体实施时,通信接口1001可以实现前述图5中所述第一媒体服务器与至少一个终端设备和目标终端设备的交互,即实现步骤S510和S540,处理单元1002可以实现前述图5中的步骤S520和S530的处理过程,具体实施细节请参照前述图5的详细描述,这里不再重复赘述。
应理解,以上装置中模块的划分仅仅是一种逻辑功能的划分,实际实现时可以全部或部分集成到一个物理实体上,也可以物理上分开。且装置中的模块可以全部以软件通过处理元件调用的形式实现;也可以全部以硬件的形式实现;还可以部分模块以软件通过处理元件调用的形式实现,部分模块以硬件的形式实现。例如,各个模块可以为单独设立的处理元件,也可以集成在装置的某一个芯片中实现,此外,也可以以程序的形式存储于存储器中,由装置的某一个处理元件调用并执行该模块的功能。此外这些模块全部或部分可以集成在一起,也可以独立实现。这里所述的处理元件又可以成为处理器,可以是一种具有信号的处理能力的集成电路。在实现过程中,上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路实现或者以软件通过处理元件调用的形式实现。
图11为本申请的实施例提供的可能的通信装置1100的结构示意图。通信装置1100可以用于实现上述方法实施例中媒体服务器的功能,因此也能实现上述方法实施例所具备的有益效果。
如图11所示,通信装置1100包括处理器1110和接口电路1120。处理器1110和接口电路1120之间相互耦合。可以理解的是,接口电路1120可以为收发器或输入输出接口。可选的,通信装置1100还可以包括存储器1130,用于存储处理器1110执行的指令或存储处理器1110运行指令所需要的输入数据或存储处理器1110运行指令后产生的数据。
可以理解的是,本申请的实施例中的处理器可以是中央控制器(CPU,centralprocessing unit),通用处理器,协控制器,数字信号控制器(digital signal processor,DSP),专用集成电路(ASIC,application-specific integrated circuit),现场可编程门阵列(FPGA,field programmable gate array)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。该控制器也可以是实现计算功能的组合,例如包含一个或多个微控制器组合,DSP和微控制器的组合等等。
当通信装置1100用于实现上述方法实施例中的方法时,处理器1110用于执行上述处理单元1002的功能,接口电路1120用于执行上述通信接口1001的功能。
当上述通信装置应用于媒体服务器或者媒体服务器的芯片时,该通信装置实现上述方法实施例中媒体服务器的功能。当上述通信装置为应用于媒体服务器的芯片时,该通信装置实现上述方法实施例中媒体服务器的功能。
此外,本申请还提供了一种计算机可读存储介质,该计算机可读存储介质存储有计算机程序,上述计算机程序在被计算设备执行时实现前述媒体服务器所实现的方法。
此外,本申请还提供了一种计算机程序产品,该计算机程序产品包括计算机指令。当该计算机指令被计算设备执行时实现前述媒体服务器所实现的方法。
本文中术语“系统”和“网络”在本文中常被可互换使用。本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。本申请涉及的术语“至少一个”,是指一个,或一个以上,即包括一个、两个、三个及以上;“多个”,是指两个,或两个以上,即包括两个、三个及以上。“以下至少一项(个)”或其类似表达,是指的这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a,b,或c中的至少一项(个),可以表示:a,b,c,a-b,a-c,b-c,或a-b-c,其中a,b,c可以是单个,也可以是多个。应理解,在本申请实施例中,“与A相应的B”表示B与A相关联,根据A可以确定B。但还应理解,根据A确定B并不意味着仅仅根据A确定B,还可以根据A和/或其它信息确定B。以及,除非有相反的说明,本申请实施例提及“第一”、“第二”等序数词是用于对多个对象进行区分,不用于限定多个对象的顺序、时序、优先级或者重要程度。此外,本申请实施例和权利要求书及附图中的术语“包括”和“具有”不是排他的。例如,包括了一系列步骤或模块的过程、方法、系统、产品或设备没有限定于已列出的步骤或模块,还可以包括没有列出的步骤或模块。
本申请的实施例中的方法步骤可以通过硬件的方式来实现,也可以由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成,软件模块可以被存放于随机存取存储器、闪存、只读存储器、可编程只读存储器、可擦除可编程只读存储器、电可擦除可编程只读存储器、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器,从而使处理器能够从该存储介质读取信息,且可向该存储介质写入信息。当然,存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。另外,该ASIC可以位于网络设备或终端中。当然,处理器和存储介质也可以作为分立组件存在于网络设备或终端中。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机程序或指令。在计算机上加载和执行所述计算机程序或指令时,全部或部分地执行本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、网络设备、用户设备或者其它可编程装置。所述计算机程序或指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机程序或指令可以从一个网站站点、计算机、服务器或数据中心通过有线或无线方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是集成一个或多个可用介质的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,例如,软盘、硬盘、磁带;也可以是光介质,例如,数字视频光盘;还可以是半导体介质,例如,固态硬盘。该计算机可读存储介质可以是易失性或非易失性存储介质,或可包括易失性和非易失性两种类型的存储介质。
在本申请的各个实施例中,如果没有特殊说明以及逻辑冲突,不同的实施例之间的术语和/或描述具有一致性、且可以相互引用,不同的实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。
Claims (18)
1.一种网络传输方法,其特征在于,应用于第一媒体服务器,所述方法包括:
接收来自至少一个终端设备的音频码流;
从所述第一媒体服务器支持的至少一种处理模式中,确定目标处理模式,其中,所述目标处理模式关联所述至少一个终端设备中的目标终端设备;
基于所述目标处理模式,对所述至少一个终端设备的音频码流进行处理,获得目标音频码流;
向所述目标终端设备发送所述目标音频码流。
2.根据权利要求1所述的方法,其特征在于,所述从所述第一媒体服务器支持的至少一种处理模式中,确定目标处理模式,包括:
根据所述第一媒体服务器的负载,和所述第一媒体服务器与所述目标终端设备之间的备用网络带宽,从所述第一媒体服务器支持的至少一种处理模式中确定所述目标终端设备关联的所述目标处理模式。
3.根据权利要求2所述的方法,其特征在于,所述根据所述第一媒体服务器的负载,和所述第一媒体服务器与所述目标终端设备之间的备用网络带宽,从所述第一媒体服务器支持的至少一种处理模式中确定所述目标终端设备关联的所述目标处理模式,包括:
若所述第一媒体服务器的负载小于或等于第一阈值、且所述第一媒体服务器与所述目标终端设备之间的备用网络带宽大于或等于第二阈值,确定所述目标处理模式包括选择性转发单元SFU模式或者多点控制单元MCU模式;或者,
若所述第一媒体服务器的负载大于第一阈值、且所述第一媒体服务器与所述目标终端设备之间的备用网络带宽大于或等于第二阈值,确定所述目标处理模式包括所述SFU模式;或者,
若所述第一媒体服务器的负载小于或等于第一阈值、且所述第一媒体服务器与所述目标终端设备之间的备用网络带宽小于第二阈值,确定所述目标处理模式包括所述MCU模式。
4.根据权利要求1-3中任一项所述的方法,其特征在于,所述第一媒体服务器支持的至少一种处理模式包括:SFU模式和/或MCU模式;
所述第一媒体服务器支持SFU模式和/或MCU模式,通过下述方式实现:
所述第一媒体服务器提供所述SFU模式的媒体服务和所述MCU模式的媒体服务;或者,
所述第一媒体服务器提供所述SFU模式的媒体服务,所述第一媒体服务器连接第二媒体服务器,所述第二媒体服务器提供所述MCU模式的媒体服务;或者,
所述第一媒体服务器提供所述MCU模式的媒体服务,所述第一媒体服务器连接第三媒体服务器,所述第三媒体服务器提供所述SFU模式的媒体服务。
5.根据权利要求4所述的方法,其特征在于,若所述第一媒体服务器提供所述SFU模式的媒体服务,所述第一媒体服务器连接第二媒体服务器,所述第二媒体服务器提供所述MCU模式的媒体服务时,所述基于所述目标处理模式,对所述至少一个终端设备的音频码流进行处理,获得目标音频码流,包括:
在所述目标处理模式为所述SFU模式时,以所述至少一个终端设备的音频码流中的N路音频码流作为所述目标音频码流,所述N为大于或等于1的正整数;或者,
在所述目标处理模式为所述MCU模式时,将所述至少一个终端设备的音频码流中的N路音频码流发送给所述第二媒体服务器,并接收来自所述第二媒体服务器的所述目标音频码流,其中,来自所述第二媒体服务器的所述目标音频码流由所述N路音频码流进行混音得到,所述N为大于或等于1的正整数。
6.根据权利要求4所述的方法,其特征在于,若所述第一媒体服务器提供所述MCU模式的媒体服务,所述第一媒体服务器连接第三媒体服务器,所述第三媒体服务器提供所述SFU模式的媒体服务时,所述基于所述目标处理模式,对所述至少一个终端设备的音频码流进行处理,获得目标音频码流,包括:
在所述目标处理模式为所述MCU模式时,将所述至少一个终端设备的音频码流中的N路音频码流进行混音处理后得到所述目标音频码流,所述N为大于或等于1的正整数;或者,
在所述目标处理模式为所述SFU模式时,将所述至少一个终端设备的音频码流中的N路音频码流作为所述目标音频码流。
7.根据权利要求6所述的方法,其特征在于,在所述目标处理模式为所述SFU模式时,将所述至少一个终端设备的音频码流中的N路音频码流作为所述目标音频码流时,所述向所述目标终端设备发送所述目标音频码流,包括:
通过所述第三媒体服务器向所述目标终端设备发送所述目标音频码流。
8.一种网络传输装置,其特征在于,应用于第一媒体服务器,所述装置包括:
通信接口,用于接收来自至少一个终端设备的音频码流;
处理单元,用于从所述第一媒体服务器支持的至少一种处理模式中,确定目标处理模式,其中,所述目标处理模式关联所述至少一个终端设备中的目标终端设备;基于所述目标处理模式,对所述至少一个终端设备的音频码流进行处理,获得目标音频码流;
所述通信接口,还用于向所述目标终端设备发送所述目标音频码流。
9.根据权利要求8所述的装置,其特征在于,所述处理单元确定目标处理模式时,具体用于:
根据所述第一媒体服务器的负载,和所述第一媒体服务器与所述目标终端设备之间的备用网络带宽,从所述第一媒体服务器支持的至少一种处理模式中确定所述目标终端设备关联的所述目标处理模式。
10.根据权利要求9所述的装置,其特征在于,所述处理单元确定目标处理模式时,具体用于:
若所述第一媒体服务器的负载小于或等于第一阈值、且所述第一媒体服务器与所述目标终端设备之间的备用网络带宽大于或等于第二阈值,确定所述目标处理模式包括选择性转发单元SFU模式或者多点控制单元MCU模式;或者,
若所述第一媒体服务器的负载大于第一阈值、且所述第一媒体服务器与所述目标终端设备之间的备用网络带宽大于或等于第二阈值,确定所述目标处理模式包括所述SFU模式;或者,
若所述第一媒体服务器的负载小于或等于第一阈值、且所述第一媒体服务器与所述目标终端设备之间的备用网络带宽小于第二阈值,确定所述目标处理模式包括所述MCU模式。
11.根据权利要求8-10中任一项所述的装置,其特征在于,所述第一媒体服务器支持的至少一种处理模式包括:SFU模式和/或MCU模式;
所述第一媒体服务器支持SFU模式和/或MCU模式,通过下述方式实现:
所述第一媒体服务器提供所述SFU模式的媒体服务和所述MCU模式的媒体服务;或者,
所述第一媒体服务器提供所述SFU模式的媒体服务,所述第一媒体服务器连接第二媒体服务器,所述第二媒体服务器提供所述MCU模式的媒体服务;或者,
所述第一媒体服务器提供所述MCU模式的媒体服务,所述第一媒体服务器连接第三媒体服务器,所述第三媒体服务器提供所述SFU模式的媒体服务。
12.根据权利要求11所述的装置,其特征在于,若所述第一媒体服务器提供所述SFU模式的媒体服务,所述第一媒体服务器连接第二媒体服务器,所述第二媒体服务器提供所述MCU模式的媒体服务时,所述处理单元获得目标音频码流时,具体用于:
在所述目标处理模式为所述SFU模式时,以所述至少一个终端设备的音频码流中的N路音频码流作为所述目标音频码流,所述N为大于或等于1的正整数;或者,
在所述目标处理模式为所述MCU模式时,将所述至少一个终端设备的音频码流中的N路音频码流发送给所述第二媒体服务器,并接收来自所述第二媒体服务器的所述目标音频码流,其中,来自所述第二媒体服务器的所述目标音频码流由所述N路音频码流进行混音得到,所述N为大于或等于1的正整数。
13.根据权利要求11所述的装置,其特征在于,若所述第一媒体服务器提供所述MCU模式的媒体服务,所述第一媒体服务器连接第三媒体服务器,所述第三媒体服务器提供所述SFU模式的媒体服务时,所述处理单元获得目标音频码流时,具体用于:
在所述目标处理模式为所述MCU模式时,将所述至少一个终端设备的音频码流中的N路音频码流进行混音处理后得到所述目标音频码流,所述N为大于或等于1的正整数;或者,
在所述目标处理模式为所述SFU模式时,将所述至少一个终端设备的音频码流中的N路音频码流作为所述目标音频码流。
14.根据权利要求13所述的装置,其特征在于,在所述目标处理模式为所述SFU模式时,将所述至少一个终端设备的音频码流中的N路音频码流作为所述目标音频码流时,所述通信接口向所述目标终端设备发送所述目标音频码流,具体用于:
通过所述第三媒体服务器向所述目标终端设备发送所述目标音频码流。
15.一种通信装置,其特征在于,包括处理器和存储器,所述处理器与所述存储器耦合;
所述存储器,用于存储程序指令;
所述处理器,用于读取所述存储器中存储的所述程序指令,以实现如权利要求1-7中任一所述的方法。
16.一种通信系统,其特征在于,包括第一媒体服务器和至少一个终端设备,其中,
所述至少一个终端设备,用于向所述第一媒体服务器发送音频码流;
所述第一媒体服务器,用于基于所述至少一个终端设备发送的音频码流,执行如权利要求1-7中任一项所述的方法。
17.一种计算机可读存储介质,其特征在于,所述存储介质中存储有计算机程序或指令,当所述计算机程序或指令被通信装置执行时,实现如权利要求1-7中任一项所述的方法。
18.一种计算机程序产品,其特征在于,当所述计算机程序产品在计算机上运行时,使得所述计算机执行如权利要求1-7中任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310108401.8A CN116156099A (zh) | 2023-01-17 | 2023-01-17 | 一种网络传输方法、装置和系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310108401.8A CN116156099A (zh) | 2023-01-17 | 2023-01-17 | 一种网络传输方法、装置和系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116156099A true CN116156099A (zh) | 2023-05-23 |
Family
ID=86357839
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310108401.8A Pending CN116156099A (zh) | 2023-01-17 | 2023-01-17 | 一种网络传输方法、装置和系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116156099A (zh) |
-
2023
- 2023-01-17 CN CN202310108401.8A patent/CN116156099A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10356365B2 (en) | Framework to support a hybrid of meshed endpoints with non-meshed endpoints | |
US10021347B2 (en) | Architecture for high availability conferencing | |
US8614732B2 (en) | System and method for performing distributed multipoint video conferencing | |
JP5320406B2 (ja) | オーディオ処理の方法、システム、及び制御サーバ | |
US20190259404A1 (en) | Encoding an audio stream | |
US20120134301A1 (en) | Wide area voice environment multi-channel communications system and method | |
US9237306B2 (en) | Distributed audio/video bridging for conferencing endpoints | |
KR20190031239A (ko) | 멀티미디어 통신들에서의 콤팩트 동시 코덱들의 이용을 위한 방법들 및 장치 | |
US9270937B2 (en) | Real time stream provisioning infrastructure | |
CN113114688B (zh) | 多媒体会议管理方法及装置、存储介质、电子设备 | |
US10382504B2 (en) | Conducting a conference call over a computer network | |
US9264662B2 (en) | Chat preauthorization | |
WO2022100528A1 (zh) | 音视频转发方法、装置、终端与系统 | |
JP2012151555A (ja) | テレビ会議システム、テレビ会議中継装置、テレビ会議中継方法および中継プログラム | |
CN116156099A (zh) | 一种网络传输方法、装置和系统 | |
US9578283B1 (en) | Audio level based management of communication resources | |
EP3055957A1 (en) | Resource allocation | |
EP3526918A1 (en) | Dynamically partitioning media streams | |
WO2015077389A1 (en) | Resource allocation | |
CN118158138A (zh) | 数据分发控制方法、装置、服务器及存储介质 | |
WO2024134010A1 (en) | Complexity reduction in multi-stream audio | |
CN114268763A (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 |