CN112839239B - 一种音视频加工的方法、装置及服务器 - Google Patents

Abstract

本申请公开了一种音视频加工的方法、装置及服务器，其中所述方法包括：接收加工任务，所述加工任务用于描述对音视频加工所需的加工流程，所述加工任务至少包括：待加工的音视频流的标识以及加工插件标识列表；将所述加工任务发送至目标容器组中，所述目标容器组包括主调度容器以及至少一个插件容器，所述插件容器内包括对应的加工插件；在所述目标容器组内，由所述主调度容器拉取与所述待加工的音视频流的标识对应的音视频流，并依次调用所述加工插件标识列表中各加工插件标识对应的插件容器，由所述插件容器启动对应的加工插件对所述音视频流进行内容加工处理。通过容器组技术，将多个加工插件部署在不同的插件容器中，可以避免多插件依赖冲突的问题。

Description

一种音视频加工的方法、装置及服务器

技术领域

本申请实施例涉及多媒体数据处理技术，尤其涉及一种音视频加工的方法、装置及服务器。

背景技术

目前，随着网络通信技术的进步和宽带网络的提速，网络直播得到了越来越多的发展和应用。为了提升主播的直播效果，通常可以采用内容加工服务来对直播的视频进行内容加工，例如，对视频进行AI(Artificial Intelligence，人工智能)美颜、背景分割、白板处理等。

在相关技术中，如图1所示，对视频进行内容加工的方式包括如下流程：通过多个接收器receiver进行拉流，对每路视频流通过解码器decoder进行解码后，通过混流器(compositor)对解码后的视频流进行混流处理，在混流的过程中，采用使用Lua语言编写插件对混流后的视频流进行加工处理，然后将加工处理后的视频通过编码器(encoder)进行编码，并将编码后的视频流进行推流处理(pusher)。

但上述的内容加工方式存在如下不足：

1、只能使用Lua语言编写插件；

2、一次拉流、解码、混流、加工、编码、推流的过程只能进行一次加工处理，如果需要对视频进行多次加工处理，需要进行多次的推拉流和编解码，延迟较高。

发明内容

本申请提供一种音视频加工的方法、装置及服务器，以解决现有技术的加工方式中存在的加工延时高、加工插件限制的问题。

第一方面，本申请实施例提供了一种音视频加工的方法，所述方法包括：

接收加工任务，所述加工任务用于描述对音视频加工所需的加工流程，所述加工任务至少包括：待加工的音视频流的标识以及加工插件标识列表；

将所述加工任务发送至目标容器组中，所述目标容器组包括主调度容器以及至少一个插件容器，所述插件容器内包括对应的加工插件；

在所述目标容器组内，由所述主调度容器拉取与所述待加工的音视频流的标识对应的音视频流，并依次调用所述加工插件标识列表中各加工插件标识对应的插件容器，由所述插件容器启动对应的加工插件对所述音视频流进行内容加工处理。

第二方面，本申请实施例还提供了一种用于进行音视频加工的服务器，所述服务器包括目标容器组，所述目标容器组包括主调度容器以及与所述主调度容器相连的至少一个插件容器，所述插件容器内包括对应的加工插件；

所述主调度容器用于接收加工任务，并根据所述加工任务中的待加工的音视频流的标识拉取对应的音视频流，以及，依次调用所述加工任务中的加工插件标识对应的插件容器，其中，所述加工任务用于描述对音视频加工所需的加工流程；

所述插件容器用于在被调用时，启动本容器的加工插件对所述音视频流进行内容加工处理。

第三方面，本申请实施例还提供了一种音视频加工的装置，所述装置包括：

任务接收模块，用于接收加工任务，所述加工任务用于描述对音视频加工所需的加工流程，所述加工任务至少包括：待加工的音视频流的标识以及加工插件标识列表；

任务发送模块，用于将所述加工任务发送至目标容器组中，所述目标容器组包括主调度容器以及至少一个插件容器，所述插件容器内包括对应的加工插件；

内容加工模块，用于在所述目标容器组内，由所述主调度容器拉取与所述待加工的音视频流的标识对应的音视频流，并依次调用所述加工插件标识列表中各加工插件标识对应的插件容器，由所述插件容器启动对应的加工插件对所述音视频流进行内容加工处理。

第四方面，本申请实施例还提供了一种服务器，所述服务器包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述的方法。

第五方面，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述的方法。

本申请所提供的技术方案，具有如下有益效果：

在本实施例中，通过容器组技术，将多个加工插件部署在不同的插件容器中，可以避免多插件依赖冲突的问题(例如，由于插件的编写语言、版本等不同，无法将多插件组合的情况)，这种部署方式同时也使得支持的插件可能性更多，对于抢占式任务来说，可以充分提升资源利用率。

在拉流以后，主调度容器通过依次调用插件容器，来触发插件容器启动对应的加工插件对音视频流进行加工处理，以实现音视频的多重云加工处理，无需多次拉流推流和编解码，降低了加工延迟，提高了对音视频流的加工效率。

另外，本实施例通过调度代理服务管理多加工插件的协同加工处理，在目标容器组中包括主调度容器以及与至少一个插件容器，主调度容器通过主调度代理与插件容器的插件调度代理通信，从而实现了主调度容器与各插件容器的通信，然后由各插件容器的插件调度代理来开启本容器的加工插件，并在开启加工插件时传递加工服务的监听端口的第一端口信息，各加工插件通过该第一端口信息与加工服务直接连接，由加工服务统一管理各加工插件，可以消除多容器都部署后发布时可能版本不一致的问题。

附图说明

图1是本申请背景技术中提及的现有对视频进行内容加工的流程示意图；

图2是本申请实施例一提供的一种音视频加工的方法实施例的流程图；

图3是本申请实施例二提供的一种音视频加工的方法实施例的流程图；

图4是本申请实施例二提供的内容加工的调度过程示意图；

图5是本申请实施例二提供的加工插件单容器部署与多容器部署的差异对比图示意图；

图6是本申请实施例三提供的一种音视频加工的方法实施例的流程图；

图7是本申请实施例三提供的另一种音视频加工的方法实施例的流程图；

图8是本申请实施例四提供的一种用于进行音视频加工的服务器实施例的结构框图；

图9是本申请实施例四提供的另一种用于进行音视频加工的服务器实施例的结构框图；

图10为本申请实施例五提供的一种音视频加工的装置实施例的结构框图；

图11是本申请实施例五提供的一种服务器的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。

实施例一

图2为本申请实施例一提供的一种音视频加工的方法实施例的流程图，该音视频加工的方法是一种类似于流水线的云加工方法，可以在云端串联多个加工插件对音视频流进行加工处理，其中，在本实施例中，该多个加工插件可以利用Pod多容器部署，以避免多插件部署在同一个容器中引起的环境依赖冲突的问题，对于抢占式任务来说，可以充分提升资源利用率。

本实施例可以应用于服务器中，如图2所示，可以包括如下步骤：

步骤201，接收加工任务，所述加工任务至少包括：待加工的音视频流的标识以及加工插件标识列表。

本实施例可以应用于对音视频流进行内容加工的场景，例如，在直播场景下对直播的视频进行美颜、背景分割等加工。对于待加工的音视频流，可以根据用户指示的加工需求，创建对应的加工任务，并把加工任务发送至实施本实施例的服务器中。

本实施例关于需求方创建加工任务的方式不作限定，例如，需求方可以是服务器上的一个业务服务，也可以是终端上的软件程序(如手机上的APP)，当需求方检测到用户触发的加工业务需求时，则可以根据用户触发的需求创建加工任务。

本实施例的加工任务可以用于描述对音视频加工所需的加工流程，示例性地，加工任务至少可以包括：待加工的音视频流的标识以及加工插件标识列表。其中，该加工插件标识列表为加工本实施例的音视频流所需的加工插件的标识组成的列表，列表中可以包括一个或多于一个的加工插件标识，各加工插件标识对应的加工插件被用于对待加工的音视频流进行加工。

步骤202，将所述加工任务发送至目标容器组中，所述目标容器组包括主调度容器以及至少一个插件容器，所述插件容器内包括对应的加工插件。

在该步骤中，在接收到加工任务以后，可以将该加工任务发送至目标容器组Pod中，以由Pod中的容器执行该加工任务。

在该实施例中，目标容器组可以包括主调度容器以及与该主调度容器连接的至少一个插件容器，各插件容器内可以包括对应的加工插件。

其中，主调度容器主要作用是对接外部的加工任务以及对云加工SDK(用于云音视频加工的可执行程序)的管理。插件容器与主调度容器通信，其作用是根据主调度容器的指令启停插件，同时会向主调度容器进行注册支持的插件信息。

步骤203，在所述目标容器组内，由所述主调度容器拉取与所述待加工的音视频流的标识对应的音视频流，并依次调用所述加工插件标识列表中各加工插件标识对应的插件容器，由所述插件容器启动对应的加工插件对所述音视频流进行内容加工处理。

在该步骤中，在目标容器组中，由主调度容器接收到加工任务以后，则可以根据待加工的音视频流的标识拉取对应的音视频流，然后调用加工插件标识列表中各加工插件标识对应的插件容器，由被调用的插件容器启动对应的加工插件对音视频流进行内容加工处理。

在一种实现中，加工插件标识列表中各加工插件标识对应的插件容器可以串联工作，前一个插件容器的输出可以作为后一个插件容器的输入。例如，假如加工任务是AI人脸动漫化，需要用到三个加工插件，加工插件1用于识别出人脸数据，加工插件2用于进行数据动漫化，加工插件3用于把动漫化的数据贴到人脸上，其中，加工插件1、2、3分别不属于不同的插件容器中，根据本实施例，每一帧数据都需要经过上面三个插件的加工处理，则加工插件1识别出的人脸的位置信息以及输出帧，可以作为加工插件2的输入，加工插件2在该人脸的位置上进行动漫化处理，输出动漫化的数据以及输出帧；该输出作为加工插件3的输入，插件3将动漫化的数据贴在人脸位置上，输出最终的帧。

各插件容器中的加工插件可以是不同能力团队提供的云美颜、云背景替换等各种音频或视频加工插件。本实施例支持加工插件的拼装，可以按照业务需求随意接入各种加工插件。并且，本实施例对加工插件的编写预言不作限定，插件的接入方可以自由选择Lua、Python、C++等等语言来编写加工插件。

在本实施例中，通过容器组技术，将多个加工插件部署在不同的插件容器中，可以避免多插件依赖冲突的问题(例如，由于插件的编写语言、版本等不同，无法将多插件组合的情况)，这种部署方式同时也使得支持的插件可能性更多，对于抢占式任务来说，可以充分提升资源利用率。

在拉流以后，主调度容器通过依次调用插件容器，来触发插件容器启动对应的加工插件对音视频流进行加工处理，以实现音视频的多重云加工处理，无需多次拉流推流和编解码，降低了加工延迟，提高了对音视频流的加工效率。

另外，本实施例可以根据加工插件标识列表进行加工插件的拼装，当需要多重内容加工时，只需要在流水线上增加对应的加工插件即可，丰富了内容加工的形式和灵活性。并且以加工任务的方式来触发内容加工，可以按照实际的业务需求自定义输入和输出的路数和参数。

实施例二

图3为本申请实施例二提供的一种音视频加工的方法实施例的流程图，本实施例在实施例一的基础上，进行更具体的说明。如图3所示，本实施例可以包括如下步骤：

步骤301，接收加工任务，所述加工任务至少包括：待加工的音视频流的标识以及加工插件标识列表。

在一种实现中，服务器中可以部署一个基于go服务的普通容器，当服务器需要接入加工任务时，可以通过该普通容器接收加工服务。

示例性地，如图4所示，该普通容器中可以包括任务调度服务(Dispatch)以及资源分配服务(ResourcesMgr)，其中，任务调度服务可以用于针对当前加工任务进行任务调度，资源分配服务可以与各加工节点进行心跳通信，并进行资源分配。在本实施例中，可以通过任务调度服务(Dispatch)接收接入的加工任务。

其中，加工任务至少可以包括：待加工的音视频流的标识以及加工插件标识列表。其中，该加工插件标识列表为加工本实施例的音视频流所需的加工插件的标识组成的列表，列表中可以包括一个或多于一个的加工插件标识，各加工插件标识对应的加工插件被用于对待加工的音视频流进行加工。除此以外，在其他示例中，列表中还可以包括执行顺序，即，各加工插件被执行的顺序。

步骤302，针对所述加工任务，进行资源分配，并根据所述资源分配的结果确定目标加工节点，以及，在所述目标加工节点中创建目标容器组。

在一种实施方式中，如图4所示，当任务调度服务接收到加工任务以后，可以将加工任务发送至资源分配服务，以请求资源分配服务进行资源分配。

对于资源分配服务而言，在一种实施方式中，其可以接收已有的各加工节点的资源上报心跳，该心跳中可以包括加工节点的资源数据，例如，当前加工节点的CPU核数、GPU卡数、显存大小、内存大小、支持的插件数据(如插件类型、该插件类型所需的CPU核数、显存大小和内存大小等)、目前已运行的插件类型，等等。

当资源分配服务接收到加工任务以后，可以根据该加工任务中的加工插件标识列表确定要运行该加工插件标识列表对应的插件的所需资源，该所需资源可以包括所需的总CPU核数、总显存大小以及总内存大小等。然后，资源分配服务分别判断已有的各加工节点的剩余资源是否满足该所需资源，然后从满足所需资源的加工节点中随机或者按照其他负载均衡策略选择一个目标加工节点，该目标加工节点就是执行加工任务的节点。资源分配服务在得到分配结果以后，可以将分配结果返回任务调度服务。

任务调度服务在根据分配结果确定目标加工节点以后，则可以在目标加工节点中创建用于执行本次加工任务的目标容器组。

在本实施例中，目标容器组可以包括主调度容器以及与该主调度容器通信的至少一个插件容器，其中，主调度容器进一步可以包括主调度代理以及加工服务，插件容器进一步可以包括插件调度代理以及对应的加工插件。插件容器是根据加工插件标识列表中的各加工插件标识依次调用到目标容器组内的。

如图4所示，假设加工任务包括AI美颜、背景分割、小程序白板等，则目标容器组可以包括主调度容器、AI美颜镜像容器、背景分割镜像容器以及小程序白板镜像容器，其中，主调度容器可以包括主调度代理(PipelineMgr)以及加工服务(PipelineServer)，该加工服务即云加工SDK；AI美颜镜像容器可以包括插件调度代理(PipelineMgr)以及AI美颜插件；背景分割镜像容器可以包括插件调度代理(PipelineMgr)以及背景分割插件；小程序白板镜像容器可以包括插件调度代理(PipelineMgr)以及白板插件。

步骤303，当通过主调度代理接收到加工任务以后，由所述主调度代理启动所述加工服务，并将所述加工任务发送至所述加工服务。

在本实施例中，任务调度服务在创建主调度容器以后，可以将加工任务发送至主调度容器中的主调度代理中。主调度代理接收到加工任务以后，可以启动加工服务，然后将加工任务发送至加工服务中，由加工服务执行内容加工流程。

步骤304，由所述加工服务根据所述加工任务中的待加工的音视频流的标识，拉取对应的音视频流。

在该步骤中，加工服务接收到加工任务以后，则可以执行拉流操作。具体的，当加工服务从加工任务中获得待加工的音视频流的标识以后，可以通过拉流线程(Puller)拉取与该待加工的音视频流的标识对应的音视频流。

需要说明的是，本实施例的音视频流可以有一个或多个，当有多个时，则可以采用多个Puller进行多路拉流。Puller可以适配不同的输入流，例如，该音视频流可以包括rtmp协议的音视频流、指定音视频网络的音视频数据或者是mp4、flv格式的文件等。

步骤305，通过所述加工服务将所述音视频流解码成帧数据，以及，将所述帧数据存储在共享内存中。

在该步骤中，当拉流以后，加工服务可以通过解码器(Decorder)对拉取的音视频流进行解码，Decorder对音视频流进行解码后得到帧数据，其中，对于视频而言，该帧数据可以为rgba格式的图像帧；对于音频而言，该帧数据可以为未经过压缩的PCM格式。

然后，加工服务可以将帧数据存储在共享内存中，在共享内存中，帧数据可以以内存偏移量进行标记，即，可以首先获取该帧数据在共享内存中的存储位置，然后计算该存储位置的内存偏移量。

步骤306，在所述加工服务中开启监听端口，并获取所述监听端口的第一端口信息。

在该步骤中，当加工服务接收到加工任务以后，还可以启动监听端口，示例性地，该监听端口可以包括基于远程过程调用协议RPC协议的thrift接口(即Thrift RPC)，该监听端口的第一端口信息可以包括Thrift RPC的端口号(thirft port)，该监听端口用来给各插件进行监听，以进行循环消费。

步骤307，由所述加工服务依次遍历所述加工插件标识列表中的加工插件标识，针对当前的加工插件标识，向所述主调度代理发送启动指令，所述启动指令包括当前的加工插件标识以及所述第一端口信息。

在该实施例中，加工插件标识列表中如果包含有两个以上的加工插件标识，则加工插件标识列表中还可以标记该两个以上的加工插件标识的执行顺序。当加工服务开启thirft port以后，其可以按照加工插件标识列表中执行顺序，依次遍历列表中的加工插件标识，逐一调用对应的插件容器。

对于当前遍历到的加工插件标识，加工服务可以向主调度代理发送启动指令，以触发主调度代理调用对应的插件容器。示例性地，该启动指令可以包括当前的加工插件标识以及第一端口信息。

步骤308，所述主调度代理根据所述启动指令中的加工插件标识，查找该加工插件标识对应的插件容器的第二端口信息，并根据所述第二端口信息将所述第一端口信息发送至对应的插件容器中。

在该步骤中，当主调度代理接收到启动指令以后，可以根据启动指令中的加工插件标识，查找该加工插件标识对应的插件容器的容器信息，示例性地，该容器信息可以包括第二端口信息，该第二端口信息为插件容器中的插件调度代理的rpc port。

然后，主调度代理可以根据该第二端口信息调用对应的插件容器，并将第一端口信息发送至该插件容器中的插件调度代理中。

步骤309，所述插件容器通过本容器的插件调度代理接收所述第一端口信息，并启动本容器的加工插件，以及将所述第一端口信息发送至该加工插件中。

在该步骤中，被调用的插件容器的插件调度代理接收所述第一端口信息以后，则启动本容器的加工插件，并将第一端口信息发送至该加工插件中。

步骤310，由所述加工插件根据所述第一端口信息监听所述监听端口，以实现与所述加工服务的通信，以及，获取待处理的帧数据，并对所述帧数据进行加工处理。

在该步骤中，当加工插件接收到第一端口信息以后，通过该第一端口信息来实现与加工服务的通信，监听加工服务通过监听端口发出的事件，如图4所示，AI美颜插件、背景分割插件以及白板插件均可以通过监听加工服务的监听端口来与加工服务进行直接通信。

在一种实施方式中，该事件可以包括加工服务发出的帧数据处理事件，则步骤310中，获取待处理的帧数据可以包括如下步骤：

步骤310-1，从所述加工服务中获取待处理的帧数据的内存偏移量信息。

在该实施例中，加工服务可以通过监听端口发出帧数据处理事件，示例性地，该事件可以包括待处理的帧数据的内存偏移量信息，当前加工插件监听到该事件以后，获得对应的内存偏移量信息，其中，该内存偏移量信息为该帧数据在共享内存的存储偏移量。

步骤310-2，根据所述待处理的帧数据的内存偏移量信息，确定所述待处理的帧数据在共享内存中的存储位置，并从所述存储位置中读取所述帧数据。

在该步骤中，当当前加工插件获得待处理的帧数据的内存偏移量信息以后，可以根据该内存偏移量信息计算待处理的帧数据在共享内存中存储位置，然后从该存储位置中读取帧数据。

当加工插件获得待处理的帧数据以后，可以采用对应的加工逻辑对该读取的帧数据进行内容加工处理。例如，若该加工插件的功能是进行人脸识别，则在获得帧数据以后，该加工插件可以识别出该帧数据中的人脸位置。

本实施例通过将帧数据存放在共享内存中，加工服务与加工插件之间不传输帧数据只传递内存偏移量，可以有效避免多级插件之间传输帧数据引起的传输延迟。

步骤311，当当前加工插件对所述帧数据加工处理完毕以后，将加工处理完的帧数据存储在共享内存中。

在该步骤中，当前加工插件对帧数据进行内容加工处理以后，可以将加工处理后的帧数据存储在共享内存中。例如，若加工插件为人脸识别插件，则可以将识别出的人脸位置以及输出帧(例如，在帧数据上标记出人脸位置)存储在共享内存中。

在一种实现中，该加工处理后的帧数据可以存储在原来的存储位置，并覆盖原有的帧数据。当然，该加工处理后的帧数据还可以存储在其他位置，本实施例对此不作限定。

步骤312，向所述加工服务返回加工完成消息，所述加工服务根据所述加工完成消息，继续遍历所述加工插件标识列表中的下一个加工插件标识，以此类推，直到所述加工插件标识列表中的加工插件标识遍历完毕。

在该步骤中，当加工插件将加工处理后的帧数据存入共享内存以后，可以向加工服务发送一个加工完成消息，以通知加工服务当前插件的加工完成，在一种实现中，该加工完成消息还可以携带加工处理后的帧数据在共享内存中的内存偏移量，这样，加工服务在下一次发送启动指令时，携带该接收到的该内存偏移量，以促使下一个加工插件根据该内存偏移量获取前一个加工插件的加工结果，进行继续加工。

加工服务接收到该加工完成消息以后，则可以判定当前加工插件已经工作完成，并继续遍历加工插件标识列表中的下一个加工插件标识，并执行步骤307-312的过程，直到加工插件标识列表的所有加工插件标识遍历完毕，以及所有加工插件标识对应的加工插件都加工处理完毕为止，则最后一个加工插件输出的结果就是当前阶段的加工结果。

需要说明的是，本实施例所描述的上述过程提出了一个基于共享内存的云加工方案，但是在其他实施例中，没有共享内存也是可以的，例如，加工服务进行拉流并解码后，可以将帧数据存储在本地，当加工服务和加工插件建立连接以后，加工服务可以直接将帧数据传递给加工插件进行加工，加工插件加工完成以后，可以将加工处理后的帧数据回传给加工服务，由加工服务再传递给下一加工插件进行加工，以此类推，直到加工插件标识列表的所有加工插件标识对应的加工插件均处理完毕，由最后一个加工插件输出的帧数据就是当前阶段的加工结果。

在本实施例中，提出了一种单Pod多容器的音视频加工方法，通过将执行当前加工任务所需的加工插件分别部署在不同的容器中，以解决多插件因版本、编写预言等的不同导致的环境依赖冲突的问题。且通过这样的方式部署多插件以后，支持插件的可能性更多了，可以充分共享GPU资源。例如，参考图5示出了普通的单容器部署多个插件以及多容器部署插件的区别，在图5中，假设中的有3卡GPU，分别部署有AB、CD、EF三组镜像六个加工插件，都是抢占式加工任务(任务谁先到谁先执行，后来的排队等待)；若使用单容器部署这六个插件，则同时段即使CDEF插件没有运行，而AB插件各有两个任务，同一时间也只能运行一个A、B任务；而如果采用本实施例的多容器部署的方式，则任何任务在其它插件没运行时，同时段可以跑三个任务，这对于抢占式任务来说，可以充分提升资源利用率。

另外，本实施例通过调度代理服务管理多加工插件的协同加工处理，在目标容器组中包括主调度容器以及与至少一个插件容器，主调度容器通过主调度代理与插件容器的插件调度代理通信，从而实现了主调度容器与各插件容器的通信，然后由各插件容器的插件调度代理来开启本容器的加工插件，并在开启加工插件时传递加工服务的监听端口的第一端口信息，各加工插件通过该第一端口信息与加工服务直接连接，由加工服务统一管理各加工插件，可以消除多容器都部署后发布时可能版本不一致的问题。

进一步地，本实施例利用共享内存IPC传输帧数据，结合本地网络通信信令的方式，解决了多插件间视频传输的耗时问题，以最低的延时代价实现多插件的低延时云加工。

实施例三

图6为本申请实施例三提供的一种音视频加工的方法实施例的流程图，本实施例在实施例一或实施例二的基础上执行，如果在实施例一的基础上执行，则本实施例可以在实施例一的步骤203之后执行，如果在实施例二的基础上执行，则本实施例可以在实施例一的步骤312之后执行。如下以在步骤312之后执行为例进行说明：

本实施例中的音视频流可以包括多路音视频流，则加工任务还可以包括：一个或多个混流目标。

在上述实施例二的步骤312之后，本实施例还可以包括如下步骤：

步骤313，当加工服务接收到各路音频流中的加工插件标识列表中的最后一个加工插件标识对应的加工插件的加工完成消息时，获取各路音视频流中最后一个加工插件存储的帧数据。

在该步骤中，在多路拉流的场景中，针对每一路音视频流，当采用实施例二的方式进行内容加工以后，加工服务可以根据各路音视频流中最后一个加工插件发送的加工完成消息，获取各路音视频流中最后一个加工插件存储的加工后的帧数据，作为该路视频流的加工结果。

步骤314，对获取的各路帧数据按照所述混流目标进行合并，生成合并帧数据。

在本实施例中，加工任务还可以包括一个或多个混流目标，其中，一个混流目标可以对应合并成一帧合并帧数据。示例性地，混流目标可以包括合并效果，或者混流所需的步骤，例如，一个混流目标可以为，合成图像帧并添加进度条。

在一个实施例中，加工服务直接根据混流目标，对获取的各路帧数据进行合并，生成合并帧数据。

在其他实施例中，加工服务还可以调用混流插件来进行数据合并处理。具体的，混流插件也可以包括一个或多个，与上述实施例二中的加工插件类似，各混流插件也部署在不同的容器的，此处可以称为混流容器，混流容器中包括混流调度代理以及混流插件，加工服务可以经由主调度代理将启动指令发送至需要调用的混流调度代理中，由混流调度代理启动混流插件，并传入加工服务开启的监听端口的端口信息(该端口信息可以与实施例二中的第一端口信息相同，也可以不同，此处不作限定)，混流插件则可以根据该端口信息监听相应的混流事件，接收各路帧数据或从共享内存中获取各路帧数据，进行混流合并处理，最终生成合并帧数据。具体的过程与实施例二中调用插件容器以启动加工插件的过程类似，可以参考实施例二的描述，此处不再赘述了。

步骤315，将所有的合并帧数据编码成目标音视频流，并对所述目标音视频流进行推流处理。

在该步骤中，当加工服务获得合并帧数据以后，可以将所有的合并帧数据编码成目标音视频流，并对目标音视频流进行推流处理。

在一种实施例中，加工任务还可以包括各混流目标对应的后加工插件标识列表，其中，每个后加工插件标识列表可以包括一个或多个加工插件标识。如图7所示，在步骤315之前，本实施例还可以包括如下步骤：

步骤316，依次调用所述后加工插件标识列表中的各加工插件标识对应的插件容器，对所述合并帧数据进行加工处理。

在该实施例中，针对混流后得到的合并帧数据，如果加工任务中存在与混流目标对应的一个或多个后加工插件标识列表，表示需要对该合并帧数据进行后加工处理。

具体的，对于每个后加工插件标识列表，可以依次调用该后加工插件标识列表中的加工插件标识对应的插件容器，对当前合并帧数据进行后加工处理，其后加工处理的过程与实施例二中的插件加工处理的过程类似，可以进行参考，此处不再赘述了。

在一种实施例中，当当前加工任务处理完毕以后，则加工服务可以统一结束所有的插件(包括实施例二中的加工插件、本实施例的混流插件以及后加工的加工插件等)。例如，若在直播场景中，当主播关闭直播以后，客户端会发送结束信令给包含调度服务的普通容器，然后调度服务会将该结束信令发送给主调度容器的主调度代理，主调度代理再将该结束信令发送给加工服务，加工服务收到结束信令后关闭拉流、推流、并发出结束插件的指令给主调度代理，然后由主调度代理将该结束插件的指令分别发送给各插件容器的插件调度代理，由各插件容器的插件调度代理关闭本容器的插件。

在本实施例中，需加工的音视频任务派发进来后，进行拉流、解码、插件加工、混流、插件后加工、编码、推流等一系列音视频流操作后，输出了加工后的音视频流，一条加工流水即可实现多重加工能力，且只需要一次推拉流和编解码的开销，可以更好地降低内容加工产生的延迟。

实施例四

图8为本申请实施例四提供的一种用于进行音视频加工的服务器实施例的结构框图，如图8所示，该服务器包括目标容器组80，所述目标容器组80可以包括主调度容器801以及与所述主调度容器801相连的至少一个插件容器802，所述插件容器802内可以包括对应的加工插件8021；

所述主调度容器801用于接收加工任务，并根据所述加工任务中的待加工的音视频流的标识拉取对应的音视频流，以及，依次调用所述加工任务中的加工插件标识对应的插件容器其中，所述加工任务用于描述对音视频加工所需的加工流程；

所述插件容器802用于在被调用时，启动本容器的加工插件对所述音视频流进行内容加工处理。

在一种实施方式中，如图9所述主调度容器801包括主调度代理8011以及加工服务8012，所述插件容器还包括插件调度代理8022；所述主调度代理8011分别与所述加工服务8012以及各插件容器的插件调度代理8022通信；

所述主调度代理8011用于在接收所述加工任务后，启动所述加工服务，以及将所述加工任务发送至所述加工服务中，并接收所述加工服务发送的启动指令；

所述加工服务8012用于根据所述加工任务开启监听端口，并根据所述监听端口的第一端口信息生成启动指令，将所述启动指令发送至所述主调度代理中；

所述主调度代理8011还用于根据所述启动指令，调用对应的插件容器，以将所述第一端口信息发送至所述插件容器的插件调度代理中；

所述插件调度代理8022用于在接收到所述第一端口信息以后，开启本容器的加工插件，并将所述第一端口信息发送至所述加工插件；

所述加工插件8021用于根据所述第一端口信息监听对应的监听端口，以实现与所述加工服务的通信。

在一种实施方式中，如图9所示，所述服务器还包括共享内存，所述共享内存用于存储所述加工服务与各加工插件通信过程中涉及的帧数据。

本申请实施例所提供的服务器可执行本申请实施例一至实施例三所提供的方法，具备执行方法相应的功能模块和有益效果。

实施例五

图10为本申请实施例五提供的一种音视频加工的装置实施例的结构框图，可以包括如下模块：

任务接收模块1001，用于接收加工任务，所述加工任务用于描述对音视频加工所需的加工流程，所述加工任务至少包括：待加工的音视频流的标识以及加工插件标识列表；

任务发送模块1002，用于将所述加工任务发送至目标容器组中，所述目标容器组包括主调度容器以及至少一个插件容器，所述插件容器内包括对应的加工插件；

内容加工模块1003，用于在所述目标容器组内，由所述主调度容器拉取与所述待加工的音视频流的标识对应的音视频流，并依次调用所述加工插件标识列表中各加工插件标识对应的插件容器，由所述插件容器启动对应的加工插件对所述音视频流进行内容加工处理。

在一种实施方式中，所述主调度容器包括主调度代理以及加工服务，所述内容加工模块1003包括：

加工服务启动子模块，用于当通过所述主调度代理接收到加工任务以后，由所述主调度代理启动所述加工服务，并将所述加工任务发送至所述加工服务；

拉流模块，用于由所述加工服务根据所述加工任务中的待加工的音视频流的标识，拉取对应的音视频流。

在一种实施方式中，所述装置还包括：

解码模块，用于在由所述主调度容器拉取与所述待加工的音视频流的标识对应的音视频流之后，通过所述加工服务将所述音视频流解码成帧数据；

存储模块，用于将所述帧数据存储在共享内存中。

在一种实施方式中，所述插件容器还包括插件调度代理；所述内容加工模块1003包括：

监听端口开启子模块，用于在所述加工服务中开启监听端口，并获取所述监听端口的第一端口信息；

启动指令发送子模块，用于由所述加工服务依次遍历所述加工插件标识列表中的加工插件标识，针对当前的加工插件标识，向所述主调度代理发送启动指令，所述启动指令包括当前的加工插件标识以及所述第一端口信息；

插件容器调用子模块，用于由所述主调度代理根据所述启动指令中的加工插件标识，查找该加工插件标识对应的插件容器的第二端口信息，并根据所述第二端口信息将所述第一端口信息发送至对应的插件容器中；

加工插件启动子模块，用于由所述插件容器通过本容器的插件调度代理接收所述第一端口信息，并启动本容器的加工插件，以及将所述第一端口信息发送至该加工插件中；

加工插件处理子模块，用于由所述加工插件根据所述第一端口信息监听所述监听端口，以实现与所述加工服务的通信，以及，获取待处理的帧数据，并对所述帧数据进行加工处理。

在一种实施方式中，所述加工插件处理子模块包括：

帧数据获取单元，用于从所述加工服务中获取待处理的帧数据的内存偏移量信息；根据所述待处理的帧数据的内存偏移量信息，确定所述待处理的帧数据在共享内存中的存储位置，并从所述存储位置中读取所述帧数据。

在一种实施方式中，所述内容加工模块1003还包括：

加工完成子模块，用于当当前加工插件对所述帧数据加工处理完毕以后，将加工处理完的帧数据存储在共享内存中；向所述加工服务返回加工完成消息，所述加工服务根据所述加工完成消息，继续遍历所述加工插件标识列表中的下一个加工插件标识，以此类推，直到所述加工插件标识列表中的加工插件标识遍历完毕。

在一种实施方式中，所述音视频流包括多路音视频流；所述加工任务还包括：一个或多个混流目标；

所述装置还包括：

多路帧数据获取模块，用于当所述加工服务接收到各路音频流中的加工插件标识列表中的最后一个加工插件标识对应的加工插件的加工完成消息时，获取各路音视频流中最后一个加工插件存储的帧数据；

帧数据合并模块，用于对获取的各路帧数据按照所述混流目标进行合并，生成合并帧数据；

编码推流模块，用于将所有的合并帧数据编码成目标音视频流，并对所述目标音视频流进行推流处理。

在一种实施方式中，所述加工任务还包括：各混流目标对应的后加工插件标识列表；

所述装置还包括：

后加工处理模块，用于在将所有的合并帧数据编码成目标音视频流之前，依次调用所述后加工插件标识列表中的各加工插件标识对应的插件容器，对所述合并帧数据进行加工处理。

在一种实施方式中，所述装置还包括：

资源分配模块，用于在接收加工任务之后，针对所述加工任务，进行资源分配，并根据所述资源分配的结果确定目标加工节点；

目标容器组创建模块，用于在所述目标加工节点中创建目标容器组。

本申请实施例所提供的装置可执行本申请实施例一至实施例三所提供的方法，具备执行方法相应的功能模块和有益效果。

实施例六

图11为本申请实施例六提供的一种服务器的结构示意图，如图11所示，该服务器包括处理器1110、存储器1120、输入装置1130和输出装置1140；服务器中处理器1110的数量可以是一个或多个，图11中以一个处理器1110为例；服务器中的处理器1110、存储器1120、输入装置1130和输出装置1140可以通过总线或其他方式连接，图11中以通过总线连接为例。

存储器1120作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本申请实施例中的上述实施例对应的程序指令/模块。处理器1110通过运行存储在存储器1120中的软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述的方法实施例中提到的方法。

存储器1120可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器1120可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器1120可进一步包括相对于处理器1110远程设置的存储器，这些远程存储器可以通过网络连接至设备/终端/服务器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置1130可用于接收输入的数字或字符信息，以及产生与服务器的用户设置以及功能控制有关的键信号输入。输出装置1140可包括显示屏等显示设备。

实施例七

本申请实施例六还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行上述方法实施例中的方法。

当然，本申请实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的方法操作，还可以执行本申请任意实施例所提供的方法中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本申请可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台电子设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

值得注意的是，上述装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。

注意，上述仅为本申请的较佳实施例及所运用技术原理。本领域技术人员会理解，本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，而本申请的范围由所附的权利要求范围决定。

Claims (14)

1.一种音视频加工的方法，其特征在于，所述方法包括：

接收加工任务，所述加工任务用于描述对音视频加工所需的加工流程，所述加工任务至少包括：待加工的音视频流的标识以及加工插件标识列表；

将所述加工任务发送至目标容器组中，所述目标容器组包括主调度容器以及至少一个插件容器，所述插件容器内包括对应的加工插件；

在所述目标容器组内，由所述主调度容器拉取与所述待加工的音视频流的标识对应的音视频流，并依次调用所述加工插件标识列表中各加工插件标识对应的插件容器，由所述插件容器启动对应的加工插件对所述音视频流进行内容加工处理；

所述主调度容器包括主调度代理以及加工服务，所述由所述主调度容器拉取与所述待加工的音视频流的标识对应的音视频流，包括：

当通过所述主调度代理接收到加工任务以后，由所述主调度代理启动所述加工服务，并将所述加工任务发送至所述加工服务；

由所述加工服务根据所述加工任务中的待加工的音视频流的标识，拉取对应的音视频流。

2.根据权利要求1所述的方法，其特征在于，在所述由所述主调度容器拉取与所述待加工的音视频流的标识对应的音视频流之后，所述方法还包括：

通过所述加工服务将所述音视频流解码成帧数据，以及，将所述帧数据存储在共享内存中。

3.根据权利要求1或2所述的方法，其特征在于，所述插件容器还包括插件调度代理；所述依次调用所述加工插件标识列表中各加工插件标识对应的插件容器，由所述插件容器启动对应的加工插件对所述音视频流进行内容加工处理，包括：

在所述加工服务中开启监听端口，并获取所述监听端口的第一端口信息；

由所述加工服务依次遍历所述加工插件标识列表中的加工插件标识，针对当前的加工插件标识，向所述主调度代理发送启动指令，所述启动指令包括当前的加工插件标识以及所述第一端口信息；

所述主调度代理根据所述启动指令中的加工插件标识，查找该加工插件标识对应的插件容器的第二端口信息，并根据所述第二端口信息将所述第一端口信息发送至对应的插件容器中；

所述插件容器通过本容器的插件调度代理接收所述第一端口信息，并启动本容器的加工插件，以及将所述第一端口信息发送至该加工插件中；

由所述加工插件根据所述第一端口信息监听所述监听端口，以实现与所述加工服务的通信，以及，获取待处理的帧数据，并对所述帧数据进行加工处理。

4.根据权利要求3所述的方法，其特征在于， 所述获取待处理的帧数据，包括：

从所述加工服务中获取待处理的帧数据的内存偏移量信息；

根据所述待处理的帧数据的内存偏移量信息，确定所述待处理的帧数据在共享内存中的存储位置，并从所述存储位置中读取所述帧数据。

5.根据权利要求3所述的方法，其特征在于，所述依次调用所述加工插件标识列表中各加工插件标识对应的插件容器，由所述插件容器启动对应的加工插件对所述音视频流进行内容加工处理，还包括：

当当前加工插件对所述帧数据加工处理完毕以后，将加工处理完的帧数据存储在共享内存中；

向所述加工服务返回加工完成消息，所述加工服务根据所述加工完成消息，继续遍历所述加工插件标识列表中的下一个加工插件标识，以此类推，直到所述加工插件标识列表中的加工插件标识遍历完毕。

6.根据权利要求5所述的方法，其特征在于，所述音视频流包括多路音视频流；所述加工任务还包括：一个或多个混流目标；

在所述依次调用所述加工插件标识列表中各加工插件标识对应的插件容器，由所述插件容器启动对应的加工插件对所述音视频流进行内容加工处理之后，所述方法还包括：

当所述加工服务接收到各路音频流中的加工插件标识列表中的最后一个加工插件标识对应的加工插件的加工完成消息时，获取各路音视频流中最后一个加工插件存储的帧数据；

对获取的各路帧数据按照所述混流目标进行合并，生成合并帧数据；

将所有的合并帧数据编码成目标音视频流，并对所述目标音视频流进行推流处理。

7.根据权利要求6所述的方法，其特征在于，所述加工任务还包括：各混流目标对应的后加工插件标识列表；

在所述将所有的合并帧数据编码成目标音视频流之前，所述方法还包括：

依次调用所述后加工插件标识列表中的各加工插件标识对应的插件容器，对所述合并帧数据进行加工处理。

8.根据权利要求1所述的方法，其特征在于，在所述接收加工任务之后，所述方法还包括：

针对所述加工任务，进行资源分配，并根据所述资源分配的结果确定目标加工节点；

在所述目标加工节点中创建目标容器组。

9.一种用于进行音视频加工的服务器，其特征在于，所述服务器包括目标容器组，所述目标容器组包括主调度容器以及与所述主调度容器相连的至少一个插件容器，所述插件容器内包括对应的加工插件；

所述主调度容器用于接收加工任务，并根据所述加工任务中的待加工的音视频流的标识拉取对应的音视频流，以及，依次调用所述加工任务中的加工插件标识对应的插件容器，其中，所述加工任务用于描述对音视频加工所需的加工流程；

所述插件容器用于在被调用时，启动本容器的加工插件对所述音视频流进行内容加工处理；

其中，所述主调度容器包括主调度代理以及加工服务，所述主调度代理用于在接收所述加工任务后，启动所述加工服务，以及将所述加工任务发送至所述加工服务中；由所述加工服务根据所述加工任务中的待加工的音视频流的标识，拉取对应的音视频流。

10.根据权利要求9所述的服务器，其特征在于，所述插件容器还包括插件调度代理；所述主调度代理分别与所述加工服务以及各插件容器的插件调度代理通信；

所述主调度代理用于在接收所述加工任务后，启动所述加工服务，以及将所述加工任务发送至所述加工服务中，并接收所述加工服务发送的启动指令；

所述加工服务用于根据所述加工任务开启监听端口，并根据所述监听端口的第一端口信息生成启动指令，将所述启动指令发送至所述主调度代理中；

所述主调度代理还用于根据所述启动指令，调用对应的插件容器，以将所述第一端口信息发送至所述插件容器的插件调度代理中；

所述插件调度代理用于在接收到所述第一端口信息以后，开启本容器的加工插件，并将所述第一端口信息发送至所述加工插件；

所述加工插件用于根据所述第一端口信息监听对应的监听端口，以实现与所述加工服务的通信。

11.根据权利要求10所述的服务器，其特征在于，所述服务器还包括共享内存，所述共享内存用于存储所述加工服务与各加工插件通信过程中涉及的帧数据。

12.一种音视频加工的装置，其特征在于，所述装置包括：

任务接收模块，用于接收加工任务，所述加工任务用于描述对音视频加工所需的加工流程，所述加工任务至少包括：待加工的音视频流的标识以及加工插件标识列表；

任务发送模块，用于将所述加工任务发送至目标容器组中，所述目标容器组包括主调度容器以及至少一个插件容器，所述插件容器内包括对应的加工插件；

内容加工模块，用于在所述目标容器组内，由所述主调度容器拉取与所述待加工的音视频流的标识对应的音视频流，并依次调用所述加工插件标识列表中各加工插件标识对应的插件容器，由所述插件容器启动对应的加工插件对所述音视频流进行内容加工处理；

所述内容加工模块包括：

加工服务启动子模块，用于当通过所述主调度代理接收到加工任务以后，由所述主调度代理启动所述加工服务，并将所述加工任务发送至所述加工服务；

拉流模块，用于由所述加工服务根据所述加工任务中的待加工的音视频流的标识，拉取对应的音视频流。

13.一种服务器，其特征在于，所述服务器包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-8任一项所述的方法。

14.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-8任一项所述的方法。

Images