多路直播混流方法、服务器、终端设备、系统及存储介质

技术领域

本发明涉及互联网直播技术领域，尤其涉及一种多路直播混流方法、服务器、终端设备、系统及存储介质。

背景技术

随着人们对多路直播室需求的提升，一个直播室中除了比赛的直播流还有各个观众的直播流，这样同一个直播室内的观众在观看比赛的同时还可以互相“面对面”交流讨论，而不仅仅是发送弹幕评论来表达自身观点，这在一定程度上提升了全场景沉浸式体验。现有的直播混流方案通常采用MCU(Microcontroller Unit，微控制单元)架构，其主要的处理逻辑是：接收每个共享端的音视频流，经过解码、与其他解码后的音视频进行混流、重新编码，之后再将混好的音视频流发送给房间里的所有人。

但随着共享音视频流的终端数增加，MCU需要对大量的音视频流进行编解码混流和分发处理，这会大幅消耗CPU、带宽等服务端资源。正因为对服务端的资源耗费很大，所以MCU架构所能共享的终端数有限，一般十几路音视频流就会达到服务端资源上限。也就是说在一个直播室最多只能支持十几个观众共同观看比赛并“面对面”交流。此外，现有的混流直播方案多是将各直播流混流后直接推送至各终端，而实际情况中，观众很可能在观看比赛的过程中临时去办别的事离开终端摄像头范围，并且没有主动退出直播室，而此时终端仍然在向服务端推流，这对服务端带宽等资源无疑是一种浪费，降低了多路直播系统的可用性，从而对用户体验造成影响。

因此，有必要提出一种提升多路直播用户体验的解决方案。

上述内容仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。

发明内容

本发明的主要目的在于提供一种多路直播混流方法、服务器、终端设备、系统及存储介质，旨在提升多路直播的用户体验。

为实现上述目的，本发明提供一种多路直播混流方法，所述多路直播混流方法应用于服务端，所述多路直播混流方法包括：

获取各终端推送的音视频流，并根据各所述音视频流得到目标音视频流；

基于所述目标音视频流中预先标注的优先级标签生成通知信息，并将所述通知信息发送至相应的终端，以供各所述终端根据所述通知信息推送自适应清晰度的音视频流；

接收所述自适应清晰度的音视频流，将所述自适应清晰度的音视频流进行混流，并将混流后的音视频流分发推送至各所述终端，以供各所述终端将所述混流后的音视频流提供至用户。

可选地，所述获取各终端推送的音视频流，并根据各所述音视频流得到目标音视频流的步骤包括：

获取各所述终端推送的音视频流；

对各所述音视频流进行特征提取，得到特征提取结果；

根据所述特征提取结果对各所述音视频流标注对应的优先级标签，得到所述目标音视频流。

可选地，所述根据所述特征提取结果对各所述音视频流标注对应的优先级标签，得到所述目标音视频流的步骤包括：

根据所述特征提取结果判断各所述音视频流所属的直播流类型；

根据各所述音视频流所属的直播流类型，对各所述音视频流标注对应的优先级标签，得到所述目标音视频流，其中，所述优先级标签包括第一优先级标签与第二优先级标签，所述第二优先级标签在标注过程中附加对应的时间戳。

可选地，所述所述基于所述目标音视频流中预先标注的优先级标签生成通知信息，并将所述通知信息发送至相应的终端的步骤包括：

检测所述多路直播状态；

根据所述多路直播状态判断所述服务端资源是否低于第一预设阈值；

若所述服务端资源低于所述第一预设阈值，则调用图像检测模块对所述第二优先级标签对应的目标音视频流进行检测，得到检测结果；

根据所述检测结果判断所述第二优先级标签对应的目标音视频流中是否存在未检测到人脸的目标音视频流；

若所述第二优先级标签对应的目标音视频流中存在未检测到人脸的目标音视频流，则向所述未检测到人脸的目标音视频流对应的终端发送第一通知，其中，所述第一通知包括中止推流通知或推送最低清晰度音视频流通知。

可选地，所述检测所述多路直播状态的步骤之后还包括：

根据所述多路直播状态判断所述服务端资源是否低于第二预设阈值；

若所述服务端资源低于所述第二预设阈值，则根据所述优先级标签、各所述音视频流所属终端的网络状态以及所述时间戳，向各所述目标音视频流对应的终端发送第二通知，其中，所述第二通知包括自适应降级推流清晰度通知。

可选地，所述获取各终端推送的音视频流，并根据各所述音视频流得到目标音视频流的步骤之前还包括：

接收各所述终端发送的加入直播请求；

根据所述加入直播请求生成推流通知，并将所述推流通知发送至对应的终端，以供所述终端根据所述推流通知向所述服务端推送预设清晰度的音视频流。

可选地，所述多路直播混流方法应用于终端，所述所述多路直播混流方法包括以下步骤：

发送音视频流至服务端，以供所述服务端根据所述音视频流得到目标音视频流，并基于所述目标音视频流中预先标注的优先级标签生成通知信息，并将所述通知信息发送至相应的终端；

接收所述服务端发送的通知信息，并根据所述通知信息推送自适应清晰度的音视频流至所述服务端，以供所述服务端接收所述自适应清晰度的音视频流，将所述自适应清晰度的音视频流进行混流，并将混流后的音视频流分发推送至各所述终端；

接收所述服务端发送的混流后的音视频流，并将所述混流后的音视频流提供至用户。

可选地，所述发送音视频流至服务端的步骤之前还包括：

接收所述用户的操作指令，并根据所述操作指令发送加入直播请求至所述服务端，以供所述服务端根据所述加入直播请求生成推流通知并发送至所述终端；

获取所述服务端发送的推流通知，以根据所述推流通知发送预设清晰度的音视频流至所述服务端。

可选地，所述接收所述服务端发送的通知信息，并根据所述通知信息推送自适应清晰度的音视频流至所述服务端的步骤包括：

接收所述服务端发送的第一通知和/或第二通知，其中，所述第一通知包括中止推流通知或推送最低清晰度音视频流通知，所述第二通知包括自适应降级推流清晰度通知；

根据所述中止推流通知停止向所述服务端推送所述音视频流，或

根据所推送最低清晰度音视频流通知和/或第二通知调整向所述服务端推送的音视频流的清晰度。

此外，为实现上述目的，本发明还提供一种多路直播混流服务器，所述多路直播混流服务器包括：

获取模块，用于获取各终端推送的音视频流，并根据各所述音视频流得到目标音视频流；

通知模块，用于基于所述目标音视频流中预先标注的优先级标签生成通知信息，并将所述通知信息发送至相应的终端，以供各所述终端根据所述通知信息推送自适应清晰度的音视频流；

混流模块，用于接收所述自适应清晰度的音视频流，将所述自适应清晰度的音视频流进行混流，并将混流后的音视频流分发推送至各所述终端，以供各所述终端将所述混流后的音视频流提供至用户。

此外，为实现上述目的，本发明还提供一种多路直播混流终端设备，所述多路直播混流终端设备包括：

推流模块，用于发送音视频流至服务端，以供所述服务端根据所述音视频流得到目标音视频流，并基于所述目标音视频流中预先标注的优先级标签生成通知信息，将混流后的音视频流与所述通知信息分发推送至各所述终端；

自适应模块，用于接收所述服务端发送的通知信息，并根据所述通知信息推送自适应清晰度的音视频流至所述服务端；

接收模块，用于接收所述服务端发送的混流后的音视频流，并将所述混流后的音视频流提供至用户。

此外，为实现上述目的，本发明还提供一种多路直播混流系统，所述多路直播混流系统包括服务器、终端设备、存储器、处理器及存储在所述存储器上并可在所述处理器上运行的多路直播混流程序，所述多路直播混流程序被所述处理器执行时实现如上所述的多路直播混流方法的步骤。

此外，为实现上述目的，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有多路直播混流程序，所述多路直播混流程序被处理器执行时实现如上所述的多路直播混流方法的步骤。

本发明实施例提出的一种多路直播混流方法、服务器、终端设备、系统及存储介质，通过获取各终端推送的音视频流，并根据各所述音视频流得到目标音视频流；基于所述目标音视频流中预先标注的优先级标签生成通知信息，并将所述通知信息发送至相应的终端，以供各所述终端根据所述通知信息推送自适应清晰度的音视频流；接收所述自适应清晰度的音视频流，将所述自适应清晰度的音视频流进行混流，并将混流后的音视频流分发推送至各所述终端，以供各所述终端将所述混流后的音视频流提供至用户。通过基于预先标注的优先级标签生成通知信息并发送至相应的终端，使各终端推送自适应清晰度的音视频流，实现了对服务端资源进行自适应释放与分配，提高了多路直播系统的可用性，从而提升了多路直播的用户体验。

附图说明

图1为现有技术中采用MCU进行直播的架构示意图；

图2为本发明实施例中采用SFU进行直播的架构示意图；

图3为本发明多路直播混流装置所属终端设备的功能模块示意图；

图4为本发明多路直播混流方法第一示例性实施例的流程示意图；

图5为图4实施例中步骤S10的具体流程示意图；

图6为图5实施例中步骤S103的具体流程示意图；

图7为图4实施例中步骤S20的具体流程示意图；

图8为本发明多路直播混流方法第二示例性实施例的流程示意图；

图9为本发明多路直播混流方法第三示例性实施例的流程示意图；

图10为本发明多路直播混流方法第四示例性实施例的流程示意图；

图11为本发明实施例中的动态自适应混流直播策略的流程示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例的主要解决方案是：通过获取各终端推送的音视频流，并根据各所述音视频流得到目标音视频流；基于所述目标音视频流中预先标注的优先级标签生成通知信息，并将所述通知信息发送至相应的终端，以供各所述终端根据所述通知信息推送自适应清晰度的音视频流；接收所述自适应清晰度的音视频流，将所述自适应清晰度的音视频流进行混流，并将混流后的音视频流分发推送至各所述终端，以供各所述终端将所述混流后的音视频流提供至用户。通过基于预先标注的优先级标签生成通知信息并发送至相应的终端，使各终端推送自适应清晰度的音视频流，实现了对服务端资源进行自适应释放与分配，提高了多路直播系统的可用性，从而提升了多路直播的用户体验。

本发明实施例涉及的技术术语：

MCU(Microcontroller Unit，微控制单元)：又称单片微型计算机或者单片机，是把中央处理器的频率与规格做适当缩减，并将内存、计数器、USB、A/D转换、UART、PLC、DMA等周边接口，甚至LCD驱动电路都整合在单一芯片上，形成芯片级的计算机，为不同的应用场合做不同组合控制；

MIX：混流模块，用于对各音视频流进行混流；

SFU：在多路直播场景中作为一个媒体流路由器，接收终端的音视频流，并根据需要转发给其他终端。

现有的直播混流方案通常采用MCU架构，其主要的处理逻辑是：接收每个共享端的音视频流，经过解码、与其他解码后的音视频进行混流、重新编码，之后再将混好的音视频流发送给房间里的所有人。参照图1，图1为现有技术中采用MCU进行直播的架构示意图，如图1所示，以B1与B2同时共享音视频流为例，它们首先将流推送给MCU服务器，MCU服务器收到两路流后，分别将两路流进行解码，之后再将解码后的两路流进行混流，然后再编码，编码后的流数据再分发给B3和B4。

MCU只需要对两路音视频流进行解码、混流、编码处理，但随着共享音视频流的终端数增加，MCU需要对大量的音视频流进行编解码混流和分发处理，这会大幅消耗CPU、带宽等服务端资源。正因为对服务端的资源耗费很大，所以MCU架构所能共享的终端数有限，一般十几路音视频流就会达到服务端资源上限。也就是说在一个直播室最多只能支持十几个观众共同观看比赛并“面对面”交流。现有的混流直播方案多是将各直播流混流后直接推送至各终端，而实际情况中，观众很可能在观看直播的过程中临时去办别的事离开终端摄像头范围，并且没有主动退出直播室，而此时终端仍然在向服务端推流，这对服务端带宽等资源无疑是一种浪费。

本发明提供一种基于图像检测的动态自适应多路直播混流方案，本方案MIX混流模块底层采用了SFU架构，和MCU架构相比其结构较为简单。参照图2，图2为本发明实施例中采用SFU进行直播的架构示意图，如图2所示，SFU在多路直播场景中更多是作为一个媒体流路由器，接收终端的音视频流，根据需要转发给其他终端。由于SFU只是接收直播流然后转发给其他人而不需要额外再进行编解码，其对CPU资源的消耗很小，所以SFU能分发的直播流数远多于MCU架构。此外，因为SFU只是对音视频数据包的直接转发，它可以根据当前的带宽状况、网络状况选择性地丢弃或补充相应的数据包，进而降低时延保证直播流的连续性。

具体地，参照图3，图3为本发明多路直播混流装置所属终端设备的功能模块示意图。该多路直播混流装置可以为独立于终端设备的、能够进行多路直播混流的装置，其可以通过硬件或软件的形式承载于终端设备上。该终端设备可以为手机、平板电脑等具有数据处理功能的智能移动终端，还可以为具有数据处理功能的固定终端设备或服务器等。

在本实施例中，该多路直播混流装置所属终端设备至少包括输出模块110、处理器120、存储器130以及通信模块140。

存储器130中存储有操作系统以及多路直播混流程序，多路直播混流装置可以将获取的各终端推送的音视频流、根据各所述音视频流得到的目标音视频流、基于所述目标音视频流中预先标注的优先级标签生成的通知信息、接收的所述自适应清晰度的音视频流，以及将所述自适应清晰度的音视频流进行混流得到的混流后的音视频流等信息存储于该存储器130中；输出模块110可为显示屏等。通信模块140可以包括WIFI模块、移动通信模块以及蓝牙模块等，通过通信模块140与外部设备或服务器进行通信。

其中，存储器130中的多路直播混流程序被处理器执行时实现以下步骤：

获取各终端推送的音视频流，并根据各所述音视频流得到目标音视频流；

基于所述目标音视频流中预先标注的优先级标签生成通知信息，并将所述通知信息发送至相应的终端，以供各所述终端根据所述通知信息推送自适应清晰度的音视频流；

接收所述自适应清晰度的音视频流，将所述自适应清晰度的音视频流进行混流，并将混流后的音视频流分发推送至各所述终端，以供各所述终端将所述混流后的音视频流提供至用户。

进一步地，存储器130中的多路直播混流程序被处理器执行时还实现以下步骤：

获取各所述终端推送的音视频流；

对各所述音视频流进行特征提取，得到特征提取结果；

根据所述特征提取结果对各所述音视频流标注对应的优先级标签，得到所述目标音视频流。

进一步地，存储器130中的多路直播混流程序被处理器执行时还实现以下步骤：

根据所述特征提取结果判断各所述音视频流所属的直播流类型；

根据各所述音视频流所属的直播流类型，对各所述音视频流标注对应的优先级标签，得到所述目标音视频流，其中，所述优先级标签包括第一优先级标签与第二优先级标签，所述第二优先级标签在标注过程中附加对应的时间戳。

进一步地，存储器130中的多路直播混流程序被处理器执行时还实现以下步骤：

检测所述多路直播状态；

根据所述多路直播状态判断所述服务端资源是否低于第一预设阈值；

若所述服务端资源低于所述第一预设阈值，则调用图像检测模块对所述第二优先级标签对应的目标音视频流进行检测，得到检测结果；

根据所述检测结果判断所述第二优先级标签对应的目标音视频流中是否存在未检测到人脸的目标音视频流；

若所述第二优先级标签对应的目标音视频流中存在未检测到人脸的目标音视频流，则向所述未检测到人脸的目标音视频流对应的终端发送第一通知，其中，所述第一通知包括中止推流通知或推送最低清晰度音视频流通知。

进一步地，存储器130中的多路直播混流程序被处理器执行时还实现以下步骤：

根据所述多路直播状态判断所述服务端资源是否低于第二预设阈值；

若所述服务端资源低于所述第二预设阈值，则根据所述优先级标签、各所述音视频流所属终端的网络状态以及所述时间戳，向各所述目标音视频流对应的终端发送第二通知，其中，所述第二通知包括自适应降级推流清晰度通知。

进一步地，存储器130中的多路直播混流程序被处理器执行时还实现以下步骤：

接收各所述终端发送的加入直播请求；

根据所述加入直播请求生成推流通知，并将所述推流通知发送至对应的终端，以供所述终端根据所述推流通知向所述服务端推送预设清晰度的音视频流。

进一步地，存储器130中的多路直播混流程序被处理器执行时还实现以下步骤：

发送音视频流至服务端，以供所述服务端根据所述音视频流得到目标音视频流，并基于所述目标音视频流中预先标注的优先级标签生成通知信息，并将所述通知信息发送至相应的终端；

接收所述服务端发送的通知信息，并根据所述通知信息推送自适应清晰度的音视频流至所述服务端，以供所述服务端接收所述自适应清晰度的音视频流，将所述自适应清晰度的音视频流进行混流，并将混流后的音视频流分发推送至各所述终端；

接收所述服务端发送的混流后的音视频流，并将所述混流后的音视频流提供至用户。

进一步地，存储器130中的多路直播混流程序被处理器执行时还实现以下步骤：

接收所述用户的操作指令，并根据所述操作指令发送加入直播请求至所述服务端，以供所述服务端根据所述加入直播请求生成推流通知并发送至所述终端；

获取所述服务端发送的推流通知，以根据所述推流通知发送预设清晰度的音视频流至所述服务端。

进一步地，存储器130中的多路直播混流程序被处理器执行时还实现以下步骤：

接收所述服务端发送的第一通知和/或第二通知，其中，所述第一通知包括中止推流通知或推送最低清晰度音视频流通知，所述第二通知包括自适应降级推流清晰度通知；

根据所述中止推流通知停止向所述服务端推送所述音视频流，或

根据所推送最低清晰度音视频流通知和/或第二通知调整向所述服务端推送的音视频流的清晰度。

本实施例通过上述方案，具体通过获取各终端推送的音视频流，并根据各所述音视频流得到目标音视频流；基于所述目标音视频流中预先标注的优先级标签生成通知信息，并将所述通知信息发送至相应的终端，以供各所述终端根据所述通知信息推送自适应清晰度的音视频流；接收所述自适应清晰度的音视频流，将所述自适应清晰度的音视频流进行混流，并将混流后的音视频流分发推送至各所述终端，以供各所述终端将所述混流后的音视频流提供至用户。通过基于预先标注的优先级标签生成通知信息并发送至相应的终端，使各终端推送自适应清晰度的音视频流，实现了对服务端资源进行自适应释放与分配，提高了多路直播系统的可用性，从而提升了多路直播的用户体验。

基于上述终端设备架构但不限于上述架构，提出本发明方法实施例。

本实施例方法的执行主体可以为一种多路直播混流装置或终端设备等，本实施例以多路直播混流装置进行举例。

参照图4，图4为本发明多路直播混流方法第一示例性实施例的流程示意图。所述多路直播混流方法包括：

步骤S10，获取各终端推送的音视频流，并根据各所述音视频流得到目标音视频流；

随着移动互联网产业的飞速发展，移动音视频也呈现出日益繁荣的现状，直播系统就是充分利用了移动音视频的价值，虽然目前直播系统开发的已经相对成熟，但是在音视频流传输方面仍有很大的优化空间。通过服务端对音视频流进行特征提取并标注优先级标签，可以实现对服务端资源的自适应释放与分配，从而降低时延，提升用户体验。在此之前，服务端需要先获取各终端的音视频流。当用户加入直播室后，终端会默认选择推送清晰度最高的音视频流到MIX服务端，服务端接收到各终端推送的音视频流后，需先对获取的音视频流进行特征提取。

服务端配置有图像识别检测模块，在接收到各终端推送过来的音视频流后，服务端的图像识别检测模块会对终端共享的音视频流进行特征提取，进而根据特征提取的结果标注音视频流的优先级标签，例如在观看欧洲杯奥运会等赛事直播过程中，提取到的比赛直播流具有记分板等特征，而观众直播流具有人脸模型特征。

通过图像识别检测模块对终端推送的音视频流进行特征提取后，可以根据所得特征提取结果对相应的音视频流标注对应的优先级标签，得到标注后的音视频流。例如根据赛事直播过程中提取到的比赛直播流具有记分板等特征，观众直播流具有人脸模型特征，由于比赛的直播流优先级最高，可以将比赛直播流标注为high，而其余的观众直播流则可以被标注为common并带上加入直播室的时间戳，以备后续混流系统达到服务端资源阈值时触发动态自适应推流策略使用。

步骤S20，基于所述目标音视频流中预先标注的优先级标签生成通知信息，并将所述通知信息发送至相应的终端，以供各所述终端根据所述通知信息推送自适应清晰度的音视频流；

进一步地，对各终端推送的音视频流标注对应的优先级标签后，可根据优先级标签生成针对相应终端的通知信息，从而由终端根据通知信息自适应调整推送的音视频流的清晰度，以实现服务端资源的自适应释放与分配。随着加入直播间并共享直播流的人数增加，服务端资源会开始大量消耗，例如服务端带宽资源，当达到设定的阈值极限时，会触发MIX模块调用图像识别检测模块对观众视频流进行特征提取检测，如果检测到某个共享直播流的观众因为某些原因离开摄像头范围即该直播流画面中无法检测到人脸，那么MIX模块就会通知该终端中止推流或者推送最低清晰度的视频流，等到该观众重新回到摄像头前观看比赛时再予以恢复。

当服务端带宽资源即将耗尽时，MIX模块还会根据各音视频流的优先级标签通知特定终端进行自适应降级推送低清晰度的视频流，以此来释放带宽资源。对于同一优先级的各音视频流，服务端会先检测各终端的网络状况，优先通知网络状况差的终端降低推流清晰度，其次再根据终端加入直播室的时间戳进行降级，越早加入的终端优先级越高。在赛事直播过程中，一般来说会优先保证比赛直播流的视频质量。

步骤S30，接收所述自适应清晰度的音视频流，将所述自适应清晰度的音视频流进行混流，并将混流后的音视频流分发推送至各所述终端，以供各所述终端将所述混流后的音视频流提供至用户

更进一步地，各终端根据接收到的通知信息推送自适应清晰度的音视频流后，由服务端对各终端推送的音视频流进行接收，并进一步将收到的音视频流进行混流，再将混流后的音视频流分发推送到各终端，终端通过前端界面将音视频流呈现给用户，由于服务端资源的自适应释放与分配，提高了多路直播系统的可用性，提升了各终端对应用户的收视体验。

在本实施例中，通过获取各终端推送的音视频流，并根据各所述音视频流得到目标音视频流；基于所述目标音视频流中预先标注的优先级标签生成通知信息，并将所述通知信息发送至相应的终端，以供各所述终端根据所述通知信息推送自适应清晰度的音视频流；接收所述自适应清晰度的音视频流，将所述自适应清晰度的音视频流进行混流，并将混流后的音视频流分发推送至各所述终端，以供各所述终端将所述混流后的音视频流提供至用户。通过基于预先标注的优先级标签生成通知信息并发送至相应的终端，使各终端推送自适应清晰度的音视频流，实现了对服务端资源进行自适应释放与分配，提高了多路直播系统的可用性，从而提升了多路直播的用户体验。

参照图5，图5为图4实施例中步骤S10的具体流程示意图。本实施例基于上述图4所示的实施例，在本实施例中，上述步骤S10包括：

步骤S101，获取各所述终端推送的音视频流；

当用户加入直播室后，终端会默认选择推送清晰度最高的音视频流到MIX服务端，服务端接收到各终端推送的音视频流后，需先对获取的音视频流进行特征提取。

步骤S102，对各所述音视频流进行特征提取，得到特征提取结果；

具体地，服务端配置有图像识别检测模块，在接收到各终端推送过来的音视频流后，服务端的图像识别检测模块会对终端共享的音视频流进行特征提取，进而根据特征提取的结果标注音视频流的优先级标签，例如在观看欧洲杯奥运会等赛事直播过程中，提取到的比赛直播流具有记分板等特征，而观众直播流具有人脸模型特征

步骤S103，根据所述特征提取结果对各所述音视频流标注对应的优先级标签，得到所述目标音视频流。

进一步地，通过图像识别检测模块对终端推送的音视频流进行特征提取后，可以根据所得特征提取结果对相应的音视频流标注对应的优先级标签，得到标注后的音视频流。例如根据赛事直播过程中提取到的比赛直播流具有记分板等特征，观众直播流具有人脸模型特征，由于比赛的直播流优先级最高，可以将比赛直播流标注为high，而其余的观众直播流则可以被标注为common并带上加入直播室的时间戳，以备后续混流系统达到服务端资源阈值时触发动态自适应推流策略使用。

本实施例通过上述方案，具体通过获取各所述终端推送的音视频流；对各所述音视频流进行特征提取，得到特征提取结果；根据所述特征提取结果对各所述音视频流标注对应的优先级标签，得到所述目标音视频流。通过将从各终端获取的音视频流进行特征提取并标注优先级标签，有助于后续进行动态自适应推流策略，为服务端资源的分配提供依据。

参照图6，图6为图5实施例中步骤S103的具体流程示意图。本实施例基于上述图5所示的实施例，在本实施例中，上述步骤S103包括：

步骤S1031，根据所述特征提取结果判断各所述音视频流所属的直播流类型；

通过图像识别检测模块对终端推送的音视频流进行特征提取后，可以根据所得特征提取结果判断各音视频流所属的直播流类型，例如，在赛事直播过程中，提取出的音视频流具有计分板或人脸模型等特征，由于比赛直播流具有记分板等特征，观众直播流具有人脸模型特征，因此可以判断音视频流所属的直播流类型为比赛直播流或观众直播流，进而可以根据音视频所属的直播流类型标注相应的优先级标签。

步骤S1032，根据各所述音视频流所属的直播流类型，对各所述音视频流标注对应的优先级标签，得到所述目标音视频流，其中，所述优先级标签包括第一优先级标签与第二优先级标签。

判断出各音视频流所属的直播流类型后，即可根据预先设定的直播流类型对应的优先级，对相应的音视频流标注对应的优先级标签，得到标注后的音视频流。例如根据赛事直播过程中提取到的比赛直播流具有记分板等特征，观众直播流具有人脸模型特征，由于比赛的直播流优先级最高，可以将比赛直播流标注为high，而其余的观众直播流则可以被标注为common并带上加入直播室的时间戳，也可以将比赛直播流标注为第一优先级，将观众直播流标注为第二优先级并带上加入直播室的时间戳，以备后续混流系统达到服务端资源阈值时触发动态自适应推流策略使用，在本发明实施例中，将比赛直播流标注第一优先级标签，将观众直播流标注第二优先级标签。

本实施例通过上述方案，具体通过根据所述特征提取结果判断各所述音视频流所属的直播流类型；根据各所述音视频流所属的直播流类型，对各所述音视频流标注对应的优先级标签，得到各标注后的音视频流，其中，所述优先级标签包括第一优先级标签与第二优先级标签。通过根据特征提取结果判断音视频流所属的直播流类型，从而标注对应的优先级标签，以用于后续进行动态自适应推流策略，为服务端资源的分配提供依据。

参照图7，图7为图4实施例中步骤S20的具体流程示意图。本实施例基于上述图4所示的实施例，在本实施例中，上述步骤S20包括：

步骤S201，检测所述多路直播状态；

在直播过程中，由于服务端资源有限，且用户量处于变化状态，因此多路直播的状态通常是动态变化的过程，为了降低直播过程的时延，提升用户的使用体验，可以采取实时监测多路直播状态的方式，实现动态自适应推流，其中，检测到的多路直播状态中至关重要的部分就是服务端资源，例如服务器的带宽资源，往往对用户接收到的音视频质量有决定性影响。

步骤S202，根据所述多路直播状态判断所述服务端资源是否低于第一预设阈值；

检测到多路直播状态后，可以判断其中的服务端资源是否低于第一预设阈值，其中，第一预设阈值可以是根据服务端的带宽资源设定的阈值极限，一旦低于该阈值极限，则会造成带宽资源不足，影响大多数用户体验，因此需要进一步对观众直播流进行检测，选取其中未检测到人脸的终端进行限流，以确保大多数在线观看的观众的用户体验。

步骤S203，若所述服务端资源低于所述第一预设阈值，则调用图像检测模块对所述第二优先级标签对应的目标音视频流进行检测，得到检测结果；

如果检测到服务端资源低于第一预设阈值，即当达到设定的阈值极限时，会触发MIX模块调用图像识别检测模块对观众直播流进行特征提取检测，以筛选出观众直播流中未检测到人脸的直播流所在的终端。

步骤S204，根据所述检测结果判断所述第二优先级标签对应的目标音视频流中是否存在未检测到人脸的目标音视频流；

调用图像识别检测模块对各观众直播流进行特征提取后，需根据检测结果判断是否存在未检测到人脸模型的音视频流，即判断直播流画面中是否检测到人脸。

步骤S205，若所述第二优先级标签对应的目标音视频流中存在未检测到人脸的目标音视频流，则向所述未检测到人脸的目标音视频流对应的终端发送第一通知，其中，所述第一通知包括中止推流通知或推送最低清晰度音视频流通知，所述第二通知包括自适应降级推流清晰度通知。

如果检测到不存在人脸模型的音视频流，即该直播流画面中无法检测到人脸，则说明相应终端的观众因为某些原因离开了摄像头范围，因此为了避免服务端资源的浪费，MIX模块即可通知该音视频流对应的终端中止推流或者推送最低清晰度的视频流，直至该观众重新回到摄像头前观看直播时再予以恢复。

本实施例通过上述方案，具体通过检测所述多路直播状态；根据所述多路直播状态判断所述服务端资源是否低于第一预设阈值；若所述服务端资源低于所述第一预设阈值，则调用图像检测模块对所述第二优先级标签对应的目标音视频流进行检测，得到检测结果；根据所述检测结果判断所述第二优先级标签对应的目标音视频流中是否存在未检测到人脸的目标音视频流；若所述第二优先级标签对应的目标音视频流中存在未检测到人脸的目标音视频流，则向所述未检测到人脸的目标音视频流对应的终端发送第一通知，其中，所述第一通知包括中止推流通知或推送最低清晰度音视频流通知，所述第二通知包括自适应降级推流清晰度通知。通过在服务器端资源低于预设阈值情况下对第二优先级标签对应的目标音视频流进行检测，筛选出暂时不需要观看直播的用户，进而通知该音视频流对应的终端中止推流或者推送最低清晰度的视频流，直至该观众重新回到摄像头前观看直播时再予以恢复，实时动态调整服务端资源的分配，提升了在线观看直播的用户的使用体验。

参照图8，图8为本发明多路直播混流方法第二示例性实施例的流程示意图。基于上述图7所示的实施例，在本实施例中，在步骤S201之后，所述多路直播混流方法还包括：

步骤S206，根据所述多路直播状态判断所述服务端资源是否低于第二预设阈值；

随着加入直播间并共享直播流的用户人数进一步增加，检测的多路直播状态中服务端资源可能达即将耗尽的状态，因此需要判断服务端资源是否低于第二预设阈值，用于进一步对服务端资源进行自适应调整。

步骤S207，若所述服务端资源低于所述第二预设阈值，则根据所述优先级标签、各所述音视频流所属终端的网络状态以及所述时间戳，向各所述目标音视频流对应的终端发送第二通知，其中，所述第二通知包括自适应降级推流清晰度通知。

如果检测到服务端资源低于第二预设阈值，即服务端资源即将耗尽，为了避免对用户体验造成影响，需要根据预先对各音视频流标注的优先级标签，向优先级较低的音视频流对应的终端发送第二通知，其中，第二通知可以是通知网络状况差的终端降低推流清晰度

以此来释放带宽资源。对于同一优先级的各直播流，对各音视频流所属的终端的网络状态进行检测，即对于同一优先级标签的音视频流，可通过检测终端网络状态通知网络状态差的终端进行自适应降级推送清晰度低的视频流。

进一步地，对同一优先级的音视频流终端进行检测后，根据检测结果向各音视频流对应的终端发送通知，以进行自适应降级推送低清晰度的视频流，其次，对于网络状态相同的终端，可再根据终端加入直播室的时间戳进行降级，越早加入的终端优先级越高，一般来说会优先保证比赛直播流的视频质量。

本实施例通过上述方案，具体通过根据所述多路直播状态判断所述服务端资源是否低于第二预设阈值；若所述服务端资源低于所述第二预设阈值，则根据所述优先级标签、各所述音视频流所属终端的网络状态以及所述时间戳，向各所述目标音视频流对应的终端发送第二通知，其中，所述第二通知包括自适应降级推流清晰度通知。通过在服务端资源即将耗尽的情况下，根据各音视频流的优先级标签通知特定终端进行自适应降级推送低清晰度的视频流，对于同一优先级的各直播流，则通过检测各终端的网络状况，优先通知网络状况差的终端降低推流清晰度，其次再根据终端加入直播室的时间戳进行降级，以此来释放带宽资源，进一步实现动态自适应推流，提升用户的使用体验。

参照图9，图9为本发明多路直播混流方法第三示例性实施例的流程示意图。基于上述图4所示的实施例，在本实施例中，在步骤S10之前，所述多路直播混流方法还包括：

步骤S01，接收各所述终端发送的加入直播请求；

当有用户需要加入直播室时，由终端接收用户的操作信息，并根据操作信息生成加入直播请求，服务端即可接收各终端发送的加入直播请求。

步骤S02，根据所述加入直播请求生成推流通知，并将所述推流通知发送至对应的终端，以供所述终端根据所述推流通知向所述服务端推送预设清晰度的音视频流。

接收到各终端发送的加入直播请求后，服务端即可根据该请求生成推流通知，进而将推流通知发送至相应的终端，由各终端根据推流通知向服务端推送音视频流，在本实施例中，各终端默认推送的音视频流清晰度为最高清晰度的视频流，作为一种实施方式，所述预设清晰度为1080p。

参照图10，图10为本发明多路直播混流方法第四示例性实施例的流程示意图。在本实施例中，所述多路直播混流方法应用于终端，所述所述多路直播混流方法包括：

步骤A10，发送音视频流至服务端，以供所述服务端根据所述音视频流得到目标音视频流，并基于所述目标音视频流中预先标注的优先级标签生成通知信息，并将所述通知信息发送至相应的终端；

在向服务端发送预设清晰度的音视频流之前，终端还需获取服务端的推流通知，具体步骤包括：

步骤A01，接收所述用户的操作指令，并根据所述操作指令发送加入直播请求至所述服务端，以供所述服务端根据所述加入直播请求生成推流通知并发送至所述终端；

当终端界面接收到用户的操作指令后，即可根据操作指令生成加入直播请求发送至服务端，进而由服务端根据加入直播请求生成推流通知。

步骤A02，获取所述服务端发送的推流通知，以根据所述推流通知发送预设清晰度的音视频流至所述服务端。

获取到服务端发送的推流通知后，终端即可根据该推流通知向服务端发送预设清晰度的音视频流，在本实施例中，各终端默认推送的音视频流清晰度为最高清晰度的视频流，作为一种实施方式，所述预设清晰度为1080p。

步骤A20，接收所述服务端发送的通知信息，并根据所述通知信息推送自适应清晰度的音视频流至所述服务端，以供所述服务端接收所述自适应清晰度的音视频流，将所述自适应清晰度的音视频流进行混流，并将混流后的音视频流分发推送至各所述终端；

进一步地，随着加入直播间并共享直播流的用户数量增加，服务端资源开始大量消耗，当服务端资源达到预设阈值时会触发动态自适应推流策略，在此过程中，相应终端进行的具体步骤包括：

步骤A201，接收所述服务端发送的第一通知和/或第二通知，其中，所述第一通知包括中止推流通知或推送最低清晰度音视频流通知，所述第二通知包括自适应降级推流清晰度通知；

接收服务端发送的第一通知或第二通知，第一通知是由服务端检测到终端提供的画面中不存在人脸模型特征时发送的通知，用于通知该终端中止推流或者推送最低清晰度的视频流，等到该观众重新回到摄像头前观看比赛时再予以恢复。第二通知是服务端根据优先级标签、终端网络状态以及加入直播室的时间戳，通知终端进行自适应降级推送低清晰度的视频流的通知。

步骤A202，根据所述包括中止推流通知停止向所述服务端推送所述音视频流，或

步骤A203，根据所推送最低清晰度音视频流通知和/或第二通知调整向所述服务端推送的音视频流的清晰度。

接收到第一通知或第二通知后，终端即可根据通知调整推送，若收到中止推流通知，即停止向服务端推送音视频流；若收到推送最低清晰度音视频流通知或第二通知，则可根据通知内容调整向所述服务端推送的音视频流的清晰度，从而释放服务端的带宽资源。

步骤A30，接收所述服务端发送的混流后的音视频流，并将所述混流后的音视频流提供至用户。

接收到服务端发送的混流后的音视频流，进而通过界面将混流后的音视频流提供给用户，通过优先级标签实现根据多路直播的状态对服务端资源进行自适应释放与分配。

本实施例通过上述方案，具体通过发送音视频流至服务端，以供所述服务端根据所述音视频流得到目标音视频流，对所述目标音视频流进行混流，并基于预先标注的优先级标签，将混流后的音视频流进行分发推送；接收所述服务端发送的混流后的音视频流，并将所述混流后的音视频流提供至用户，其中，所述优先级标签用于所述服务端根据所述多路直播的状态对服务端资源进行自适应释放与分配。通过接收服务端的通知信息调整推流，实现动态自适应推流，释放服务端资源，从而提升用户的体验。

此外，本发明实施例还提出一种多路直播混流服务器，所述多路直播混流服务器包括：

获取模块，用于获取各终端推送的音视频流，并根据各所述音视频流得到目标音视频流；

通知模块，用于基于所述目标音视频流中预先标注的优先级标签生成通知信息，并将所述通知信息发送至相应的终端，以供各所述终端根据所述通知信息推送自适应清晰度的音视频流；

混流模块，用于接收所述自适应清晰度的音视频流，将所述自适应清晰度的音视频流进行混流，并将混流后的音视频流分发推送至各所述终端，以供各所述终端将所述混流后的音视频流提供至用户。

参照图11，图11为本发明实施例中的动态自适应混流直播策略的流程示意图，如图11所示，本方案的具体流程如下：

步骤1，首先，一个用户加入直播室，终端默认选择推送清晰度最高的视频流到MIX服务端。

步骤2，在接收到各终端推送过来的直播流后，服务端的图像识别检测模块会对终端共享的音视频流进行特征提取检测并标注优先级标签，如比赛直播流具有记分板等特征，而观众直播流具有人脸模型特征。因为比赛的直播流优先级最高，会被标注为high，而其余的观众直播流则会被标注为common并带上加入直播室的时间戳，以备后续混流系统达到服务端资源阈值时触发动态自适应推流策略使用。

步骤3，完成对各直播视频流优先级标注后，MIX模块会开始将各直播流进行混流后再分发推送至直播室内的所有终端。

步骤4，随着加入直播间并共享直播流的人数增加，服务端的带宽资源开始大量消耗，当达到设定的阈值极限时，会触发MIX模块调用图像检测模块对观众视频流进行特征提取检测，如果检测到某个共享直播流的观众因为某些原因离开摄像头范围即该直播流画面中无法检测到人脸，那么MIX模块就会通知该终端中止推流或者推送最低清晰度的视频流，等到该观众重新回到摄像头前观看比赛时再予以恢复。

步骤5，当服务端带宽资源即将耗尽时，MIX模块还会根据步骤2中各直播流的优先级通知特定终端进行自适应降级推送低清晰度的视频流，以此来释放带宽资源。对于同一优先级的各直播流，服务端会先检测各终端的网络状况，优先通知网络状况差的终端降低推流清晰度，其次再根据终端加入直播室的时间戳进行降级，越早加入的终端优先级越高。一般来说会优先保证比赛直播流的视频质量。

本实施例通过上述方案，具体基于图像检测的动态自适应多路直播混流方案，通过图像识别检测对多路视频流进行优先级标注，使得服务端能够按此策略在带宽等资源达到设定阈值时进行动态调整终端推流策略。此外，服务端图像检测模块的定时检测任务能够根据实时的场景变化自适应调整终端推流数量或清晰度。这实现了服务端带宽等资源根据实时场景变化动态释放与分配的策略，大幅增加了同一个直播室内所能容纳的共享直播流的观众数量，同时提升了整个多路直播系统的可用性。

此外，本发明还提供一种多路直播混流终端设备，所述多路直播混流终端设备包括：

推流模块，用于发送音视频流至服务端，以供所述服务端根据所述音视频流得到目标音视频流，并基于所述目标音视频流中预先标注的优先级标签生成通知信息，将混流后的音视频流与所述通知信息分发推送至各所述终端；

自适应模块，用于接收所述服务端发送的通知信息，并根据所述通知信息推送自适应清晰度的音视频流至所述服务端；

接收模块，用于接收所述服务端发送的混流后的音视频流，并将所述混流后的音视频流提供至用户。

本实施例实现多路直播混流的原理及实施过程，请参照上述各实施例，在此不再赘述。

此外，本发明实施例还提出一种多路直播混流系统，所述多路直播混流系统包括服务器、终端设备、存储器、处理器及存储在所述存储器上并可在所述处理器上运行的多路直播混流程序，所述多路直播混流程序被所述处理器执行时实现如上所述的多路直播混流方法的步骤。

由于本多路直播混流程序被处理器执行时，采用了前述所有实施例的全部技术方案，因此至少具有前述所有实施例的全部技术方案所带来的所有有益效果，在此不再一一赘述。

此外，本发明实施例还提出一种计算机可读存储介质，所述计算机可读存储介质上存储有多路直播混流程序，所述多路直播混流程序被处理器执行时实现如上所述的多路直播混流方法的步骤。

由于本多路直播混流程序被处理器执行时，采用了前述所有实施例的全部技术方案，因此至少具有前述所有实施例的全部技术方案所带来的所有有益效果，在此不再一一赘述。

相比现有技术，本发明实施例提出的多路直播混流方法、服务器、终端设备、系统及存储介质，通过获取各终端推送的音视频流，并根据各所述音视频流得到目标音视频流；基于所述目标音视频流中预先标注的优先级标签生成通知信息，并将所述通知信息发送至相应的终端，以供各所述终端根据所述通知信息推送自适应清晰度的音视频流；接收所述自适应清晰度的音视频流，将所述自适应清晰度的音视频流进行混流，并将混流后的音视频流分发推送至各所述终端，以供各所述终端将所述混流后的音视频流提供至用户。通过基于预先标注的优先级标签生成通知信息并发送至相应的终端，使各终端推送自适应清晰度的音视频流，实现了对服务端资源进行自适应释放与分配，提高了多路直播系统的可用性，从而提升了多路直播的用户体验。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，被控终端，或者网络设备等)执行本申请每个实施例的方法。

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